Describe Matt Larson からの通告 here.
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:
- 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).