Why is systemd-resolved falling back to using Google Public DNS over IPv6 when I did not configure it to do...












2















I'm having problems with SystemD's resolved service on Ubuntu 18.10 - on my wireless network we have an IPv6 subnet that is tunneled through some weird network setup (work stuff) and can't be used for DNS resolution.



For some reason, even though I have set up static DNS configuration in /etc/systemd/resolved.conf.d/dns.conf to only include IPv4 DNS records, and the DHCP never advertises IPv6 DNS servers, resolved always adds some funky IPv6 addresses to the connection-specific DNS configuration on my wireless connection, and then "fallsback" to them and stops resolving addresses.



This is my dns.conf (the primary resolved.conf is default - there's nothing there):



[Resolve]

DNS=172.18.1.254 8.8.8.8 8.8.4.4 1.1.1.1

DNSSEC=no


(the first DNS address is the local router)



The resolved global configuration (as can be gotten from resolvectl status):



Global

       LLMNR setting: no

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 172.18.1.254

         DNS Servers: 172.18.1.254

                      8.8.8.8

                      8.8.4.4

                      1.1.1.1

...



Link 2 (wlp2s0)

      Current Scopes: DNS

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 2001:4860:4860::4444

         DNS Servers: 172.18.1.254

                      8.8.8.8

                      8.8.4.4

                      2001:470:1f09:114c::1

                      2001:4860:4860::4444

                      2001:4860:4860::8888

          DNS Domain: ~.


The wlp2s0 status starts with the current DNS server set as 172.18.1.254, then after a short time (we're talking minutes here), it falls back through all the IPv4 servers and lands on one of the IPv6 servers - after which all DNS queries fail, and I'm basically get disconnected from any meaningful network operation. A systemctl restart systemd-resolved clears the issue for a few minutes, after which its back to "no DNS for you, come back when you have a non-IPv6 network".



I have no idea where those IPv6 addresses come from. I've enabled debug logging on resolved, and looking at the debug log the first mention of an IPv6 address is something like this:



Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Switching to DNS server 2001:470:1f09:114c::1 for interface wlp2s0.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using DNS server 2001:470:1f09:114c::1 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.


It looks like if something on my system queries an address that cannot be resolved, and the upstream DNS server returns SERVFAIL (this is not just my local router's DNS resolver that is broken - 8.8.8.8 returns the same response), then resolved falls back through all the server until it finds a server that doesn't respond at all - on the way causing any query, not just the one that is broken, to use a broken server.



I can trace the path of such an escalation in the debug log (some.domain is a placeholder for another address that cannot be resolved):



Feb 12 10:36:01 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:01 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Using DNS server 172.18.1.254 for transaction 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Cache miss for some.domain IN AAAA

Feb 12 10:36:01 vesho systemd-resolved[22371]: Transaction 44627 for <some.domain IN AAAA> scope dns on wlp2s0/*.

...

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Switching to DNS server 8.8.8.8 for interface wlp2s0.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using DNS server 8.8.8.8 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Server returned error SERVFAIL, retrying transaction with reduced feature level UDP.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Switching to DNS server 8.8.4.4 for interface wlp2s0.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using DNS server 8.8.4.4 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Server returned error SERVFAIL, retrying transaction with reduced feature level UDP.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Switching to DNS server 2001:470:1f09:114c::1 for interface wlp2s0.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using DNS server 2001:470:1f09:114c::1 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:08 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:08 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:08 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Using DNS server 2001:4860:4860::8888 for transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:13 vesho systemd-resolved[22371]: Timeout reached on transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:13 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:18 vesho systemd-resolved[22371]: Timeout reached on transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:18 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Sending query packet with id 51369.

... 

goes like that for a while

...

Feb 12 10:36:28 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:28 vesho systemd-resolved[22371]: Server returned error: SERVFAIL

Feb 12 10:36:28 vesho systemd-resolved[22371]: Added SERVFAIL cache entry for some.domain IN A 30s

Feb 12 10:36:28 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> on scope dns on wlp2s0/* now complete with <rcode-failure> from network (unsigned)

Feb 12 10:36:28 vesho systemd-resolved[22371]: Freeing transaction 51369.


So to conclude, my question is: Where does resovled find those IPv6 server addresses and how can I stop it from using them at all (setting a hardcoded DNS or FallbackDNS in the configuration files doesn't seem to stop it)?



If anyone has any suggestion for another solution to this problem, I'd love to hear it. Except if its "disable resolved" - I'm actually doing that now so I can get some work done, but I'd like to get to the bottom of this resolved problem and fix it.






networking dns systemd-resolved







share|improve this question

























  • The proper IPV6 addresses of Google Public DNS do not, really, qualify as "funky". (-:

    – JdeBP
    Feb 13 at 16:59











  • I thought its something like this, but term "funky" here refers to how they appear out of thin air - I did not configure this.

    – Guss
    Feb 13 at 17:01











  • Why is systemd-resolved falling back to using Google Public DNS over IPv6 when I did not configure it to do that? has more of the right keywords. (-:

    – JdeBP
    Feb 13 at 18:00











  • Thank you for the suggestion, I updated the question subject.

    – Guss
    Feb 13 at 18:20
















2















I'm having problems with SystemD's resolved service on Ubuntu 18.10 - on my wireless network we have an IPv6 subnet that is tunneled through some weird network setup (work stuff) and can't be used for DNS resolution.



For some reason, even though I have set up static DNS configuration in /etc/systemd/resolved.conf.d/dns.conf to only include IPv4 DNS records, and the DHCP never advertises IPv6 DNS servers, resolved always adds some funky IPv6 addresses to the connection-specific DNS configuration on my wireless connection, and then "fallsback" to them and stops resolving addresses.



This is my dns.conf (the primary resolved.conf is default - there's nothing there):



[Resolve]

DNS=172.18.1.254 8.8.8.8 8.8.4.4 1.1.1.1

DNSSEC=no


(the first DNS address is the local router)



The resolved global configuration (as can be gotten from resolvectl status):



Global

       LLMNR setting: no

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 172.18.1.254

         DNS Servers: 172.18.1.254

                      8.8.8.8

                      8.8.4.4

                      1.1.1.1

...



Link 2 (wlp2s0)

      Current Scopes: DNS

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 2001:4860:4860::4444

         DNS Servers: 172.18.1.254

                      8.8.8.8

                      8.8.4.4

                      2001:470:1f09:114c::1

                      2001:4860:4860::4444

                      2001:4860:4860::8888

          DNS Domain: ~.


The wlp2s0 status starts with the current DNS server set as 172.18.1.254, then after a short time (we're talking minutes here), it falls back through all the IPv4 servers and lands on one of the IPv6 servers - after which all DNS queries fail, and I'm basically get disconnected from any meaningful network operation. A systemctl restart systemd-resolved clears the issue for a few minutes, after which its back to "no DNS for you, come back when you have a non-IPv6 network".



I have no idea where those IPv6 addresses come from. I've enabled debug logging on resolved, and looking at the debug log the first mention of an IPv6 address is something like this:



Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Switching to DNS server 2001:470:1f09:114c::1 for interface wlp2s0.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using DNS server 2001:470:1f09:114c::1 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.


It looks like if something on my system queries an address that cannot be resolved, and the upstream DNS server returns SERVFAIL (this is not just my local router's DNS resolver that is broken - 8.8.8.8 returns the same response), then resolved falls back through all the server until it finds a server that doesn't respond at all - on the way causing any query, not just the one that is broken, to use a broken server.



I can trace the path of such an escalation in the debug log (some.domain is a placeholder for another address that cannot be resolved):



Feb 12 10:36:01 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:01 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Using DNS server 172.18.1.254 for transaction 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Cache miss for some.domain IN AAAA

Feb 12 10:36:01 vesho systemd-resolved[22371]: Transaction 44627 for <some.domain IN AAAA> scope dns on wlp2s0/*.

...

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Switching to DNS server 8.8.8.8 for interface wlp2s0.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using DNS server 8.8.8.8 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Server returned error SERVFAIL, retrying transaction with reduced feature level UDP.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Switching to DNS server 8.8.4.4 for interface wlp2s0.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using DNS server 8.8.4.4 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Server returned error SERVFAIL, retrying transaction with reduced feature level UDP.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Switching to DNS server 2001:470:1f09:114c::1 for interface wlp2s0.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using DNS server 2001:470:1f09:114c::1 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:08 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:08 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:08 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Using DNS server 2001:4860:4860::8888 for transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:13 vesho systemd-resolved[22371]: Timeout reached on transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:13 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:18 vesho systemd-resolved[22371]: Timeout reached on transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:18 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Sending query packet with id 51369.

... 

goes like that for a while

...

Feb 12 10:36:28 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:28 vesho systemd-resolved[22371]: Server returned error: SERVFAIL

Feb 12 10:36:28 vesho systemd-resolved[22371]: Added SERVFAIL cache entry for some.domain IN A 30s

Feb 12 10:36:28 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> on scope dns on wlp2s0/* now complete with <rcode-failure> from network (unsigned)

Feb 12 10:36:28 vesho systemd-resolved[22371]: Freeing transaction 51369.


So to conclude, my question is: Where does resovled find those IPv6 server addresses and how can I stop it from using them at all (setting a hardcoded DNS or FallbackDNS in the configuration files doesn't seem to stop it)?



If anyone has any suggestion for another solution to this problem, I'd love to hear it. Except if its "disable resolved" - I'm actually doing that now so I can get some work done, but I'd like to get to the bottom of this resolved problem and fix it.






networking dns systemd-resolved







share|improve this question

























  • The proper IPV6 addresses of Google Public DNS do not, really, qualify as "funky". (-:

    – JdeBP
    Feb 13 at 16:59











  • I thought its something like this, but term "funky" here refers to how they appear out of thin air - I did not configure this.

    – Guss
    Feb 13 at 17:01











  • Why is systemd-resolved falling back to using Google Public DNS over IPv6 when I did not configure it to do that? has more of the right keywords. (-:

    – JdeBP
    Feb 13 at 18:00











  • Thank you for the suggestion, I updated the question subject.

    – Guss
    Feb 13 at 18:20














2












2








2








I'm having problems with SystemD's resolved service on Ubuntu 18.10 - on my wireless network we have an IPv6 subnet that is tunneled through some weird network setup (work stuff) and can't be used for DNS resolution.



For some reason, even though I have set up static DNS configuration in /etc/systemd/resolved.conf.d/dns.conf to only include IPv4 DNS records, and the DHCP never advertises IPv6 DNS servers, resolved always adds some funky IPv6 addresses to the connection-specific DNS configuration on my wireless connection, and then "fallsback" to them and stops resolving addresses.



This is my dns.conf (the primary resolved.conf is default - there's nothing there):



[Resolve]

DNS=172.18.1.254 8.8.8.8 8.8.4.4 1.1.1.1

DNSSEC=no


(the first DNS address is the local router)



The resolved global configuration (as can be gotten from resolvectl status):



Global

       LLMNR setting: no

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 172.18.1.254

         DNS Servers: 172.18.1.254

                      8.8.8.8

                      8.8.4.4

                      1.1.1.1

...



Link 2 (wlp2s0)

      Current Scopes: DNS

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 2001:4860:4860::4444

         DNS Servers: 172.18.1.254

                      8.8.8.8

                      8.8.4.4

                      2001:470:1f09:114c::1

                      2001:4860:4860::4444

                      2001:4860:4860::8888

          DNS Domain: ~.


The wlp2s0 status starts with the current DNS server set as 172.18.1.254, then after a short time (we're talking minutes here), it falls back through all the IPv4 servers and lands on one of the IPv6 servers - after which all DNS queries fail, and I'm basically get disconnected from any meaningful network operation. A systemctl restart systemd-resolved clears the issue for a few minutes, after which its back to "no DNS for you, come back when you have a non-IPv6 network".



I have no idea where those IPv6 addresses come from. I've enabled debug logging on resolved, and looking at the debug log the first mention of an IPv6 address is something like this:



Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Switching to DNS server 2001:470:1f09:114c::1 for interface wlp2s0.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using DNS server 2001:470:1f09:114c::1 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.


It looks like if something on my system queries an address that cannot be resolved, and the upstream DNS server returns SERVFAIL (this is not just my local router's DNS resolver that is broken - 8.8.8.8 returns the same response), then resolved falls back through all the server until it finds a server that doesn't respond at all - on the way causing any query, not just the one that is broken, to use a broken server.



I can trace the path of such an escalation in the debug log (some.domain is a placeholder for another address that cannot be resolved):



Feb 12 10:36:01 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:01 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Using DNS server 172.18.1.254 for transaction 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Cache miss for some.domain IN AAAA

Feb 12 10:36:01 vesho systemd-resolved[22371]: Transaction 44627 for <some.domain IN AAAA> scope dns on wlp2s0/*.

...

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Switching to DNS server 8.8.8.8 for interface wlp2s0.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using DNS server 8.8.8.8 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Server returned error SERVFAIL, retrying transaction with reduced feature level UDP.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Switching to DNS server 8.8.4.4 for interface wlp2s0.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using DNS server 8.8.4.4 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Server returned error SERVFAIL, retrying transaction with reduced feature level UDP.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Switching to DNS server 2001:470:1f09:114c::1 for interface wlp2s0.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using DNS server 2001:470:1f09:114c::1 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:08 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:08 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:08 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Using DNS server 2001:4860:4860::8888 for transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:13 vesho systemd-resolved[22371]: Timeout reached on transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:13 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:18 vesho systemd-resolved[22371]: Timeout reached on transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:18 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Sending query packet with id 51369.

... 

goes like that for a while

...

Feb 12 10:36:28 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:28 vesho systemd-resolved[22371]: Server returned error: SERVFAIL

Feb 12 10:36:28 vesho systemd-resolved[22371]: Added SERVFAIL cache entry for some.domain IN A 30s

Feb 12 10:36:28 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> on scope dns on wlp2s0/* now complete with <rcode-failure> from network (unsigned)

Feb 12 10:36:28 vesho systemd-resolved[22371]: Freeing transaction 51369.


So to conclude, my question is: Where does resovled find those IPv6 server addresses and how can I stop it from using them at all (setting a hardcoded DNS or FallbackDNS in the configuration files doesn't seem to stop it)?



If anyone has any suggestion for another solution to this problem, I'd love to hear it. Except if its "disable resolved" - I'm actually doing that now so I can get some work done, but I'd like to get to the bottom of this resolved problem and fix it.






networking dns systemd-resolved







share|improve this question
















I'm having problems with SystemD's resolved service on Ubuntu 18.10 - on my wireless network we have an IPv6 subnet that is tunneled through some weird network setup (work stuff) and can't be used for DNS resolution.



For some reason, even though I have set up static DNS configuration in /etc/systemd/resolved.conf.d/dns.conf to only include IPv4 DNS records, and the DHCP never advertises IPv6 DNS servers, resolved always adds some funky IPv6 addresses to the connection-specific DNS configuration on my wireless connection, and then "fallsback" to them and stops resolving addresses.



This is my dns.conf (the primary resolved.conf is default - there's nothing there):



[Resolve]

DNS=172.18.1.254 8.8.8.8 8.8.4.4 1.1.1.1

DNSSEC=no


(the first DNS address is the local router)



The resolved global configuration (as can be gotten from resolvectl status):



Global

       LLMNR setting: no

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 172.18.1.254

         DNS Servers: 172.18.1.254

                      8.8.8.8

                      8.8.4.4

                      1.1.1.1

...



Link 2 (wlp2s0)

      Current Scopes: DNS

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 2001:4860:4860::4444

         DNS Servers: 172.18.1.254

                      8.8.8.8

                      8.8.4.4

                      2001:470:1f09:114c::1

                      2001:4860:4860::4444

                      2001:4860:4860::8888

          DNS Domain: ~.


The wlp2s0 status starts with the current DNS server set as 172.18.1.254, then after a short time (we're talking minutes here), it falls back through all the IPv4 servers and lands on one of the IPv6 servers - after which all DNS queries fail, and I'm basically get disconnected from any meaningful network operation. A systemctl restart systemd-resolved clears the issue for a few minutes, after which its back to "no DNS for you, come back when you have a non-IPv6 network".



I have no idea where those IPv6 addresses come from. I've enabled debug logging on resolved, and looking at the debug log the first mention of an IPv6 address is something like this:



Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Switching to DNS server 2001:470:1f09:114c::1 for interface wlp2s0.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using DNS server 2001:470:1f09:114c::1 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.


It looks like if something on my system queries an address that cannot be resolved, and the upstream DNS server returns SERVFAIL (this is not just my local router's DNS resolver that is broken - 8.8.8.8 returns the same response), then resolved falls back through all the server until it finds a server that doesn't respond at all - on the way causing any query, not just the one that is broken, to use a broken server.



I can trace the path of such an escalation in the debug log (some.domain is a placeholder for another address that cannot be resolved):



Feb 12 10:36:01 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:01 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Using DNS server 172.18.1.254 for transaction 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:01 vesho systemd-resolved[22371]: Cache miss for some.domain IN AAAA

Feb 12 10:36:01 vesho systemd-resolved[22371]: Transaction 44627 for <some.domain IN AAAA> scope dns on wlp2s0/*.

...

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Switching to DNS server 8.8.8.8 for interface wlp2s0.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using DNS server 8.8.8.8 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Server returned error SERVFAIL, retrying transaction with reduced feature level UDP.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:03 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Switching to DNS server 8.8.4.4 for interface wlp2s0.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:03 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Using DNS server 8.8.4.4 for transaction 51369.

Feb 12 10:36:03 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Server returned error SERVFAIL, retrying transaction with reduced feature level UDP.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:04 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Switching to DNS server 2001:470:1f09:114c::1 for interface wlp2s0.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:04 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Using DNS server 2001:470:1f09:114c::1 for transaction 51369.

Feb 12 10:36:04 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:08 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:08 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:08 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Using DNS server 2001:4860:4860::8888 for transaction 51369.

Feb 12 10:36:08 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:13 vesho systemd-resolved[22371]: Timeout reached on transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:13 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:13 vesho systemd-resolved[22371]: Sending query packet with id 51369.

...

Feb 12 10:36:18 vesho systemd-resolved[22371]: Timeout reached on transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Retrying transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Switching to DNS server 2001:4860:4860::8888 for interface wlp2s0.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Cache miss for some.domain IN A

Feb 12 10:36:18 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> scope dns on wlp2s0/*.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Using feature level UDP+EDNS0 for transaction 51369.

Feb 12 10:36:18 vesho systemd-resolved[22371]: Sending query packet with id 51369.

... 

goes like that for a while

...

Feb 12 10:36:28 vesho systemd-resolved[22371]: Processing incoming packet on transaction 51369 (rcode=SERVFAIL).

Feb 12 10:36:28 vesho systemd-resolved[22371]: Server returned error: SERVFAIL

Feb 12 10:36:28 vesho systemd-resolved[22371]: Added SERVFAIL cache entry for some.domain IN A 30s

Feb 12 10:36:28 vesho systemd-resolved[22371]: Transaction 51369 for <some.domain IN A> on scope dns on wlp2s0/* now complete with <rcode-failure> from network (unsigned)

Feb 12 10:36:28 vesho systemd-resolved[22371]: Freeing transaction 51369.


So to conclude, my question is: Where does resovled find those IPv6 server addresses and how can I stop it from using them at all (setting a hardcoded DNS or FallbackDNS in the configuration files doesn't seem to stop it)?



If anyone has any suggestion for another solution to this problem, I'd love to hear it. Except if its "disable resolved" - I'm actually doing that now so I can get some work done, but I'd like to get to the bottom of this resolved problem and fix it.






networking dns systemd-resolved




networking dns systemd-resolved






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 13 at 18:20







Guss

















asked Feb 13 at 16:52









GussGuss

6,29111326




6,29111326













  • The proper IPV6 addresses of Google Public DNS do not, really, qualify as "funky". (-:

    – JdeBP
    Feb 13 at 16:59











  • I thought its something like this, but term "funky" here refers to how they appear out of thin air - I did not configure this.

    – Guss
    Feb 13 at 17:01











  • Why is systemd-resolved falling back to using Google Public DNS over IPv6 when I did not configure it to do that? has more of the right keywords. (-:

    – JdeBP
    Feb 13 at 18:00











  • Thank you for the suggestion, I updated the question subject.

    – Guss
    Feb 13 at 18:20



















  • The proper IPV6 addresses of Google Public DNS do not, really, qualify as "funky". (-:

    – JdeBP
    Feb 13 at 16:59











  • I thought its something like this, but term "funky" here refers to how they appear out of thin air - I did not configure this.

    – Guss
    Feb 13 at 17:01











  • Why is systemd-resolved falling back to using Google Public DNS over IPv6 when I did not configure it to do that? has more of the right keywords. (-:

    – JdeBP
    Feb 13 at 18:00











  • Thank you for the suggestion, I updated the question subject.

    – Guss
    Feb 13 at 18:20

















The proper IPV6 addresses of Google Public DNS do not, really, qualify as "funky". (-:

– JdeBP
Feb 13 at 16:59





The proper IPV6 addresses of Google Public DNS do not, really, qualify as "funky". (-:

– JdeBP
Feb 13 at 16:59













I thought its something like this, but term "funky" here refers to how they appear out of thin air - I did not configure this.

– Guss
Feb 13 at 17:01





I thought its something like this, but term "funky" here refers to how they appear out of thin air - I did not configure this.

– Guss
Feb 13 at 17:01













Why is systemd-resolved falling back to using Google Public DNS over IPv6 when I did not configure it to do that? has more of the right keywords. (-:

– JdeBP
Feb 13 at 18:00





Why is systemd-resolved falling back to using Google Public DNS over IPv6 when I did not configure it to do that? has more of the right keywords. (-:

– JdeBP
Feb 13 at 18:00













Thank you for the suggestion, I updated the question subject.

– Guss
Feb 13 at 18:20





Thank you for the suggestion, I updated the question subject.

– Guss
Feb 13 at 18:20










0






active

oldest

votes











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500438%2fwhy-is-systemd-resolved-falling-back-to-using-google-public-dns-over-ipv6-when-i%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500438%2fwhy-is-systemd-resolved-falling-back-to-using-google-public-dns-over-ipv6-when-i%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

How to make a Squid Proxy server?

Image
1 I want to set up squid proxy server for monitoring user activity in a network and Internet Web URL filtering for user. I also want to configure the user login, user log, user access group, and block unwanted web sites in my network. Please help me and guide me the full process to do this. server proxy squid share | improve this question edited Jul 31 '12 at 14:45 Jorge Castro 37.1k 107 422 617 asked Jul 31 '12 at 5:16 Goivind Tiwari Goivind Tiwari ...
Read more

Is this a new Fibonacci Identity?

Image
6 1 $begingroup$ I have found the following Fibonacci Identity (and proved it). If $F_n$ denotes the nth Fibonacci Number, we have the following identity begin{equation} F_{n-r+h}F_{n+k+g+1} - F_{n-r+g}F_{n+k+h+1} = (-1)^{n+r+h+1} F_{g-h}F_{k+r+1} end{equation} where $F_1 = F_2 = 1$ , $r leq n$ , $h leq g$ , and $n, g, k in mathbb{N}$ . It is not too hard to show that this identity subsumes Cassini's Identity, Catalan's Identity, Vajda's Idenity, and d'Ocagne's identity to name a few. I have done a pretty thorough literature review, and I have not found anything like this, but I am still wondering if anyone has seen this identity before? I found this by accident after noticing some patterns in some analysis work I was doing, so if this is already known I would be curious to see w...
Read more

19世紀

Image
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。 （ 2012年3月 ） 千年紀: 2千年紀 世紀: 18世紀 - 19世紀 - 20世紀 十年紀: 1800年代 1810年代 1820年代 1830年代 1840年代 1850年代 1860年代 1870年代 1880年代 1890年代 19世紀に君臨した大英帝国。 19世紀 （じゅうきゅうせいき）は、西暦1801年から西暦1900年までの100年間を指す世紀。 目次 1 19世紀の歴史 1.1 国民国家の成立 1.2 帝国主義の興隆 1.3 列強の植民地争奪戦 2 できごと 2.1 1800年代 2.2 1810年代 2.3 1820年代 2.4 1830年代 2.5 1840年代 2.6 1850年代 2.7 1860年代 2.8 1870年代 2.9 1880年代 2.10 1890年代 2.11 1900年代 3 文化 3.1 文学 3.2 音楽 3.3 思想 3.4 科学 3.5 技術 4 人物 4.1 ヨーロッパ 4.1.1 政治家・王族 4.1.1.1 フランス 4.1.1.2 オーストリア＝ハンガリー 4.1.1.3 ロシア 4.1.1.4 イギリス 4.1.1.5 ドイツ（プロイセンほかドイツ領邦を含む） 4.1.1.6 北欧 4.1.1.7 イタリア 4.1.1.8 スペイン 4.1.1.9 ベルギー 4.1.1.10 ギリシア 4.1.2 軍人 4.1.3 実業家 4.1.4 科学と技術 4.1.5 思想と哲学・人文諸学 4.1.6 宗教 4.1.7 文学 4.1.8 美術 4.1.9 音楽 4.1.10 社会事業家 4.1.11 探検家・旅行家 4.1.12 料...
Read more