[sig-dns]Revised Policy Proposal: Lame DNS

  • To: sig-dns at apnic dot net
  • Subject: [sig-dns]Revised Policy Proposal: Lame DNS
  • From: Anne Lord <anne at apnic dot net>
  • Date: Mon, 21 Jul 2003 16:47:26 +1000 (EST)
  • Cc: sig at apnic dot net, <sig-dns-chair at apnic dot net>
  • List-archive: <http://www.apnic.net/mailing-lists/sig-dns/>
  • List-help: <mailto:sig-dns-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on DNS issues <sig-dns.lists.apnic.net>
  • List-post: <mailto:sig-dns@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-dns>,<mailto:sig-dns-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-dns>,<mailto:sig-dns-request@lists.apnic.net?subject=unsubscribe>
  • Sender: sig-dns-admin@lists.apnic.net
    • 
      Below is a revised text proposal for the DNS Ops SIG at the forthcoming
      APNIC Open Policy Meeting in Korea.  
      
      An activity is proposed for identifying, testing and disabling lame 
      DNS delegations.   This was previously presented at APNIC15 and 
      the revised proposal incorporates feedback received.
      
      Your comments and feedback on this proposal are much appreciated.
      
      Regards,
      Anne
      ----------------------------------------------------------------------
      See you at APNIC 16
      Seoul, Korea, 19-22 August 2003          http://www.apnic.net/meetings
      ----------------------------------------------------------------------
      
      A proposal for sweeping lame DNS reverse delegations 
      
      Proposed by: APNIC
      Version: 1.1
      Date: 22 July 2003
      
      1	Summary
      
      This is a proposal to authorise the APNIC Secretariat to test for, and 
      disable, lame DNS reverse delegations. 
      
      The process would consist of the following steps:
      
      "	Identify potential lameness;
      "	Test the DNS reverse delegation (15 day test period); 
      "	Attempt to notify the domain holder (45 day notice period); 
      "	Disable lame DNS reverse delegation.
      
      During the notice period, the APNIC Secretariat will try to contact the 
      domain-holder by all reasonable means, using all contact information in 
      the registered domain objects.
      
      Disabled reverse delegations will be identified in the whois database with 
      special entries in the remarks field. While a reverse DNS domain is disabled, 
      the domain-holder will be emailed monthly reminders. Domain holders will be 
      able to re-enable their reverse delegations at any time.
      
      The APNIC Secretariat will report regularly to the DNS SIG on activities 
      under this proposal, and will manage the process with community consultation.
      
      2	Background and problem statement
      
      DNS reverse delegations are considered lame if some or all of the registered 
      DNS nameservers are unreachable or badly configured. APNIC research has 
      shown that a significant proportion (between 10 and 15 percent) of reverse 
      delegations in the APNIC Whois database are currently lame.
      
      Lame DNS reverse delegations can cause several problems across the Internet, 
      such as:
      
      * Delays in service binding for clients using affected address ranges. These 
        delays come from timeouts in reverse-address lookup when the receiving 
        party tries to resolve the calling source address. 
      
      * Refusal of service due to failures during DNS processing.
      
      * Increased DNS traffic between caching DNS nameservers and the listed 
        authorities down from the root, processing requests which can only fail 
        after timeout. This represents a measurable load on critical infrastructure 
        which the RIRs have been requested to investigate and reduce.
      
      Lame DNS reverse delegations can affect both the users of the network in 
      question and unrelated third parties. End users cannot resolve this problem 
      themselves because of the hierarchical nature of authoritative delegation. 
      If the network administrators do not correct errors in their DNS 
      configurations, the only other mechanism to reduce its impact is for the 
      RIR to resume control of the delegated domain and disable the listing of the 
      misconfigured servers so a valid NXDOMAIN DNS response can be sent.
      
      The Internet community is still discussing definitions of "lameness DNS". 
      However, for the purposes of this proposal, the following four types of 
      problems are relevant:
      
      Problem					
      A listed DNS server is not reachable.   
      
      Policy implication
      This should be considered as lame DNS.
      
      However, it is important to try to reach the DNS server from at least 
      two geographically separate locations. If one or more locations are able 
      to reach the server then it is not considered lame.
      
      Problem
      A listed DNS server is reachable, but does not respond on port 53.
      
      Policy implication
      This should be considered as lame DNS.
      
      Problem
      A listed DNS server is reachable and responds on port 53, but it is not 
      able to answer for the domain.
      	
      This problem could arise in the following circumstances:
      * The server is a secondary and has been unable to re-load the zone 
        from a master/authoritative source, with no local copy of the zone held 
        at restart time.
      
      * An error in the runtime configuration of the zone has caused it to be 
        skipped when the server was started.
      
      Policy implication
      This should be considered as lame DNS.
      
      Problem
      A listed DNS server is reachable and responds on port 53, but serves 
      incorrect data for the domain. 
      
      Incorrect data could take one of two forms:
      * Zone serial is not in synchronization with the listed master/authoritative 
        source.
      
      * Zone serial is in synchronization, but authority bit is not set.
      
      Policy implication
      This should not be considered as lame DNS.
      
      Although this may be considered lame under a strict definition, this problem 
      does not have a significant impact on global DNS root nameservers. 
      
      3	Other RIRs
      
      3.1	ARIN
      ARIN has a policy of managing lame reverse DNS delegations under a 30 
      day notice process, which is documented at:
      
      http://www.arin.net/policy/2002_1.html
      
      ARIN only disables non-authoritative servers. It does not currently disable 
      lame DNS for unreachable nameservers. ARIN has a year of experience with 
      this policy and reports on lame DNS status at ARIN meetings.
      
      For the purposes of the ARIN policy, DNS reverse delegations are considered 
      lame if:
      
      * AA bit is not set in response header, the zone is not marked as 
        authoritative.
      * AA bit is set in response header, but there is nothing in the answer 
        section.
      * AA bit is set in response header, but the answer is not an SOA record.
      
      3.2	LACNIC
      LACNIC performs DNS checks and updates whois records on a regular cycle. 
      The check is based on a statistical measurement and marks lame DNS daily, 
      restoring non-lame status on a weekly cycle. A proposal to formalise this 
      process and de-list lame delegations may be presented at future LACNIC 
      member meetings.
      
      3.3	RIPE NCC
      At this time, RIPE NCC measures the extent of lame DNS for informational 
      purposes only. As is the case in other RIRs, RIPE NCC requires the listed 
      authoritative nameservers to be functional at the time the reverse domain is 
      first delegated. Details of the RIPE lame measurement process are available 
      at:
      
      	http://www.ripe.net/ripencc/pub-services/stats/revdns/
      
      4	Proposal
      
      4.1	Details of proposed procedure
      It is proposed that APNIC should adopt procedures to repair or remove 
      persistently lame DNS delegations. The details of the proposed procedures 
      are as follows:
      
      Step 1 - Identify potential lameness
      
      * APNIC currently runs regular administrative tests on DNS delegations, 
      for statistical purposes. It is proposed to extend the scope of these tests 
      by specifically identifying potentially lame DNS delegations.
      
      Step 2 - Test the DNS reverse delegation (15 day test period)
      
      * When a DNS delegation is identified as potentially lame, a "lame DNS timer" 
      will start.
      
      * While the timer is running, the delegation will be regularly tested for 
      lameness. The testing will be performed from at least two geographically 
      separate locations.
      
      * If the DNS delegation successfully resolves DNS during the testing period, 
      then the timer will be reset. This allows for temporary problems to be fixed 
      before any action is required from APNIC.
      
      * If the timer runs for 15 days without being reset, then the DNS 
      delegation will be considered as persistently lame.
      
      Step 3 - Attempt to notify the domain holder (45 day notice period)
      
      * Once a DNS delegation is considered persistently lame, the 45 day notice 
      period will start.
      
      * APNIC will email each admin-c and tech-c registered in the domain to 
      inform them of the problem in their delegation. If the problem is not fixed, 
      this email will be repeated weekly.
      
      * If APNIC receives no reply from the emails, it will try to contact the 
      domain holders using any other contact information available (such as phone, 
      fax, or postal mail). APNIC may also seek contact through parent records in 
      the database, upstream ISPs, and any other relevant contact details that 
      may be available.
      
      Step 4 - Disable lame DNS delegation
      
      * If the DNS delegation is still lame at the end of the 45 day notice period, 
      APNIC will insert a special marker in the remarks field of the relevant 
      domain object. This marker will identify the DNS delegation as 
      "administratively blocked" and will cause the delegation to be withdrawn. 
      
      * The special marker may be removed by the domain holders at any time, using 
      normal whois database procedures. 
      
      * The special marker will contain text noting that APNIC is overriding the 
      listed "nserver" records, timestamp information, and a URL to instructions for 
      re-enabling the delegation.
      
      * While the delegation remains blocked, APNIC will send monthly email 
      remainders to each admin-c and tech-c.
      
      4.2	Scope of proposed procedure
      This procedure will apply to each nserver entry listed in domain objects. 
      Therefore, if all nserver entries in a particular domain object are disabled 
      for persistent lameness, the entire domain will be withdrawn from the DNS. In 
      these cases, reverse DNS lookup will terminate in the APNIC nameservers with 
      an NXDOMAIN response.
      
      4.3	Reporting
      Because DNS lameness is globally visible, details of the current status of 
      all domains under test will be posted to the APNIC website. 
      
      At each APNIC Open Policy Meeting, the DNS SIG agenda will include a report 
      by the APNIC Secretariat on activities relating to DNS lameness.  Reports will 
      also be sent to the DNS SIG mailing list. The reports will include the 
      status of domain objects, the rate of administrative disabling and 
      re-enabling, and related activities.
      
      The APNIC Secretariat may also make additional reports to other bodies, such 
      as IEPG and NANOG.
      
      5	Implementation
      This proposal will be implemented three months after it has been accepted by 
      the APNIC community.