Hi, Can I also add we have some discussion on this issue in the (now obsolete) draft draft-ietf-dnsop-dontpublish-unreachable-03, which can be found at:
http://www.watersprings.org/pub/id/draft-ietf-dnsop-dontpublish-unreachable-03.txt After Washington IETF, a couple of us (at least myself and Alain) discussed taking this one up. One important issue is who is harmed by such publishing beyond the site advertising and sites connecting to it. What is the 3rd party impact? The above text mentions ambiguity as the key concern foor private addresses, but also talks about otehr types on unreachables. Regarding lack of uniqueness, if we cannot assume that CA ULAs are unique, then should we bother with them at all? :) Mark's mail suggests lack of such a guarantee is an issue, but that is only for non-CA prefixes, where people will be tempted to use the minimal prefix, i.e. all 0s most likely instead of a random 40 or 41 bit number (whichever it is :), because they will have to type these addresses in on an operational basis. Tim On Fri, Dec 03, 2004 at 03:27:41PM +1100, Mark Andrews wrote: > > > The section deals with how ULA's interact with the DNS. > > This sort of detail needs to be there otherwise it will not > > be read. One can argue whether auto configuring nameservers > > needs to be there but the gist of the rest does. > > Some text. > > Changing the NS records to point to BLACKHOLE-1.IANA.ORG > and BLACKHOLE-2.IANA.ORG is one possible change for the > example zones. > > --- draft-ietf-ipv6-unique-local-addr-08.txt Mon Nov 29 23:58:52 2004 > +++ draft-ietf-ipv6-unique-local-addr-08.txt.new Fri Dec 3 15:22:43 2004 > @@ -469,19 +469,51 @@ > > 4.4 DNS Issues > > - At the present time AAAA and PTR records for locally assigned local > - IPv6 addresses are not recommended to be installed in the global DNS. > - The operational issues relating to this are beyond the scope of this > - document. > - > - For background on this recommendation, the concern about adding AAAA > - and PTR records to the global DNS for locally assigned local IPv6 > - addresses stems from the lack of complete assurance that the prefixes > - are unique. There is a small possibility that the same PTR record > - might be registered by two different organizations. Due to this > - concern, adding AAAA records is thought to be unwise because matching > - PTR records can not be registered > + Sites using ULAs need to ensure that reverse DNS queries for ULAs do not > + leak out of the site(s) using the ULAa. This is best ensured by > + configuring the sites DNS servers to serve both C.F.IP6.ARPA and > + D.F.IP6.ARPA in addition to anymore specific zones under these used for > + local reverse lookups. > > + Leaking reverse queries will put extreme loads on the infrastructure > + servers and has in the past required sacrificial servers to be > + deployed to absorb the load cause by leaking queries. > + > + e.g. > + The following "empty" zones will prevent queries leaking from the > + zone. > + > + C.F.IP6.ARPA: > + C.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. <contact-address>. ( > + 1 7200 3600 604800 3600 ) > + C.F.IP6.ARPA. 3600 IN NS C.F.IP6.ARPA. > + C.F.IP6.ARPA. 3600 IN TXT Generated as per RFCXXXX > + C.F.IP6.ARPA. 3600 IN NS ::1 > + > + D.F.IP6.ARPA: > + D.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. <contact-address>. ( > + 1 7200 3600 604800 3600 ) > + D.F.IP6.ARPA. 3600 IN NS D.F.IP6.ARPA. > + D.F.IP6.ARPA. 3600 IN TXT Generated as per RFCXXXX > + C.F.IP6.ARPA. 3600 IN NS ::1 > + > + Multiple sites connecting using ULAs may want maintain common > + C.F.IP6.ARPA and D.F.IP6.ARPA zones and use them delegate more specific > + zones. It is not expected that centrally addresses will have delegations > + in the global DNS tree. > + > + Advertising locally assigned ULA AAAA records in the global DNS is > + MUST NOT occur as they are not globally unique and will lead > + to unexpected connections. > + > + Advertising centrally assigned ULA AAAA records in the global DNS is > + not encouraged at this point in time as not all applications recover > + well from attempting to reach a non-reachable addresses. > + > + Populating the reverse zones with appropriate PTR records is at the > + site's disgression. One should note that many applications will not > + accept a PTR record without the associated AAAA record also being > + available. Supplying this may require a split DNS configuration. > > 4.5 Application and Higher Level Protocol Issues > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
