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

[Jeff Schmidt]

Fair point re: apples and Tonka Trucks. 😊

I think this is a fine idea, should be tested, and may very well wind-up in the toolbox. It may have some traits incrementally superior to some other techniques, but it isn’t a game changer.  was responding somewhat energetically to the consensus call which implies larger scope than “this is a good idea.”

What I see is a “pool” of techniques that are in the TRT’s toolbox, all with various risk profiles, objectives, data collection value, and alerting value/characteristics. We as a group argue about the specifics (which technique is better at X than the other, alerting is more important than data collection, etc.), but in general we agree that there are a sea of tradeoffs and multiple potential techniques.

Jeff





From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Casey Deccio <casey at deccio.net>
Date: Tuesday, August 29, 2023 at 1:31 AM
To: 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)
Hi Jeff,

There are a lot of apples and oranges being compared here.  Let me see if I can break things down.

(Note that I've slightly re-ordered your message, just to better support the flow of my response.)


On Aug 28, 2023, at 9:46 AM, Jeff Schmidt <jschmidt at jasadvisors.com<mailto:jschmidt at jasadvisors.com>> wrote:

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.

I'm not sure why the delegation of the nearly empty zone (with wildcard HINFO) is being compared to controlled interruption.  Over and over again in the past two NCAP calls we have discussed the idea of going from least/minimally disruptive to more disruptive, as part of a workflow.  The proposal to delegate a nearly empty zone with wildcard, as proposed, is on the *minimally* disruptive side.  Controlled interruption is, by design, *completely* disruptive.  Thus, these are on opposite sides of the spectrum.  There is no notification value because notification is not part of the design.  These are not to be compared.


This approach may be used in a “rotation” with 2012 CI in the spirit of maximizing notification opportunity and coverage.

I'm not really even sure what this means.  I think you're discussing what later, more disruptive parts of the workflow might look like. But the current discussion and proposal are about the minimally disruptive component -- what has been referred to as PCA (though I stubbornly refrain from referring to it as PCA because its meaning continues to be ambiguous and imprecise to me).

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.

I don't know what you mean here.  Have you read what I've written?

(see https://mm.icann.org/pipermail/ncap-discuss/2023-August/001226.html)


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.

You're going to have to walk me through your logic here.  Why would an HINFO record ever be returned?  Why would an HINFO record ever be queried?


Yes, we may get better data. Might.

*Will* get better data!  There is no doubt.

Compared to root server (e.g., DITL) data:

To be clear: I am not one that believes that data from the root servers has no value.  But it is clear that fidelity is being lost with caching, qname minimization, aggressive negative caching, and (perhaps) local root.  By deploying a nearly empty zone (with HINFO wildcard) like the one proposed, we address all of those things.


Compared to controlled interruption:

With controlled interruption we had almost nothing in terms of DNS query data.  One of the things that saved the root cause analysis was the ability to query Farsight's DNSDB for historical DNS mappings associated with controlled interruption (thank you, Farsight!).  But there are issues.  First, the Farsight sensors are not everywhere.  Second, they don't have client IP addresses.  So yes, this provides much more data.


But is the juice worth the squeeze?

That is a valid question -- for all the things we're considering.  But you have to precisely define "juice" and precisely define "squeeze".  For me, the juice is a minimally disruptive mechanism that gets us full qnames and mitigates the effects of caching (not to mention aggressive negative caching, local root, and qname minimization).  For me, the squeeze is that the delegation has to be added to the root zone and that there is technically a change in server behavior, even if risk of disruption is expected to be negligible if any.


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

Please see my first comment.  Notification has no part in this.  This is about returning a negative response where a negative response is expected.



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

I have no idea what you mean by that.  Everything that I have investigated shows that *suffering* from collisions is caused by an *answer* being returned and the application attempting to communicate with the host associated with the address.  Based on my analysis, I have no reason to believe that any application could care about anything other whether or not getaddrinfo() returns a 0 (resolution succeeded) or a non-zero value (resolution failed).  MacOS doesn't even distinguish the different between the two.  Do you have reason to believe otherwise?  If so, please walk me through your logic.  What fallout has Cloudflare seen during the past six or so years?

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

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

This helps our vulnerable young Jedi sysadmins how?

If someone did experience an issue, and they did decide to issue an ANY to investigate, wouldn't it be easy enough to stick a note in the HINFO record?

*   HINFO "" "name collision detected.  Visit https://namecollisions.icann.org for more info."
(or whatever...)

But again, based on my analysis, I find no reason to suggest that end-users and end-systems would experience these issues.



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?

We've gone back to comparison with controlled interruption.  Again, I emphasize that these cannot and should not be compared.  But since you brought this up, let me argue several points on this.

First, 127.0.53.53 is a thing.  But it is a thing for the very small population of Internet users that were affected by name collisions during the past eight or so years.  By referring to the population as "small", I'm not saying that those effects are insignificant (particularly to those that experienced them) or that we needn't care about those or any future collisions.  But this simply is not a universal thing; only those that were 1) somehow associated with it or 2) affected by it, have had any need to know anything about 127.0.53.53.  Why would anyone else need to know or care?

Second, I don't doubt that searching the Web for an IP address is a thing.  But one of the challenges of the controlled interruption IP address -- and in fact the very reason that they *had* to search the Web -- was because they couldn't use any of the other, more common tools that have been available *much longer* than controlled interruption -- like Whois and reverse DNS (in-addr.arpa and ip6.arpa).  As a network operator, vulnerable Jedi sysadmin, and network researcher, Whois and reverse DNS (e.g., "dig -x") have always been my go-to tools, way before a Web search.

I reiterate that the deployment of a nearly empty TLD zone cannot be compared to controlled interruption. Nonetheless, at some point we will be discussing more disruptive mechanisms, among which is controlled interruption.  So consider the above as counter-argument for the importance of the "brand" of 127.0.53.53.  It certainly has a presence, but I have no reason to believe that it is as significant as it has been suggested.

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

Indeed.  I think that's part of the problem solving process.

“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.


I expressed my own opinion about this on the NCAP call last week, and I'll do it again:

1. While I believe that the TRT should use their own discretion with regard to their analysis and recommendations, I think the methodologies for data generation and collection should be consistent and spelled out fairly specifically.

2. I agree with using the proposed DNS zone configuration for the minimally disruptive step in a name collisions workflow.

Thanks,
Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230830/13ca3f5c/attachment-0001.html>