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

[George Michaelson]

I am very glad somebody is asking these questions. They're food for thought
and go beyond strict DNS/53 (not that it IS 53 any more, so I mean "old
school dns as protocols") to the wider question  of name to locator mapping
in a multiple service context, and the fracture of a unitary namespace into
name spaces, subject to views, and order of enquiry issues.

These are great questions. I wish I had answers. I hope I see some!

G

On Sat, 11 Jun 2022, 5:50 am Petr Menšík, <pemensik at redhat.com> wrote:

> 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
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220611/528d57c4/attachment.html>