Search Support
contact us

Let Us Make it Easy for You. Call 1-877-898-3290 for MyTime Support™. Learn More

Troubleshooting Domain Names

Article Rating: 2 / 5 Votes: 17

New Referral Behavior for VeriSign’s COM, NET and EDU Registries

When queried for an existing A or AAAA record serving as glue (an address record 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] servers are changing to this 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 "" and "" zones would work today:






These two domains are configured in a "cycle": all of's servers are in the domain, and all of's servers are in the domain. Such a cyclic configuration resolves today because [a-m] 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 would follow to resolve any data at "":

The iterative resolver queries a .com authoritative name server for "" and receives a referral to "" listing only name servers in "".

Even though the referral includes A records for "" and "" 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 "" and "", the iterative resolver now has the names but no addresses for any "" name servers.  It must temporarily suspend the query for "" to look up the address of one of the "" name servers.  Let's assume it chooses to resolve "".

The iterative resolver eventually queries a .net authoritative name server for the A records for "".  With the current referral behavior of [a-m], the .net server returns a non-authoritative answer for the A record for "".  The iterative resolver uses this address to contact this "" name server and resolve "".

After March 1, 2010, when the referral behavior changes, the .net server will not return the A record for ""; instead, it will return a referral to "".  But recall that all of the "" name servers are in the "" domain. The only reason the iterative resolver is attempting to resolve "" now is to resolve the initial query, "", also obviously in the "" domain. Thus with each domain depending on the other, resolution can no longer succeed.


Please review and update the set-up of your name server to ensure your domain will continue to resolve. Failure to do this will result in an interruption of service beginning March 1, 2010 and will create an un-resolvable circular reference within the name server.   

You have two options to avoid interruption of your domain service:

1. Move your name servers to Network Solutions and use our free ADNS manager to customize your settings.

2. Continue to use your existing name servers and make the necessary modifications at the host.