Re: spurious failures of resolved

[Roman Odaisky <roma@xxxxxxxxxxx>]

On Thursday, 24 September 2020 15:07:12 EEST Kevin P. Fleming wrote:
> In your network configuration for the faulty link you can just set
> "UseDNS=no" in the 'DHCPv4' section and then resolved will not even
> try to use those resolvers.

Like most people, I don’t have any systemd network configuration files.
Isn’t Domains=~. supposed to be kind of a global UseDNS=no anyway?

For the record, my workaround is resolvectl dns wlp59s0 '', but the question 
is why is it even necessary.

-- 
WBR
Roman.

> On Thu, Sep 24, 2020 at 7:45 AM Roman Odaisky <roma@xxxxxxxxxxx> wrote:
> > Hi,
> > 
> > I have the following resolved configuration:
> > 
> > [Resolve]
> > DNS=8.8.8.8 8.8.4.4
> > Domains=~.
> > 
> > and the following resolvectl output:
> > 
> > Link 76 (usb0)
> > 
> >       Current Scopes: DNS
> > 
> > DefaultRoute setting: yes
> > 
> >        LLMNR setting: yes
> > 
> > MulticastDNS setting: no
> > 
> >   DNSOverTLS setting: no
> >   
> >       DNSSEC setting: no
> >     
> >     DNSSEC supported: no
> >   
> >   Current DNS Server: 192.168.42.129
> >   
> >          DNS Servers: 192.168.42.129
> >          
> >           DNS Domain: ~.
> > 
> > Link 2 (wlp59s0)
> > 
> >       Current Scopes: DNS
> > 
> > DefaultRoute setting: yes
> > 
> >        LLMNR setting: yes
> > 
> > MulticastDNS setting: no
> > 
> >   DNSOverTLS setting: no
> >   
> >       DNSSEC setting: no
> >     
> >     DNSSEC supported: no
> >   
> >   Current DNS Server: <an IP address>
> >   
> >          DNS Servers: <an IP address>
> >          
> >                       <an IP address>
> >           
> >           DNS Domain: ~.
> > 
> > The default route is via usb0. The wlp59s0 link is faulty (that’s why I’ve
> > resorted to USB tethering). The DNS servers provided by DHCP for that link
> > use public IP addresses yet decline to provide services for clients
> > outside that ISP, with responses like this:
> > 
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18189
> > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> > 
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 2800
> > ;; QUESTION SECTION:
> > ;freedesktop.org.               IN      A
> > 
> > (note it’s not an NXDOMAIN)
> > 
> > The second IP address is more honest and sets status: REFUSED.
> > 
> > This situation results in the following behavior: if I query some domain,
> > it always fails for the first time then works afterwards.
> > 
> > $ resolvectl query google.com.uy
> > google.com.uy: resolve call failed: 'google.com.uy' does not have any RR
> > of
> > the requested type
> > 
> > $ resolvectl query google.com.uy
> > google.com.uy: 172.217.169.163                 -- link: usb0
> > 
> > -- Information acquired via protocol DNS in 5.8ms.
> > -- Data is authenticated: no
> > 
> > Did I misconfigure something? Did I misread resolved.conf(5) which states
> > “Use the construct "~." to use the system DNS server defined with DNS=
> > preferably for all domains”? Is there a bug?
> > 
> > --
> > TIA
> > Roman.
> > 
> > 
> > _______________________________________________
> > systemd-devel mailing list
> > systemd-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel




_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel