<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.apple-tab-span
        {mso-style-name:apple-tab-span;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word;-webkit-nbsp-mode: space;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal">Thank you Casey.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This had some good discussion during last week’s NCAP DG call.  It seemed to me the group was largely supportive of this for the technical description of PCA.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If no questions/comments/concerns arise – shall we call consensus on this technical aspect of the workflow within PCA?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Matt<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">NCAP-Discuss <ncap-discuss-bounces@icann.org> on behalf of Casey Deccio <casey@deccio.net><br>
<b>Date: </b>Wednesday, August 23, 2023 at 8:22 PM<br>
<b>To: </b>NCAP Discussion Group <ncap-discuss@icann.org><br>
<b>Subject: </b>[EXTERNAL] Re: [NCAP-Discuss] Nearly-empty TLD zone contents (was Re: Outline of possible phases)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<table class="MsoNormalTable" border="0" cellpadding="0" width="1185" style="width:888.75pt;background:#F5ECCE">
<tbody>
<tr>
<td width="1175" style="width:881.25pt;padding:.75pt .75pt .75pt .75pt">
<p><strong><span style="font-family:"Calibri",sans-serif;color:#993300">Caution:</span></strong><span style="color:#993300"> </span><span style="color:black">This email originated from outside the organization. Do not click links or open attachments unless
 you recognize the sender and know the content is safe. </span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Aug 16, 2023, at 11:48 AM, Casey Deccio <<a href="mailto:casey@deccio.net">casey@deccio.net</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">3. Finally, to more fully address the issue of qname minimization (#3) -- for which a low TTL might not help -- here is a new idea to help see the full qname where it would otherwise be lost on qname-minimizing resolvers that follow the
 NXDOMAIN principles in RFC 8020.  We add a wildcard HINFO record to the zone.  This would make it so that queries for foo.applied-for-tld-string would result in NOERROR (empty answer) instead of NXDOMAIN, which means that the resolver has no choice but to
 query again for  bar.foo.applied-for-tld-string, even if it strictly follows the RFC 8020 principles.  Note that this is inspired by RFC 8482, where HINFO is used for minimal ANY responses, but it is applied here for a different purpose.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Here is the resulting zone, with 1) no DNSSEC, 2) 60-second TTL and negative cache TTL, and 3) the use of an HINFO record:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Example (60-second TTL):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">$TTL<span class="apple-tab-span"> </span>60<br>
@<span class="apple-tab-span"> </span>IN<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">SOA<span class="apple-tab-span"> </span>localhost. root.localhost. (<br>
      1<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">; Serial<br>
 3600<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">; Refresh<br>
 3600<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">; Retry<br>
86400<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">; Expire<br>
 60 )<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">; Negative Cache TTL<br>
@<span class="apple-tab-span"> </span>IN<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">NS<span class="apple-tab-span"> </span><a href="http://secure-web.cisco.com/12lPYSMu0zdHdvAkLCz0oTmb9iU7KyqlOTpYH9a76G10muwigKaGNoEkdOQ8etcyrCIJ57icnxNrFpoMoGEFu2GhEFVvGVkB_fz2urSm-PqFXtgtn6g-I4aF5DHzouIK6bHLqFWY8mwmiIDhEiz4xZI3jJjd_4bb5ROOAC2pTIuiWlrIlhLpzeJzomdZDxDZn7t0CrMK5QeNFJLKpBO_eS4gP9p8m7OjIRtGb1gPCkc3lk3ZFFzrF3-ENx1lAhKcGQU4OgkHxVkvO7Bq43IOhiuGxrqUWVq-SYiWIKRg8yZk/http%3A%2F%2Fns1.trial-delegation.icann.org%2F">ns1.trial-delegation.icann.org</a>.<br>
@<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">IN<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">NS<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal"><a href="http://secure-web.cisco.com/1KBK2jpYQdOdeD8LH11nBgogbI_ec2yIMhknIHQEMhPG4yVeOkdQZCqH3AH2qJM21BilMbNwFpUe7fnCPaUIKhB6znUb0dFYKDDSoEXD2v06RVPUHPBttyTkfrTrH7y29lGEThkApLlgu5MQVNu4BmA_dq2JeEXS2xsR9fxeIvbrHyHHY2OovcJYvYtRHqdI2ShSU1IaelTjvzI-WLRBrBA5g3hjLw9XkTbb5D_1uc-7_m8G3UZmNkMkPQ4xDgt2TwQHtOzU2LqO_QSA2KEiJH7paPiCkSrrbXGiMfY2FkSU/http%3A%2F%2Fns2.trial-delegation.icann.org%2F">ns2.trial-delegation.icann.org</a>.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">*   HINFO "" ""<br>
<br>
<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I know that the HINFO record idea is new, and there might be some concerns with that.  It is still a negative response (NXDOMAIN vs. NOERROR).  Like anything else proposed, this has to do with the risk/reward we are looking for.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Because there was some discussion in the last meeting about the concerns with NOERROR vs. NXDOMAIN coming from the servers associated with a,  this email explores those issues a bit more.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">First, let me mention that there is some precedent to this approach.  Cloudflare's "black lies" approach to DNSSEC results in smaller response sizes [1].  They do this by responding to queries that would otherwise result in NXDOMAIN with
 a NODATA response (NOERROR with empty answer section).  This allows their servers to divulge less about the names in a given DNS zone.  For example:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><begin DNS snippet><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">$ dig +dnssec @ns1.cloudflare-dns.com <a href="http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com">
abc123.cloudflare-dns.com</a><br>
;; communications error to 162.159.0.33#53: timed out<br>
<br>
; <<>> DiG 9.18.17 <<>> +dnssec @ns1.cloudflare-dns.com <a href="http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com">
abc123.cloudflare-dns.com</a><br>
; (1 server found)<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11807<br>
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1<br>
;; WARNING: recursion requested but not available<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags: do; udp: 1232<br>
;; QUESTION SECTION:<br>
;<a href="http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com">abc123.cloudflare-dns.com</a>.<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">IN<span class="apple-tab-span"> </span>A<br>
<br>
;; AUTHORITY SECTION:<br>
<a href="http://secure-web.cisco.com/1yIULp4vifzwjO5tdNamJUsmPRrwBI12UOqD_U5GU_GMxFGDn-yhyUsvAerdfLP3ilWbw8s67xVVs_iLyO9INO9c3ZYz9-woYIkC3saVcafT6XClF9kCW7CyJA5_wIQ5hKPY_OUsmgDeCzanM-sjgYbBKvSa_YZOwVWyR5POM72HjZS5I9mqT-_AIbVTvDMrivALe2LwNfEnrA5OBTabivvZfeZzjoI1f9jcVVUWNZlKy0xfymPUxLQu_M3SXiM-BgKeda3cv3kc6zzo-Hlu51kIwp8wgVpzXPoud7rmiZu0/http%3A%2F%2Fcloudflare-dns.com">cloudflare-dns.com</a>.<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">1800<span class="apple-tab-span"> </span>IN<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">SOA<span class="apple-tab-span"> </span><a href="http://secure-web.cisco.com/1wcsbCurLVpDq3_RNZDWv1ogzNl2Befk89xvuA70Kt1WS-Z8I8td0kfpKqaE2v7MT2zArgeSNbkTt6brFxswQTO_TQkfYu8AoBaJnOrJdztwVJQChw48BkVhyREJM8nuONq6xDRPX_ro4Mu2SkRo8ZMch7QmLKSWwO2xzVh8UnVZfKSAbznzocbQxxCGJFlILN6hHFAu0jU5vp90xNe5X_XmhMikng6kkJHFqeuxr5OJdfM8g7-be8gYZiUzPWFJOX0Mm6_A4YWXZ1Loys_8r8HP7hhWX72381YlrVlOlFc0/http%3A%2F%2Fns1.cloudflare-dns.com">ns1.cloudflare-dns.com</a>.
<a href="http://secure-web.cisco.com/1sk3CtE0xcEeQ8uZ4kkUZUvNDjPYYvrKhxzONWRmszMf_l8i853izpE-QiK9Buu2QLpvB-yDK0Nr6jHnE1X5Yb3lgUoRc76h3GCpvMenBH7Bm98HpeWWUXQcl28WhbNLqo3kDBAXyx9fcEc62sLnEKJAs-Zr4jrKbwRjQ1wK2XntwL-8q_6USSuhAubsFJcdXNfCFJ69dnNEesUX9Ckr8WOEIWz2qW-5fJLfwznIiN02Ka53xkrU2kH5y0qrqDClISj32OhdtRMmH1XRZpKrg1G_y5QidfukF22PUpwTgxxM/http%3A%2F%2Fdns.cloudflare.com">
dns.cloudflare.com</a>. 2317900719 10000 2400 604800 1800<br>
<a href="http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com">abc123.cloudflare-dns.com</a>.
 1800<span class="apple-tab-span"> </span>IN<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">NSEC<span class="apple-tab-span"> </span>\<a href="http://secure-web.cisco.com/1UJ3V0KQgNal-eho23Yc6R7zO8k8OsFni7-B0OJPsGiHPxbCmWf8AHd9d9pRYT_2a4Mitr5bKCzMMUz4QyvlpaVMxm_LvQgB2yZTMzCoW5eUDg4usshfPGSlajwY0zgsRbt5CwvTplxzXqJHiEizv5D0Fptafpmy-HErsGdiPb_JRuM0A49sUzpGONZ6FDvp0-wNDwEsTPiIEJi6UTfAdpl2Q2uhWjo2wxiVWO_Fg86HxyOkwIDr537mfHgFIVzwJg9UNG_xtRFpVbr8dBE_8h-wIi69s60Ny2RJha-QlMMM/http%3A%2F%2F000.abc123.cloudflare-dns.com">000.abc123.cloudflare-dns.com</a>.
 RRSIG NSEC TYPE65283<br>
<a href="http://secure-web.cisco.com/1yIULp4vifzwjO5tdNamJUsmPRrwBI12UOqD_U5GU_GMxFGDn-yhyUsvAerdfLP3ilWbw8s67xVVs_iLyO9INO9c3ZYz9-woYIkC3saVcafT6XClF9kCW7CyJA5_wIQ5hKPY_OUsmgDeCzanM-sjgYbBKvSa_YZOwVWyR5POM72HjZS5I9mqT-_AIbVTvDMrivALe2LwNfEnrA5OBTabivvZfeZzjoI1f9jcVVUWNZlKy0xfymPUxLQu_M3SXiM-BgKeda3cv3kc6zzo-Hlu51kIwp8wgVpzXPoud7rmiZu0/http%3A%2F%2Fcloudflare-dns.com">cloudflare-dns.com</a>.<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">1800<span class="apple-tab-span"> </span>IN<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">RRSIG<span class="apple-tab-span"> </span>SOA 13 2 1800 20230824173340 20230822153340 34505
<a href="http://secure-web.cisco.com/1yIULp4vifzwjO5tdNamJUsmPRrwBI12UOqD_U5GU_GMxFGDn-yhyUsvAerdfLP3ilWbw8s67xVVs_iLyO9INO9c3ZYz9-woYIkC3saVcafT6XClF9kCW7CyJA5_wIQ5hKPY_OUsmgDeCzanM-sjgYbBKvSa_YZOwVWyR5POM72HjZS5I9mqT-_AIbVTvDMrivALe2LwNfEnrA5OBTabivvZfeZzjoI1f9jcVVUWNZlKy0xfymPUxLQu_M3SXiM-BgKeda3cv3kc6zzo-Hlu51kIwp8wgVpzXPoud7rmiZu0/http%3A%2F%2Fcloudflare-dns.com">
cloudflare-dns.com</a>. v1vdQ5FyVwdvwl6ovxwzdMlcRbGmTyUj4tzjjn4DSOkaxI+Hrks9VATS eft4Wmzv40ApGg9Mv8rY3oCJQcSE7A==<br>
<a href="http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com">abc123.cloudflare-dns.com</a>.
 1800<span class="apple-tab-span"> </span>IN<span class="apple-tab-span"><o:p></o:p></span></p>
<p class="MsoNormal">RRSIG<span class="apple-tab-span"> </span>NSEC 13 3 1800 20230824173340 20230822153340 34505
<a href="http://secure-web.cisco.com/1yIULp4vifzwjO5tdNamJUsmPRrwBI12UOqD_U5GU_GMxFGDn-yhyUsvAerdfLP3ilWbw8s67xVVs_iLyO9INO9c3ZYz9-woYIkC3saVcafT6XClF9kCW7CyJA5_wIQ5hKPY_OUsmgDeCzanM-sjgYbBKvSa_YZOwVWyR5POM72HjZS5I9mqT-_AIbVTvDMrivALe2LwNfEnrA5OBTabivvZfeZzjoI1f9jcVVUWNZlKy0xfymPUxLQu_M3SXiM-BgKeda3cv3kc6zzo-Hlu51kIwp8wgVpzXPoud7rmiZu0/http%3A%2F%2Fcloudflare-dns.com">
cloudflare-dns.com</a>. fjSv13nBRDZ2l2oYir+/Hx3BQQkF/kg7vSX5ZvyCUrtmAASHLeZeudII SrhlPeiaOD2WE16A8VTdcnelC8YFZg==<br>
<br>
;; Query time: 83 msec<br>
;; SERVER: 162.159.0.33#53(<a href="http://secure-web.cisco.com/1wcsbCurLVpDq3_RNZDWv1ogzNl2Befk89xvuA70Kt1WS-Z8I8td0kfpKqaE2v7MT2zArgeSNbkTt6brFxswQTO_TQkfYu8AoBaJnOrJdztwVJQChw48BkVhyREJM8nuONq6xDRPX_ro4Mu2SkRo8ZMch7QmLKSWwO2xzVh8UnVZfKSAbznzocbQxxCGJFlILN6hHFAu0jU5vp90xNe5X_XmhMikng6kkJHFqeuxr5OJdfM8g7-be8gYZiUzPWFJOX0Mm6_A4YWXZ1Loys_8r8HP7hhWX72381YlrVlOlFc0/http%3A%2F%2Fns1.cloudflare-dns.com">ns1.cloudflare-dns.com</a>)
 (UDP)<br>
;; WHEN: Wed Aug 23 10:33:40 MDT 2023<br>
;; MSG SIZE  rcvd: 389<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><end DNS snippet></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><br>
<br>
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">In the above example,  <a href="http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com">abc123.cloudflare-dns.com</a>
 does not exist.  However, the server indicates that it does exist, but with only RRSIG and NSEC records.  And it indicates that there is nothing between <a href="http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com">abc123.cloudflare-dns.com</a>.
 and \<a href="http://secure-web.cisco.com/1UJ3V0KQgNal-eho23Yc6R7zO8k8OsFni7-B0OJPsGiHPxbCmWf8AHd9d9pRYT_2a4Mitr5bKCzMMUz4QyvlpaVMxm_LvQgB2yZTMzCoW5eUDg4usshfPGSlajwY0zgsRbt5CwvTplxzXqJHiEizv5D0Fptafpmy-HErsGdiPb_JRuM0A49sUzpGONZ6FDvp0-wNDwEsTPiIEJi6UTfAdpl2Q2uhWjo2wxiVWO_Fg86HxyOkwIDr537mfHgFIVzwJg9UNG_xtRFpVbr8dBE_8h-wIi69s60Ny2RJha-QlMMM/http%3A%2F%2F000.abc123.cloudflare-dns.com">000.abc123.cloudflare-dns.com</a>.
 -- i.e., a minimal covering.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My point in demonstrating this is to show that Cloudflare servers have been returning NOERROR responses in place of NXDOMAIN responses for the past 6-7 years.  Note that their servers only respond this way if 1) the domain is signed and
 2) the DO (DNSSEC OK) bit is set in the query -- but that is the behavior of most DNS resolvers, even if they aren't configured to do DNSSEC validation.  There are approximately 22K domains in the Tranco list of top domains [2] that are signed and hosted by
 Cloudflare.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Now let's look at the behavior of getaddrinfo() -- the de facto library call on various OSes. When there is an error, getaddrinfo() returns a non-zero value corresponding to the error encountered.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On Linux, There are two errors related to NXDOMAIN/NODATA (man getaddrinfo):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">       EAI_NODATA<br>
       EAI_NONAME<br>
When I test these, they work as expected; a name that results in NXDOMAIN returns EAI_NONAME, and a name that results in NODATA returns EAI_NODATA.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On MacOS, there is a single error related to NXDOMAIN/NODATA (man gai_strerror):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">       EAI_NONAME        hostname or servname not provided, or not known<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">When I test these, indeed both NXDOMAIN and NODATA result in EAI_NONAME being returned.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thus, NXDOMAIN and NODATA are indistinguishable from the perspective of the program using getaddrinfo().<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On Windows, There are two errors related to NXDOMAIN/NODATA [3]:<br>
       WSAHOST_NOT_FOUND<br>
       WSANO_DATA<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I have not tested Windows to confirm behavior.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Because NXDOMAIN/NODATA is exposed via the getaddrinfo() interface (on Linux and Windows), it's possible that an application could react differently or that a new error message could result.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">However, let us consider this from the context of the root causes, using section 5.3 of the Root Cause Analysis document [4] as a baseline.  Of the 13 reports analyzed for which it could be determined whether or not private namespace was
 being used, 11 (85%) indicated that private namespace was being used.  For example, supposing "foo" is a nonexistent TLD, "<span style="color:black">example.foo" is being used by a given organization.  In this case, the organization typically configures its
 resolvers to answer authoritatively for names ending in "foo", keeping them from forwarding the queries to Internet DNS servers.  The only time queries do go to the Internet then is when the resolvers are misconfigured or when a mobile system is connected
 to a network outside the corporate network, so it's not using the configured resolvers.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">What this means is that resolution of names in private namespace under nonexistent TLDs fails when those queries reach public authoritative servers.  That's good, of course, because things become problematic when
 the names *resolve*.  Currently resolution fails with NXDOMAIN, but with a NODATA configuration, they would still fail, just with different a different error.  My question is if the problem is when names resolve -- does it matter how resolution fails, as long
 as it fails?  I suppose it could, but I can't think of a use case for that.  Again, the problem is when they *do* resolve.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Casey</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://secure-web.cisco.com/1OY2JMpKFNMhoE6dMnH0NeVjdRi7bi8sefUT88HxdJCbM3igkd23fvMpjO-yGOo-q74chdKNFHc7BKf-BtUEwnRb5Z1flhPvLZmx6o-5hy4LIMPRCqxzxqAdSAGsXbgukQ3zbVT8n67_F5J6ALEg73IZ_m7aaYoluslHMpfnSPDyuKRyvIoR8CFjOVCOcr91YlAjM0wcant0jRWtDOPhe32SrHp1pGlS4Fki2JApFt3U3Y6rZepir3ooUenFvHAtGjNjjhRxbYvzEdlymFHXNjddwRDKiUmHnEDEx1RkQNTY/https%3A%2F%2Fblog.cloudflare.com%2Fblack-lies%2F">https://blog.cloudflare.com/black-lies/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://secure-web.cisco.com/1hNTXhI3q6KE7NHjgc2r_bJ8whYPK5acdNM4ANjrGLKcEmEVy8eVGYBNlLXjLe34wyXSn--8ATA6P3aY_B22o2XANZ4ReDeygyGemPsAiDod4EJHIByyK7FrXVR58KchWDPfLKQHs7H147pW-jseQJFV0zfiy-rZKCbqjEeDB-zxyv4sVodtLUnSGgZZ3YzW7t-OjSgELPBuSglt-DprirhzZKBavCNie05O5wQfEgm56y-z0zAbfvz4sGkA7E_x6qBBqnXRQJL30okmhNu9Hj7nzxW9WhTrLwdglAS1TQuc/https%3A%2F%2Ftranco-list.eu%2F">https://tranco-list.eu/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[3] <a href="https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2">https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[4] <a href="https://docs.google.com/document/d/1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing">
https://docs.google.com/document/d/1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing</a><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>