DENIC's Comments on DNS Root Zone Glue Policy

[Peter Koch <pk@xxxxxxxx>]

On behalf of DENIC, the ccTLD registry for the DE top level domain, I would
like to submit the following comments on the IANA Root Zone Glue Policy.

Regards,
  Peter Koch
  (DENIC eG)

-----------------------------------------------------------------------------

Introduction
------------

In response to the public announcement
        <http://www.icann.org/announcements/announcement-3-05dec06.htm>,
DENIC would like to submit the following comments.

First, we appreciate the public review of the current IANA policy on so-called
"shared glue", which in the past has proven to be a source of confusion and
delay for root zone updates.

Prior to addressing specific issues, we would like to remark that the part of
RFC 1034, section 4.2.1, quoted in the announcement, actually suggests that
glue address records only be accepted for name servers with names in or below
the delegated zone. Current IANA policy accepts and demands glue address
records for all name servers below the delegating zone, i.e., each and every
server in the case of the root zone. This so-called "wide" glue policy (see
draft-koch-dns-glue-clarifications-02.txt) is the major cause of the current
ambiguity, since multiple TLDs might share an authoritative name server and
therefore might want to alter the same glue address information.
While a narrow glue policy would alleviate the problem, given that for any
necessary glue RRSet there would be a unique TLD and thus a canonical point
of contact, we do not want to suggest a policy change right now.
However, DENIC would like to encourage further discussion of the operational
and other effects of a narrow glue policy for the root zone in the broader
DNS operational community, i.e., involving TLD operators, root server operators,
and the IETF.


Characteristics of Glue Address Information
-------------------------------------------

Taking the wide glue policy for granted, it is important to identify the
various needs for authentication and authorization (approval) of address
information changes and the role glue data plays in DNS name resolution.

DNS glue information is not authoritative, but it is useful and good practice
that it be kept in sync with authoritative data. While glue data can be and
is used to direct some DNS queries to certain addresses, depending on the
properties of the delegated zone and various other factors, it does not offer
full control over the resolution process. Sooner or later the authoritative
NS RRSet of the delegated zone as well as those NS RRs' target names will
chime in, so both sources, glue and authoritative data, ought to be consistent.

Since the authoritative data is maintained by or close to the responsible name
server operator, it makes sense to rely upon this information and copy it into
the delegating zone as glue data where necessary.  However, access to the
authoritative information must happen securely, i.e., preserving authenticity
and integrity. In the current model, a provider of a DNS TLD name server does
not play an active role in the change process. While many TLD name service
providers are registries themselves, this is by no means a requirement,
so it cannot be assumed that IANA has a direct secure channel to the name
server operator.

Until other methods of DNS data origin authentication are deployed widely
enough, DNS glue data changes need to be authenticated through the available
channels. We therefore propose that any two or 10% (whichever is more) affected
TLD Managers (managers of those TLDs served by the name server in question)
may function as witnesses for the data change.
We assume that the TLD Managers do have secure channels with their name service
providers as well as with IANA and therefore can fulfill this role.

We would like to emphasize that the TLD Managers only act as witnesses;
they do not need to "agree" with the change. We suggest a timeout of two weeks
after which any change requested by an authorized initiator will be executed,
provided it passes all technical checks.

Any affected TLD may act as initiator of a change. A detailed outline of our
proposed scheme can be found further below.


Glue address changes with size changes 
--------------------------------------

There are cases where changes to the glue data would affect the policy
compliance of a third party delegation, i.e., when the addition of an RR to
an RRSet or the addition of an RRSet (most likely the AAAA RRSet) would expand
the size of a TLD referral response.  While still the authoritative data would
technically dominate the name resolution, in these cases it is most important
to keep the size of the referral below the 512 octet threshold.
Therefore, for any requested change that would increase the RRSet size (or add
an RRSet), all affected TLDs should be checked and the request be refused
if at least one of these TLDs would fail the size test with the new glue data.
This condition needs to be brought to the attention of IANA staff immediately.
It is assumed that these cases are rare and will be resolved by direct
communication with all affected TLDs.


Suggested Schedule for Glue Data Changes
----------------------------------------

1) Name server operator initiates change of authoritative address data.
   Name server (or servers) provide(s) service under all old and new addresses.

2) Name server operator notifies customers (affected TLD Registries).

3) One or more affected TLD Managers authenticate to the update system
   and initiate glue data update procedure (involves proper authorization).

4) Automated process compares authoritative DNS address records with the
   glue data repository, avoiding effects of caching.
   Any change will be presented to the initiator.
   If implementing the change would result in any of the affected TLD
   losing compliance with the DNS referral response size requirements,
   processing is stopped and IANA staff is notified immediately. Similar
   action should be taken if the network diversity requirements that are
   currently discussed under a different consultation were jeopardized by
   the address change.

5) Automated process identifies affected parties and sends notification
   messages. Timeout clock is started.

6) After the witness threshold is met (max(2, 10%)) or the timeout
   expires, the proposed change is again verified with the then current
   authoritative data. Pending any unforeseen changes and the technical
   checks (defined elsewhere), the glue data is changed in the root zone.
   If at least one witness questions the authenticity of the proposed new
   glue data, IANA staff is notified immediately to resolve the issue
   manually, including the opportunity to ignore the claim if an evaluation
   with due diligence supports the proposed change.

7) Name server operator may decommission the service on the old
   IP address(es) only after the updated root zone version has been
   fully distributed and one "expire" interval plus one "TTL" time
   has passed (currently 7 + 2 == 9 days).


Responses to Guiding Questions
------------------------------

1) How should IANA accept requests to alter root zone glue? (either in
   general, or specifically for shared glue)

     TLD Managers may act as initiators for name servers listed in their
     IANA Template. A procedure like the one outlined above would be
     applicable to both "shared" and "unshared" name servers. If a server
     is used by only a single TLD, this TLD can act as initiator and witness
     on its own behalf. For shared name servers, the proposed procedure
     avoids deadlocks by asking TLD registries to witness a glue data
     change and not to approve it.

2) What criteria should be used to approve shared root zone changes?

     See above. Since the primary source of name server address information
     is the authoritative data, the proposed procedure defaults to using
     this source. The witnesses assure authenticity and integrity of the
     data collected through the DNS to combat attacks on the change
     procedure by means of spoofed DNS responses.
     The more shared a name server is, the more critical the data is and
     thus more witnesses are required. The minimum number of two is proposed
     to prevent attacks by a compromised TLD access to the data management
     system. This, of course, does not apply to unshared name servers.

3) In the event that an affected party contests a change, how should this
   conflict resolved and on what grounds can a change proceed regardless?

     Since the prima facie evidence of a change is the authoritative DNS
     data, a party (TLD acting as witness) contesting a change must
     substantiate their claim. In any case, manual intervention is necessary
     and the change can proceed if this manual inspection unambiguously
     discovers the address RRSet(s) in question.

-----------------------------------------------------------------------------