www.yahoo.com,
and www.microsoft.com.
We use popular names to increase the chance of getting an answer.
That is, we believe that the nameservers for the popular names have
high-availability and throughout the Internet.
We say the nameserver allows
recursion if it provides at least one A RR for each query. This
means, for example, if a nameserver only returned 2 out of 3 queries,
it would not get marked as recursive.
This was done to account for nameservers that, for whatever reason,
think they are authoritative for one of the query names.
We test for TCP support by setting the `usevc' option to
Net::DNS::Resolver and then making an SOA query for the zone. We
say the nameserver supports TCP if it returns at least one answer
RR. Each nameserver is tested only once.
We test for zone transfer with Net::DNS::Resolver's axfr_start
and axfr_next functions. We say the nameserver allows the
zone transfer if it returns at least one RR. Each nameserver is
tested only once, even if it is authoritative for many zones.
We send version.bind queries to each authoritative nameserver
just once.
Query Sources
We distributed our queries from approximately 250 IP addresses
in the same /24 subnet.
Results
The scan ran from 2005-06-27 12:42 UTC to 2005-06-29 12:19 UTC.
We analyzed 1,311,909 zones and 260,098 nameservers.
How many nameservers advertise their software version?
About 36% of nameservers do not openly advertise their software
version. Most of those that do are running BIND software:
| NORMAL_BIND | 133363 | 51.3% |
| NOANSWER | 60645 | 23.3% |
| NOREPLY | 34054 | 13.1% |
| OTHER | 20771 | 8.0% |
| NOADDRESS | 5910 | 2.3% |
| EMPTY | 2889 | 1.1% |
| SEMI_NORMAL_BIND | 2317 | 0.9% |
| NSD | 65 | 0.0% |
| TINYDNS | 42 | 0.0% |
| ULTRADNS | 41 | 0.0% |
- NORMAL_BIND
the version string matches the pattern
/^[489]\.[0-9]/
- SEMI_NORMAL_BIND
the version string matches the pattern
/^{named,bind} [489]\.[0-9]/
- NOREPLY
we did not receive a DNS reply to the query
- NOANSWER
we received a reply, but it did not contain any answer RRs
- EMPTY
the version.bind reply was the empty string
- NOADDRESS
we could not determine the IP address for the nameserver
How many nameservers allow recursion?
The following table shows how many nameservers appear to
recursively resolve domain names on our behalf:
| YES | 191510 | 75.3% |
| NO | 62677 | 24.7% |
| NOADDRESS | 5910 | |
NOADDRESS means we could not determine the IP address for the nameserver.
We also have data on how many DNS replies came back with the RA bit set:
| Query Name | Set | Clear |
|---|
| www.microsoft.com | 84.0% | 16.0% |
| www.google.com | 83.7% | 16.3% |
| www.yahoo.com | 83.7% | 16.3% |
Note that the percentage in the first table is lower. This may be due to
our requirement to receive answers to all three names. It may also
be due to nameservers that set the RA bit, but don't actually
provide recursion for some reason.
How many nameservers allow a zone transfer?
The following table shows how many nameservers allowed us to
transfer one of their zones:
| YES | 105270 | 41.4% |
| NO | 148917 | 58.6% |
| NOADDRESS | 5910 | |
NOADDRESS means we could not determine the IP address for the nameserver.
Related to this measurement is the number of nameservers that
allow TCP transactions at all:
| YES | 199306 | 78.4% |
| NO | 54881 | 21.6% |
| NOADDRESS | 5910 | |
Are nameservers topologically dispersed?
RFC 2182 states: secondary servers must be placed at both topologically
and geographically dispersed locations on the Internet, to minimize
the likelihood of a single failure disabling all of them. While we
do not test for geographic diversity, we can easily examine the
topologic aspects of a zone's nameservers. Our assumption that
topologic locality implies geographic locality is is true in most,
but not quite all cases. The following table shows the percentage
of zones having all their authoritative nameservers within the given
CIDR-sized subnets:
| CIDR Mask | Percentage | Cumulative |
|---|
| 32 | 3.9% | 3.9% |
| 31 | 10.5% | 14.4% |
| 30 | 5.2% | 19.6% |
| 29 | 4.8% | 24.4% |
| 28 | 2.1% | 26.4% |
| 27 | 2.4% | 28.8% |
| 26 | 1.6% | 30.4% |
| 25 | 1.0% | 31.4% |
| 24 | 1.4% | 32.8% |
| 23 | 5.3% | 38.1% |
| 22 | 2.5% | 40.7% |
| 21 | 6.0% | 46.7% |
| 20 | 6.2% | 52.9% |
| 19 | 1.6% | 54.5% |
| 18 | 2.0% | 56.5% |
| 17 | 0.5% | 56.9% |
| 16 | 0.3% | 57.3% |
Do delegations match authoritative NS records?
Here we examine whether delegation NS records (listed in the parent
zone) match the authoritative NS records (found in the zone itself).
We use the following six categories:
- Equal
The delegation records exactly match the authoritative records
- Disjoint
The delegation and authoritative records have no members in common
- Subset
The delegation records are a subset of the authoritative records
- Superset
The delegation records are a superset of the authoritative records
- Intersect
The delegation the authoritative records each contain members not found in the other set
- No Authoritative Nameservers
The supposedly-authoritative nameservers (learned from the parent
zone) did not return any NS records for the zone
Note that we are only comparing nameserver names, rather than IP
addresses. This may explain why there is a non-zero number of zones with
Disjoint delegation/authoritative nameservers. The following table
shows the percentage of each category:
| Equal | 784735 | 60.5% |
| No Authoritative Nameservers | 292480 | 22.5% |
| Subset | 83331 | 6.4% |
| Disjoint | 82171 | 6.3% |
| Superset | 31174 | 2.4% |
| Intersect | 24140 | 1.9% |
Do all nameservers return the same TTL for NS records?
Here we consider two slightly different cases. The first table
shows the percentage of zones where the authoritative nameservers
return NS records with mis-matched TTLs. This includes all NS records
from all nameservers for a zone. The first column is the number of
unique TTLs returned:
| 1 | 992137 | 98.7% |
| 2 | 12886 | 1.3% |
| 3 | 500 | 0.0% |
| 4 | 22 | 0.0% |
| 5 | 4 | 0.0% |
| 7 | 1 | 0.0% |
Similarly, the second table shows the percentage of nameservers
that return differing NS record TTLs in response to a single query:
| 1 | 2537385 | 99.9% |
| 2 | 2276 | 0.1% |
| 3 | 16 | 0.0% |
| 7 | 7 | 0.0% |
Are SOA values within their suggested ranges?
Refresh
RFC 1912 suggests that the SOA Refresh value should be at least 20
minutes and no longer than 12 hours. The following table shows the
distribution of Refresh values:
| <20m | 51596 | 4.3% |
| 20m to 12h | 1029125 | 85.3% |
| >12h | 126132 | 10.5% |
Retry
RFC 1912 suggests that the SOA Retry value is typically less than
the Refresh value. The following table shows the distribution of
Retry values:
| retry <= refresh | 1179456 | 97.7% |
| retry > refresh | 27397 | 2.3% |
Expire
RFC 1912 suggests that the SOA Expire value should be at least 2
weeks and no longer than 4 weeks. The following table shows the
distribution of Expire values:
| <2w | 899636 | 74.5% |
| 2w to 4w | 102180 | 8.5% |
| >4w | 205037 | 17.0% |
Minimum
RFC 2308 suggests that the SOA Minimum value (aka the negative
caching TTL) should be at least 1 hour and no longer than 3 hours.
Common nameserver implementations usually enforce their own negative
caching limits of 3 hours or less. The following table shows the
distribution of Minimum values:
| <1h | 241748 | 20.0% |
| 1h to 3h | 338738 | 28.1% |
| >3h | 626367 | 51.9% |
Do serial numbers for a zone match?
| SAME | 1036811 | 79.9% |
| NOADDRESS | 228427 | 17.6% |
| DIFF | 26921 | 2.1% |
| OFFBYONE | 5872 | 0.5% |
- SAME
all authoritative nameservers return the same serial number
for the zone
- NOADDRESS
we could not determine the IP address for one or more of
the authoritative nameservers
- OFFBYONE
the minimum and maximum serial numbers among the set of
authoritative nameservers differed by only one
- DIFF
one or more of the authoritative nameservers has a serial
number different than the rest, where the difference is greater
than one
How many zones have a lame server?
| NOTLAME | 1086726 | 83.7% |
| NOERROR | 124016 | 9.6% |
| NOREPLY | 76154 | 5.9% |
| SERVFAIL | 3331 | 0.3% |
| REFUSED | 1661 | 0.1% |
| NXDOMAIN | 741 | 0.1% |
| NOTIMP | 2 | 0.0% |
| MULTIPLE | 5226 | 0.4% |
For zones with one lame server, we list the RCODE from the lame reply.
Zones with more than one lame server are represented by the
MULTIPLE line.
Note this only includes nameservers for which we have an IP address.
If a zone has 3 nameservers and we have can't get an IP address for
1 nameserver, the zone is included in the analysis with the 2 good
nameservers. In other words, an unresolvable nameserver is not
counted as a lame server.
Notes
Nameservers Density
We wish to note that some nameservers are authoritative for many
different zones. This may affect certain measurements, such as
the topological dispersion. For example, if a company with
many zones happens to have all its nameservers on the same subnet,
that may artifically inflate the percentages in the "Are nameservers topologically dispersed?" section.
To get an idea of the how many zones each nameserver hosts, note that
the mean number of zones per nameserver is 37.2, while the median
is 3.0. The following table shows how many zones each of the top 25
nameservers are authoritative for:
| NS Rank | Count | CDF |
|---|
| 1 | 253710 | 3.57% |
| 2 | 253705 | 7.13% |
| 3 | 253693 | 10.70% |
| 4 | 253635 | 14.26% |
| 5 | 253590 | 17.83% |
| 6 | 68736 | 18.79% |
| 7 | 68732 | 19.76% |
| 8 | 67948 | 20.72% |
| 9 | 67948 | 21.67% |
| 10 | 49306 | 22.36% |
| 11 | 49300 | 23.06% |
| 12 | 47608 | 23.73% |
| 13 | 47396 | 24.39% |
| 14 | 47252 | 25.06% |
| 15 | 47040 | 25.72% |
| 16 | 38390 | 26.26% |
| 17 | 36125 | 26.77% |
| 18 | 36125 | 27.27% |
| 19 | 36115 | 27.78% |
| 20 | 36115 | 28.29% |
| 21 | 36080 | 28.80% |
| 22 | 27130 | 29.18% |
| 23 | 27106 | 29.56% |
| 24 | 26982 | 29.94% |
| 25 | 26622 | 30.31% |
Announcement to NANOG
We announced this survey to the NANOG mailing list on June 24 (3
days beforehand) including the addresses where queries would come
from. It is possible that some people may have configured filters
on their networks to block our probes. However, we do not expect
that those doing so would have much effect on the results of this
survey.
Complaints Received
As a result of this survey we received four abuse complaints via
email (3 from humans, 1 automated). All complaints were about
zone transfer attempts. After explaining the survey,
the humans were very understanding.
Prior to the survey we added comments to the ARIN whois database
for our source netblock. The comments provided a brief
explanation of the survey and included our contact details.
Without these comments and descriptive web page, we probably would
have received more complaints.
© 2020 The Measurement Factory.
