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

Windl, Ulrich u.windl at ukr.de
Fri Aug 2 06:40:05 UTC 2024


Hi!

It does not answer your question, but I wonder who at the Microsoft world started to suggest using “.local” as domain. See https://en.wikipedia.org/wiki/.local for further details.

Ulrich

From: systemd-devel <systemd-devel-bounces at lists.freedesktop.org> On Behalf Of struth
Sent: Friday, August 2, 2024 1:04 AM
To: systemd-devel at lists.freedesktop.org
Subject: [EXT] [systemd-devel] Some base questions around systemd-resolved

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.
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'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/b46e0dc8/attachment.htm>


More information about the systemd-devel mailing list