[dns-operations] Input from dns-operations on NCAP proposal

Thu Jun 2 23:00:18 UTC 2022

On Mon, May 23, 2022 at 7:00 AM Thomas, Matthew via dns-operations <
dns-operations at dns-oarc.net> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: "Thomas, Matthew" <mthomas at verisign.com>
> To: "dns-operations at dns-oarc.net" <dns-operations at dns-oarc.net>
> Cc:
> Bcc:
> Date: Mon, 23 May 2022 13:48:12 +0000
> Subject: Input from dns-operations on NCAP proposal
>
> 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.
>

I think I understand the problems that NCAP is trying to solve, but want to
be sure that understanding is correct.

   - NCAP do not have (real-time and) continuous access to all of the root
   servers' query/response data, and need some other way to identify queries
   that currently result in NXDOMAIN responses, for specific TLDs prior to
   delegation
   - Due to QNAME minimization, the root servers would in many/most cases
   not see the full name for which the resolver is attempting resolution
   - NCAP would like to ensure it is safe to delegate a candidate TLD, on
   the basis of query data for that TLD prior to delegation.
   - NCAP would like to operate some sort of server that would receive DNS
   queries for such candidate TLD(s)
   - NCAP would like to not cause "no error" responses to any query at or
   below the candidate TLD(s) to be sent by their server. In other words,
   either directly or indirectly, the resolvers should send an NXDOMAIN for
   the candidate TLD as a result of the answers sent by NCAP

At any node in the DNS tree, currently, there are (to the best of my
knowledge) five possible DNS record type sets that can exist at that node:

   1. An ENT (empty non-terminal): an implicit node which exists only
   because of the existence of a descendant node (one of the other four types
   beneath the ENT in the DNS tree). An ENT by definition can never be a
   "leaf" node of the DNS tree
   2. A zone cut, aka delegation point, consisting of a non-apex NS RRSET
   (and if the zone is signed, the NS would NOT have an RRSIG, and would also
   have optionally DS RRSET, an RRSIG over the DS, and either an NSEC record
   plus its RRSIG or an NSEC3 record without an opt-out condition and its
   RRSIG.)
   3. A DNAME record (redirecting clients to another branch of the DNS tree
   for names that would have been beneath the owner of the DNAME record in the
   DNS tree)
   4. A CNAME record (redirecting clients to another node of the DNS tree
   for only the exact name match and applicable to all query RRTYPEs).
   5. Any other combinations of RRTYPEs.

NB: only ONE of those 5 types is allowed to exist at a given node in the
DNS tree; the NS RRTYPE exists on both sides of a zone cut, and on the
child side would be at the "apex" of the zone, and classified as type 5
(Any other combination). The apex of a zone is REQUIRED to have NS and SOA
records, of course.

Of these 5, only ONE can ever result in an NXDOMAIN response to a query for
the node itself, and only under specific circumstances -- the CNAME.
(A "lame" delegation due to a zone cut, would not result in NXDOMAIN, but
could result in REFUSED, SERVFAIL, or even a no-data, no-error referral
upwards.)

Here is the circumstance where a CNAME would result in an NXDOMAIN:
If the target (right-hand side) of a CNAME is itself a CNAME, and that
CNAME's target cannot be resolved, the response to a client would be an
NXDOMAIN, with the answer section consisting of the chain of CNAME records.
Other names beneath the CNAME

Deliberately setting up the following should allow a candidate TLD to be
configured so that queries for exactly the name of the TLD to be observed
(and result in NXDOMAIN answers from the resolver), and would leave
unaffected the children of the candidate TLD.

   - Establish a regular DNS server which serves some particular zone (e.g.
   ncap.example.net).
   - Add a CNAME record in that zone, for purposes of causing an NXDOMAIN
   result. This could be a non-existent name within the same zone -- this
   would be the recommended approach for the CNAME target.
      - deliberately-broken-cname.ncap.example.net CNAME
      does-not-exist.ncap.example.net.
   - In the root zone, add a CNAME record for the candidate TLD pointing to
   the owner name of the above CNAME.
      - candidate-tld. CNAME deliberately-broken-cname.ncap.example.net.
   - Configure appropriate monitoring to observe queries for
   deliberately-broken-cname.ncap.example.net on the DNS server
   - Configure the TTL of the in-zone CNAME record to cause re-queries from
   resolvers, to estimate query volume

Additional child record CNAMEs could be added with the same or similar
target(s).

   - Each CNAME would be added to the root zone, since there is no
   delegation involved.
      - e.g. common-name.candidate-tld. CNAME
      some-other-target-that-is-cnamed-to-nxdomain.ncap.example.net.

It would also be possible to add a wildcard CNAME below any FQDN, which
would match any descendant of the FQDN for which no existing name was
present in the zone. (Details of wildcard matching are omitted for brevity.)

   - e.g *.candidate-tld. CNAME
   wildcard-target-that-is-cnamee-to-nxdomain.ncap.example.net.

It would be advisable to do this first, before any consideration of doing
option 3.
None of the other options is advisable.

Brian Dickson

P.S. This solution can be tested and validated relatively easily, as it
only involves normal, standard DNS server(s) and supported record types.
P.P.S. Of course, you would need to supply your own real domain name
anywhere in the above that "example.net" appears.

>
>
> Best,
>
>
>
> Matt Thomas
>
> NCAP Co-chair
>
>
>
>
>
> ---------- Forwarded message ----------
> From: "Thomas, Matthew via dns-operations" <dns-operations at dns-oarc.net>
> To: "dns-operations at dns-oarc.net" <dns-operations at dns-oarc.net>
> Cc:
> Bcc:
> Date: Mon, 23 May 2022 13:48:12 +0000
> Subject: [dns-operations] Input from dns-operations on NCAP proposal
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220602/b73e97e4/attachment.html>