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

[Viktor Dukhovni]

On Fri, Jun 10, 2022 at 09:16:11PM +0200, Petr Menšík wrote:

> - first is libc interface getaddrinfo() provided by nss plugins. Names 
> can be resolved also by different protocols than just DNS. A good 
> examples might be MDNS (RFC 6762), LLMNR (RFC 4795) or Samba 
> (nmblookup). Standardized calls provide only blocking resolution interface.

The nsswitch (originall from SunOS IIRC) indeed has limitations, but is
unlikely to fade away quickly, especially because it also handles
non-DNS queries (passwd, group, services, ...).

That said, best practice for "hosts" has been essentially:

    hosts: files dns

with a very short /etc/hosts with just the local system address and
name, perhaps only a loopback address at that.  But this was before as
mention below the introduction of "mdns" et. al., and in some
"enterprise" environments "samba" or similar.

> * Asynchronous interface does not exist in useful form. It is easy to 
> handle multiple connections in single thread, but multiple resolutions 
> in single thread are not supported. nss plugins are simple to write, but 
> hard to use in responsibe program. Should that be changed?

Indeed asynchronous interfaces for some of these would be quite useful,
and some dedicated libraries (alternatives to good-*old* libresolv)
provide these for DNS specifically, but they are not ubiquitous, and
would introduce completely new APIs undreamed of in SvID and POSIX.

> * MDNS usually uses names under .local domain. What should be preferred 
> order of single label names, like 'router.'? Should be LLMNR tried 
> first, samba first or DNS search applied first? Should it avoid reaching 
> DNS when search domain is not set?

I rather expect there is no one-size-fits-all answer, and so
nsswitch.conf or equivalent is here to stay.  Sometimes one wants no
"mdns" or similar at all.  The right answer for a laptop trying to
locate nearby printers is rather different than the answer for a server
racked in a datacentre.

> - primary interest for us is DNS protocol. On Unix systems it specifies 
> nameservers to use in /etc/resolv.conf also with some options. We would 
> like to offer DNS cache installed on local machine, which should 
> increase speed of repeatedly resolved names.

Definitely, with DNSSEC validation, and (on laptops) perhaps support for
probing of DNSSEC support when switching between WiFi networks, or
opting in to a captive portal, so that DNSSEC is used when available,
once the portal T&Cs etc have been dealt with, and real DNS servers
(ideally) become reachable.

> * I would like to have support for multiple interfaces and redirection 
> of names subtree to local network interfaces servers. For example 
> 'home.arpa' redirected to local router at home, but example.com 
> redirected to VPN connection.

This is largely a laptop problem, but indeed the local caching
nameserver could have appropriate stub zones defined, so that
queries for "special" zones are sent to non-default servers.

> I think RFC 8801 and RFC 7556 specify standardized way to list
> interface specific domains. Existing implementations misuse RFC 2937
> for a source of such list now. Something like this is implemented by
> systemd-resolved on Ubuntu and Fedora systems. But it introduced
> couple of new issues. Is something similar implemented on end user
> machines? I think laptop and phones are typical devices with multiple
> interfaces, where it would make sense.

This is a complex question, that can't be answered in a brief email
thread.  Designs need to be throught through, written up, debated,
zealously supported, ignored, dismissed out of hand, ... :-) :-(

> - how should single label names be handled?

Local policy.

> -- is domain (opt. 15) and search (opt. 117) from DHCP already dead? 
> Should they be completely avoided even in trusted networks?

They had some merit for moving laptops between corporate offices, but
are problematic on shared public WiFi networks, so perhaps by now best
ignored.  The hot new trend is to always leave mobile devides on
"external" networks, even on prem.  And so you're always on the public
Internet, where search lists from DHCP are not trustworthy.

> -- 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!

> -- I have seen usage of search domains on cloud technologies. Is there 
> common example what they are used for? Do we need ndots option with 
> value different from 1?

For managed servers in datacentres there is some plausible value in
search lists, but anything with more than one element used to qualify
names with more than zero dots has dubious semantics in the face of
timeouts, or other transient failures.  Should these abort the query,
or occasionally seek the answer in what could be the wrong place?

> - should we expect DNSSEC capabilities on every machine?

This is probably not the right way to ask the question.  Some
datacentre machines will want DNSSEC all the time, some never.
As for laptops, it rather depends on whether they start "trusting"
HTTPS and SVCB indirection without using DoH or DoT to tunnel to a
"trusted" resolver, and how much impact forgery of these and future
security-relevant DNS data will have.

> -- should we even enable DNSSEC validation on every machine by default? 
> When it would be good idea and when it wouldn't?

Ideally yes, if well designed to downgrade gracefully in captive
portals, when switching wireless networks, in ways that are clear to the
experienced user (perhaps a menubar icon) and not intrusive to the
novice.  And of course does not silently and unexpectedly degrade to
insecure (without the user involved in selecting a new network).

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.

> - should asynchronous API be prepared for common name to addresses and 
> vice versa? One which would support both local network resolution and 
> unicast DNS in easy to use way? Usable even in GUI applications without 
> common hassle with worker threads?

Would be nice.  OpenBSD may IIRC have code in that space, don't know
whether it is a good model to emulate, or a lesson to avoid.

> If there is documentation for name subtree mapping to interface servers 
> on different systems, I would be glad if you could share links to it. If 
> we should improve current situation, I would like to first gather 
> expected requirements for such system. Is there some summary already?

I guess this can be about whether a VPN is active or not, and whether
then to route some DNS queries to some server over the VPN.  Some
enterprises build this sort of thing in managed OS images for employee
laptops, with each company developing or buying custom software for the
managed user experience.  Perahps some part of this s ripe for inclusion
in the base vendor OS.

-- 
    Viktor.