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

[Phil Pennock]

On 2022-06-10 at 21:16 +0200, Petr Menšík wrote:
> - 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?

No, these are common.  But, whether you use them depends upon whether or
not you trust DHCP to tell you which DNS servers to use.  If you trust
DHCP to tell you the DNS servers, then there's no additional issue with
domain or search lists.

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

Yes: in Kubernetes, name resolution of "something" which might be a pod,
or might be a service (which will ultimately somehow map back to ports)
or might be something else, and handling the concept of "namespaces"

If I run an Alpine container right now, I see:

    search default.svc.cluster.local svc.cluster.local cluster.local
    nameserver 10.43.0.10
    options ndots:5

This is in the 'default' namespace, but if I were in a different
namespace then the first element there would change.  It's then common
to see people expect to resolve 'fred' as being in this namespace, or
'fred.foo' expecting that to find 'fred' in the 'foo' namespace, all
without needing to know what name this cluster has because the goal is
to resolve a _local_ name.  (Right up until folks discover they want to
enable TLS internally and .. oh, right, now they need to know the
cluster name after all.)

In hosted Kubernetes in a cloud, that search list might include
provider-specific zones afterwards (`internal` for AWS,
`google.internal` and a project-specific zone for GCloud, etc).

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

I think that there should be a concept of "raw DNS and network access"
and "application access", and applications should get DNSSEC by default,
but things managing booting the system itself might not.  For instance,
if you're trying to find NTP servers, and the local clock isn't set yet,
then DNSSEC validation will kill the ability to find the servers to set
the time to get DNSSEC working.

I think that "raw" should be opt-in, not the default.  Protect
everything by default.

Which leads to the two local DNS resolution services, the old lwres and
the systemd DBus API
(https://www.freedesktop.org/wiki/Software/systemd/resolved/), and how
with containerisation and namespacing, you don't need the application to
necessarily know about opting in: you arrange for the container to map
the DNS service accordingly.

There has also been (fairly) recent discussion about whether or not DNS
resolvers should be sanitising results for "normal" data, instead of
being payload agnostic; eg, PTR results which contain embedded NUL
characters in the labels.  This would probably tie into the same access
system, giving you "raw DNS", "DNSSEC unfiltered" and "DNSSEC
sanity-filtered".

-Phil