[NCAP-Discuss] Nearly-empty TLD zone contents (was Re: Outline of possible phases)

Mon Aug 28 15:46:59 UTC 2023

“Consensus” that this is a good, clever, and potentially useful technical approach that should certainly be in the TRT’s “toolbox” – yes. Uncontroversial.

“Consensus” that this particular technical technique should/must(?) be used at some certain point, for some certain duration, during 202x round procedures – no.

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?

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”:

A regular dig returns NOERROR and an empty rrset. Full stop – no one suffering from collisions issues will understand that:

% dig +short abc123.cloudflare-dns.com
%
<empty rrset, no errors, wth?>

If someone knows to ask for ANY, they’ll get:

% dig +short -t any abc123.cloudflare-dns.com
"RFC8482" ""
HINFO 13 3 3600 20230829163530 20230827143530 34505 cloudflare-dns.com. QP6uSm2mnGdv+8MbGcnmFZhkmV5shRnxe/SrIV41WnyL+XutBn+zh+2C gUvDVMoIXTJQ0OtReNYW3/0m03+mwQ==
%

This helps our vulnerable young Jedi sysadmins how?

Related, Wikipedia now knows about 127.0.53.53. I didn’t do this, but someone did c. 2018:

https://en.wikipedia.org/wiki/Wildcard_DNS_record

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 *not* leverage the value/awareness already present in 127.0.53.53?

The NCAP seems to suffer from the “good idea fairy.”

Jeff

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Thomas, Matthew via NCAP-Discuss <ncap-discuss at icann.org>
Date: Monday, August 28, 2023 at 4:31 AM
To: casey at deccio.net <casey at deccio.net>, ncap-discuss at icann.org <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Nearly-empty TLD zone contents (was Re: Outline of possible phases)
Thank you Casey.

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.

If no questions/comments/concerns arise – shall we call consensus on this technical aspect of the workflow within PCA?

Matt

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Casey Deccio <casey at deccio.net>
Date: Wednesday, August 23, 2023 at 8:22 PM
To: NCAP Discussion Group <ncap-discuss at icann.org>
Subject: [EXTERNAL] Re: [NCAP-Discuss] Nearly-empty TLD zone contents (was Re: Outline of possible phases)

Caution: 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.

On Aug 16, 2023, at 11:48 AM, Casey Deccio <casey at deccio.net<mailto:casey at deccio.net>> wrote:

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.

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:

Example (60-second TTL):

$TTL 60
@ IN
SOA localhost. root.localhost. (
      1
; Serial
 3600
; Refresh
 3600
; Retry
86400
; Expire
 60 )
; Negative Cache TTL
@ IN
NS ns1.trial-delegation.icann.org<http://secure-web.cisco.com/12lPYSMu0zdHdvAkLCz0oTmb9iU7KyqlOTpYH9a76G10muwigKaGNoEkdOQ8etcyrCIJ57icnxNrFpoMoGEFu2GhEFVvGVkB_fz2urSm-PqFXtgtn6g-I4aF5DHzouIK6bHLqFWY8mwmiIDhEiz4xZI3jJjd_4bb5ROOAC2pTIuiWlrIlhLpzeJzomdZDxDZn7t0CrMK5QeNFJLKpBO_eS4gP9p8m7OjIRtGb1gPCkc3lk3ZFFzrF3-ENx1lAhKcGQU4OgkHxVkvO7Bq43IOhiuGxrqUWVq-SYiWIKRg8yZk/http%3A%2F%2Fns1.trial-delegation.icann.org%2F>.
@
IN
NS
ns2.trial-delegation.icann.org<http://secure-web.cisco.com/1KBK2jpYQdOdeD8LH11nBgogbI_ec2yIMhknIHQEMhPG4yVeOkdQZCqH3AH2qJM21BilMbNwFpUe7fnCPaUIKhB6znUb0dFYKDDSoEXD2v06RVPUHPBttyTkfrTrH7y29lGEThkApLlgu5MQVNu4BmA_dq2JeEXS2xsR9fxeIvbrHyHHY2OovcJYvYtRHqdI2ShSU1IaelTjvzI-WLRBrBA5g3hjLw9XkTbb5D_1uc-7_m8G3UZmNkMkPQ4xDgt2TwQHtOzU2LqO_QSA2KEiJH7paPiCkSrrbXGiMfY2FkSU/http%3A%2F%2Fns2.trial-delegation.icann.org%2F>.
*   HINFO "" ""

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.

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.

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:

<begin DNS snippet>
$ dig +dnssec @ns1.cloudflare-dns.com abc123.cloudflare-dns.com<http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com>
;; communications error to 162.159.0.33#53: timed out

; <<>> DiG 9.18.17 <<>> +dnssec @ns1.cloudflare-dns.com abc123.cloudflare-dns.com<http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com>
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11807
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;abc123.cloudflare-dns.com<http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com>.
IN A

;; AUTHORITY SECTION:
cloudflare-dns.com<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>.
1800 IN
SOA ns1.cloudflare-dns.com<http://secure-web.cisco.com/1wcsbCurLVpDq3_RNZDWv1ogzNl2Befk89xvuA70Kt1WS-Z8I8td0kfpKqaE2v7MT2zArgeSNbkTt6brFxswQTO_TQkfYu8AoBaJnOrJdztwVJQChw48BkVhyREJM8nuONq6xDRPX_ro4Mu2SkRo8ZMch7QmLKSWwO2xzVh8UnVZfKSAbznzocbQxxCGJFlILN6hHFAu0jU5vp90xNe5X_XmhMikng6kkJHFqeuxr5OJdfM8g7-be8gYZiUzPWFJOX0Mm6_A4YWXZ1Loys_8r8HP7hhWX72381YlrVlOlFc0/http%3A%2F%2Fns1.cloudflare-dns.com>. dns.cloudflare.com<http://secure-web.cisco.com/1sk3CtE0xcEeQ8uZ4kkUZUvNDjPYYvrKhxzONWRmszMf_l8i853izpE-QiK9Buu2QLpvB-yDK0Nr6jHnE1X5Yb3lgUoRc76h3GCpvMenBH7Bm98HpeWWUXQcl28WhbNLqo3kDBAXyx9fcEc62sLnEKJAs-Zr4jrKbwRjQ1wK2XntwL-8q_6USSuhAubsFJcdXNfCFJ69dnNEesUX9Ckr8WOEIWz2qW-5fJLfwznIiN02Ka53xkrU2kH5y0qrqDClISj32OhdtRMmH1XRZpKrg1G_y5QidfukF22PUpwTgxxM/http%3A%2F%2Fdns.cloudflare.com>. 2317900719 10000 2400 604800 1800
abc123.cloudflare-dns.com<http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com>. 1800 IN
NSEC \000.abc123.cloudflare-dns.com<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>. RRSIG NSEC TYPE65283
cloudflare-dns.com<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>.
1800 IN
RRSIG SOA 13 2 1800 20230824173340 20230822153340 34505 cloudflare-dns.com<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>. v1vdQ5FyVwdvwl6ovxwzdMlcRbGmTyUj4tzjjn4DSOkaxI+Hrks9VATS eft4Wmzv40ApGg9Mv8rY3oCJQcSE7A==
abc123.cloudflare-dns.com<http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com>. 1800 IN
RRSIG NSEC 13 3 1800 20230824173340 20230822153340 34505 cloudflare-dns.com<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>. fjSv13nBRDZ2l2oYir+/Hx3BQQkF/kg7vSX5ZvyCUrtmAASHLeZeudII SrhlPeiaOD2WE16A8VTdcnelC8YFZg==

;; Query time: 83 msec
;; SERVER: 162.159.0.33#53(ns1.cloudflare-dns.com<http://secure-web.cisco.com/1wcsbCurLVpDq3_RNZDWv1ogzNl2Befk89xvuA70Kt1WS-Z8I8td0kfpKqaE2v7MT2zArgeSNbkTt6brFxswQTO_TQkfYu8AoBaJnOrJdztwVJQChw48BkVhyREJM8nuONq6xDRPX_ro4Mu2SkRo8ZMch7QmLKSWwO2xzVh8UnVZfKSAbznzocbQxxCGJFlILN6hHFAu0jU5vp90xNe5X_XmhMikng6kkJHFqeuxr5OJdfM8g7-be8gYZiUzPWFJOX0Mm6_A4YWXZ1Loys_8r8HP7hhWX72381YlrVlOlFc0/http%3A%2F%2Fns1.cloudflare-dns.com>) (UDP)
;; WHEN: Wed Aug 23 10:33:40 MDT 2023
;; MSG SIZE  rcvd: 389
<end DNS snippet>

In the above example,  abc123.cloudflare-dns.com<http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com> 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 abc123.cloudflare-dns.com<http://secure-web.cisco.com/1exbHXulCS_KpKH0rU45qpbSB78tzAaaBG-z5rV48B2ja9smnFl1oDZhNXgvbfb40p_JDX40-45gRNhPotzD92TuJycbrv8I2PHukoCNEo26PhiQ-GOdcAqh7dCE-O6tD9xov5GE_IkOKEIR84j9TW6quzvFREtkfTMDeULol8yOVNrpUIdUiHPE49-t76JVmgHQ4rNqyUQxap5XB9L6rhc_SDCfv8Y0CIzF8enXC0eoNpaaxALMKrlVyOeyM6dpHFV4dPWznP-uFo1Udwo8TBZthir0l_YhroJQMzfnlIOE/http%3A%2F%2Fabc123.cloudflare-dns.com>. and \000.abc123.cloudflare-dns.com<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>. -- i.e., a minimal covering.

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.

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.

On Linux, There are two errors related to NXDOMAIN/NODATA (man getaddrinfo):
       EAI_NODATA
       EAI_NONAME
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.

On MacOS, there is a single error related to NXDOMAIN/NODATA (man gai_strerror):
       EAI_NONAME        hostname or servname not provided, or not known
When I test these, indeed both NXDOMAIN and NODATA result in EAI_NONAME being returned.

Thus, NXDOMAIN and NODATA are indistinguishable from the perspective of the program using getaddrinfo().

On Windows, There are two errors related to NXDOMAIN/NODATA [3]:
       WSAHOST_NOT_FOUND
       WSANO_DATA
I have not tested Windows to confirm behavior.

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.

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, "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.

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.

Casey

[1] https://blog.cloudflare.com/black-lies/<https://secure-web.cisco.com/1OY2JMpKFNMhoE6dMnH0NeVjdRi7bi8sefUT88HxdJCbM3igkd23fvMpjO-yGOo-q74chdKNFHc7BKf-BtUEwnRb5Z1flhPvLZmx6o-5hy4LIMPRCqxzxqAdSAGsXbgukQ3zbVT8n67_F5J6ALEg73IZ_m7aaYoluslHMpfnSPDyuKRyvIoR8CFjOVCOcr91YlAjM0wcant0jRWtDOPhe32SrHp1pGlS4Fki2JApFt3U3Y6rZepir3ooUenFvHAtGjNjjhRxbYvzEdlymFHXNjddwRDKiUmHnEDEx1RkQNTY/https%3A%2F%2Fblog.cloudflare.com%2Fblack-lies%2F>
[2] https://tranco-list.eu/<https://secure-web.cisco.com/1hNTXhI3q6KE7NHjgc2r_bJ8whYPK5acdNM4ANjrGLKcEmEVy8eVGYBNlLXjLe34wyXSn--8ATA6P3aY_B22o2XANZ4ReDeygyGemPsAiDod4EJHIByyK7FrXVR58KchWDPfLKQHs7H147pW-jseQJFV0zfiy-rZKCbqjEeDB-zxyv4sVodtLUnSGgZZ3YzW7t-OjSgELPBuSglt-DprirhzZKBavCNie05O5wQfEgm56y-z0zAbfvz4sGkA7E_x6qBBqnXRQJL30okmhNu9Hj7nzxW9WhTrLwdglAS1TQuc/https%3A%2F%2Ftranco-list.eu%2F>
[3] https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2
[4] https://docs.google.com/document/d/1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230828/693b57f0/attachment-0001.html>