<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">These are great questions. I wish I had answers. I hope I see some!</div><div dir="auto"><br></div><div dir="auto">G</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 11 Jun 2022, 5:50 am Petr Menšík, <<a href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello DNS experts,<br>
<br>
I were thinking about requirements for future name resolution primarily <br>
on Linux desktop and servers. But if anyone could comment other systems <br>
and their design, I would be glad too. I would like to formulate <br>
requirements first and find a good way to implement them later.<br>
<br>
We have two ways used to resolve names to ip addresses on GNU/Linux.<br>
<br>
- first is libc interface getaddrinfo() provided by nss plugins. Names <br>
can be resolved also by different protocols than just DNS. A good <br>
examples might be MDNS (RFC 6762), LLMNR (RFC 4795) or Samba <br>
(nmblookup). Standardized calls provide only blocking resolution interface.<br>
<br>
* Asynchronous interface does not exist in useful form. It is easy to <br>
handle multiple connections in single thread, but multiple resolutions <br>
in single thread are not supported. nss plugins are simple to write, but <br>
hard to use in responsibe program. Should that be changed?<br>
<br>
* MDNS usually uses names under .local domain. What should be preferred <br>
order of single label names, like 'router.'? Should be LLMNR tried <br>
first, samba first or DNS search applied first? Should it avoid reaching <br>
DNS when search domain is not set?<br>
<br>
- primary interest for us is DNS protocol. On Unix systems it specifies <br>
nameservers to use in /etc/resolv.conf also with some options. We would <br>
like to offer DNS cache installed on local machine, which should <br>
increase speed of repeatedly resolved names.<br>
<br>
* I would like to have support for multiple interfaces and redirection <br>
of names subtree to local network interfaces servers. For example <br>
'home.arpa' redirected to local router at home, but <a href="http://example.com" rel="noreferrer noreferrer" target="_blank">example.com</a> <br>
redirected to VPN connection. I think RFC 8801 and RFC 7556 specify <br>
standardized way to list interface specific domains. Existing <br>
implementations misuse RFC 2937 for a source of such list now. Something <br>
like this is implemented by systemd-resolved on Ubuntu and Fedora <br>
systems. But it introduced couple of new issues. Is something similar <br>
implemented on end user machines? I think laptop and phones are typical <br>
devices with multiple interfaces, where it would make sense.<br>
<br>
My questions:<br>
<br>
- how should single label names be handled?<br>
-- is domain (opt. 15) and search (opt. 117) from DHCP already dead? <br>
Should they be completely avoided even in trusted networks?<br>
-- in which order should be resolution tried? Should machine cache block <br>
queries to single label hostnames not expanded to FQDN on DNS protocol?<br>
-- I have seen usage of search domains on cloud technologies. Is there <br>
common example what they are used for? Do we need ndots option with <br>
value different from 1?<br>
<br>
- should we expect DNSSEC capabilities on every machine?<br>
-- should we even enable DNSSEC validation on every machine by default? <br>
When it would be good idea and when it wouldn't?<br>
<br>
- should asynchronous API be prepared for common name to addresses and <br>
vice versa? One which would support both local network resolution and <br>
unicast DNS in easy to use way? Usable even in GUI applications without <br>
common hassle with worker threads?<br>
<br>
If there is documentation for name subtree mapping to interface servers <br>
on different systems, I would be glad if you could share links to it. If <br>
we should improve current situation, I would like to first gather <br>
expected requirements for such system. Is there some summary already?<br>
<br>
Thank you for any feedback!<br>
<br>
Best Regards,<br>
Petr<br>
<br>
-- <br>
Petr Menšík<br>
Software Engineer, RHEL<br>
Red Hat, <a href="http://www.redhat.com/" rel="noreferrer noreferrer" target="_blank">http://www.redhat.com/</a><br>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB<br>
<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank" rel="noreferrer">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>