2

On one of my servers starting this morning, every DNS lookup sent to systemd-resolved comes backs SERVFAIL and I am completely stuck debugging any further as there are not any errors to go on. I am running a fresh install of Ubuntu 19.10.

DNS Lookup:

$ dig google.com @127.0.0.53

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> google.com @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42929
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.            IN  A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Mar 29 10:56:07 PDT 2020
;; MSG SIZE  rcvd: 39
$ resolvectl query google.com
google.com: resolve call failed: No appropriate name servers or networks for name found

And the systemd-resolve status:

$ systemd-resolve --status | cat
Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 9 (vnet1)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 8 (vnet0)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 7 (virbr0-nic)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 6 (virbr0)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 5 (br0)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.0.0.1

Link 4 (enp6s0)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (eno2)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.0.0.1

Link 2 (eno1)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Neither restarting the systemd-resolved service, nor restarting the server fixes things.

When I query a DNS server directly with dig, it resolves as expected.

Has anybody ran into this before or have ideas on what I could look at further to try and figure out what is going on?

3
  • Your dig example did not come back with an answer either. Try the 10.0.0.1 directly.
    – ubfan1
    Mar 29, 2020 at 19:18
  • When I connect to 10.0.0.1 directly with dig, it returns successfully
    – Nathan
    Mar 29, 2020 at 19:22
  • I'd expect a "Current Scopes:" to be DNS on a link with a DNS server, and to have some "DNS Domains" set. I can't help much beyond that, sorry.
    – ubfan1
    Mar 29, 2020 at 19:36

1 Answer 1

0

I had the same issue on my Hyper-V ubuntu 18.04 VM for the last two days. I ended up adding the upstream DNS in /etc/systemd/resolved.conf. I tried adding 8.8.8.8, 1.1.1.1 as the upstream but they wouldn't work.

What worked for me was adding the host windows machine's address.

[Resolve]   
DNS=192.168.96.1

restart service
systemd-resolved restart

Validate output with
systemd-resolve --status

Global
         DNS Servers: **192.168.96.1**
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .