<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=Windows-1252">
<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:10.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;}
.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"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">“Consensus” that this is a good, clever, and potentially useful technical approach that should certainly be in the TRT’s “toolbox” – yes. Uncontroversial.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">“Consensus” that this particular technical technique should/must(?) be used at some certain point, for some certain duration, during 202x round procedures – no.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This isn’t a one-for-one with 2012 CI because there is no notification value of 127.0.53.53 appearing in logs or manual dig/nslookup invocations. This approach may be used in a “rotation” with 2012 CI in the
spirit of maximizing notification opportunity and coverage. My understanding is that this would break clients without any notification or rationale or log other than “something failed at the application layer” – and may be even more difficult for them to debug
because the DNS layer doesn’t appear to have returned an error. Anyone experiencing collisions issues isn’t likely to have a clue about HINFO and they’ll be left befuddled. If we really want to confuse the people that need our help – this is the way to do
it. Yes, we may get better data. Might. But is the juice worth the squeeze?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This seems like a great way to confuse the people we’re trying to help. Notification value seems to have gone from “questionable” to “zero”:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">A regular dig returns NOERROR and an empty rrset. Full stop – no one suffering from collisions issues will understand that:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">% dig +short abc123.cloudflare-dns.com<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">%<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><empty rrset, no errors, wth?><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">If someone knows to ask for ANY, they’ll get:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">% dig +short -t any abc123.cloudflare-dns.com<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"RFC8482" ""<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">HINFO 13 3 3600 20230829163530 20230827143530 34505 cloudflare-dns.com. QP6uSm2mnGdv+8MbGcnmFZhkmV5shRnxe/SrIV41WnyL+XutBn+zh+2C gUvDVMoIXTJQ0OtReNYW3/0m03+mwQ==<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">%<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This helps our vulnerable young Jedi sysadmins how?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Related, Wikipedia now knows about 127.0.53.53. I didn’t do this, but someone did c. 2018:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><a href="https://en.wikipedia.org/wiki/Wildcard_DNS_record">https://en.wikipedia.org/wiki/Wildcard_DNS_record</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Hard to argue against the “notification brand equity” present in 127.0.53.53. If we really want to notify and help people, why does NCAP at every turn seem to invent ways to *<b>not</b>* leverage the value/awareness
already present in 127.0.53.53?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The NCAP seems to suffer from the “good idea fairy.”
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jeff<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><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 Thomas, Matthew via NCAP-Discuss <ncap-discuss@icann.org><br>
<b>Date: </b>Monday, August 28, 2023 at 4:31 AM<br>
<b>To: </b>casey@deccio.net <casey@deccio.net>, ncap-discuss@icann.org <ncap-discuss@icann.org><br>
<b>Subject: </b>Re: [NCAP-Discuss] Nearly-empty TLD zone contents (was Re: Outline of possible phases)<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Thank you Casey.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">If no questions/comments/concerns arise – shall we call consensus on this technical aspect of the workflow within PCA?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Matt<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></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)</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></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-size:10.0pt;font-family:"Calibri",sans-serif;color:#993300">Caution:</span></strong><span style="font-size:10.0pt;font-family:"Times New Roman",serif;color:#993300"> </span><span style="font-size:10.0pt;font-family:"Times New Roman",serif;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><span style="font-size:10.0pt;font-family:"Times New Roman",serif"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Aug 16, 2023, at 11:48 AM, Casey Deccio <</span><a href="mailto:casey@deccio.net"><span style="font-size:11.0pt">casey@deccio.net</span></a><span style="font-size:11.0pt">> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Example (60-second TTL):<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">$TTL<span class="apple-tab-span">
</span>60<br>
@<span class="apple-tab-span"> </span>IN<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">SOA<span class="apple-tab-span">
</span>localhost. root.localhost. (<br>
1<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">; Serial<br>
3600<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">; Refresh<br>
3600<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">; Retry<br>
86400<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">; Expire<br>
60 )<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">; Negative Cache TTL<br>
@<span class="apple-tab-span"> </span>IN<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">NS<span class="apple-tab-span">
</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"><span style="font-size:11.0pt">ns1.trial-delegation.icann.org</span></a><span style="font-size:11.0pt">.<br>
@<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">IN<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">NS<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"><span style="font-size:11.0pt">ns2.trial-delegation.icann.org</span></a><span style="font-size:11.0pt">.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">* HINFO "" ""<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><begin DNS snippet><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">$ dig +dnssec @ns1.cloudflare-dns.com
</span><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"><span style="font-size:11.0pt">abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt"><br>
;; communications error to 162.159.0.33#53: timed out<br>
<br>
; <<>> DiG 9.18.17 <<>> +dnssec @ns1.cloudflare-dns.com </span><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"><span style="font-size:11.0pt">abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt"><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>
;</span><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"><span style="font-size:11.0pt">abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">IN<span class="apple-tab-span">
</span>A<br>
<br>
;; AUTHORITY SECTION:<br>
</span><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"><span style="font-size:11.0pt">cloudflare-dns.com</span></a><span style="font-size:11.0pt">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">1800<span class="apple-tab-span">
</span>IN<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">SOA<span class="apple-tab-span">
</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"><span style="font-size:11.0pt">ns1.cloudflare-dns.com</span></a><span style="font-size:11.0pt">.
</span><a href="http://secure-web.cisco.com/1sk3CtE0xcEeQ8uZ4kkUZUvNDjPYYvrKhxzONWRmszMf_l8i853izpE-QiK9Buu2QLpvB-yDK0Nr6jHnE1X5Yb3lgUoRc76h3GCpvMenBH7Bm98HpeWWUXQcl28WhbNLqo3kDBAXyx9fcEc62sLnEKJAs-Zr4jrKbwRjQ1wK2XntwL-8q_6USSuhAubsFJcdXNfCFJ69dnNEesUX9Ckr8WOEIWz2qW-5fJLfwznIiN02Ka53xkrU2kH5y0qrqDClISj32OhdtRMmH1XRZpKrg1G_y5QidfukF22PUpwTgxxM/http%3A%2F%2Fdns.cloudflare.com"><span style="font-size:11.0pt">dns.cloudflare.com</span></a><span style="font-size:11.0pt">. 2317900719
10000 2400 604800 1800<br>
</span><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"><span style="font-size:11.0pt">abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt">.
1800<span class="apple-tab-span"> </span>IN<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">NSEC<span class="apple-tab-span">
</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"><span style="font-size:11.0pt">000.abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt">.
RRSIG NSEC TYPE65283<br>
</span><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"><span style="font-size:11.0pt">cloudflare-dns.com</span></a><span style="font-size:11.0pt">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">1800<span class="apple-tab-span">
</span>IN<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">RRSIG<span class="apple-tab-span">
</span>SOA 13 2 1800 20230824173340 20230822153340 34505 </span><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"><span style="font-size:11.0pt">cloudflare-dns.com</span></a><span style="font-size:11.0pt">.
v1vdQ5FyVwdvwl6ovxwzdMlcRbGmTyUj4tzjjn4DSOkaxI+Hrks9VATS eft4Wmzv40ApGg9Mv8rY3oCJQcSE7A==<br>
</span><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"><span style="font-size:11.0pt">abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt">.
1800<span class="apple-tab-span"> </span>IN<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">RRSIG<span class="apple-tab-span">
</span>NSEC 13 3 1800 20230824173340 20230822153340 34505 </span><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"><span style="font-size:11.0pt">cloudflare-dns.com</span></a><span style="font-size:11.0pt">.
fjSv13nBRDZ2l2oYir+/Hx3BQQkF/kg7vSX5ZvyCUrtmAASHLeZeudII SrhlPeiaOD2WE16A8VTdcnelC8YFZg==<br>
<br>
;; Query time: 83 msec<br>
;; SERVER: 162.159.0.33#53(</span><a href="http://secure-web.cisco.com/1wcsbCurLVpDq3_RNZDWv1ogzNl2Befk89xvuA70Kt1WS-Z8I8td0kfpKqaE2v7MT2zArgeSNbkTt6brFxswQTO_TQkfYu8AoBaJnOrJdztwVJQChw48BkVhyREJM8nuONq6xDRPX_ro4Mu2SkRo8ZMch7QmLKSWwO2xzVh8UnVZfKSAbznzocbQxxCGJFlILN6hHFAu0jU5vp90xNe5X_XmhMikng6kkJHFqeuxr5OJdfM8g7-be8gYZiUzPWFJOX0Mm6_A4YWXZ1Loys_8r8HP7hhWX72381YlrVlOlFc0/http%3A%2F%2Fns1.cloudflare-dns.com"><span style="font-size:11.0pt">ns1.cloudflare-dns.com</span></a><span style="font-size:11.0pt">)
(UDP)<br>
;; WHEN: Wed Aug 23 10:33:40 MDT 2023<br>
;; MSG SIZE rcvd: 389<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"><end DNS snippet></span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"><br>
<br>
<br>
</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">In the above example, </span><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"><span style="font-size:11.0pt">abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt">
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 </span><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"><span style="font-size:11.0pt">abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt">.
and \</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"><span style="font-size:11.0pt">000.abc123.cloudflare-dns.com</span></a><span style="font-size:11.0pt">.
-- i.e., a minimal covering.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Linux, There are two errors related to NXDOMAIN/NODATA (man getaddrinfo):<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> 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></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On MacOS, there is a single error related to NXDOMAIN/NODATA (man gai_strerror):<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> EAI_NONAME hostname or servname not provided, or not known<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">When I test these, indeed both NXDOMAIN and NODATA result in EAI_NONAME being returned.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Thus, NXDOMAIN and NODATA are indistinguishable from the perspective of the program using getaddrinfo().<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Windows, There are two errors related to NXDOMAIN/NODATA [3]:<br>
WSAHOST_NOT_FOUND<br>
WSANO_DATA<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I have not tested Windows to confirm behavior.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;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><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Casey</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">[1] </span><a href="https://secure-web.cisco.com/1OY2JMpKFNMhoE6dMnH0NeVjdRi7bi8sefUT88HxdJCbM3igkd23fvMpjO-yGOo-q74chdKNFHc7BKf-BtUEwnRb5Z1flhPvLZmx6o-5hy4LIMPRCqxzxqAdSAGsXbgukQ3zbVT8n67_F5J6ALEg73IZ_m7aaYoluslHMpfnSPDyuKRyvIoR8CFjOVCOcr91YlAjM0wcant0jRWtDOPhe32SrHp1pGlS4Fki2JApFt3U3Y6rZepir3ooUenFvHAtGjNjjhRxbYvzEdlymFHXNjddwRDKiUmHnEDEx1RkQNTY/https%3A%2F%2Fblog.cloudflare.com%2Fblack-lies%2F"><span style="font-size:11.0pt">https://blog.cloudflare.com/black-lies/</span></a><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">[2] </span><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"><span style="font-size:11.0pt">https://tranco-list.eu/</span></a><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">[3] </span><a href="https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2"><span style="font-size:11.0pt">https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2</span></a><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">[4] </span><a href="https://docs.google.com/document/d/1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing"><span style="font-size:11.0pt">https://docs.google.com/document/d/1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing</span></a><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>