<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 2, 2024, 02:04 struth <<a href="mailto:struthm8@gmail.com">struthm8@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello systemd-devel group.<br>I have just started using systemd-resolved to try and achieve a goal that I will try to explain.<br>I know very little about it (web searches so far) so please excuse any silly questions or trains of thought.<br>I have a Debian Bullseye client in a Microsoft network that uses a .local domain.<br>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.<br>I have read here [ <a href="https://github.com/systemd/systemd/issues/8852" target="_blank" rel="noreferrer">https://github.com/systemd/systemd/issues/8852</a> ] that .local can be used.<br><br>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.<br><br>I thought that systemd-resolved could cache the DNS entries and retain them until any of the DNS Servers returned to service.<br>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.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">"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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I would ideally like the entries to stay in cache until updated from DNS Server again (once one returns to service).<br><br>On the SRV point: How can I be sure that it caches the full result of the SRV query?<br>Eg: SRV gives 2 x A-records which then need to resolve to 2xIP-addresses.</div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>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.<br>Please excuse if this is too much or too little information.<br><br>root@VATCPCOMMLC1:~# cat /etc/systemd/resolved.conf<br>[Resolve]<br>DNS= 10.24.1.135 10.24.129.135 10.24.1.136 10.24.129.136<br>#FallbackDNS=<br>Domains=itsvic.local<br>#DNSSEC=no<br>#DNSOverTLS=no<br>#MulticastDNS=yes<br>#LLMNR=yes<br>#Cache=yes<br>DNSStubListener=yes<br>#DNSStubListenerExtra=<br>#ReadEtcHosts=yes<br>#ResolveUnicastSingleLabel=no<br>root@VATCPCOMMLC1:~#<br><br>root@VATCPCOMMLC1:~# ls -l /etc/resolv.conf<br>lrwxrwxrwx 1 root root 39 Jul 30 14:11 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf<br>root@VATCPCOMMLC1:~#<br>root@VATCPCOMMLC1:~# cat ../run/systemd/resolve/stub-resolv.conf<br>nameserver 127.0.0.53<br>options edns0 trust-ad<br>search itsvic.local<br>root@VATCPCOMMLC1:~#<br><br>root@VATCPCOMMLC1:~# cat /etc/nsswitch.conf<br># /etc/nsswitch.conf<br>passwd: files systemd<br>group: files systemd<br>shadow: files<br>gshadow: files<br>hosts: files dns<br>networks: files<br>protocols: db files<br>services: db files<br>ethers: db files<br>rpc: db files<br>netgroup: nis<br>root@VATCPCOMMLC1:~# <br>root@VATCPCOMMLC1:~# resolvectl statusresolvectl status<br>Global<br> Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported<br> resolv.conf mode: stub<br>Current DNS Server: 10.24.1.135<br> DNS Servers: 10.24.1.135 10.24.129.135 10.24.1.136 10.24.129.136<br> DNS Domain: itsvic.local<br>Link 2 (ens192)<br>Current Scopes: none<br> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported<br><br>Link 3 (ens224)<br>Current Scopes: none<br> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported<br><br>Link 4 (bond0)<br>Current Scopes: LLMNR/IPv4 LLMNR/IPv6<br> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported<br><br>root@VATCPCOMMLC1:~# dig srv _sip._tcp.osvsig-mets-prod.voip.itsvic.local<br>dig srv _sip._tcp.osvsig-mets-prod.voip.itsvic.local<br>; <<>> DiG 9.16.48-Debian <<>> srv _sip._tcp.osvsig-mets-prod.voip.itsvic.local<br>;; global options: +cmd<br>;; Got answer:<br>;; WARNING: .local is reserved for Multicast DNS<br>;; You are currently testing what happens when an mDNS query is leaked to DNS<br>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57884<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 65494<br>;; QUESTION SECTION:<br>;_sip._tcp.osvsig-mets-prod.voip.itsvic.local. IN SRV<br><br>;; ANSWER SECTION:<br>_sip._tcp.osvsig-mets-prod.voip.itsvic.local. 3600 IN SRV 20 0 5060 osvn2-mets-prod.voip.itsvic.local.<br>_sip._tcp.osvsig-mets-prod.voip.itsvic.local. 3600 IN SRV 10 0 5060 osvn1-mets-prod.voip.itsvic.local.<br><br>;; Query time: 0 msec<br>;; SERVER: 127.0.0.53#53(127.0.0.53)<br>;; WHEN: Tue Jul 30 15:38:47 AEST 2024<br>;; MSG SIZE rcvd: 179<br><br>Thanks for any help.</div> </blockquote></div></div></div>