Internet DRAFT - draft-minda-dnsop-using-in-bailiwick-nameservers
draft-minda-dnsop-using-in-bailiwick-nameservers
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, <http://www.apnic.net/meetings/19/docs/sigs/dns/
dns-pres-fujiwara-improving-revdns.pdf>.
[3] Minda, M., "Using In-Bailiwick Namesevers", Feb 2005,
<http://www.nanog.org/mtg-0501/pdf/minda.pdf>.
[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]
