[dns-wg] Action Item 48.1: Lame Delegations -- first draft

Dear all,

here is a first draft addressing action item 48.1 on lame delegation problems
on large scale name servers. It's a -00 kind of document mainly issuing the
problem statement. Although there are some hours left, I don't expect
anyone to have read it by the WG meeting. An HTML version may be made
available later and depending on how the PDP evolves, we might want or need
to inject it into the policy developing engine. Comments are welcome!

-Peter
-------------- next part --------------



RIPE DNS WG 48.1                                                 P. Koch
                                                                DENIC eG
                                                             May 4, 2005


       DNS lame delegations caused by AXFR source unavailability


Abstract

   This document analyses causes for DNS lame delegations seen on large
   name servers and investigates and assesses countermeasures.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Signs of Lame Delegations  . . . . . . . . . . . . . . . . . .  2
   3.  Problems on large name servers . . . . . . . . . . . . . . . .  3
   4.  Ways to deal with missing XFR source . . . . . . . . . . . . .  4
   5.  Proactive measures . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Wishlist . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
   9.  Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
   A.  Copyright Statement  . . . . . . . . . . . . . . . . . . . . .  6
























Koch                                                            [Page 1]

RIPE DNS WG DRAFT       Large Scale DNS Lame Dels               May 2005


1.  Introduction

   This document analyses causes for DNS lame delegations seen on large
   (thousands of zones) name servers and investigates and assesses
   countermeasures.

   First we will define the term "lame delegation" and similar
   operational problems.  In the third section we will address various
   reasons that lead to lame delegations.  The fourth paragraph will
   summarize mechanisms server administrators currently do or could
   apply to lower the impact of lame delegations.

2.  Signs of Lame Delegations

   A lame delegation is a DNS delegation where the target of the NS RR
   does not respond authoritatively to queries for the domain so
   delegated.

   Lame delegations show different symptoms, which are sometimes given
   separate names:

   1.  The server's responses do not have the AA bit set

   2.  The server responses with an (upward) referral

   3.  The server responses SERVFAIL

   4.  The server responses REFUSED

   5.  The server refuses the query packet (giving either ICMP port
       unreachable or TCP RST)

   6.  The server does not respond at all

   7.  The server's name does not exist (NXDOMAIN)

   8.  The server's name does not own any A (or AAAA) RRs

   Cases (1) and (2) above are classical signs of a zone that has been
   forgotten by its server, either by expiry or due to syntax errors.

   Cases (1) through (4) are common lame delegations, cases (5) and (6)
   often just appear as temporary operational problems and cases (7) and
   (8) are sometimes called stale delegations.  The latter may result in
   a significant increase of the query volume at the servers serving the
   domain the non existing name server is expected to reside in.

   When all delegations for a domain are lame, the domain is delegated



Koch                                                            [Page 2]

RIPE DNS WG DRAFT       Large Scale DNS Lame Dels               May 2005


   perfectly lame.

   While operational guidelines suggest that the NS RRSet of a zone and
   the corresponding delegation in the parent zone should match, there
   are sometimes inconsistencies.  Without acknowledging or endorsing
   this practice the union of both NS RRSets shall be eligible for a
   lame delegation assessment.  In other words, even an NS RR that is
   only present in the delegated (child) zone may constitute a lame
   delegation as well.

3.  Problems on large name servers

   RFC 1034 [RFC1034] specifies the way and frequency the slave will
   check with the master for a zone change.  Details are controlled by
   the "refresh", "retry" and "expire" timer values.  A slave is
   expected to try checking a zone with its master (For the sake of
   simplicity we assume there is only a single master per slave) until
   it either succeeds or the "expire" timer is reached, after which the
   zone should be "discarded".  Different software implementations
   handle this in different ways [[list to be added]].

   Software implementations currently either apply hard coded upper and
   lower bounds to these timer values or allow for their manual
   configuration.  This aids in preventing unjustified resource
   consumption by unfortunate configurations.

   While the (primary) master not necessarily needs to be delegated the
   zone (hidden or stealth master), it may become unresponsive or non-
   authoritative.  As a consequence, the slave or slaves depending on
   this master will subsequently have to discard the zone and become
   lame themselves.  Reasons may be one or more of:

   o  The slave cannot connect to the master

   o  SOA not available at master

   o  SOA not authoritative at master

   o  SOA OK, AXFR refused

   o  AXFR breaks

   o  Zone does not load

   If the SOA check or the subsequent AXFR between master and slave
   fails, there are multiple potential causes:





Koch                                                            [Page 3]

RIPE DNS WG DRAFT       Large Scale DNS Lame Dels               May 2005


   o  Syntax error in zone at master

   o  CNAME sin (CNAME at zone apex)

   o  SOA serial decremented

   o  error in zone list at master (forgot zone)

   o  Customer changed AXFR source

   o  Customer applied (too strict) access control

   o  Customer vanishes

   o  Address space reassigned ("you are attacking me on port 53")

   o  Software problem at master

   Name servers serving large numbers of slave zones, may thus face two
   different problems related to lameness:

   o  Increased traffic, sometimes even query storms, due to lame
      delegations.  This may be worse if the zone is delegated perfectly
      lame (master and all slaves are delegated lame.

   o  A significant fraction of resources may be spent on the higher
      frequency retries caused by SOA check failures.  This may decrease
      the servers' performance and degrade service for all other zones
      on that server.


4.  Ways to deal with missing XFR source

   ignore This may result in a service degradation for all customers.

   call customer This is tedious, expensive and sometimes impossible, if
      there is no direct relationship between the name server operator
      and the zone maintainer.

   deconfigure zone The delegation will usually remain and queries will
      continue to arrive.

   substitute missing zone with last available copy Introduces (other
      type of) inconsistencies, may be difficult to get hands on "latest
      version"






Koch                                                            [Page 4]

RIPE DNS WG DRAFT       Large Scale DNS Lame Dels               May 2005


   substitute missing zone with empty zone This is invasive, introduces
      hard failures and may thus increase load on the hotline.

   have delegation revoked The name service provider may not necessarily
      be able to authoritatively (pun intended) communicate with a
      registrar or a registry.


5.  Proactive measures

   Logs on the slave should be inspected automatically for signs of AXFR
   source unavailability as an early warning measure.

   Zone maintainers, name server operators and registries can prevent
   certain problems by (more) careful tailoring of SOA timer parameters.

6.  Wishlist

   From a name server operator's perspective it would be helpful if the
   operator could change or delete a delegation to his name server and
   could change the server's registered IP address, if any.  There are
   two problems with this approach: authentication of the server
   operator and status of the domain should the number of active
   delegations fall below a required minimum.  In the long run it may be
   useful to give the name server operator a dedicated role in the
   current concept of the "triple R trio".

   Software vendors could add logic to prefer sane zones' SOA checks
   over those for potentially abandoned ones, maybe by applying some
   (timer) penalty to zones that could not be verified with the master
   for a "long" time (for given "refresh", "retry" and "expire" values.

7.  Security Considerations

   DNSSEC may introduce additional problems, when a slave has data with
   outdated sigantures only.  In addition, substituting an expireed zone
   with an empty or the last available copy will no longer be feasible.

8.  Acknowledgements

   Thanks to Andre Koopal from MCI NL for bringing this up at RIPE 48.

9.  Disclaimer

   The measures are listed here for informational purposes only.  None
   of them is yet recommended and they should be used after a careful
   risk/benefit assessment only.




Koch                                                            [Page 5]

RIPE DNS WG DRAFT       Large Scale DNS Lame Dels               May 2005


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE REPRESENTS OR
   IS SPONSORED BY (IF ANY), 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.

   Any position taken by the author reflects his personal views and does
   not constitute a policy statement of the sponsoring institution.

10.  References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1912]  Barr, D., "Common DNS Operational and Configuration
              Errors", RFC 1912, February 1996.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, August 1996.

   [RIPE203]  Koch, P., "Recommendations for DNS SOA Values", RIPE 203,
              June 1999.


Author's Address

   Peter Koch
   DENIC eG
   Wiesenhuttenplatz 26
   Frankfurt  60329
   DE

   Phone: +49 69 27235 0
   Email: pk at DENIC.DE

Appendix A.  Copyright Statement

   Copyright (C) Peter Koch, DENIC eG (2005)









Koch                                                            [Page 6]