DNS Behaviour Changes
Changes to .com/.net/.edu Name Servers in Preparation for DNSSEC
On 1 March 2010, Verisign made two changes that affect the behaviour 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 Behaviour 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 be marked authoritative, (i.e., the AA bit was not set.) While this behaviour 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 behaviour was also supported by the DNS standards.
The [a-m].gtld-servers.net servers have now changed to the latter referral behaviour: 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 well 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":
- 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 defence 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 us 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 behaviour 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 01 March 2010, however, the .net server does not return the A record for "ns1.example.net"; instead, it returns a referral to "example.net". But remember 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 no. 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 no. 1 are. Instead, all of the domains in list no. 2 use exclusively name servers from domains that are part of a cycle. In other words, a domain in list no. 2 has all its name servers from one or more domains in list no. 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 no. 2.
If a domain appears in one of the two lists, the 01 March change requires that at least one of its name servers be changed to either break the cycle (for domains in list no. 1) or remove the domain's dependency on a cycle (for domains in list no. 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 a case where 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 behaviour 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 01 March 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 promoted to authoritative status. These A and AAAA records are not actually 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