IETF DNSOP Working Group M. Minda Internet-Draft JPRS Expires: January 18, 2006 July 17, 2005 Using In-Bailiwick Namesevers in .ARPA draft-minda-dnsop-using-in-bailiwick-nameservers-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Many People know that reverse DNS lookup of IN-ADDR.ARAP zone is slow. People supposed to be the case is issue of LAME delegation. But this is not correct. There are two reasons. One is glulessness and the other is BIND 8 on caching nameserver. Most of nameservers in ARPA zone are out-of-bailiwick names and this causes gluelessness This document explains the problem with gluelessness, the problem with old BIND implementations and suggests recommended way to configure nameservers in .ARPA. Minda Expires January 18, 2006 [Page 1] Internet-Draft In-Bailwick Nameservers July 2005 1. Introduction In many cases, reverse DNS lookup is slower than standard DNS lookup. Many people believed that it was caused by the lame delegation. It is true that the lame delegation disturb the retrieval of the DNS lookup. However, even if the nameserver is correctly configured, and lame delegation does not exist, it takes time for the reverse DNS lookup, or reverse DNS lookup can not do. It is because the hostname of nameserver is used the standard name in .ARPA zone. 2. Why is Reverse DNS Lookup slow? Why is Reverse DNS Lookup slow? There is a description in section 2.3 of RFC1912 [4]. 2.3 Glue A Records ..... You shouldn't have any A records in an in-addr.arpa zone file (unless you're using RFC 1101-style encoding of subnet masks). ..... Of course this is correct, but the hostname of nameserver is used the standard name, e.g. "ns.example.net". However, the hostname of nameserver is out of .ARPA zone by using standard name. For this case, nameserver of .ARPA zone can answer the name of nameserver and can not answer the glue of nameserver. When the glue of namesever is not obtained, the caching nameserver is retrieved from root nameserver again. It takes time to repeat the re-retrieval from the root nameserver. 3. BIND 8 issue This section describes the problem of caching nameserver with BIND 8 (including BIND 4), when the glue of namesever is not obtained. 3.1 BIND 8 behavior Caching nameserver with BIND 8 (including BIND 4) have a following issue. 1. In iterative query, BIND 8 starts name server hostname resolution at glueless delegation. 2. But if all name servers are glueless and all IP addresses are unknown (not in cache), BIND 8 stops first iterative query and does not answer anything. Minda Expires January 18, 2006 [Page 2] Internet-Draft In-Bailwick Nameservers July 2005 3. After timeout (5 or 10 sec), stub resolver or application re- tries querying to caching server. 4. Before then, glueless nameserver addresses may be in cache. 5. As a result, name resolution becomes slower for waiting timeouts. (5-30sec) 6. At the second time (and after that) DNS query, the DNS cache works well; therefore the problem has been hided. Caching nameserver with BIND 8 can resolve domain name, however it depends on the re-try query from the client. In this case, name resolution becomes slower. But the effective cache makes it be unaware. So, many people dose not know about this behavior. 3.2 Old BIND 8 behavior The following problem is in BIND 8 up to version 8.2.7 (including BIND 4) in addition to the above-mentioned. Caching nameserver fails in name resolution when it receives the result of query without glue twice continuously. This is very serious issue, because it fails in almost permanent. 4. Improving reverse DNS lookup performance There are two reasons why reverse DNS lookup is slow. o The hostname of nameserver is used the standard name. It cause gluelessness and caching nameserver repeat the re-retrieval from the root nameserver. o Caching nameserver on BIND 8 with glueless issue. If BIND 9 or other implement is used, a latter problem can be solved. However, the problem of the former remains. 4.1 Solve the issue To solve this, glue is surely obtained. In other words, avoid glueless delegation. Use in-bailiwick nameserver in .ARPA, and add glue information to .ARPA zone. For example, case of nameserver with 202.11.16.0/24 (16.11.202.in- addr.arpa.). Currently (standard name) ns01.jprs.co.jp. ns02.jprs.co.jp. In-Bailiwich Nameserver ns01.16.11.202.in-addr.arpa. ns02.16.11.202.in-addr.arpa. Minda Expires January 18, 2006 [Page 3] Internet-Draft In-Bailwick Nameservers July 2005 And add glue record to "11.202.in-addr.arpa." zone. 4.2 In-Bailiwick Nameserver's benefit There are many benefits in using in-bailiwick nameserver. o Decrease resolving cost o Decrease resolving time o Evasion of BIND 8 issue o Remove a dependency of TLD's DNS tree The last item invents more benefits. It makes easy to troubleshoot with DNS. In ENUM, using in-bailiwick nameserver with "e164.arpa" zone is very useful to resolving. In DNSSEC, using in-bailiwick nameserver with DNSSEC is much reduce the cost of verify on caching nameserver and is easy to deploy the DNSSEC on part of DNS tree. 4.3 Required changes It is necessary to change an existing system for using in-bailiwick nameserver. Registration system on RIR, NIR and LIR should change to accept in- bailiwick nameserver and to accept glue A or AAAA RR. Of course, reverse DNS registration policy should change. And user's DNS configuration should change. 5. In-Bailiwick Nameserver's disadvantage There are several disadvantages or worries with in-bailiwick nameserver. The nameserver of RIR, NIR and LIR should have a lot of names. For example, 193.0.0.193 have currently "ns.ripe.net.". But with in- bailiwick nameserver, 193.0.0.193 have ripe.58.in-addr.arpa. ripe.59.in-addr.arpa. ripe.60.in-addr.arpa. ripe.61.in-addr.arpa. ripe.124.in-addr.arpa. ripe.125.in-addr.arpa. ..... A lot of names with one IP address is technically unquestionable. However, it is easy to cause a human error to have to manage a lot of names with glue. The caching effect might weaken. One nameserver has one name, caching nameserver has to remember only one name. If one nameserver has a lot of names, caching nameserver has to remember a lot of Minda Expires January 18, 2006 [Page 4] Internet-Draft In-Bailwick Nameservers July 2005 names. The DNS traffic might increase according to the condition. 6. Conclusion In-bailiwick nameserver also has a lot of advantages, and has the disadvantage. The author's recomendation. o The nameserver of RIR, NIR or LIR SHOULD use in-bailiwick nameserver. o The nameserver of end user MAY use in-bailiwick nameserver. It applies to not only .ARPA zone but also general zone. 7. Future Work If it is possible, it is necessary to investigate the effect of cache with in-bailiwick nameserver. 8. Acknowledgment The author expresses gratitude to Kazunori Fujiwara and the person present of dns-wg at RIPE50 to give a valuable opinion. 9. References [1] Minda, M., "Using In-Bailiwick Namesevers in .ARPA", May 2005, < http://www.ripe.net/ripe/meetings/ripe-50/presentations/ ripe50-dns-in-bailiwick.pdf>. [2] Fujiwara, K., "Improving reverse DNS lookup performance", Feb 2005, . [3] Minda, M., "Using In-Bailiwick Namesevers", Feb 2005, . [4] Baar, D., "Common DNS Operational and Configuration Errors", RFC 1912, Feb 1996. Minda Expires January 18, 2006 [Page 5] Internet-Draft In-Bailwick Nameservers July 2005 Author's Address Masato Minda Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Email: minmin@jprs.co.jp URI: http://jprs.co.jp/ Minda Expires January 18, 2006 [Page 6] Internet-Draft In-Bailwick Nameservers July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Minda Expires January 18, 2006 [Page 7]