Will IPv6 kill double-reverse lookups?
Paul Vixie
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:
$ORIGIN 8.f.4.0.1.0.0.2.ip6.arpa.
$TTL 2H
@ IN SOA ns-int.isc.org. hostmaster.isc.org. (
2004102900 ; serial
8H ; refresh
30M ; retry
4w2d ; expiry
1H ) ; minimum
NS ns-ext.vix.com.
NS ns-ext.isc.org.
NS ns.ripe.net.
NS ns-int.isc.org.
...
; (published ISC servers - lo0 aliases)
$ORIGIN 0.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa.
$ORIGIN 2.0.0.0
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0
1.0.0.0 PTR f1.sql1.isc.org.
2.0.0.0 PTR f2.sql1.isc.org.
3.0.0.0 PTR cvs.isc.org.
4.0.0.0 PTR internal.isc.org.
5.0.0.0 PTR external.isc.org.
6.0.0.0 PTR jabber.isc.org.
7.0.0.0 PTR d.dns.br. ; fneves@
8.0.0.0 PTR d.ext.nic.fr. ; nic.fr
9.0.0.0 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.
1.1.0.0 PTR res1.sfo2.isc.org.
2.1.0.0 PTR res1.pao1.isc.org.
3.1.0.0 PTR ns-ext.isc.org.
4.1.0.0 PTR f.6to4-servers.net.
5.1.0.0 PTR ns-int.isc.org.
6.1.0.0 PTR ns.tech.org.
7.1.0.0 PTR sanog.isc.org.
8.1.0.0 PTR ftp.isc.org.
9.1.0.0 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.
1.2.0.0 PTR monitor.isc.org.
2.2.0.0 PTR ntp.isc.org.
3.2.0.0 PTR ntp2.ntp.isc.org.
--
Paul Vixie
More information about the bind-users
mailing list