[dns-operations] [Ext] How should work name resolution on a modern system?

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 09:09:50PM +0000, Paul Hoffman wrote:

> > The IETF tends to be very conservative in leave lots of lattitude in its
> > specifications for various potential corner cases.  The caution is often
> > times warranted, and yet in the same 3 decades or so nothing has changed
> > the fact that A/AAAA records at TLDs are profoundly fragile.
> 
> What is "profoundly fragile" about A or AAAA records at any level of
> the DNS hierarchy?

The fact that queries for these via almost all real-world systems would
get qualified with the local search list and resolved in highly
non-portable ways, for example:

    $ host go
    go.corp.google.com is an alias for uberproxy.l.google.com.
    uberproxy.l.google.com has address [...]
    uberproxy.l.google.com has IPv6 address [...]

If "go" were a ccTLD that attempted to publish A/AAAA records, it would
work rather poorly on the network why I am sitting this minute.

> Also note that the example given earlier is a ccTLD, not a gTLD. ICANN
> does not have contracts with (most of) the ccTLD admins.

Makes no difference.  This has nothing to do with ICANN, and everything
to do with RES_DEFNAMES and RES_DNSRCH.

> > So as a platform library maintainer, I'd be stricter than IETF was
> > willing to be, and would in fact have getaddrinfo(3) return an empty
> > list for "some-tld" and even "some-tld.", with the notable exception of
> > "localhost", whith the nsswitch code sending no A/AAAA DNS queries for
> > TLDs.  Only /etc/hosts and other local sources would be consulted.
> 
> Advocating that a library not check for valid data (even if you
> believe that it is "profoundly fragile" seems more likely to lead to
> damage than checking for it.

In many cases, better to consistently fail than to be lucky some
fraction of the time.  The library in question is above the DNS layer.
Applications that directly query DNS can choose to make A/AAAA queries
with single-label qnames, that's fine, but getaddrinfo(3) would in my
hands shun DNS for such names.

--
    Viktor.