[systemd-devel] Some base questions around systemd-resolved

Fri Aug 2 05:08:10 UTC 2024

On Fri, Aug 2, 2024, 02:04 struth <struthm8 at gmail.com> wrote:

> Hello systemd-devel group.
> I have just started using systemd-resolved to try and achieve a goal that
> I will try to explain.
> I know very little about it (web searches so far) so please excuse any
> silly questions or trains of thought.
> I have a Debian Bullseye client in a Microsoft network that uses a .local
> domain.
> I know that this is a bad policy, but there is nothing I can do about
> it. I have no choice or authority in this matter. This is how they have
> configured their whole environment.
> I have read here  [ https://github.com/systemd/systemd/issues/8852 ] that
> .local can be used.
>
> At times there is complete isolation from the 4 Domain DNS servers and I
> want my client machine to still be able to resolve DNS entries
> (specifically SRV records with included A records) during this outage.
>
> I thought that systemd-resolved could cache the DNS entries and retain
> them until any of the DNS Servers returned to service.
> This only seems to happen for a short time after the outage. After some
> time ( I don't know how to tell how long) the entries seem to drop from
> cache.
>

Generally DNS caches are required to honor the TTL of each record and not
cache it further than that. Your dig output shows a TTL of 1h (3600) for
the SRV records, which was defined as part of the DNS entry and starts
counting down the moment that record is received from an authoritative
server (the DC).

"Serve stale" – caching beyond TTL if servers are outright unreachable –
was defined a few years back, but only some caches implement it (as an
option). I think bind and unbound do, but systemd-resolved doesn't. So run
unbound configured that way and have resolved speak to it.

I would ideally like the entries to stay in cache until updated from DNS
> Server again (once one returns to service).
>
> On the SRV point: How can I be sure that it caches the full result of the
> SRV query?
> Eg: SRV gives 2 x A-records which then need to resolve to 2xIP-addresses.
>

I think it's necessary to actually make those A-queries for them to be
cached. Some are provided along with the SRV reply but I'm not sure how
caching of the 'Additional' section works.

> I'm not sure of the mailing lists policy for including config samples of
> logs, so I will include it here in email and see what happens.
> Please excuse if this is too much or too little information.
>
> root at VATCPCOMMLC1:~# cat /etc/systemd/resolved.conf
> [Resolve]
> DNS= 10.24.1.135 10.24.129.135 10.24.1.136 10.24.129.136
> #FallbackDNS=
> Domains=itsvic.local
> #DNSSEC=no
> #DNSOverTLS=no
> #MulticastDNS=yes
> #LLMNR=yes
> #Cache=yes
> DNSStubListener=yes
> #DNSStubListenerExtra=
> #ReadEtcHosts=yes
> #ResolveUnicastSingleLabel=no
> root at VATCPCOMMLC1:~#
>
> root at VATCPCOMMLC1:~# ls -l /etc/resolv.conf
> lrwxrwxrwx 1 root root 39 Jul 30 14:11 /etc/resolv.conf ->
> ../run/systemd/resolve/stub-resolv.conf
> root at VATCPCOMMLC1:~#
> root at VATCPCOMMLC1:~# cat ../run/systemd/resolve/stub-resolv.conf
> nameserver 127.0.0.53
> options edns0 trust-ad
> search itsvic.local
> root at VATCPCOMMLC1:~#
>
> root at VATCPCOMMLC1:~# cat /etc/nsswitch.conf
> # /etc/nsswitch.conf
> passwd:         files systemd
> group:          files systemd
> shadow:         files
> gshadow:        files
> hosts:          files dns
> networks:       files
> protocols:      db files
> services:       db files
> ethers:         db files
> rpc:            db files
> netgroup:       nis
> root at VATCPCOMMLC1:~#
> root at VATCPCOMMLC1:~# resolvectl statusresolvectl status
> Global
>          Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
>   resolv.conf mode: stub
> Current DNS Server: 10.24.1.135
>        DNS Servers: 10.24.1.135 10.24.129.135 10.24.1.136 10.24.129.136
>         DNS Domain: itsvic.local
> Link 2 (ens192)
> Current Scopes: none
>      Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
>
> Link 3 (ens224)
> Current Scopes: none
>      Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
>
> Link 4 (bond0)
> Current Scopes: LLMNR/IPv4 LLMNR/IPv6
>      Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
>
> root at VATCPCOMMLC1:~# dig srv _sip._tcp.osvsig-mets-prod.voip.itsvic.local
> dig srv _sip._tcp.osvsig-mets-prod.voip.itsvic.local
> ; <<>> DiG 9.16.48-Debian <<>> srv
> _sip._tcp.osvsig-mets-prod.voip.itsvic.local
> ;; global options: +cmd
> ;; Got answer:
> ;; WARNING: .local is reserved for Multicast DNS
> ;; You are currently testing what happens when an mDNS query is leaked to
> DNS
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57884
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 65494
> ;; QUESTION SECTION:
> ;_sip._tcp.osvsig-mets-prod.voip.itsvic.local. IN SRV
>
> ;; ANSWER SECTION:
> _sip._tcp.osvsig-mets-prod.voip.itsvic.local. 3600 IN SRV 20 0 5060
> osvn2-mets-prod.voip.itsvic.local.
> _sip._tcp.osvsig-mets-prod.voip.itsvic.local. 3600 IN SRV 10 0 5060
> osvn1-mets-prod.voip.itsvic.local.
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Tue Jul 30 15:38:47 AEST 2024
> ;; MSG SIZE  rcvd: 179
>
> Thanks for any help.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240802/51d43b69/attachment-0001.htm>