(Apologies in advance that some of you will see multiple copies of
this message on various lists.)
On March 1, 2010, VeriSign will be making two changes that affect the
behavior of the authoritative name servers for the .com, .net and .edu
zones ([a-m].gtld-servers.net). The changes are a prerequisite for
deploying DNSSEC in these three zones beginning in 2010.
Because of the widespread use of .com and .net, and because resolution
of some domains might be affected, we'd like to notify the community
in advance about these changes.
The two changes are:
1. New referral behavior
When queried for an existing A or AAAA record serving as glue (an
address record at or below NS records at a delegation point), the
authoritative name servers for .com and .net respond with the glue
record in the answer section. However, the answer is not marked
authoritative, i.e., the AA bit is not set. While this behavior
conforms to the DNS standards, recent authoritative servers do not
respond this way. Instead, when queried for a name at or below a
delegation point, recent authoritative servers respond with a referral
to the delegated zone. This behavior is also supported by the DNS
standards.
The [a-m].gtld-servers.net servers are changing to the latter referral
behavior: queries for glue records will result in referrals rather
than non-authoritative answers.
Note that this change will affect the resolution of certain domains
under .com and .net that depend upon one another. For example, the
following configuration of mutually interdependent "example.com" and
"example.net" zones would work today:
example.com. NS ns1.example.net.
example.com. NS ns2.example.net.
example.net. NS ns1.example.com.
example.net. NS ns2.example.com.
These two domains are configured in a "cycle": all of example.com's
servers are in the example.net domain, and all of example.net's
servers are in the example.com domain. Such a cyclic configuration
resolves today because [a-m].gtld-servers.net are authoritative for
both the .com and .net zones, and because these servers return queries
for glue as non-authoritative answers as described above.
To illustrate exactly why this configuration works today, consider the
steps an iterative resolver (the portion of a recursive name server
that sends queries) would follow to resolve any data at
"www.example.com":
* The iterative resolver queries a .com authoritative name server for
"www.example.com" and receives a referral to "example.com" listing
only name servers in "example.net".
* Even though the referral includes A records for "ns1.example.net"
and "ns2.example.net" in the additional section of the DNS message,
modern iterative resolvers ignore these records as a defense against
cache poisoning.
* Having discarded the A records for "ns1.example.net" and
"ns2.example.net", the iterative resolver now has the names but no
addresses for any "example.com" name servers. It must temporarily
suspend the query for "www.example.com" to look up the address of one
of the "example.com" name servers. Let's assume it chooses to resolve
"ns1.example.net".
* The iterative resolver eventually queries a .net authoritative name
server for the A records for "ns1.example.net". With the current
referral behavior of [a-m].gtld-servers.net, the .net server returns a
non-authoritative answer for the A record for "ns1.example.net". The
iterative resolver uses this address to contact this "example.com"
name server and resolve "www.example.com".
As of March 1, 2010, when the referral behavior changes, the .net
server will not return the A record for "ns1.example.net"; instead,
it will return a referral to "example.net". But recall that all of
the "example.net" name servers are in the "example.com" domain.
The only reason the iterative resolver is attempting to resolve
"ns1.example.net" now is to resolve the initial query,
"www.example.com", also obviously in the "example.com" domain.
Thus with each domain depending on the other, resolution can no
longer succeed.
VeriSign has created two lists of .com and .net domains that may be
affected by this change:
#1: Domains participating in cycles
Domains on this list are mutually interdependent as described above.
For example, given the scenario described above, both "example.com"
and "example.net" would be on list #1.
#2: Domains that depend exclusively on domains in cycles
Domains on this list are not actively part of a cycle as those in
list #1. Instead, all of the domains in list #2 use exclusively
name servers from domains that are part of a cycle. In other words,
a domain in list #2 has all its name servers from one or more
domains in list #1. Continuing the example above, if the domain
"foo.com" had name servers "ns1.example.com" and "ns2.example.com",
then "foo.com" would appear in list #2.
Both lists follow at the end of this message. Note that the lists
were created on Monday, January 4, 2010, and the content of the
.com/.net registry changes all the time. Therefore, it's possible
that some domains in the lists are no longer in cycles nor depend on
domains in cycles.
If a domain appears in one of the two lists, to ensure successful
resolution after March 1, 2010, at least one of its name servers must
be changed to either break the cycle (for domains in list #1) or
remove the domain's dependency on a cycle (for domains in list #2).
2. Glue no longer promoted to authoritative status
In the .com/.net registry system, a domain can be placed on an
administrative hold status. A domain on hold is not published: the NS
records delegating the domain are removed from the .com or .net zone.
For example, registrars sometimes place a domain on hold if it is
about to expire but the registrant has not responded to requests to
renew it, or if it is being used for malicious activity.
Currently, when a domain is placed on hold, its NS records are removed
from the zone but not any of the A and AAAA records of name servers in
that domain. For example, consider if the domain "example.com"
existed in the registry along with the name server "ns.example.com".
(An important note: whether or not the "example.com" zone itself
actually uses "ns.example.com" as one of its authoritative name
servers is irrelevant to the behavior described here. The important
point is that "ns.example.com" is in the "example.com" domain, i.e.,
below it in the DNS name space.)
If the "example.com" domain were placed on hold today, the NS records
delegating it would be removed from the .com zone. The A and AAAA
records for "ns.example.com" remain in the zone. In fact, since these
records are no longer below a delegation point, they are promoted to
become authoritative data.
As of March 1, 2010, when a domain goes on hold, the NS records
delegating the domain will be removed from the zone, and the A and
AAAA records for name servers below the domain will no longer be
promoted to authoritative status. These A and AAAA records will not
actually be removed: although they will not be returned when queried
for directly, they will appear in the additional section of referrals
that reference them.
In the example above, if "example.com" went on hold, its NS records
would be removed from the zone. But if the "example.net" domain uses
"ns.example.com" as a name server, a referral response to
"example.net" will include the A and AAAA records for "ns.example.com"
in the additional section.
A principal motivation for this change is DNSSEC. When DNSSEC is
deployed in the .com and .net zones, A and AAAA records promoted to
authoritative data would have to be signed, resulting in increased
complexity for the overall registry system. This change in business
logic (where the removal of a domain on hold also affects name servers
below that domain) is consistent with the behavior of other top-level
domain registries.
If you have questions about these changes, you may follow up here,
contact me directly, or send email to VeriSign's registry customer
service group at info@verisign-grs.com.
Matt Larson