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
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
