On March 1, 2010, Verisign made 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. The two changes are
New Referral Behavior and Glue No Longer Promoted to Authoritative Status.
In the past, 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 would respond with the glue record in the answer section. However, the answer would not marked authoritative, (i.e., the AA bit was not set.) While this behavior conformed to the DNS standards, recent authoritative servers did not respond this way. Instead, when queried for a name at or below a delegation point, recent authoritative servers responded with a referral to the delegated zone. This behavior was also supported by the DNS standards.
The [a-m].gtld-servers.net servers have now changed to the latter referral behavior: queries for glue records result in referrals rather than non-authoritative answers.
Note that this change affects 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 worked fine in the past:
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 were 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 used to resolve because [a-m].gtld-servers.net were authoritative for both the .com and .net zones, and because these servers returned queries for glue as non-authoritative answers as described above.
To illustrate exactly why this configuration worked, 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":
As of March 1, 2010, however, the .net server does not return the A record for "ns1.example.net"; instead, it returns 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:
List 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.
List 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.
If a domain appears in one of the two lists, the March 1 change requires that at least one of its name servers 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).
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.
Before the change, when a domain was placed on hold, its NS records were 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.)
It used to be that if the "example.com" domain was placed on hold, the NS records delegating it were removed from the .com zone. The A and AAAA records for "ns.example.com" remained in the zone. In fact, since these records were no longer below a delegation point, they were promoted to become authoritative data.
As of March 1, 2010, when a domain goes on hold, the NS records delegating the domain are removed from the zone, and the A and AAAA records for name servers below the domain are no longer be promoted to authoritative status. These A and AAAA records are not actually be removed: although they are not returned when queried for directly, they 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.
If you have questions about these changes, please contact Verisign's registry customer service group.Back to top