--- Begin Message ---
DNS-Operations,
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
--- End Message ---
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
