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

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 02:31:37PM +0200, Petr Menšík wrote:

> >> - how should single label names be handled?
> >
> > Local policy.
>
> I have made some tests. nss plugins in glibc do not allow trying single 
> label applied with search domain in dns. Then try other plugins like 
> llmnr. Then as a last resort try resolution of this name on DNS with 
> just the name without anything appended. I think this cannot be 
> configured on today's Linux implementation.

See resolv.conf(5):

  options
      ...
      no-tld-query (since glibc 2.14)
         Sets RES_NOTLDQUERY in _res.options.  This option causes
         res_nsearch()  to  not  attempt  to  resolve  an unqualified
         name as if it were a top level domain (TLD).  This option can
         cause problems if the site has ``localhost'' as a TLD rather
         than having localhost on one or more elements of  the  search
         list.   This option has no effect if neither RES_DEFNAMES or
         RES_DNSRCH is set.

The name "localhost" should just be hardcoded to map to "127.0.0.1" and
"::1" in getaddrinfo(3), without any queries to DNS or any other
oracles.  Failing that, just list it in /etc/hosts, and search that
(short) file first (but this is more fragile).

    https://datatracker.ietf.org/doc/html/rfc6761#section-6.3

       3.  Name resolution APIs and libraries SHOULD recognize localhost
           names as special and SHOULD always return the IP loopback address
           for address queries and negative responses for all other query
           types.  Name resolution APIs SHOULD NOT send queries for
           localhost names to their configured caching DNS server(s).

       4.  Caching DNS servers SHOULD recognize localhost names as special
           and SHOULD NOT attempt to look up NS records for them, or
           otherwise query authoritative DNS servers in an attempt to
           resolve localhost names.  Instead, caching DNS servers SHOULD,
           for all such address queries, generate an immediate positive
           response giving the IP loopback address, and for all other query
           types, generate an immediate negative response.  This is to avoid
           unnecessary load on the root name servers and other name servers.

See also (expired draft):

    https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost-02

> >> -- in which order should be resolution tried? Should machine cache block
> >> queries to single label hostnames not expanded to FQDN on DNS protocol?
> > For getaddrinfo(3), indeed there is no reason to ask a TLD for its IP
> > address, worst case is you actually get an answer!
>
> Well, I am not sure this is sarcasm or not. Current systemd-resolved 
> redirects single label to LLMNR lookup if that is enabled. Should DNS be 
> asked before LLMNR even for single labels? Should local cache try to 
> protect root servers from unnecessary queries? It seems windows 11 does 
> apply search first, then LLMNR. I am not sure whether it tries also 
> single label query as last step.

Single label names passed to getaddrinfo(3) should not result in single
label "A" or "AAAA" DNS queries.

> I would display a DNSSEC support somewhere in connection status windows 
> only. I do not think DNSSEC would be as important captive portal 
> indication or limited connectivity. I would like to implement captive 
> portal support in NM, which would allow also DNSSEC. But at least 
> dnssec-trigger implementation reported annoying error every time I got 
> disconnected. I am sure this is not the correct way. It has to be able 
> to guess when DNSSEC is failing and when whole connection does not work.

Some fine-tuning of the various scenarios may still be needed.

> > Of course for DNSSEC on end-user (rather than datacentre) devices to
> > matter, support would need to be broader than just Linux laptops.  It
> > would need to ultimately encompass MacOS, Windows, Android, iOS, ...
> > But some vendor would to be the first mover.
>
> Understood. But I am not able to influence those.

Speaking of which, we now have some news of Apple supporting end-user
device DNSSEC, with applications presently opting in for this service,
so not yet on by default.  The first moves are being made...

> Interesting, would you be able to find a documentation for it?

I'd use Google to find it, which is available to all... :-)

    https://www.google.com/search?client=firefox-b-1-d&q=openbsd+async+dns+lookup
->  https://man.openbsd.org/asr_run.3

-- 
    Viktor.