On Mon, May 23, 2022 at 1:53 PM Thomas, Matthew via dns-operations
wrote:
> 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
Any plan that starts with adding buggy TLDs to the root zone is
alarming and needs to be extremely carefully studied, but using
out-of-bailiwick nameservers -- a.ncap-servers.net? -- is easy and
would avoid an additional layer of likely caching difficulties,
potential resolution failure and name collisions.
> 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
