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