1 / 11

IPv6 DNS issues

IPv6 DNS issues. draft-ietf-dnsop-ipv6-dns-issues-00.txt Alain.Durand@sun.com. Draft objective. Accepted as wg document last meeting Document IPv6 related issues Proposed operational recommendations Candidate for BCP or Informational. Name space continuity.

francesca-murphy
Download Presentation

IPv6 DNS issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPv6 DNS issues draft-ietf-dnsop-ipv6-dns-issues-00.txt Alain.Durand@sun.com

  2. Draft objective • Accepted as wg document last meeting • Document IPv6 related issues • Proposed operational recommendations • Candidate for BCP or Informational

  3. Name space continuity • Every recursive DNS server SHOULD be either IPv4-only or dual stack. • Every single DNS zone SHOULD be served by at least one IPv4 reachable DNS server • This recommendation could be revisited if/when translation techniques between IPv4 & IPv6 are deployed.

  4. Local scope addresses • Link local addresses SHOULD NOT be published in the DNS. • Site local addresses SHOULD NOT be published in the public DNS. They MAY be published in a site view of the DNS if two-face DNS is deployed. • Question: • Can we recommend to put SL in the .local.arpa (or .site.arpa) zone?

  5. SL & Reverse path DNS • Site local addresses SHOULD NOT be populated in the public reverse tree. If two-face DNS is deployed, site local addresses MAY be populated in the local view of reverse tree.

  6. RFC3041 & Reverse path DNS • RFC3041 (privacy extension) addresses SHOULD NOT be published in reverse path DNS

  7. 6to4 & Reverse path DNS (unresolved) • draft-moore-6to4-dns-03.txt • draft-ymbk-…. • ? Rfc1101 trick (see later)

  8. “pre-populating” Reverse path DNS(unresolved) • Widespread current practice for ISP serving home customers • 2 reasons: • letting the customer manage the tree • Don’t want to answer calls when something goes wrong because of the absence of a PTR • The size of v6 address space does not allow this practice any more

  9. Pre-populating: solutions • Wildcard entry • Several people are uneasy with wildcard in general • DNS record synthesis (reverse & forward tree) • may affect DNSsec • RFC1101 trick (not in the draft)

  10. RFC1101 “trick”(last resort when no PTR has been found) • Network admin configures PTR & AAAA for network name as in RFC1101 • getaddrinfo(): • If PTR exist, returns it • If not, zero the interface ID and ask a PTR • Return string: $InterfaceID “+” $NetName • getnameinfo(): • If AAAA exist, returns it • If not and syntax $InterfaceID “+” $NetName, get AAAA for NetName and paste $IntefaceID

  11. Possible extensions • Repeat trick at /48 boundary: • $InterfaceID “+” $SubnetID “+” $PrefixName • Use it for 6to4 • $InterfaceID “+” $SubnetID “+6to4+”PTR(IPv4 underlying address)

More Related