[dbwg] RE: Policy Proposal 2002-1

[Member Services]

The following information is provided in support of the
discussion that will take place this week during the
Data Base Working Group session of the ARIN Public
Policy Meeting.

Richard Jimmerson
Director of Operations
American Registry for Internet Numbers (ARIN)



--------------------------------------

This is a summary of some DNS lameness testing run from our Chantilly 
network location.  The main test reads in all of the /8 zones we have 
under in-addr.arpa and tests each NS RR to see if the name server 
mentioned is indeed authoritative for the reported zone.  One 
complicating factor is that some name servers have multiple 
addresses, this is addressed in the testing software.

Something to keep in mind about this.  The tests can be improved to 
see if there are transient errors (some lameness is always there, 
some comes and goes day to day).  Even so, a summary of the 6 runs 
has been performed and found that 36% of the zones delegated were 
lame (or unreachable) in all of the test runs.  How to interpret the 
numbers and what to do with the numbers are both open questions.  But 
for now, back to the test at hand.

There are between 500-600 thousand NS records in the test.  The first 
chart counts the number of NS records that fall into one of the 
"server health" categories.  ("Server" being a name server listing in 
the DNS, i.e., an NS RR).  "Good only" refers to one-address servers 
that reply favorably and refers to multiply-addressed servers that 
reply favorable from all of their addresses.  "Bad only" means that 
unfavorable replies were returned, "Down only" means that no replies 
were received, and "Missing only" means that there were no address 
records available for the name server.  The remaining categories 
apply to just multiply-addressed servers and shows how many have 
different results based on which IP address is tested.

The value of these counts is that it shows how much per-RR work is 
needed to clean up the /8 files.  The counting data is suspect 
though, as all testing is done with the DNS UDP (unreliable) protocol 
from one location.

Counting by NS RR's:
Date:                    07/26/02 07/28/02 07/31/02 08/01/02 08/02/02 08/04/02
Good only:                301418   298909   299528   291934   291073   284762
Bad only:                 195828   194508   193536   189221   189276   189265
Down only:                 38345    41126    41256    36938    38493    43840
Missing only:              15495    15877    16803    15922    15828    16320
Good and Bad only:             2        2        1        1        1        1
Good and Down only:          167      146      120      271      379      748
Bad and Down only:           126      202      472      386      467      380
Good, Bad and Down only:       0        0        0        0        0        0

(Each of the runs used the then current versions of the zone files, 
which are generated twice a day.  The accounts for some variations in 
the totals.)

All well and good, but the true impact of lameness may lie in what 
happens when a zone cannot be reached, as opposed to having some 
difficulty getting there. In other words, as I traverse down the DNS 
tree, I might find a lame server but there is another server that 
isn't lame.  In this instance, although there was an unnecessary 
lookup done, the lameness did not result in more load on the root (or 
upper) DNS servers nor led the resolver into a loop.

The following counts are listed in separate tables because the counts 
are split into /16 and /24 zone delegations.  Note that the "No IP 
address" value differs from the "Missing only" counts above because, 
e.g., the 2,783 non-addressable delegated zones in the first run used 
name servers that appeared in a total of 15,495 NS RR's across all of 
our zone files.  This is not unusual.

What is more significant is the number of "All broken" zones in the 
runs.  This lists the number if zones that cannot be reached and are 
likely the ones that are causing an extra load on the root/upper 
servers.

Counting zone by zone:

==> 2002-07-26-0400-run <==
Count of zone by zone results:
Category         All   /16's  /24's
-------------- ------ ------ ------
No IP address    2783     96   2687
No broken      111889   5878 106011
Some broken     29981   2168  27813
All broken      90381   1986  88395

==> 2002-07-28-1600-run <==
Count of zone by zone results:
Category         All   /16's  /24's
-------------- ------ ------ ------
No IP address    2910    101   2809
No broken      109420   5353 104067
Some broken     32329   2678  29651
All broken      90306   2003  88303

==> 2002-07-31-1600-run <==
Count of zone by zone results:
Category         All   /16's  /24's
-------------- ------ ------ ------
No IP address    3203    103   3100
No broken      109947   5664 104283
Some broken     31914   2396  29518
All broken      90620   1998  88622

==> 2002-08-01-1600-run <==
Count of zone by zone results:
Category         All   /16's  /24's
-------------- ------ ------ ------
No IP address    3041    106   2935
No broken      108322   5436 102886
Some broken     28922   2434  26488
All broken      87385   2018  85367

==> 2002-08-02-1600-run <==
Count of zone by zone results:
Category         All   /16's  /24's
-------------- ------ ------ ------
No IP address    3025    101   2924
No broken      108189   5226 102963
Some broken     28315   2588  25727
All broken      88416   2075  86341

==> 2002-08-04-1600-run <==
Count of zone by zone results:
Category         All   /16's  /24's
-------------- ------ ------ ------
No IP address    3033    107   2926
No broken      101109   5295  95814
Some broken     35816   2591  33225
All broken      88112   2005  86107

BTW, the date designation and time refers to the generation of the 
zone files.  The runs are made just after the new files are available 
to the testing machine.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                       
ARIN Research Engineer