Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

systemd-resolved fails to fall back to non-DNSSEC style requests in allow-downgrade mode. #21107

Open
jameshilliard opened this issue Oct 24, 2021 · 0 comments
Open

systemd-resolved fails to fall back to non-DNSSEC style requests in allow-downgrade mode. #21107

jameshilliard opened this issue Oct 24, 2021 · 0 comments
Labels
dnssec resolve

Comments

@jameshilliard
Copy link
Contributor

jameshilliard commented Oct 24, 2021 •
edited

systemd version the issue has been seen with

249

Used distribution

buildroot

Linux kernel version used (uname -a)

Linux buildroot 5.14.11 #1 SMP Sat Oct 23 05:21:36 MDT 2021 x86_64 GNU/Linux

CPU architecture issue was seen on

x86_64

Expected behaviour you didn't see

Systemd should fallback to using packets without any DNSSEC features if a resolver fails to respond(times out) to DNS packets using DNSSEC features like the "Checking Disabled" bit in allow-downgrade mode.

Unexpected behaviour you saw

Systemd keeps retrying unsuccessfully to query a resolver that does not support the "Checking Disabled" flag without falling back to regular DNS request with the "Checking Disabled" bit removed on request timeout. For some reason the dns server I'm hitting this issue with does allow the "Checking Disabled" bit to be set for private tld's, however those responses are of course unvalidated. The router/dns server appears to be a tp-link TL-WDR8690.

Steps to reproduce the problem

Run systemd with DNSOverTLS=opportunistic DNSSEC=allow-downgrade set with a dhcp assigned DNS server that does not respond to requests if the "Checking Disabled" bit is set.

Additional program output to the terminal or log subsystem illustrating the issue

Oct 21 02:27:55 buildroot systemd-resolved[211]: Using feature level UDP for transaction 59363.
Oct 21 02:27:55 buildroot systemd-resolved[211]: Emitting UDP, link MTU is 1500, socket MTU is 1500, minimal MTU is 40
Oct 21 02:27:55 buildroot systemd-resolved[211]: Sending query packet with id 59363 of size 40.
Oct 21 02:27:55 buildroot systemd-resolved[211]: Timeout reached on transaction 3233.
Oct 21 02:27:55 buildroot systemd-resolved[211]: Retrying transaction 3233, after switching servers.
Oct 21 02:27:55 buildroot systemd-resolved[211]: Cache miss for bing.com IN A
Oct 21 02:27:55 buildroot systemd-resolved[211]: Firing regular transaction 3233 for <bing.com IN A> scope dns on enp1s0/* (validate=yes).
Oct 21 02:27:55 buildroot systemd-resolved[211]: Using feature level UDP for transaction 3233.
Oct 21 02:27:55 buildroot systemd-resolved[211]: Emitting UDP, link MTU is 1500, socket MTU is 1500, minimal MTU is 40
Oct 21 02:27:55 buildroot systemd-resolved[211]: Sending query packet with id 3233 of size 26.

Note that even though the resolved transaction feature level appears to be "UDP" wireshark traces show the DNSSEC flag "Checking Disabled" flag is still present which causes the router's DNS server to fail to respond at all to queries(except private domain/tld queries).

# resolvectl --no-pager
Global
           Protocols: +LLMNR +mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/unsupported
    resolv.conf mode: uplink
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2001:4860:4860::8888#dns.google
                      2606:4700:4700::1001#cloudflare-dns.com 2001:4860:4860::8844#dns.google

Link 2 (enp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/unsupported
Current DNS Server: 192.168.0.101
       DNS Servers: 192.168.0.101

Link 3 (sit0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported

Link 4 (wlp2s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported

Link 5 (wg2)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported

Link 6 (wg0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported

Link 7 (wg1)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported

Is it normal to have validate=yes:

Oct 21 02:27:55 buildroot systemd-resolved[211]: Firing regular transaction 3233 for <bing.com IN A> scope dns on enp1s0/* (validate=yes).

on a link with allow-downgrade/unsupported?:

Link 2 (enp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/unsupported
Current DNS Server: 192.168.0.101
       DNS Servers: 192.168.0.101

# dig @192.168.0.101 bing.com +noadflag +noedns +cdflag

; <<>> DiG 9.11.35 <<>> @192.168.0.101 bing.com +noadflag +noedns +cdflag
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

# dig @192.168.0.101 bing.com +noadflag +noedns +nocdflag

; <<>> DiG 9.11.35 <<>> @192.168.0.101 bing.com +noadflag +noedns +nocdflag
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31049
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bing.com.			IN	A

;; ANSWER SECTION:
bing.com.		60	IN	A	13.107.21.200
bing.com.		60	IN	A	204.79.197.200

;; Query time: 0 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Sun Oct 24 09:22:38 UTC 2021
;; MSG SIZE  rcvd: 58

# dig @192.168.0.101 tplogin.cn +noadflag +noedns +cdflag

; <<>> DiG 9.11.35 <<>> @192.168.0.101 tplogin.cn +noadflag +noedns +cdflag
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43498
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;tplogin.cn.			IN	A

;; ANSWER SECTION:
tplogin.cn.		0	IN	A	192.168.0.101

;; Query time: 0 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Sun Oct 24 09:24:33 UTC 2021
;; MSG SIZE  rcvd: 44

# dig @192.168.0.101 tplogin.cn +noadflag +noedns +nocdflag

; <<>> DiG 9.11.35 <<>> @192.168.0.101 tplogin.cn +noadflag +noedns +nocdflag
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41458
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;tplogin.cn.			IN	A

;; ANSWER SECTION:
tplogin.cn.		0	IN	A	192.168.0.101

;; Query time: 0 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Sun Oct 24 09:25:05 UTC 2021
;; MSG SIZE  rcvd: 44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
dnssec resolve
Milestone
No milestone
Development

No branches or pull requests
2 participants
@poettering @jameshilliard