0

Lately systemd-resolved fails to resolve most domains with the following error:

$ resolvectl query slashdot.org
slashdot.org: resolve call failed: 'slashdot.org' does not have any RR of the requested type

I have currently reduced my config to the following:

[Resolve]
DNS=1.1.1.1
$ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/unsupported
    resolv.conf mode: foreign
  Current DNS Server: 1.1.1.1
         DNS Servers: 1.1.1.1
Fallback DNS Servers: 1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700::1111 2001:4860:4860::8888 2606:4700:4700::1001 2001:4860:4860::8844

I can resolve names through the same dns service via dig:

$ dig @1.1.1.1 slashdot.org

; <<>> DiG 9.16.11 <<>> @1.1.1.1 slashdot.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57735
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;slashdot.org.                  IN      A

;; ANSWER SECTION:
slashdot.org.           262     IN      A       216.105.38.15

;; Query time: 20 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Mar 31 10:33:43 CEST 2021
;; MSG SIZE  rcvd: 57

Somehow it still succeeds in resolving a few domains, even after I resolvectl flush-caches:

$ resolvectl query stackexchange.com
stackexchange.com: 151.101.65.69               -- link: enp0s25
                   151.101.1.69                -- link: enp0s25
                   151.101.193.69              -- link: enp0s25

-- Information acquired via protocol DNS in 34.2ms.
-- Data is authenticated: no

How can I solve this?

UPDATE

I have taken a look at the traffic (1st: resolvectl, 2nd dig):

20:29:53.540625 IP (tos 0x0, ttl 64, id 40410, offset 0, flags [DF], proto UDP (17), length 58)
    192.168.178.39.35819 > one.one.one.one.domain: [bad udp cksum 0x7509 -> 0x3c24!] 10838+% A? slashdot.org. (30)
20:29:53.558319 IP (tos 0x0, ttl 58, id 46858, offset 0, flags [DF], proto UDP (17), length 74)
    one.one.one.one.domain > 192.168.178.39.35819: [udp sum ok] 10838 q: A? slashdot.org. 1/0/0 slashdot.org. A 216.105.38.15 (46)
--
20:29:55.350287 IP (tos 0x0, ttl 64, id 40434, offset 0, flags [none], proto UDP (17), length 81)
    192.168.178.39.59104 > one.one.one.one.domain: [bad udp cksum 0x7520 -> 0x93a9!] 57704+ [1au] A? slashdot.org. ar: . OPT UDPsize=4096 [COOKIE e0f529ee021d164e] (53)
20:29:55.367233 IP (tos 0x0, ttl 58, id 57041, offset 0, flags [DF], proto UDP (17), length 85)
    one.one.one.one.domain > 192.168.178.39.59104: [udp sum ok] 57704 q: A? slashdot.org. 1/0/1 slashdot.org. A 216.105.38.15 ar: . OPT UDPsize=1232 (57)

resolvectl sets the CD bit, dig sets AD (which is cleared by the server). Other than that, they receive basically the same response. It's the same with the query about stackexchange, which succeeds. (Although I am surprised that I could still read the traffic after I had re-enabled DNS over TLS, the pcap doesn't show any tls records.)

2
  • My tool of choice is tcpdump. It is great at showing you the DNS queries that go over the wire. For example, tcpdump udp port 53, then run the above slashdot query. – berndbausch Mar 31 at 9:38
  • @berndbausch thank you! I have done so and have also inspected the recorded traffic in wireshark. Unfortunately I have still not been able to figure it out. – Moritz Petersen Mar 31 at 20:11
0

This was a bug in systemd which has since been fixed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.