[postquantumfax]

resolv.conf-> search

If you are not a consumer on an ISP emulating dialup it is quite likely that a popular name in a naming convention I.e. 'mercury' resolves to something for you and something for someone at a different firm (mercury.intranet.[firm].not-so-stupid-tld). A cert is possibly not a fully qualified one so when ICANN gives away mercury you need to append .asshat to everything ICANN names.

(Two firms have an unambiguous situation because they don't trust each others private roots but they both trust a cert issued for the public trust as a fqdn which is why TLDs expanding is a form of theft/breakage against every intranet..)

[dc396]

Ah, resolver (not DNS) search paths. They were a really bad idea that can and do lead to leaked queries that can result in all sorts of unpleasantness and risks.

As for certs, AFAIK, you can't get a certificate for a non-fqdn from a public CA since 2015.

[arcfour]

Run your own DNS then, if you're using your own DNS? Why are your queries for internal systems leaking out to the internet?

[postquantumfax]

If icann sells www as a tld domain then your use of www as a machine name you may refer to unqualified is a risk because virtually every piece of software in the world respects public issuance until you delete it all if you can.

The DNS naming confusion was largely dealt with by having a small number of TLDs and rarely referring to complex things like partially specified subdomains, but every once in a while a fool named their machine com, org, or net. (Though these as subdomains were far more toxic.)

[dc396]

You might want to look at the "domain" directive of resolv.conf and the concept of "split horizon DNS".

[postquantumfax]

I've done plenty of interesting things but a distributed correction attempt for ICANN's incompetence is never going to be adequate. You can read their own work on gTLDs in the past to know they understand this.

[dc396]

Accusing ICANN of incompetence when you can't be bothered to configure your DNS to avoid leaking queries to the root is an interesting approach.

[postquantumfax]

There's no leak being discussed. Everyone in the world sets resolving and it is what it is with the current TLDs when ICANN needs more coke money they possibly break every node in the world and a distributed group of thousands has to look if something bad happened.

There is the argument that ICANN should no longer be consulted ever by nodes of consequence but that is an argument that they have failed 100% in their responsibilities.

If you don't care at all about zone delegation and global resolution then you obviously don't have an opinion on how to evaluate ICANNs stewardship of global domain delegation.

We have run out if IPv4 addresses but there is NAT is not a satisfying answer to start. But we have let ICANN polute naming so let's implement shadow naming everywhere is an even less satisfactory answer.

[JdeBP]

I think that the scenario here is where the queries are explicitly not leaking, and you've raised a red herring.

If I understand correctly, the scenario is an internal machine named "george", which is being properly search-pathed and looked up as "george.example.org." with nothing leaking anywhere, becoming vulnerable to Walmart being able to issue certificates in the name "george", because the DNS client library's search pathing is not read out by the layers that simply know the machine as "george".

I'm not totally convinced by the premise here that certificate checkers never read out the final fully-qualified domain name from getaddrinfo().

[postquantumfax]

This isn't a red herring at all. This is DNS resolution and client PKIX implementation. You could fix your whole network to not import anything from outside, ban all BYOD, etc, or you could fire ICANN clowns who think they need to make changes to the reserved list because, why? Money, corruption, self importance?

HN is full of people from SaaS startups who in essence want to buy the perfect 900 number. But DNS and delegation goes far deeper than selling one name for $20 and going to other $20 names to store your code and email at other SaaS providers.