Will IPv6 kill double-reverse lookups?

[Paul Vixie]

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