[dc396]

I'm not sure what you mean by "DNS allows search" -- by the usual definition of "search", the DNS doesn't: it is a lookup mechanism. I'm also not sure who "we" are in your idea or what you mean by "qualified with an end dot": all domains that get looked up implicitly have a "." (a zero length label that signifies the end of the query name) if it isn't explicit.

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

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