230 likes | 493 Views
&. DNS and IPv6 IPv6 Summit, Canberra 31st October & 1 st November 2005 Chris Wright, Chief Technology Officer. Introduction. Chicken & Egg Problem. Service Providers - need content before migrating users – There has to be a benefit
E N D
& DNS and IPv6 IPv6 Summit, Canberra 31st October & 1st November 2005 Chris Wright, Chief Technology Officer
Chicken & Egg Problem • Service Providers - need content before migrating users – There has to be a benefit • Content providers - need users before they will provide content – They are (generally) businesses • Both parties require top-level infrastructure
IPv6 enabling DNS – 1st Step • Users need DNS to access content in a “user-friendly” manner • Content providers need DNS to direct users to their content • System & Network Administrators need DNS to simplify configuration and management • IPv6 enabling DNS is the first step towards a solution • Need both the ability to access DNS via IPv6 and the ability for IPv6 records to be published in the DNS
IPv6 & The Domain Name System
IPv6 & DNS – Potential Issues • Increased packet size (larger resource records) • Accessibility Issues • Standardised resource records • Maintaining backward compatibility • Increased Database size = increased hardware requirements
Summary of Changes • New Resource Records • Provisioning Changes (Registry) • DNS Extensions (not IPv6 exclusive)
The ‘Quad A’ Record(AAAA) • Similar to ‘A’ Resource Record for IPv4 (RFC3596) • Holds the IPv6 Record for a host • Entered into zone file in standard representation • Backward compatible with (most) non-IPv6 aware resolvers (ignored RR type)
The ‘Reverse Pointer’ Record(PTR) • Not really a ‘new’ resource record (RFC3596) • Zone cuts at the “nibble” boundary (as apposed to the byte boundary with IPv4) • Backward compatible with (most) non-IPv6 aware resolvers (ignored)
The Experimental Records (A6, DNAME) • Enable split records (provider, client) (RFC2672 & RFC2874) • Provide for provider renumbering, independent of client • Require significant protocol changes (not backward compatible – binary fields in RR) • Currently depreciated to “experimental” status by IETF to assess the need (as per RFC3363, RFC3364)
Other Protocol Changes(Potential) • EDNS0 (RFC2671) • Larger UDP packets • Addition of new label types – not backward compatible (necessarily)
DNS software changes • BIND 8 – AAAA Resource records, no native IPv6 transport (patch available) • BIND 9 – All currently defined IPv6 record types, native IPv6 transport • djbns – AAAA RR only, IPv6 transport only with patch • NSD – as per BIND 9
Migration Guidelines(IPv4 & IPv6 mixed environments) • How to transition without affecting availability? • All recursive name servers should be IPv4 only or dual stack hosts • All zones should be served by at least one authoritative IPv4 capable host • Defined in RFC3901
Name Services for the root and GTLD’s(.com, .net etc) • Root – none IPv6 accessible • .com/.net – 2 out of 13 IPv6 accessible • .org/.info – 2 out of 5 IPv6 accessible * These taken from zone files, doesn’t take into account actual number of servers etc. (eg. any-casting)
Glue Records for the gTLD’s(.com, .net etc) • All major gTLD’s support publishing IPv6 glue records. • None enforce any particular rules (as discussed previously)
Name Services for .au and the 2LD’s(.com.au, .net.au etc) • Currently no name services at the ccTLD and the 2LD’s are accessible via IPv6 transport • Migration plans are in place • Expected completion date – 1st half of next year
Glue Records for .au and the 2LD’s(.com.au, .net.au etc) • Currently .au Registry system has full support for IPv6 glue records • AAAA record format is used • Will be implementing full checks and not allowing delegations that violate the recommendations of RFC3901
Creating an IPv6 Test bed in Australia • Need to establish IPv6 backbone so that providers can access DNS via their IPv6 addresses • Encourage use of IPv6 within Australia • Facilitate migration – guaranteed DNS services • IPv6-IPv4 gateways
Thank You Questions?