You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are working on implementing DNS over TLS in RHEL. And I have hit multiple times, that there is no simple way to obtain desired resolvers by applications or even by DNS cache implementation itself.
There are multiple implementations able to provide DNS over TLS and local caching. At least on VPS machines, they often receive fixed IP addresses directly from host. But there is not a good protocol for specifying fixed resolvers to use from the host also, when it should use local cache at the same time.
Because to do so now, the host needs to know in advance, which cache implementation and its configuration would be used. And therefore use implementation specific configuration format.
When no cache is used, /etc/resolv.conf can provide fixed name servers. And they are often specified fixed way. But if we want to use local DNS cache, localhost must be present in resolv.conf. Of course, it is not possible to use DNS over TLS, eventually also DNS over HTTPS or even DNS over QUIC protocols. For those encrypted variants, just IP address is often not enough. It needs to know also expected hostname in certificate.
Because this would make sense to be used across distributions and from multiple DNS caches, would it make sense to define such format here? Is there a better place for such proposal?
The problem is, if I define DNS= in /etc/systemd/resolved.conf, that would be used only by resolved. Of course I can also use /etc/unbound/unbound.conf. Or I can use dnsmasq configured in /etc/dnsmasq.conf. Whatever I use, the configuration differs a lot in syntax. But the result would be more or less the same in /etc/resolv.conf. That would just point to localhost (exact address may vary a bit).
I may want to use tools like dig or unbound-host to query not localhost, but information on forwarders. But specification by hand, when more parameters than TLS neeeds to be specified, can be somehow tiring. They could just read that information from the file itself and I would use a single parameter to tell it not to use /etc/resolv.conf, but something like /etc/resolver.conf.
Another issue is simple way to query from applications, where does local cache forward. And even more important, how is that forwarding protected, if any way used. Runtime configuration may contain additions to static configuration from file.
The text was updated successfully, but these errors were encountered:
pemensik
changed the title
Upstream resolver specification config, including possible encrypted features
Upstream DNS resolver specification config, including possible encrypted features
Oct 17, 2024
Hi, sorry for the delay. We discussed this in our team meetings a few times, but without any real conclusion. The basic requirement that we try to satisfy before merging of any standards document is to have a working implementation. It doesn't have to be feature complete, but it needs to be complete enough to verify that the specification can be sanely implemented and is not ambiguous.
So to move this forward, we'd want both a document and an implementation (possibly external), to effectively develop both in tandem.
We are working on implementing DNS over TLS in RHEL. And I have hit multiple times, that there is no simple way to obtain desired resolvers by applications or even by DNS cache implementation itself.
There are multiple implementations able to provide DNS over TLS and local caching. At least on VPS machines, they often receive fixed IP addresses directly from host. But there is not a good protocol for specifying fixed resolvers to use from the host also, when it should use local cache at the same time.
Because to do so now, the host needs to know in advance, which cache implementation and its configuration would be used. And therefore use implementation specific configuration format.
When no cache is used, /etc/resolv.conf can provide fixed name servers. And they are often specified fixed way. But if we want to use local DNS cache, localhost must be present in resolv.conf. Of course, it is not possible to use DNS over TLS, eventually also DNS over HTTPS or even DNS over QUIC protocols. For those encrypted variants, just IP address is often not enough. It needs to know also expected hostname in certificate.
Because this would make sense to be used across distributions and from multiple DNS caches, would it make sense to define such format here? Is there a better place for such proposal?
The problem is, if I define DNS= in /etc/systemd/resolved.conf, that would be used only by resolved. Of course I can also use /etc/unbound/unbound.conf. Or I can use dnsmasq configured in /etc/dnsmasq.conf. Whatever I use, the configuration differs a lot in syntax. But the result would be more or less the same in /etc/resolv.conf. That would just point to localhost (exact address may vary a bit).
I may want to use tools like dig or unbound-host to query not localhost, but information on forwarders. But specification by hand, when more parameters than TLS neeeds to be specified, can be somehow tiring. They could just read that information from the file itself and I would use a single parameter to tell it not to use /etc/resolv.conf, but something like /etc/resolver.conf.
Another issue is simple way to query from applications, where does local cache forward. And even more important, how is that forwarding protected, if any way used. Runtime configuration may contain additions to static configuration from file.
The text was updated successfully, but these errors were encountered: