<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 23, 2022 at 7:00 AM Thomas, Matthew via dns-operations <<a href="mailto:dns-operations@dns-oarc.net">dns-operations@dns-oarc.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br><br>---------- Forwarded message ----------<br>From: "Thomas, Matthew" <<a href="mailto:mthomas@verisign.com" target="_blank">mthomas@verisign.com</a>><br>To: "<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>" <<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>><br>Cc: <br>Bcc: <br>Date: Mon, 23 May 2022 13:48:12 +0000<br>Subject: Input from dns-operations on NCAP proposal<br>
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_5175569554266658208WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">DNS-Operations,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">Currently, any recursive name server querying for non-delegated TLDs gets a NXDOMAIN from the root.</span><span style="font-size:11pt;font-family:"Times New Roman",serif;color:black">
</span><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.).</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">Proposal</span></b><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">:</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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. </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">Configuration 1: Generate a synthetic NXDOMAIN response to all queries with no SOA provided in the authority section.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">Configuration 2: Generate a synthetic NXDOMAIN response to all queries with a SOA record. Some example queries for the TLD .foo are below:</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">1) Query for bar.foo returns NXDOMAIN with SOA</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">2) Query for .foo returns NXDOMAIN with SOA</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">3) Query for .foo SOA returns NXDOMAIN with SOA</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">4) Query for ns1.foo NS or ns2.foo returns NXDOMAIN with SOA</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">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.</span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">The level of disruption to existing private use of such labels by this restricted form of name delegation would be reasonably expected to be
<i>minimal</i>; 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.</span></p></div></div></blockquote><div><br></div><div>I think I understand the problems that NCAP is trying to solve, but want to be sure that understanding is correct.</div><div><ul><li>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</li><li>Due to QNAME minimization, the root servers would in many/most cases not see the full name for which the resolver is attempting resolution</li><li>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.</li><li>NCAP would like to operate some sort of server that would receive DNS queries for such candidate TLD(s)</li><li>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</li></ul><div>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:</div></div><div><ol><li>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</li><li>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.)</li><li>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)</li><li>A CNAME record (redirecting clients to another node of the DNS tree for only the exact name match and applicable to all query RRTYPEs).</li><li>Any other combinations of RRTYPEs.</li></ol><div>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.</div><div><br></div><div>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. </div><div>(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.)</div></div><div><br></div><div>Here is the circumstance where a CNAME would result in an NXDOMAIN:</div><div>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.</div><div>Other names beneath the CNAME </div><div><br></div><div>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.</div><div><br></div><div><ul><li>Establish a regular DNS server which serves some particular zone (e.g. <a href="http://ncap.example.net">ncap.example.net</a>).</li><li>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.</li><ul><li><a href="http://deliberately-broken-cname.ncap.example.net">deliberately-broken-cname.ncap.example.net</a> CNAME <a href="http://does-not-exist.ncap.example.net">does-not-exist.ncap.example.net</a>.</li></ul><li>In the root zone, add a CNAME record for the candidate TLD pointing to the owner name of the above CNAME.</li><ul><li>candidate-tld. CNAME <a href="http://deliberately-broken-cname.ncap.example.net">deliberately-broken-cname.ncap.example.net</a>.</li></ul><li>Configure appropriate monitoring to observe queries for <a href="http://deliberately-broken-cname.ncap.example.net">deliberately-broken-cname.ncap.example.net</a> on the DNS server</li><li>Configure the TTL of the in-zone CNAME record to cause re-queries from resolvers, to estimate query volume</li></ul><div>Additional child record CNAMEs could be added with the same or similar target(s). </div><div><ul><li>Each CNAME would be added to the root zone, since there is no delegation involved.</li><ul><li>e.g. common-name.candidate-tld. CNAME <a href="http://some-other-target-that-is-cnamed-to-nxdomain.ncap.example.net">some-other-target-that-is-cnamed-to-nxdomain.ncap.example.net</a>.</li></ul></ul></div></div><div>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.)</div><div><ul><li>e.g *.candidate-tld. CNAME <a href="http://wildcard-target-that-is-cnamee-to-nxdomain.ncap.example.net">wildcard-target-that-is-cnamee-to-nxdomain.ncap.example.net</a>.</li></ul><div>It would be advisable to do this first, before any consideration of doing option 3.</div></div><div>None of the other options is advisable.</div><div><br></div><div>Brian Dickson</div><div><br></div><div>P.S. This solution can be tested and validated relatively easily, as it only involves normal, standard DNS server(s) and supported record types.</div><div>P.P.S. Of course, you would need to supply your own real domain name anywhere in the above that "<a href="http://example.net">example.net</a>" appears.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_5175569554266658208WordSection1"><p class="MsoNormal"><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Arial,sans-serif;color:black"> </span><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Best,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Matt Thomas<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">NCAP Co-chair<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
</div>
</div>
<br><br><br>---------- Forwarded message ----------<br>From: "Thomas, Matthew via dns-operations" <<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>><br>To: "<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>" <<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>><br>Cc: <br>Bcc: <br>Date: Mon, 23 May 2022 13:48:12 +0000<br>Subject: [dns-operations] Input from dns-operations on NCAP proposal<br>_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div>