> From: Bruce Campbell <[EMAIL PROTECTED]> > > > http://www.apnic.net/meetings/19/docs/sigs/dns/dns-pres-fujiwara-improving-revdns.pdf > > > This talks about (re-)introducing A records to the reverse map. > > This requires RFC1912 Section 2.3 "Glue A Records" update. > > Common interpretation (based on the examples) is that 'thalt shalt not > have out-of-bailiwick A records in in-addr.arpa zones', leaving the > possibility of having in-bailiwick A records within the zones open. > > From a Registry POV, allowing in-bailiwick glue adds the requirement of > keeping track of the IP addresses used; whilst it is clearly the > responsibility of the child to keep the parent informed about changes, > most people simple do not think about these things until breakage occurs, > with the finger of blame being pointed at the parent for not supporting > the do-what-I-want-not-what-I-say interface correctly.
In my opinion, as long as it is possible, it is good to reduce glueless delegations. Current reverse DNS tree has three or four delegation point, IANA to RIRs, (RIRs to NIRs,) NIRs to LIRs, LIRs to LIR's customers. Using in-bailiwick A record may cause an error for most people, but IANA, RIRs, NIRs (, LIRs) can use in-bailiwick A records correctly. Using in-bailiwick A record in one delegation saves at least three DNS queries for out-bailiwick A resolving (root, .NET, RIRs server). Step by step implementation is possible and effective. And more, there are many people who want to register in-bailiwick A record in reverse DNS tree. In DNSSEC, In my opinion, end host should verify and be full resolving. Then DNS cache effeciency may become low, glueless delegation resolving cost will become higher. -- Fujiwara, Kazunori JPRS . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
