IETF 90 Part 2: IPv6 reverse DNS [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
ARIN Advisory Council member, Cathy Aronson, shares some of her thoughts on IPv6 reverse DNS from IETF 90 in Toronto, Ontario, Canada last week.
Some thoughts on IPv6 reverse DNS.
Lee Howard was speaking in the Sunset4 working group at IETF 90. He mentioned something that got me thinking. I have often discussed in my talks problems in IPv6 that were unanticipated. A lot of these problems are unintended consequences of very large subnet sizes. Some problems are outlined in RFC 6583.
Lee mentioned another interesting problem, reverse DNS. Best practice [RFC1033] says that every Internet-reachable host should have a name (per RFC 1912) that is recorded with a PTR record in the .arpa zone. It also says that the PTR and the A record must match.
So in IPv4 for a network block like 192.0.2.0/24 the entries would be in the form
1.2.0.192.IN-ADDR-ARPA. IN PTR 1.user.anytown.AW.example.com.
2.2.0.192.IN-ADDR-ARPA. IN PTR 1.user.anytown.AW.example.com.
The corresponding A records would be
1.user.anytown.AW.example.com. IN A 192.0.2.1
2.user.anytown.AW.example.com. IN A 192.0.2.2
So imagine an IPv6 /48.
A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a would be be:
a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA. IN PTR 1.user.anytown.AW.example.com.
“Since 2^^80 possible addresses could be configured in the 2001:db8:f00/48 zone alone, it is impractical to write a zone with every possible address entered. If 1000 entries could be written per second, the zone would still not be complete after 38 trillion years."
It is also the case that addresses are assigned dynamically out of these huge address ranges and so it may be difficult to determine the address ahead of time.
The document outlines several solutions all of which have problems. For detailed information about the solutions please consult the document.
In my opinion it may be time to take another look at this practice and see if requiring forward and reverse match is still necessary. There are applications which depend on this and it’s not entirely clear that it is really needed any more.
I have asked some folks what is being done about this on networks today. I was told that most residential service providers are simply not providing reverse DNS for their IPv6 customers. Other service providers will delegate the reverse zone to the customer upon request and some provide a web portal for the customer to manage their own reverse. Yet others generate the in-addr on demand. So they perform the equivalent of $GENERATE but instead of storing all the generated responses in memory they generate the record when the request is received and respond with the generated record that is then discarded. Another provider I talked to is planning on returning NXDomain (non-existent domain) when queried for the reverse.
Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.