☰

resolvctlクエリの失敗： 'domain'に要求されたタイプのRRがありません。

tag-icon • tag-icon networking systemd dns opensuse systemd-resolved
resolvctlクエリの失敗： 'domain'に要求されたタイプのRRがありません。

最近、systemd-resolvedは、次のエラーのため、ほとんどのドメインを特定できませんでした。

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

現在の構成を次のように減らしました。

[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

digを使用すると、同じDNSサービスを介して名前を解決できます。

$ 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

私が次のことを行った後でも、まだいくつかのドメインを解析できました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

この問題をどのように解決できますか？

修正する

トラフィックを見ました（最初：resolvctl、2番目の発掘）。

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)

resolvctlはCDビットを設定し、digはADを設定します（サーバーによってクリアされます）。そうでなければ、彼らが受け取った答えは本質的に同じでした。 stackexchangeを照会する場合も同様であり、成功します。 （TLSを介してDNSを再度有効にした後でもトラフィックを読み取ることができることに驚きましたが、pcapにはTLSレコードは表示されません。）

答え1

これは抜け穴systemdはこの問題を解決しました。

関連情報