1. Verisignについて

Contents

  1. Verisignについて
    1. DNS Behavior Changes
    2. 影響???

循環参照問題

https://www.verisign.com/en_US/innovation/dnssec/dns-behavior-changes/index.xhtml?loc=en_US

DNSSEC対応のために以下の変更をする(した）らしい。それにしても古すぎる。-- ToshinoriMaeno 2016-01-25 02:41:21

用心深いリゾルバーはいまも問題に遭遇するだろう。-- ToshinoriMaeno 2016-01-25 02:43:12

1.1. DNS Behavior Changes

Changes to .com/.net/.edu Name Servers in Preparation for DNSSEC

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.

1.2. 影響???

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 

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:"

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

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".

（これが問題のない動作と言えるのだろうか。-- ToshinoriMaeno 2016-01-25 02:48:19)

As of March 1, 2010, however,

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: 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).

Glue No Longer Promoted to Authoritative Status