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

[Petr Menšík]

Hello DNS experts,

I were thinking about requirements for future name resolution primarily 
on Linux desktop and servers. But if anyone could comment other systems 
and their design, I would be glad too. I would like to formulate 
requirements first and find a good way to implement them later.

We have two ways used to resolve names to ip addresses on GNU/Linux.

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

* 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?

* 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?

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

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

My questions:

- how should single label names be handled?
-- is domain (opt. 15) and search (opt. 117) from DHCP already dead? 
Should they be completely avoided even in trusted networks?
-- in which order should be resolution tried? Should machine cache block 
queries to single label hostnames not expanded to FQDN on DNS protocol?
-- 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?

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

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

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?

Thank you for any feedback!

Best Regards,
Petr

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB