Will IPv6 kill double-reverse lookups?
vixie at sa.vix.com
Thu Nov 4 18:47:02 UTC 2004
David Carmean <dlc-bu at halibut.com> writes:
> Presuming that a party/organization wants to limit "information leakage"
> by maintaining a split DNS system, and presuming that they choose to cater
> to the dubious practice of double-reverse-lookups a-la TCP Wrappers and
> others, with IPv4 it is easy enough to fill the "outside" in-addr.arpa
> and forward zones with generic hostnames with matching PTR and A records.
> NAT makes this even easier.
> IPv6 makes this monumentally impractical, if not technically infeasible.
> With typical firewall policies, not only will we not have NAT or ALGs to
> limit the range of source addresses visible outside to a single "subnet"
> (and therefor a single zone), EUI-64 host address autoconfiguration and
> RFC-3041 address privacy extensions mean that 2^65 (forward and reverse)
> entries would have to be preconfigured.
not really. in ipv4, ddns/dhcp interaction requires that the host tell the
dhcp server its name so that the dhcp server can do a dns dynamic update to
install a PTR RR. the host performs a dns dynamic update to install an A RR,
or can signal to the dhcp server that it ought to do this (assuming that the
dhcp server has update privileges in the "forward" zone, which is unlikely.)
(isc's dhcp client and server implementations support this logic, i think.)
after some early experience with ipv6 deployment, a number of communities
are switching from EUI64 to either dhcp6 or static addressing. my personal
server is 2001:4f8:3:bb::1 and the PTR was set-once-and-forget-about. isc's
dhcp server does not currently support dhcp6 but there has been some interest
in it and if funding appears, we'll be supporting dhcp6 including dhcp6/ddns
interaction just as we do in ipv4.
of course, any EUI64 client can already do ddns using the "nsupdate" shell
level tool. access control could be as course-grained as "allow anyone who
can do a tcp 3-way handshake from that LAN's address space to update any
records in that LAN's PTR space" or as fine grained as per-client TSIG, or
some kind of middle ground like per-LAN TSIG. there's been some interest in
adding a BIND9 ACL of the form "let an initiator update the PTR pertaining to
its tcp source address, and let it update the A/AAAA RRs in some zone if the
final A or AAAA is the same as the tcp transport address" but nothing firm
has come out of those discussions.
> I was going to ask here if the BIND developers had thought about a feature
> to synthesize matching ip6.arpa and forward record sets to satisfy TCP
> Wrappers and the like, but then I began to wonder whether this problem
> will serve as an agitator to get people to stop fooling themselves into
> using DNS for endpoint authentication/authorization.
tcp wrappers trap a lot of low-end noise, even in november 2004. i don't
expect folks to stop using them, or demanding that PTRs and AAAAs "match"
in an ipv6 world. the fact that they won't stop a determined attacker does
not make them useless, either in my opinion, or in the commonly held view.
therefore, some kind of static assignment, or dhcp6/ddns, or eui64/ddns, is
going to be required. now we just need some technology and BCPs on the topic.
> What are those of you (all five of you, maybe?) with more than a handful
> of deployed IPv6 nodes doing about this question?
here's an example:
@ IN SOA ns-int.isc.org. hostmaster.isc.org. (
2004102900 ; serial
8H ; refresh
30M ; retry
4w2d ; expiry
1H ) ; minimum
; (published ISC servers - lo0 aliases)
184.108.40.206 PTR f1.sql1.isc.org.
220.127.116.11 PTR f2.sql1.isc.org.
18.104.22.168 PTR cvs.isc.org.
22.214.171.124 PTR internal.isc.org.
126.96.36.199 PTR external.isc.org.
188.8.131.52 PTR jabber.isc.org.
184.108.40.206 PTR d.dns.br. ; fneves@
220.127.116.11 PTR d.ext.nic.fr. ; nic.fr
18.104.22.168 PTR res2.sql1.isc.org.
a.0.0.0 PTR collect.isc.org.
b.0.0.0 PTR bindforum.isc.org.
c.0.0.0 PTR news.isc.org.
d.0.0.0 PTR www.isc.org.
e.0.0.0 PTR freebsd.isc.org.
f.0.0.0 PTR nic-af.isc.org.
0.1.0.0 PTR res1.sql1.isc.org.
22.214.171.124 PTR res1.sfo2.isc.org.
126.96.36.199 PTR res1.pao1.isc.org.
188.8.131.52 PTR ns-ext.isc.org.
184.108.40.206 PTR f.6to4-servers.net.
220.127.116.11 PTR ns-int.isc.org.
18.104.22.168 PTR ns.tech.org.
22.214.171.124 PTR sanog.isc.org.
126.96.36.199 PTR ftp.isc.org.
188.8.131.52 PTR crypto-publish.isc.org.
a.1.0.0 PTR oarc.isc.org.
b.1.0.0 PTR idn.isc.org.
c.1.0.0 PTR mx-1.isc.org.
d.1.0.0 PTR mx-2.isc.org.
e.1.0.0 PTR mirrors.isc.org.
f.1.0.0 PTR mozilla.isc.org.
0.2.0.0 PTR demo.oarc.isc.org.
184.108.40.206 PTR monitor.isc.org.
220.127.116.11 PTR ntp.isc.org.
18.104.22.168 PTR ntp2.ntp.isc.org.
More information about the bind-users