lame delegation work
Mark Kosters
markk at netsol.com
Mon Apr 8 14:09:48 EDT 2002
Hi
WRT this morning's interesting lame delegation discussion, I'd thought I
would resurrect the InterNIC's lame delegation policy attempt that
Tom Newell and I wrote in '96. Unfortunately, we never achieved any
consensus on this so it was not implemented.
Hopefully, this could be useful input as the policy discussion moves
forward.
Regards,
Mark
--
Mark Kosters markk at netsol.com Verisign Applied Research
-------------- next part --------------
[ URL ftp://rs.internic.net/policy/internic/internic-domain-5.txt ] [ 07/96 ]
========================================================================
The InterNIC Lame Delegation Policy - DRAFT
Table of Contents
I. Introduction
II. The Lame Delegation Detection and Notification Process
III. Correction Procedures
Appendix A (What Is Lame Delegation?)
Appendix B (How Can I See If The Server Is "lame"?)
Appendix C (DNS Bibliography)
========================================================================
I. Introduction
Effective October 1, 1996, the InterNIC will implement a more
restrictive registration process that verifies authoritative responses
from registered name servers. This document details how InterNIC will
deal with name registrations whose name server does not answer
authoritatively for the domain which is listed in the parent registry.
Lame delegations (names registered without correct primary or secondary
name-service) result in the propagation of false DNS information and
place a significant burden on the DNS system. Further, listing name
servers that do not answer authoritatively for a particular domain means
that users cannot find out more information about names within that zone
of authority and results in host lookup failure, loss of mail, and other
problems. Additionally, the condition places a significant burden on the
administrators of "falsely" identified name servers.
The InterNIC is not interested in "policing" the Internet to determine
to what use a name is put. However, the InterNIC does have a
responsibility to maintain accurate DNS information and to prevent the
distribution of false data to the root name servers.
Appendix A describes "Lame Delegation" in more detail and includes
a discussion of the effect Lame Delegation has on all Internet users.
Appendix B describes how to detect "Lame Delegation."
Appendix C provides a concise bibliography for a more detailed
examination of DNS.
II. The "Lame" Detection and Notification Process
The InterNIC has considered two possible methods for determining whether
name servers are operational for a requested name: before the
registration takes place or after registration is completed. Each
scenario presents potential problems:
Pre-registration considerations:
A) An applicant faces the risk of completing the name server
configuration work only to find at the time of name registration that
the name has already been requested.
B) At the time of registration, the name server may not be reachable
or otherwise available due to the name server being down or because of
transient network conditions.
Post-registration considerations:
A) The name server may not yet be configured and thus the InterNIC
propagates "false" DNS information.
B) The name server may not yet be attached to the Internet.
The InterNIC has experimented with both methods and has had more success
with routine post-registration checking. Therefore, the InterNIC will
implement the Lame Delegation policy as follows:
1) After receipt/processing of a name registration template, and at
random intervals thereafter, the InterNIC will perform a DNS query via
UDP Port 53 on domain names for an SOA response for the name being
registered.
2) If the query of the domain name returns a non-authoritative
response from all the listed name servers, the query will be repeated
four times over the next 30 days at random intervals approximately 7
days apart, with notification to all listed whois and nameserver
contacts of the possible pending deletion. If at least one server
answers correctly, but one or more are lame, FYI notifications will be
sent to all contacts and checking will be discontinued. Additionally,
e-mail notices will be provided to the contact for the name servers
holding the delegation to alert them to the "lame" condition.
Notifications will state explicitly the consequences of not correcting
the "lame" condition and will be assigned a descriptive subject as
follows:
Subject: Lame Delegation Notice: DOMAIN_NAME
The notification will include a timestamp for when the query
was performed.
3) If, following 30 days, the name servers still provide no
SOA response, the name will be placed in a "hold" status and the DNS
information will no longer be propagated. The administrative contact
will be notified by postal mail and all whois contacts will be notified
by e-mail, with instructions for taking corrective action.
4) Following 60 days in a "hold" status, the name will be deleted
and made available for reregistration. Notification of the final
deletion will be sent to the name server and domain name contacts listed
in the NIC database.
III. Correction Procedures
1) The lame condition may be caused by any number of problems,
including transient outages, a misconfigured name server, or a
deliberately inactive name that is being reserved for later use.
Contact your Internet service provider or Technical Contact for
assistance.
2) Once the lame condition has been corrected, notify the
InterNIC by submitting a "modify" domain name template indicating in the
"purpose" section that the condition has been corrected. Please include
all information in items 7 and 8 as well.
3) After InterNIC receives notification that the lame condition
has been corrected, a DNS query via UDP Port 53 will be performed to
verify that the name server provides an authoritative response. If it
does, the name will be removed from the lame delegation notification
cycle; if it does not, the name will remain in the notification cycle.
In summary, this policy proposes that domain names marked as "Lame
Delegations" be put on hold for 60 days if for any 30 day period they
fail to provide authoritative name-service. While to those not familiar
with DNS this may seem punitive, if a domain name has no name-service,
it provides no functionality and cannot be reached by any Internet
service. During this period, should the name-holder correct the
problem, they may simply contact the InterNIC and the name information
will again be propagated to the root name servers presuming
authoritative servers answer in accordance with this policy. Although
new applicants may sometimes experience delays in finding a service
provider, or installing their own name servers, 90 days is a reasonable
period for the contracting of such service.
========================================================================
Appendix A (What is "Lame Delegation"?)
In it's early days, the Internet relied upon a centrally
administered table that mapped host names to IP addresses. As
the number of Internet hosts grew, it quickly became apparent
that this centrally-maintained table was an administrative
burden and prone to errors. In response to this problem, the
domain name system was developed as a scaleable solution which
hierarchically distributed host naming information to the
administrators within the respective local domains. This
delegation was achieved by creating pointers to the name servers
that performed for that delegation level. For example, the root
authority "." has delegated the us domain, ".us" to isi.edu to
administer and to further delegate.
The InterNIC is the delegation authority for the root domain,
the three-letter Top-level domains (com, edu, org, net, and
gov), and the root domain for reverse-lookups
(in-addr.arpa). The InterNIC will register for each delegation,
the current holder of that particular domain name, its corporate
name and postal address, both technical and administrative
contacts for that particular delegation, and the domain servers
(up to seven). In the past, the registration process has been an
informal affair where anyone who desired a domain name was able
to fill out a template and send it to the InterNIC to be
registered. Spot checks have been done in the past to make sure
the name servers answered for the requested domain but as the
number of registrations grew, it became an increasingly resource
intensive process, resulting in delayed registrations. As a
result, authoritative name service has not been verified for all
registered names.
With domain name registrations growing at an exponential rate,
the InterNIC has sought to automate every process possible in
the domain registration cycle. In the past, an authoritative
answer from both the primary and secondary name-service was not
required at the time of the domain submission. As a result, in
a number of instances, administrators of name servers have found
that without their knowledge, name registrations have been
delegated, "pointing" towards their service without
authorization. Obviously, without further data provided to that
service, the name servers would be incapable of answering DNS
queries, however, even a negative response to queries places a
burden on systems. As a result, the InterNIC proposes a more
restrictive stance, automating the process whereby name-service is
verified for domain name
applications. We will now reject submissions at the time of
receipt if registration constitutes "Lame Delegation". "Lame
Delegation" is the condition whereby a name-space is delegated to
an entity but that entity will not answer to that name. This can
occur under the following conditions:
None of the listed servers are reachable.
The server is reachable but does not answer to DNS
queries.
The listed server is reachable but does not answer
authoritatively with an SOA record for the name.
Simply put, "Lame Delegation" is bad because:
- it increases the burden on the root name servers which causes
ALL domain names to be resolved at a slower rate.
- Internet service providers who have their servers listed by
users who are not customers are burdened unfairly. The result
can be decreased performance of name server machines,
dissatisfied/confused customers who cannot understand why an
application may not be functioning (non-resolving URL's), or
wasted time and resources spent tracking unauthorized use
of system resources.
- It serves as an unintended "reservation" mechanism for
domain names.
The Domain Name System FAQ offers the following more technical
examination of "Lame Delegation". It is available at the URL:
ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq/
Q: What is "Lame Delegation"?
A: Two things are required for a "Lame Delegation":
1) A name server X is delegated as authoritative for a zone.
2) name server X is not performing name-service for that zone.
Try to think of a "Lame Delegation" as a long-term condition, brought
about by a misconfiguration somewhere. Bryan Beecher's 1992 LISA
paper on "Lame Delegations" is good to read on this. The problem
really lies in misconfigured name servers, not "lameness" brought
about by transient outages. The latter is common on the Internet
and hard to avoid, while the former is correctable.
In order to be performing name-service for a zone, it must have
(presumed correct) data for that zone, and it must be answering
authoritatively to resolver queries for that zone. (The AA bit is
set in the flags section)
The "classic" "Lame Delegation" case is when name server X is
delegated
as authoritative for domain Y, yet when you ask Y about X, it
returns non-authoritative data.
Here's an example that shows what happens most often (using dig,
dnswalk, and doc to find).
Let's say the domain bogus.com gets registered at the NIC and they
have listed 3 name servers, both from their *upstream* provider:
bogus.com IN NS ns.bogus.com
bogus.com IN NS upstream.com
bogus.com IN NS upstream1.com
So the root servers have this info. But when the admins at
bogus.com actually set up their zone files they put something like:
bogus.com IN NS upstream.com
bogus.com IN NS upstream1.com
So your name server may have the name server info cached (which it
may have gotten from the root). The root says "go ask ns.bogus.com"
since they are authoritative.
This is usually from names being registered at the NIC (either
nic.ddn.mil or rs.internic.net), and then updated later, but the
folks who make the updates later never let the folks at the NIC know
about it.
========================================================================
=
Appendix B (How Can I See If The Server Is "lame" ?)
You can check things manually with either "nslookup", "dig", or
current versions of "host."
nslookup - distributed on most UNIX systems.
dig - freely available
(ftp://ftp.is.co.za/networking/ip/dns/dig/).
This tool is preferred over nslookup.
host - freely available
(ftp://ftp.is.co.za/networking/ip/dns/host/).
To check with nslookup for example.com with the name server being
venera.isi.edu:
nslookup
> server venera.isi.edu
> set type=any
> example.com.
If the answer comes back marked as "Non-authoritative answer" and
venera.isi.edu is listed in the "Authoritative answers can be found
from:"
section, then this is a "Lame Delegation". Your name server is listed
as an
authoritative name server, but is not returning authoritative data.
To check with "dig" for the domain example.com and the name server being
venera.isi.edu:
dig @venera.isi.edu example.com. any
If you do not receive an SOA resource record for example.com, then
this
is a "Lame Delegation."
There are also two tools we recommend that actively check for "Lame
Delegations" - "doc" and "dnswalk." They are included in the most
recent
distribution of bind:
ftp://ftp.vix.com/pub/bind/release/bind-4.9.3-REL.tar.gz
The "lamers" script that is included as part of the above release
can also actively check for "Lame Delegation." It parses the "Lame
Delegation"
notices from BIND's syslog and produces a summary report.
========================================================================
=
Appendix C (DNS Bibliography)
DNS Resources Directory (Maintained by andras at is.co.za)
http://www.dns.net/dnsrd/docs/
comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ)
Part 1
ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-
faq/part1
Part 2
ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-
faq/part2
DNS and BIND
October 1992, Reprint March 1993 with minor corrections.
Paul Albitz and Cricket Liu
Publisher: O'Reilly & Associates
ISBN: 1-56592-010-4
TCP/IP Network Administration
August 1992, Reprint January 1994 with minor corrections.
Craig Hunt
Publisher: O'Reilly & Associates
ISBN: 0-937175-82-X
UNIX System Administration Handbook, Second Edition
1995
Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein
Publisher: Prentice Hall
ISBN: 0-13-151051-7
TCP/IP Illustrated, Volume 1
1994
Author: W. Richard Stevens
Publisher: Addison-Wesley Publishing Company
ISBN: 0-201-63346-9
Related RFC's:
Postel, J.B.; Reynolds, J.K. Domain Requirements. Marina del Rey, CA:
University of Southern California, Information Sciences Inst.; 1984
October; RFC 920. 14 p.
ftp://rs.internic.net/rfc/rfc920.txt
Harrenstien, K.; Stahl, M.K.; Feinler, E.J. DoD Internet Host Table
Specification. Menlo Park, CA: SRI International, 1985 October;
RFC 952. 6 p.
ftp://rs.internic.net/rfc/rfc952.txt
Harrenstien, K.; Stahl, M.K.; Feinler, E.J. Hostname Server. Menlo
Park, CA: SRI International, 1985 October; RFC 953. 5 p.
ftp://rs.internic.net/rfc/rfc953.txt
Partridge, C. Mail Routing and the Domain System. Cambridge, MA: BBN
Labs., Inc.; 1986 January; RFC 974. 7 p.
ftp://rs.internic.net/rfc/rfc 974.txt
Lazear, W.D. MILNET Name Domain Transition. McLean, VA: MITRE Corp.;
1987; RFC 1031. 10 p.
ftp://rs.internic.net/rfc/rfc1031.txt
Stahl, M.K. Domain Administrators Guide. Menlo Park, CA: SRI
International;
1987 November; RFC 1032. 14 p.
ftp://rs.internic.net/rfc/rfc1032.txt
Lottor, M. Domain Administrators Operations Guide. Menlo Park, CA: SRI
International 1987 November; RFC 1033. 22 p.
ftp://rs.internic.net/rfc/rfc1033.txt
Mockapetris, P. Domain Names - Concepts and Facilities. Marina del Rey,
CA: University of Southern California, Information Sciences Inst.; 1987
November; RFC 1034. 55p. Updated-by: RFC 1101
ftp://rs.internic.net/rfc/rfc1034.txt
Mockapetris, P. Domain names - Implementation and Specification. Marina
del Rey, CA: University of Southern California, Information Sciences
Inst.; 1987 November; RFC 1035. 55 p. Updated-by: RFC 1101
ftp://rs.internic.net/rfc/rfc1035.txt
Mockapetris, P. DNS Encoding of Network Names and Other Types. Marina
del
Rey, CA: University of Southern California, Information Sciences Inst.;
1989 April; RFC 1101. 14 p. Updates: RFC 1034; RFC 1035
ftp://rs.internic.net/rfc/rfc1101.txt
Cooper, A.; Postel, J. The US Domain. Marina del Rey, CA: University of
Southern California, Information Sciences Inst.;1993 June; RFC 1480. 47
p.
ftp://rs.internic.net/rfc/rfc1480.txt
Postel, J. Domain Name System Structure and Delegation. Marina del Rey,
CA:
University of Southern California, Information Sciences Inst.; 1994
March;
RFC 1591 7 p.
ftp://rs.internic.net/rfc/rfc1591.txt
More information about the Dbwg
mailing list