IETF 90 Part 2: IPv6 reverse DNS

IETF 90 Part 2: IPv6 reverse DNS

By Cathy Aronson – ARIN AC Member

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.

Post written by:

Cathy Aronson
ARIN AC Member

Cathy Aronson has been an active ARIN participant since 1998. Cathy was also on the original ASO Address Council.  Cathy acts as an advocate for address policy by volunteering to do many presentations to get involvement of other communities such as NANOG.  She feels that cross pollination of ARIN with other RIRs as well as ARIN with other networking groups is essential to making good address policy. Cathy was most recently a network engineer at Cascadeo Corporation where she helped manage addressing and routing for a number of clients.

Previously, Cathy was a member of the technical staff at Packet Design, where she was responsible for operational aspects of their Internet scaling projects. Earlier Cathy was at the @Home Network where she was responsible for routing and IP addressing. She began her career at Merit, Inc. where she worked on the NSFNET Backbone. Cathy designed and implemented the OSI/CLNP for the Energy Sciences Network. Although OSI/CLNP was never widely deployed, the experience has given greater insight into addressing and scaling issues. Cathy joined the Advisory Council in June 1998 first serving an interim six-month term before being re-elected later that year to a three-year term. She was re-elected to the AC in 2001, 2004, 2007, 2010, and 2013. Her term expires 31 December 2016.

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.

Recent blogs categorized under: Outreach

GET THE LATEST!  

Sign up to receive the latest news about ARIN and the most pressing issues facing the Internet community.

SIGN ME UP →

Blog Categories

IPv6 •  Public Policy •  Caribbean •  Updates •  Grant Program •  Customer Feedback •  ARIN Bits •  Fellowship Program •  Tips •  Internet Governance •  IPv4 •  Security •  Outreach •  Elections •  RPKI •  Training •  IRR •  Data Accuracy

 

Twitter