[DNSOP] Input from DNSOP on NCAP proposal

["Thomas, Matthew" <[e-mail]>]

DNSOP,

The Name Collision Analysis Project (NCAP) group is considering new ways in which additional DNS data can be collected for name collision assessment purposes while attempting to preserve the NXDOMAIN response dependent systems and applications currently receive from the root. We are looking for community input around any known technical challenges or problems with the proposed delegation strategies listed below. Here is some relevant background and context for the proposal.

First, within the context of NCAP, a name collision refers to the situation where a name that is defined and used in one DNS namespace may also appear in another. Users and applications intending to use a name in one namespace may attempt to use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces.

In the 2012 round of new gTLDs, DNS data collected at the root server system via DNS-OARC’s DITL collection was used to assess name collision visibility. The use of DITL data for name collision assessment purposes has growing limitations in terms of accessibility, increasing data anonymization constraints, a narrow data collection time window, and the limited annual collection frequency. Other changes in the DNS, such as Qname Minimization, Aggressive NSEC Caching, etc., also continue to impair name collision measurements at the root.

The 2012 round of new gTLDs used a technique called Controlled Interruption.  Attempts to query a new TLD during the controlled interruption period for an A record would result in an answer of the loopback address 127.0.53.53. The change from NXDOMAIN to an answer was intended to be a gentle disruption to systems experiencing name collisions (i.e., systems that were explicitly or implicitly relying on a NXDOMAIN response) and the mnemonic IP address was intended to lead investigative system administrators to informative web search results telling them about the TLD’s delegation.

In preparation for the next round of TLDs, the NCAP team is examining possible new ways of passively collecting additional DNS data while providing a less disruptive NXDOMAIN response to queries.

Currently, any recursive name server querying for non-delegated TLDs gets a NXDOMAIN from the root. Enumerating all possible ramifications of negative answers on end users and applications is not possible; every application can react differently to negative answers. Regardless of the reason, the errors received when returning a NXDOMAIN answer are both useful to systems and end users (e.g., spam filtering services, search list processing, etc.).

The proposed system below is an attempt to preserve the NXDOMAIN response these name collision systems are currently receiving, while enabling additional data collection capabilities. The NCAP is looking to the DNS community to see if you are aware of any kind of technical implications from a risk perspective that the proposed configurations would a.) cause systems to behave differently or b.) induce harmful collateral damage.

Proposal:

The proposal would involve delegating a candidate TLD. The delegation process of inserting a string into the DNS root zone will make the TLD active in the domain name system. The required delegation information in the referral from the root is a complete set of NS records and the minimal set of requisite glue records. The candidate TLD would be delegated to servers running custom DNS software. The TLD would not be DNSSEC signed.

We would like to understand which of the following configurations would be the least disruptive to systems and applications that were relying on the NXDOMAIN response.

Configuration 1: Generate a synthetic NXDOMAIN response to all queries with no SOA provided in the authority section.

Configuration 2: Generate a synthetic NXDOMAIN response to all queries with a SOA record.  Some example queries for the TLD .foo are below:

1) Query for bar.foo returns NXDOMAIN with SOA
2) Query for .foo returns NXDOMAIN with SOA
3) Query for .foo SOA returns NXDOMAIN with SOA
4) Query for ns1.foo NS or ns2.foo returns NXDOMAIN with SOA

Configuration 3: Use a properly configured empty zone with correct NS and SOA records. Queries for the single label TLD would return a NOERROR and NODATA response.

The level of disruption to existing private use of such labels by this restricted form of name delegation would be reasonably expected to be minimal; however, the series of referrals and responses received by resolvers are different from a direct NXDOMAIN response from the root server system and deviate from the DNS protocol. It is possible that even this slight difference could impact application resolution processes, such as search list processing. The NCAP would appreciate any technical insights from a risk perspective the community may be able to provide regarding the proposal.

Best,

Matt Thomas
NCAP Co-chair