Re: Temporary failure in name resolution

[Dan Ritter]

Shaheena Kazi wrote: 
> Package: ntpsec
> 
> Hello, we were using Bullseye and have upgraded to Bookworm.
> With Bookworm, we have ntpsec.
> The package is installed successfully and the service looks good.
> But the syslog is filled with below messages:
> 
> 2024-03-06T14:58:11.724851+05:30 hostname-shaheena ntpd[35823]: DNS:
> dns_check: DNS error: -3, Temporary failure in name resolution
> 2024-03-06T14:58:11.724862+05:30 hostname-shaheena ntpd[35823]: DNS:
> dns_take_status: None=>temp, 3
> 2024-03-06T14:58:19.572547+05:30 hostname-shaheena ntpd[35823]: DNS:
> dns_probe: None, cast_flags:1, flags:20801
> 2024-03-06T14:58:19.588607+05:30 hostname-shaheena ntpd[35823]: DNS:
> dns_check: processing None, 1, 20801
> 
> In ntp.conf the server is always set to None. We keep it to None always.

Did you name a machine "None" in /etc/hosts or your local DNS?

NTP does not work without either an authoritative clock or a
remote NTP server - preferably a pool of NTP servers. Do you
have an authoritative clock source, such as a GPS receiver or an
atomic clock?

Please show us your complete ntp.conf


-dsr-

Temporary failure in name resolution

[Shaheena Kazi]

Package: ntpsec

Hello, we were using Bullseye and have upgraded to Bookworm.
With Bookworm, we have ntpsec.
The package is installed successfully and the service looks good.
But the syslog is filled with below messages:

2024-03-06T14:58:11.724851+05:30 hostname-shaheena ntpd[35823]: DNS:
dns_check: DNS error: -3, Temporary failure in name resolution
2024-03-06T14:58:11.724862+05:30 hostname-shaheena ntpd[35823]: DNS:
dns_take_status: None=>temp, 3
2024-03-06T14:58:19.572547+05:30 hostname-shaheena ntpd[35823]: DNS:
dns_probe: None, cast_flags:1, flags:20801
2024-03-06T14:58:19.588607+05:30 hostname-shaheena ntpd[35823]: DNS:
dns_check: processing None, 1, 20801

In ntp.conf the server is always set to None. We keep it to None always.

In bullseye it never gave any such messages in the syslog.. even though the
server was None.
But with Bookworm, it gives the above messages in syslog.

When I change the server to the ntp server name in the ntp.conf file... I
don't see these messages in the syslog.

Am I missing any configurations or anything else..
How can get rid of these messages in syslog
Any help will be appreciated. Thanks

Regards,
SK

Re: Temporary failure in name resolution

[John Hasler]

Curt writes:
> Yet the reserved gTLDs from the 2018 ICANN resolution are .home, .corp,
> and .mail. Does home.arpa comply with that resolution?

Yes.  Turns out that there were existing uses of '.home'.  Also, putting
it under 'arpa.' puts it under IETF control.

https://datatracker.ietf.org/doc/html/rfc8375
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Temporary failure in name resolution

[debian-user]

Curt  wrote:
> On 2024-01-12, debian-u...@howorth.org.uk
>  wrote:
> > Curt  wrote:  
> >> On 2024-01-11, Max Nikulin  wrote:  
> >> >
> >> > There was a thread that "home" as the top level domain might not
> >> > be really safe (somebody might register it). A reserved domain
> >> > is "home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry
> >> > should be
> >> >
> >> > 127.0.1.1   thinkpad.home.arpa thinkpad
> >> >
> >> 
> >>  The .arpa domain is the “Address and Routing Parameter Area”
> >> domain and is designated to be used exclusively for
> >> Internet-infrastructure purposes.
> >> 
> >> https://www.iana.org/domains/arpa  
> >
> > Indeed, and a little way down that page it says:
> >
> >   home.arpa For non-unique use in residential home networks
> > RFC 8375  
> 
> I missed that.
> 
> Yet the reserved gTLDs from the 2018 ICANN resolution
> are .home, .corp, and .mail. Does home.arpa comply with that
> resolution?

I don't see there's any connection between that resolution and anything
done within the .arpa gTLD. So there's no notion of 'complying'.

Re: Temporary failure in name resolution

[Jeffrey Walton]

On Fri, Jan 12, 2024 at 12:33 PM  wrote:
>
> Jeffrey Walton  wrote:
> > On Fri, Jan 12, 2024 at 11:08 AM Curt  wrote:
> > >
> > > On 2024-01-12, debian-u...@howorth.org.uk
> > >  wrote:
> > > > Curt  wrote:
> > > >> On 2024-01-11, Max Nikulin  wrote:
> > > >> >
> > > >> > There was a thread that "home" as the top level domain might
> > > >> > not be really safe (somebody might register it). A reserved
> > > >> > domain is "home.arpa" so e.g. to have "thinkpad",
> > > >> > the /etc/hosts entry should be
> > > >> >
> > > >> > 127.0.1.1   thinkpad.home.arpa thinkpad
> > > >> >
> > > >>
> > > >>  The .arpa domain is the “Address and Routing Parameter Area”
> > > >> domain and is designated to be used exclusively for
> > > >> Internet-infrastructure purposes.
> > > >>
> > > >> https://www.iana.org/domains/arpa
> > > >
> > > > Indeed, and a little way down that page it says:
> > > >
> > > >   home.arpa For non-unique use in residential home networks
> > > > RFC 8375
> > >
> > > I missed that.
> > >
> > > Yet the reserved gTLDs from the 2018 ICANN resolution
> > > are .home, .corp, and .mail. Does home.arpa comply with that
> > > resolution?
> >
> > And to muddy the waters a little more, IANA has some reserved domain
> > names, too:
> > .
> > Also see .
>
> Those references don't seem to muddy the issue. The second refers to
> the first and the first says
>
>   home.arpa.[RFC8375]

The fellow asked about .home, .corp, and .mail immediately above.

IANA widens the list to include names like local. and invalid. There
are more names than just the few named in this thread.

Jeff

Re: Temporary failure in name resolution

[debian-user]

Jeffrey Walton  wrote:
> On Fri, Jan 12, 2024 at 11:08 AM Curt  wrote:
> >
> > On 2024-01-12, debian-u...@howorth.org.uk
> >  wrote:  
> > > Curt  wrote:  
> > >> On 2024-01-11, Max Nikulin  wrote:  
> > >> >
> > >> > There was a thread that "home" as the top level domain might
> > >> > not be really safe (somebody might register it). A reserved
> > >> > domain is "home.arpa" so e.g. to have "thinkpad",
> > >> > the /etc/hosts entry should be
> > >> >
> > >> > 127.0.1.1   thinkpad.home.arpa thinkpad
> > >> >  
> > >>
> > >>  The .arpa domain is the “Address and Routing Parameter Area”
> > >> domain and is designated to be used exclusively for
> > >> Internet-infrastructure purposes.
> > >>
> > >> https://www.iana.org/domains/arpa  
> > >
> > > Indeed, and a little way down that page it says:
> > >
> > >   home.arpa For non-unique use in residential home networks
> > > RFC 8375  
> >
> > I missed that.
> >
> > Yet the reserved gTLDs from the 2018 ICANN resolution
> > are .home, .corp, and .mail. Does home.arpa comply with that
> > resolution?  
> 
> And to muddy the waters a little more, IANA has some reserved domain
> names, too:
> .
> Also see .

Those references don't seem to muddy the issue. The second refers to
the first and the first says 

  home.arpa.[RFC8375]

> Jeff
> 

Re: Temporary failure in name resolution

[Jeffrey Walton]

On Fri, Jan 12, 2024 at 11:08 AM Curt  wrote:
>
> On 2024-01-12, debian-u...@howorth.org.uk  wrote:
> > Curt  wrote:
> >> On 2024-01-11, Max Nikulin  wrote:
> >> >
> >> > There was a thread that "home" as the top level domain might not be
> >> > really safe (somebody might register it). A reserved domain is
> >> > "home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry should
> >> > be
> >> >
> >> > 127.0.1.1   thinkpad.home.arpa thinkpad
> >> >
> >>
> >>  The .arpa domain is the “Address and Routing Parameter Area” domain
> >> and is designated to be used exclusively for Internet-infrastructure
> >>  purposes.
> >>
> >> https://www.iana.org/domains/arpa
> >
> > Indeed, and a little way down that page it says:
> >
> >   home.arpa For non-unique use in residential home networks
> > RFC 8375
>
> I missed that.
>
> Yet the reserved gTLDs from the 2018 ICANN resolution are .home, .corp,
> and .mail. Does home.arpa comply with that resolution?

And to muddy the waters a little more, IANA has some reserved domain
names, too: 
.
Also see .

Jeff

Re: Temporary failure in name resolution

[Curt]

On 2024-01-12, debian-u...@howorth.org.uk  wrote:
> Curt  wrote:
>> On 2024-01-11, Max Nikulin  wrote:
>> >
>> > There was a thread that "home" as the top level domain might not be 
>> > really safe (somebody might register it). A reserved domain is 
>> > "home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry should
>> > be
>> >
>> > 127.0.1.1   thinkpad.home.arpa thinkpad
>> >  
>> 
>>  The .arpa domain is the “Address and Routing Parameter Area” domain
>> and is designated to be used exclusively for Internet-infrastructure
>>  purposes.
>> 
>> https://www.iana.org/domains/arpa
>
> Indeed, and a little way down that page it says:
>
>   home.arpa For non-unique use in residential home networks
> RFC 8375

I missed that.

Yet the reserved gTLDs from the 2018 ICANN resolution are .home, .corp,
and .mail. Does home.arpa comply with that resolution?

>:P
>
>


-- 

Re: Temporary failure in name resolution

[Byung-Hee HWANG]

On Fri, Jan 12, 2024 at 11:24:53AM +, debian-u...@howorth.org.uk wrote:
> Curt  wrote:
> > On 2024-01-11, Max Nikulin  wrote:
> > >
> > > There was a thread that "home" as the top level domain might not be 
> > > really safe (somebody might register it). A reserved domain is 
> > > "home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry should
> > > be
> > >
> > > 127.0.1.1   thinkpad.home.arpa thinkpad
> > >  
> > 
> >  The .arpa domain is the “Address and Routing Parameter Area” domain
> > and is designated to be used exclusively for Internet-infrastructure
> >  purposes.
> > 
> > https://www.iana.org/domains/arpa
> 
> Indeed, and a little way down that page it says:
> 
>   home.arpa For non-unique use in residential home networks
> RFC 8375
> 

Oh thanks for information!


Sincerely, Byung-Hee

Re: Temporary failure in name resolution

[debian-user]

Curt  wrote:
> On 2024-01-11, Max Nikulin  wrote:
> >
> > There was a thread that "home" as the top level domain might not be 
> > really safe (somebody might register it). A reserved domain is 
> > "home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry should
> > be
> >
> > 127.0.1.1   thinkpad.home.arpa thinkpad
> >  
> 
>  The .arpa domain is the “Address and Routing Parameter Area” domain
> and is designated to be used exclusively for Internet-infrastructure
>  purposes.
> 
> https://www.iana.org/domains/arpa

Indeed, and a little way down that page it says:

  home.arpa For non-unique use in residential home networks
RFC 8375

:P

Re: Temporary failure in name resolution

[Max Nikulin]

On 11/01/2024 10:19, Greg Wooledge wrote:

On Thu, Jan 11, 2024 at 10:10:43AM +0700, Max Nikulin wrote:

On 11/01/2024 03:25, Greg Wooledge wrote:

On Wed, Jan 10, 2024 at 07:19:41PM +, Rodolfo Medina wrote:

Greg Wooledge  writes:


What is the output of "grep -F $(hostname) /etc/hosts"?


   127.0.1.1   caterina-thinkpad.home  caterina-thinkpad



I would say that it is better to fix discrepancy between (likely)
/etc/hostname and /etc/hosts and to use a consistent name. If "thinkpad" is
the preferred one then update /etc/hosts otherwise check


I wouldn't
want to assume that nothing is using the name "caterina-thinkpad", so it
would be wise to retain it.


A fair point. Adding FQDN and "thinkpad" before existing names should be 
better. I would still try to find and fix existing occurrences of the 
old name


grep -r caterina-thinkpad /etc

or even "grep -R"


Also, for the love of glob, WHY THE SYSTEMD bullshit... you change the
hostname on Debian by editing the /etc/hostname file, and then by
running the "hostname" command as root with the new name as its
argument (or rebooting).

I don't know why "hostnamectl" even exists as a concept.  It's repulsive.
It also fails to be init-system-agnostic, with no upside to compensate.


I assume that systemd is the default, otherwise the chance that the user 
knows lower level commands is higher. hostnamectl changes both the 
/etc/hostname file and kernel runtime state, so it ensures consistent 
configuration. Moreover, I expect that more services using hostname are 
notified and will not use the stale name. Candidates may be (while I am 
unsure if it really applicable) bluetoothd, multicast DNS responder for 
names and service discovery queries, and perhaps more.


Perhaps hostname was changed from GUI and it is similar to hostnamectl.

Re: Temporary failure in name resolution

[Marco Moock]

Am 11.01.2024 um 16:34:01 Uhr schrieb Curt:

> On 2024-01-11, Max Nikulin  wrote:
> >
> > There was a thread that "home" as the top level domain might not be 
> > really safe (somebody might register it). A reserved domain is 
> > "home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry should
> > be
> >
> > 127.0.1.1   thinkpad.home.arpa thinkpad
> >  
> 
>  The .arpa domain is the “Address and Routing Parameter Area” domain
> and is designated to be used exclusively for Internet-infrastructure
>  purposes.

.home.arpa is a special reserved domain for the uncoordinated usage.

https://datatracker.ietf.org/doc/html/rfc8375.html

Re: Temporary failure in name resolution

[Curt]

On 2024-01-11, Max Nikulin  wrote:
>
> There was a thread that "home" as the top level domain might not be 
> really safe (somebody might register it). A reserved domain is 
> "home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry should be
>
> 127.0.1.1   thinkpad.home.arpa thinkpad
>

 The .arpa domain is the “Address and Routing Parameter Area” domain and
 is designated to be used exclusively for Internet-infrastructure
 purposes.

https://www.iana.org/domains/arpa

Re: Temporary failure in name resolution

[tomas]

On Wed, Jan 10, 2024 at 07:19:41PM +, Rodolfo Medina wrote:
> Greg Wooledge  writes:
> 
> > On Wed, Jan 10, 2024 at 06:34:53PM +, Rodolfo Medina wrote:
> >>  writes:
> >> > Where/how does this error message "appear"?
> >> 
> >> As an output of the `startx' command.
> >
> > It would be lovely to see the *entire* error message, in case some part
> > of it identifies the program that produced the error.  Many messages do.
> 
> 
> /etc/resolv.conf is there again (the system created it) but the error message
> does not seem to occur any more.  Even if it occurred again, I have no way to
> fetch it, cause it appears (it used to) at login.

I think this is it (all other advice in this thread about getting
/etc/hosts in order is not bad, but I think it wasn't your problem).

"The system" as you put it is probably dhcpd (or its systemd
cousin, whatever that's called these days). When it goes to
fetch an IP address, it also gets an address or two for the
local name servers, which it puts [1] in /etc/resolv.conf

I guess for some reason there was a stale entry there which
wasn't removed when you lost connectivity.

Cheers

[1] with some indirection or two, e.g. resolvconf
-- 
t


signature.asc
Description: PGP signature

Re: Temporary failure in name resolution

[David Wright]

On Thu 11 Jan 2024 at 10:10:43 (+0700), Max Nikulin wrote:

> There was a thread that "home" as the top level domain might not be
> really safe (somebody might register it). A reserved domain is
> "home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry should be
> 
> 127.0.1.1   thinkpad.home.arpa thinkpad

https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail

These three would appear to be safe from being registered.

Cheers,
David.

Re: Temporary failure in name resolution

[Greg Wooledge]

On Thu, Jan 11, 2024 at 10:10:43AM +0700, Max Nikulin wrote:
> On 11/01/2024 03:25, Greg Wooledge wrote:
> > On Wed, Jan 10, 2024 at 07:19:41PM +, Rodolfo Medina wrote:
> > > Greg Wooledge  writes:
> > > > What is the output of the "hostname" command?
> > > 
> > > It's: `thinkpad'.
> > > 
> > > > What is the output of "grep -F $(hostname) /etc/hosts"?
> > > 
> > >   127.0.1.1   caterina-thinkpad.home  caterina-thinkpad
> > 
> > There's the problem, then.  You do not have "thinkpad" as an entry in
> > your /etc/hosts file, so the system is unable to lookup "the IP address"
> > for its own hostname.  X sessions tend to frown upon that.
> > 
> > Adding "thinkpad" to the 127.0.1.1 line should take care of this.  You
> > can retain the other fields, and simply use thinkpad as a second alias.
> 
> I would say that it is better to fix discrepancy between (likely)
> /etc/hostname and /etc/hosts and to use a consistent name. If "thinkpad" is
> the preferred one then update /etc/hosts otherwise check
> 
>  hostnamectl
> 
> and update (as root)
> 
>  hostnamectl hostname caterina-thinkpad

There's clearly some back story here that we're not privy to.  I wouldn't
want to assume that nothing is using the name "caterina-thinkpad", so it
would be wise to retain it.

> 127.0.1.1   thinkpad.home.arpa thinkpad

If something tries to look up "caterina-thinkpad" after you've removed
that alias, then we're back to the same problem, just in reverse.

The safe move is to retain both names, until the owner is sure that it's
safe to discard one of them.

Also, for the love of glob, WHY THE SYSTEMD bullshit... you change the
hostname on Debian by editing the /etc/hostname file, and then by
running the "hostname" command as root with the new name as its
argument (or rebooting).

I don't know why "hostnamectl" even exists as a concept.  It's repulsive.
It also fails to be init-system-agnostic, with no upside to compensate.

Re: Temporary failure in name resolution

[Max Nikulin]

On 11/01/2024 03:25, Greg Wooledge wrote:

On Wed, Jan 10, 2024 at 07:19:41PM +, Rodolfo Medina wrote:

Greg Wooledge  writes:

What is the output of the "hostname" command?


It's: `thinkpad'.


What is the output of "grep -F $(hostname) /etc/hosts"?


  127.0.1.1   caterina-thinkpad.home  caterina-thinkpad


There's the problem, then.  You do not have "thinkpad" as an entry in
your /etc/hosts file, so the system is unable to lookup "the IP address"
for its own hostname.  X sessions tend to frown upon that.

Adding "thinkpad" to the 127.0.1.1 line should take care of this.  You
can retain the other fields, and simply use thinkpad as a second alias.


I would say that it is better to fix discrepancy between (likely) 
/etc/hostname and /etc/hosts and to use a consistent name. If "thinkpad" 
is the preferred one then update /etc/hosts otherwise check


 hostnamectl

and update (as root)

 hostnamectl hostname caterina-thinkpad

There was a thread that "home" as the top level domain might not be 
really safe (somebody might register it). A reserved domain is 
"home.arpa" so e.g. to have "thinkpad", the /etc/hosts entry should be


127.0.1.1   thinkpad.home.arpa thinkpad

I have not tried it, but I expect that startx should have no issues with 
output redirection, so to capture its messages to a file


 startx |& tee /tmp/startx-messages.txt

Another places to look for errors are ~/.xsession-errors and

journalctl -b --user

Re: Temporary failure in name resolution

[Greg Wooledge]

On Wed, Jan 10, 2024 at 07:19:41PM +, Rodolfo Medina wrote:
> Greg Wooledge  writes:
> > What is the output of the "hostname" command?
> 
> It's: `thinkpad'.
> 
> > What is the output of "grep -F $(hostname) /etc/hosts"?
> 
> It's:
> 
>  127.0.1.1   caterina-thinkpad.home  caterina-thinkpad

There's the problem, then.  You do not have "thinkpad" as an entry in
your /etc/hosts file, so the system is unable to lookup "the IP address"
for its own hostname.  X sessions tend to frown upon that.

Adding "thinkpad" to the 127.0.1.1 line should take care of this.  You
can retain the other fields, and simply use thinkpad as a second alias.

Re: Temporary failure in name resolution

[Marco Moock]

Am 10.01.2024 um 19:19:41 Uhr schrieb Rodolfo Medina:

> > What is the output of "grep -F $(hostname) /etc/hosts"?  
> 
> It's:
> 
>  127.0.1.1   caterina-thinkpad.home  caterina-thinkpad

Add

::1 localhost localhost.localdomain ip6-localhost ip6-loopback
127.0.0.1   localhost localhost.localdomain

Re: Temporary failure in name resolution

[Rodolfo Medina]

Greg Wooledge  writes:

> On Wed, Jan 10, 2024 at 06:34:53PM +, Rodolfo Medina wrote:
>>  writes:
>> > Where/how does this error message "appear"?
>> 
>> As an output of the `startx' command.
>
> It would be lovely to see the *entire* error message, in case some part
> of it identifies the program that produced the error.  Many messages do.


/etc/resolv.conf is there again (the system created it) but the error message
does not seem to occur any more.  Even if it occurred again, I have no way to
fetch it, cause it appears (it used to) at login.


> Failing that, let's go out on a limb and guess that it's *your own*
> hostname that can't be resolved.
>
> What is the output of the "hostname" command?

It's: `thinkpad'.


> What is the output of "grep -F $(hostname) /etc/hosts"?

It's:

 127.0.1.1   caterina-thinkpad.home  caterina-thinkpad


> What is the output of "grep hosts /etc/nsswitch.conf"?

It's:

 hosts:  files mdns4_minimal [NOTFOUND=return] dns


-
Rodolfo

Re: Temporary failure in name resolution

[Greg Wooledge]

On Wed, Jan 10, 2024 at 06:34:53PM +, Rodolfo Medina wrote:
>  writes:
> > Where/how does this error message "appear"?
> 
> As an output of the `startx' command.

It would be lovely to see the *entire* error message, in case some part
of it identifies the program that produced the error.  Many messages do.

Failing that, let's go out on a limb and guess that it's *your own*
hostname that can't be resolved.

What is the output of the "hostname" command?

What is the output of "grep -F $(hostname) /etc/hosts"?

What is the output of "grep hosts /etc/nsswitch.conf"?

Re: Temporary failure in name resolution

[Rodolfo Medina]

 writes:

> On Wed, Jan 10, 2024 at 06:13:55PM +, Rodolfo Medina wrote:
>> Debian 12 on Thinkpad T450s.
>> 
>> The error message `Temporary failure in name resolution' appears whenever I
>> log into X with `startx' at prompt after boot, but it *only* occurs if the
>> PC is *not* connected to internet; otherwise it does not appear;
>> nevertheless, it annoys me and I wish to get rid of it.  Any suggestions?
>
> Where/how does this error message "appear"?

As an output of the `startx' command.


> Obviously, "something" is trying to resolve a host name and is unable to.
> Depending on which host name "it" is trying to resolve, that might be
> reasonable (i.e. if that host is "out there") or not.
>
> So let's try finding out what this "something" is...

The problem seems to be solved after I removed the file /etc/resolv.conf, that
included a certain nameserver...

Thanks,

Rodolfo

Re: Temporary failure in name resolution

[tomas]

On Wed, Jan 10, 2024 at 06:13:55PM +, Rodolfo Medina wrote:
> Debian 12 on Thinkpad T450s.
> 
> The error message `Temporary failure in name resolution' appears whenever I 
> log
> into X with `startx' at prompt after boot, but it *only* occurs if the PC is
> *not* connected to internet; otherwise it does not appear; nevertheless, it
> annoys me and I wish to get rid of it.  Any suggestions?

Where/how does this error message "appear"?

Obviously, "something" is trying to resolve a host name and is unable to.
Depending on which host name "it" is trying to resolve, that might be
reasonable (i.e. if that host is "out there") or not.

So let's try finding out what this "something" is...

Cheers
-- 
t


signature.asc
Description: PGP signature

Temporary failure in name resolution

[Rodolfo Medina]

Debian 12 on Thinkpad T450s.

The error message `Temporary failure in name resolution' appears whenever I log
into X with `startx' at prompt after boot, but it *only* occurs if the PC is
*not* connected to internet; otherwise it does not appear; nevertheless, it
annoys me and I wish to get rid of it.  Any suggestions?

Thanks,

Rodolfo

Re: Temporary failure in name resolution error when I try to ping Debian 12 / DomU running on top of the Devuan 5 host os / Dom0

[Andrew M.A. Cater]

)
> metric=2
> ;;
> *)
> fatal "Unrecognised interface type ${type_if}"
> ;;
> esac
> 
> # If we've been given a list of IP addresses, then add routes from dom0 to
> # the guest using those addresses.
> for addr in ${ip} ; do
> ${cmdprefix} ip route ${ipcmd} ${addr} dev ${dev} src ${main_ip} metric
> ${metric}
> done
> 
> handle_iptable
> 
> call_hooks vif post
> 
> log debug "Successful vif-route ${command} for ${dev}."
> if [ "${command}" = "online" ]
> then
> success
> fi
> 
> 
> B) on the guest os (Debian 12)
> 
> 
> /etc/network/interfaces :
> 
> source /etc/network/interfaces.d/*
> iface enX0 inet static
> address 192.168.1.10/24
> gateway 192.168.1.7
> 
> /etc/resolv.conf :
> 
> options edns0 trust-ad
> search homenet.telecomitalia.it
> nameserver 8.8.8.8
> 
> 
> this is what happens within the guest os (Debian 12) :
> 
> 
> root@bookworm:~# ifup enX0
> 
> root@bookworm:~# ip a
> 
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
> default qlen 1000
>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>inet 127.0.0.1/8 scope host lo
>   valid_lft forever preferred_lft forever
>inet6 ::1/128 scope host noprefixroute
>   valid_lft forever preferred_lft forever
> 
> 2: sit0@NONE:  mtu 1480 qdisc noop state DOWN group default qlen
> 1000
>link/sit 0.0.0.0 brd 0.0.0.0
> 
> 3: enX0:  mtu 1500 qdisc
> pfifo_fast state UP group default
> qlen 1000
>link/ether 00:16:3e:12:34:56 brd ff:ff:ff:ff:ff:ff
>inet 192.168.1.10/24 brd 192.168.1.255 scope global enX0
>   valid_lft forever preferred_lft forever
>inet6 fe80::216:3eff:fe12:3456/64 scope link
>   valid_lft forever preferred_lft forever
> 
> root@bookworm:~# ping google.it
> ping: google.it: Temporary failure in name resolution
> 
> 
> Where can be the error ? thanks.
> 
> -- 
> Mario.

Re: Temporary failure in name resolution error when I try to ping Debian 12 / DomU running on top of the Devuan 5 host os / Dom0

[Mario Marietto]

orwarding
>> echo 1 >/proc/sys/net/ipv4/conf/mlan0/forwarding
>> echo 1 >/proc/sys/net/ipv4/conf/mlan0/proxy_arp
>> /usr/sbin/arp -i mlan0 -Ds $main_ip mlan0 pub
>> ipcmd='add'
>> cmdprefix=''
>> ;;
>> remove|offline)
>> do_without_error ifdown ${dev}
>> ipcmd='del'
>> cmdprefix='do_without_error'
>> ;;
>> esac
>>
>> case "${type_if}" in
>> tap)
>> metric=1
>> ;;
>> vif)
>> metric=2
>> ;;
>> *)
>> fatal "Unrecognised interface type ${type_if}"
>> ;;
>> esac
>>
>> # If we've been given a list of IP addresses, then add routes from dom0 to
>> # the guest using those addresses.
>> for addr in ${ip} ; do
>> ${cmdprefix} ip route ${ipcmd} ${addr} dev ${dev} src ${main_ip}
>> metric ${metric}
>> done
>>
>> handle_iptable
>>
>> call_hooks vif post
>>
>> log debug "Successful vif-route ${command} for ${dev}."
>> if [ "${command}" = "online" ]
>> then
>> success
>> fi
>>
>>
>> B) on the guest os (Debian 12)
>>
>>
>> /etc/network/interfaces :
>>
>> source /etc/network/interfaces.d/*
>> iface enX0 inet static
>> address 192.168.1.10/24
>> gateway 192.168.1.7
>>
>> /etc/resolv.conf :
>>
>> options edns0 trust-ad
>> search homenet.telecomitalia.it
>> nameserver 8.8.8.8
>>
>>
>> this is what happens within the guest os (Debian 12) :
>>
>>
>> root@bookworm:~# ifup enX0
>>
>> root@bookworm:~# ip a
>>
>> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
>> default qlen 1000
>>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>inet 127.0.0.1/8 scope host lo
>>   valid_lft forever preferred_lft forever
>>inet6 ::1/128 scope host noprefixroute
>>   valid_lft forever preferred_lft forever
>>
>> 2: sit0@NONE:  mtu 1480 qdisc noop state DOWN group default qlen
>> 1000
>>link/sit 0.0.0.0 brd 0.0.0.0
>>
>> 3: enX0:  mtu 1500 qdisc
>> pfifo_fast state UP group default
>> qlen 1000
>>link/ether 00:16:3e:12:34:56 brd ff:ff:ff:ff:ff:ff
>>inet 192.168.1.10/24 brd 192.168.1.255 scope global enX0
>>   valid_lft forever preferred_lft forever
>>inet6 fe80::216:3eff:fe12:3456/64 scope link
>>   valid_lft forever preferred_lft forever
>>
>> root@bookworm:~# ping google.it
>> ping: google.it: Temporary failure in name resolution
>>
>>
>> Where can be the error ? thanks.
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


-- 
Mario.

Re: Temporary failure in name resolution error when I try to ping Debian 12 / DomU running on top of the Devuan 5 host os / Dom0

[jeremy ardley]

On 20/11/23 05:54, Mario Marietto wrote:

root@bookworm:~# ifup enX0

root@bookworm:~# ip a

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 <http://127.0.0.1/8> scope host lo
  valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host noprefixroute
  valid_lft forever preferred_lft forever

2: sit0@NONE:  mtu 1480 qdisc noop state DOWN group default 
qlen 1000

   link/sit 0.0.0.0 brd 0.0.0.0

3: enX0:  mtu 1500 qdisc 
pfifo_fast state UP group default

qlen 1000
   link/ether 00:16:3e:12:34:56 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.10/24 <http://192.168.1.10/24> brd 192.168.1.255 
scope global enX0

  valid_lft forever preferred_lft forever
   inet6 fe80::216:3eff:fe12:3456/64 scope link
  valid_lft forever preferred_lft forever

root@bookworm:~# ping google.it <http://google.it>
ping: google.it <http://google.it>: Temporary failure in name resolution



In the client try the command

dig @8.8.8.8 lists.debian.org mx

This will tell if your network config allows your client to access the 
8.8.8.8 DNS server.


What is the contents of your host /etc/resolv.conf ?

Re: Temporary failure in name resolution error when I try to ping Debian 12 / DomU running on top of the Devuan 5 host os / Dom0

[Mario Marietto]

 iface enX0 inet static
> address 192.168.1.10/24
> gateway 192.168.1.7
>
> /etc/resolv.conf :
>
> options edns0 trust-ad
> search homenet.telecomitalia.it
> nameserver 8.8.8.8
>
>
> this is what happens within the guest os (Debian 12) :
>
>
> root@bookworm:~# ifup enX0
>
> root@bookworm:~# ip a
>
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
> default qlen 1000
>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>inet 127.0.0.1/8 scope host lo
>   valid_lft forever preferred_lft forever
>    inet6 ::1/128 scope host noprefixroute
>   valid_lft forever preferred_lft forever
>
> 2: sit0@NONE:  mtu 1480 qdisc noop state DOWN group default qlen
> 1000
>link/sit 0.0.0.0 brd 0.0.0.0
>
> 3: enX0:  mtu 1500 qdisc
> pfifo_fast state UP group default
> qlen 1000
>link/ether 00:16:3e:12:34:56 brd ff:ff:ff:ff:ff:ff
>inet 192.168.1.10/24 brd 192.168.1.255 scope global enX0
>   valid_lft forever preferred_lft forever
>inet6 fe80::216:3eff:fe12:3456/64 scope link
>   valid_lft forever preferred_lft forever
>
> root@bookworm:~# ping google.it
> ping: google.it: Temporary failure in name resolution
>
>
> Where can be the error ? thanks.
>
> --
> Mario.
>


-- 
Mario.

Temporary failure in name resolution error when I try to ping Debian 12 / DomU running on top of the Devuan 5 host os / Dom0

[Mario Marietto]

Hello.

I'm trying to configure Debian 12 / DomU on my (Arm32) Chromebook because I
want to use the Internet and I want its IP address to be seen from
"outside" of my LAN.

This is the tutorial that I'm following :


https://github.com/mobile-virt/u-boot-chromebook-xe303c12/tree/chromebook/xen#starting-a-domu-guest

Given these config files :


A) on the host os (Devuan 5)

Linux devuan-bunsen 6.1.61-stb-xen-cbe+ #1 SMP PREEMPT Sat Nov  4 13:46:17
EDT 2023 armv7l

root@devuan-bunsen:~# ifconfig

lo: flags=73  mtu 65536
   inet 127.0.0.1  netmask 255.0.0.0
   inet6 ::1  prefixlen 128  scopeid 0x10
   loop  txqueuelen 1000  (Local Loopback)
   RX packets 2729  bytes 8279984 (7.8 MiB)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 2729  bytes 8279984 (7.8 MiB)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

mlan0: flags=4163  mtu 1500
   inet 192.168.1.7  netmask 255.255.255.0  broadcast 192.168.1.255
   inet6 fe80::8839:239b:9b37:cf84  prefixlen 64  scopeid 0x20
   RX packets 19694  bytes 2193230 (2.0 MiB)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 18757  bytes 10464406 (9.9 MiB)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vif4.0: flags=4163  mtu 1500
   inet 192.168.1.7  netmask 255.255.255.255  broadcast 192.168.1.255
   ether fe:ff:ff:ff:ff:ff  txqueuelen 1000  (Ethernet)
   RX packets 359  bytes 94924 (92.6 KiB)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 42  bytes 1764 (1.7 KiB)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

nano debian.cfg :

kernel = '/Dati/xen/kernels/zImage-6.1.61-stb-xen-cbe+'
memory = '768'
name = 'Debian-bookworm'
vcpus = '1'
disk = [ '/Dati/xen/debian.img,,xvda,w' ]
vif = [ 'type=vif,mac=00:16:3e:12:34:56,script=vif-route' ]
extra = 'console=hvc0 root=/dev/xvda rw init=/sbin/init
xen-fbfront.video=24,1024,768'


nano /etc/xen/scripts/vif-route-local :

#!/bin/bash
#
# ${XEN_SCRIPT_DIR}/vif-route
#
# Script for configuring a vif in routed mode.
#
# Usage:
# vif-route (add|remove|online|offline)
#
# Environment vars:
# dev vif interface name (required).
# XENBUS_PATH path to this device's details in the XenStore (required).
#
# Read from the store:
# ip  list of IP networks for the vif, space-separated (default given in
# this script).
#

dir=$(dirname "$0")
. "${dir}/vif-common.sh"
#netdev=$(mlan0)
main_ip=$(dom0_ip)
case "${command}" in
add|online)
echo $dev
  echo $ip
echo $main_ip
ifconfig ${dev} ${main_ip} netmask 255.255.255.255 up
echo 1 >/proc/sys/net/ipv4/conf/${dev}/proxy_arp
echo 1 >/proc/sys/net/ipv4/conf/${dev}/forwarding
echo 1 >/proc/sys/net/ipv4/conf/mlan0/forwarding
echo 1 >/proc/sys/net/ipv4/conf/mlan0/proxy_arp
/usr/sbin/arp -i mlan0 -Ds $main_ip mlan0 pub
ipcmd='add'
cmdprefix=''
;;
remove|offline)
do_without_error ifdown ${dev}
ipcmd='del'
cmdprefix='do_without_error'
;;
esac

case "${type_if}" in
tap)
metric=1
;;
vif)
metric=2
;;
*)
fatal "Unrecognised interface type ${type_if}"
;;
esac

# If we've been given a list of IP addresses, then add routes from dom0 to
# the guest using those addresses.
for addr in ${ip} ; do
${cmdprefix} ip route ${ipcmd} ${addr} dev ${dev} src ${main_ip} metric
${metric}
done

handle_iptable

call_hooks vif post

log debug "Successful vif-route ${command} for ${dev}."
if [ "${command}" = "online" ]
then
success
fi


B) on the guest os (Debian 12)


/etc/network/interfaces :

source /etc/network/interfaces.d/*
iface enX0 inet static
address 192.168.1.10/24
gateway 192.168.1.7

/etc/resolv.conf :

options edns0 trust-ad
search homenet.telecomitalia.it
nameserver 8.8.8.8


this is what happens within the guest os (Debian 12) :


root@bookworm:~# ifup enX0

root@bookworm:~# ip a

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
  valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host noprefixroute
  valid_lft forever preferred_lft forever

2: sit0@NONE:  mtu 1480 qdisc noop state DOWN group default qlen
1000
   link/sit 0.0.0.0 brd 0.0.0.0

3: enX0:  mtu 1500 qdisc
pfifo_fast state UP group default
qlen 1000
   link/ether 00:16:3e:12:34:56 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.10/24 brd 192.168.1.255 scope global enX0
  valid_lft forever preferred_lft forever
   inet6 fe80::216:3eff:fe12:3456/64 scope link
      valid_lft forever preferred_lft forever

root@bookworm:~# ping google.it
ping: google.it: Temporary failure in name resolution


Where can be the error ? thanks.

-- 
Mario.

Re: Temporary failure in name resolution

[Stefan Monnier]

>> That I can believe (and isn't a bad option, IMO),
>> but the discussion was about broken DNS proxies/servers.
> Well, I assume that's your term for the modem/router being leased
> by the OP from att, and similar.

Not really.  It was my attempt at reproducing the approximate
description of some vague potential sources of problems seen earlier in
the thread.

> I would assume that, rather like BT (British Telecom) and their
> HomeHubs for domestic customers, they lock in the addresses of their
> own DNS servers for the reasons outlined above.

That would make sense, indeed: it could even be a perfectly fine piece
of software, just purposefully misconfigured like you describe.

> But I don't recognise your statement "most home routers used `dnsmasq`",
> because AIUI dnsmasq implies "It can serve the names of local machines
> which are not in the global DNS" (Wikipedia), and none of my routers has

IIRC while "it can" this depends on the configuration being used.
My statement was based on my memory of the contents of the "big GPL
tarball" that you could usually get from the somewhat complying
companies (after they were reminded of the terms of the GPL license
used in the software inside their boxes).

[ To me, this is actually one of the great successes of the GPL, since
  it spurred the whole development of OpenWRT.  ]

>> That's not even needed: just tell the DHCP clients to use the ISP's
>> DNS servers.
> That seems to be the general solution. But I'm not sure if that's
> possible with certain devices, like "smart" TVs that can browse
> the web.

It should work under the condition that the DHCP client uses the info
provided by DHCP.  I'm sure there are devices braindead enough to
hardcode their own list of DNS servers (IIUC it's somewhat common to
have hardcoded Google-DNS servers in some Android devices).


Stefan

Re: Temporary failure in name resolution

[David Wright]

On Mon 05 Apr 2021 at 09:33:25 (-0400), Stefan Monnier wrote:
> >>> A notable class of exceptions is that of OpenWrt powered devices:
> >>> OpenWrt comes with dnsmasq configured out of the box, and thus provides
> >>> caching.
> >> "Back in the days" (at the beginning of OpenWRT), most home routers used
> >> `dnsmasq`, AFAIK.  So I'd expect today's devices to use `dnsmasq` or
> >> similar as well.  Why would the manufacturers bundle some broken dns
> >> proxy/server instead of `dnsmasq`?

Perhaps because they want to scrutinise all the names that you look
up. That allows them to perform "security" and "family" filtering,
in the style of 1.1.1.2 and 1.1.1.3. And when they block a site,
they can insert their own web page to suck you into somewhere in
their servers.

> > I think it's attempt to save up on system resources, and also cost and
> > firmware size reduction.
> > You can build a device that looks shiny on the outside and put 5-8 years old
> > SoC inside with bare minimum EEPROM and RAM required for it to function.
> 
> The ones with `dnsmasq` back then had typically 4MB of flash and 16MB of RAM.
> 
> Are the ones with broken DNS proxy/server really coming with fewer
> resources than that?
> 
> > And besides, you can make it so there is no internal DNServer at all,
> 
> That I can believe (and isn't a bad option, IMO),
> but the discussion was about broken DNS proxies/servers.

Well, I assume that's your term for the modem/router being leased
by the OP from att, and similar. I would assume that, rather like
BT (British Telecom) and their HomeHubs for domestic customers,
they lock in the addresses of their own DNS servers for the
reasons outlined above.

But I don't recognise your statement "most home routers used `dnsmasq`",
because AIUI dnsmasq implies "It can serve the names of local machines
which are not in the global DNS" (Wikipedia), and none of my routers has
been able to do that, even when they're the very device that handed out
the name and IP address by DHCP.

> > just a simple iptables SNAT rule for port #53 hidden from end user
> > behind a checkbox on the web interface named "Enable DNS relay".
> 
> That's not even needed: just tell the DHCP clients to use the ISP's
> DNS servers.

That seems to be the general solution. But I'm not sure if that's
possible with certain devices, like "smart" TVs that can browse
the web.

Cheers,
David.

Re: Temporary failure in name resolution

[Stefan Monnier]

>>> A notable class of exceptions is that of OpenWrt powered devices:
>>> OpenWrt comes with dnsmasq configured out of the box, and thus provides
>>> caching.
>> "Back in the days" (at the beginning of OpenWRT), most home routers used
>> `dnsmasq`, AFAIK.  So I'd expect today's devices to use `dnsmasq` or
>> similar as well.  Why would the manufacturers bundle some broken dns
>> proxy/server instead of `dnsmasq`?
> I think it's attempt to save up on system resources, and also cost and
> firmware size reduction.
> You can build a device that looks shiny on the outside and put 5-8 years old
> SoC inside with bare minimum EEPROM and RAM required for it to function.

The ones with `dnsmasq` back then had typically 4MB of flash and 16MB of RAM.

Are the ones with broken DNS proxy/server really coming with fewer
resources than that?

> And besides, you can make it so there is no internal DNServer at all,

That I can believe (and isn't a bad option, IMO),
but the discussion was about broken DNS proxies/servers.

> just a simple iptables SNAT rule for port #53 hidden from end user
> behind a checkbox on the web interface named "Enable DNS relay".

That's not even needed: just tell the DHCP clients to use the ISP's
DNS servers.


Stefan

Re: Temporary failure in name resolution

[Alexander V. Makartsev]

On 05.04.2021 07:40, Dan Norton wrote:



[1]https://wiki.debian.org/resolv.conf#Modifying_.2Fetc.2Fdhcp.2Fdhclient.conf

After the AT tech does his thing tomorrow, I plan to add

supersede domain-name-servers 1.1.1.1,1.0.0.1;

to resolv.conf. Until then I want things to be unchanged from the 10.9
upgrade.

No one else is reporting this exact problem so I believe that the
problem and the upgrade were coincidental and nothing needs to
change in 10.9 to correct "Temporary failure in name resolution."

Thanks, Alexander.

  - Dan


Don't mention it.
I just want correct you, the file, where "supersede" string should go, 
is "/etc/dhcp/dhclient.conf" not "/etc/resolv.conf".


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Temporary failure in name resolution

[Alexander V. Makartsev]

On 05.04.2021 07:47, Stefan Monnier wrote:

A notable class of exceptions is that of OpenWrt powered devices:
OpenWrt comes with dnsmasq configured out of the box, and thus provides
caching.

"Back in the days" (at the beginning of OpenWRT), most home routers used
`dnsmasq`, AFAIK.  So I'd expect today's devices to use `dnsmasq` or
similar as well.  Why would the manufacturers bundle some broken dns
proxy/server instead of `dnsmasq`?
I think it's attempt to save up on system resources, and also cost and 
firmware size reduction.
You can build a device that looks shiny on the outside and put 5-8 years 
old SoC inside with bare minimum EEPROM and RAM required for it to function.
All manufacturers do that, gotta sell those stockpiled, but outdated 
chips somehow, and still make a profit.
And besides, you can make it so there is no internal DNServer at all, 
just a simple iptables SNAT rule for port #53 hidden from end user 
behind a checkbox on the web interface named "Enable DNS relay".


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Temporary failure in name resolution

[Dan Norton]

Alexander V. Makartsev on Sat, 3 Apr 2021 01:17:59 +0500 wrote:

>On 02.04.2021 22:56, Dan Norton wrote:
>> Alexander V. Makartsev wrote Wed, 31 Mar 2021 10:16:08 +0500:
>>
>> "Is "192.168.1.254" an IP address of your DSL modem?
>> If you don't need to resolve hostnames from you local network, like
>> "somepc1.attlocal.net" and only want to access the Internet, you can
>> configure one or more of the public DNS servers. From Google [1]:
>> 8.8.8.8 8.8.4.4
>> >From CloudFlare [2]:
>> 1.1.1.1"
>>
>> I don't know. I did not put that line in /etc/resolv.conf. When I get
>> more time I may remove it and see what happens.
>>
> If you didn't put that line in /etc/resolv.conf, then probably it was
> configured by DHCP client, which used the information send by your DSL
> modem. That would explain "attlocal.net" lines. Do you have
> administrative access to your DSL modem's configuration web interface?
> Or is it a leased device that was configured by your ISP and you don't
> have the option to configure it?

It is a leased device. I have spent lots of quality time with my ISP,
repeating the name resolution story to 4 support reps. Finally they had
AT look at my connection and found that although it is currently
working, "the downstream margin is low (< 15db) and a bridge tap needs
to be removed." according to AT This state of things is with:

# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 192.168.1.254

which is as it was before the name resolution problem occurred and not
immutable.

Earlier, in the OP I wrote:
>> # systemctl status systemd-resolved
>> shows it being active and "Processing requests...".

This a mistake I made. Early on in an effort to get name resolution, I
had enabled systemd-resolved, which did not help, and I forgot to
return it to disabled.

> If you have the access to DSL modem, you can configure its DHCP server
> to always send proper DNS server addresses, like "1.1.1.1", "8.8.8.8",
> instead of "192.168.1.254". Alternatively, and if you don't have the
> access to DSL modem, you can modify "dhclient.conf" file to
> effectively
> override name server addresses sent by your modem with known good
> ones.
> This procedure is described in Debian Wiki. [1] Basically, all you
> have
> to do is add at the end of the file this string: supersede
> domain-name-servers 1.1.1.1,1.0.0.1,8.8.8.8,8.8.4.4;

> [1]https://wiki.debian.org/resolv.conf#Modifying_.2Fetc.2Fdhcp.2Fdhclient.conf

After the AT tech does his thing tomorrow, I plan to add

supersede domain-name-servers 1.1.1.1,1.0.0.1;

to resolv.conf. Until then I want things to be unchanged from the 10.9
upgrade. 

No one else is reporting this exact problem so I believe that the
problem and the upgrade were coincidental and nothing needs to
change in 10.9 to correct "Temporary failure in name resolution."

Thanks, Alexander.

 - Dan

Re: Temporary failure in name resolution

[Stefan Monnier]

> A notable class of exceptions is that of OpenWrt powered devices:
> OpenWrt comes with dnsmasq configured out of the box, and thus provides
> caching.

"Back in the days" (at the beginning of OpenWRT), most home routers used
`dnsmasq`, AFAIK.  So I'd expect today's devices to use `dnsmasq` or
similar as well.  Why would the manufacturers bundle some broken dns
proxy/server instead of `dnsmasq`?


Stefan

Re: Temporary failure in name resolution

[Celejar]

On Sat, 3 Apr 2021 02:15:55 +0500
"Alexander V. Makartsev"  wrote:

...

> Most of SOHO class routers\modems don't offer fully-fledged DNS server 
> and domain name caching features.
> They act as relays, simply redirecting DNS requests to the nearest 
> configured domain name server.

A notable class of exceptions is that of OpenWrt powered devices:
OpenWrt comes with dnsmasq configured out of the box, and thus provides
caching.

Celejar

Re: Temporary failure in name resolution

[David Christensen]

On 4/3/21 9:05 AM, Dan Norton wrote:

On 3/31/21 1:33 PM, David Christensen wrote:



"$ host -v -t A www.debian.org 192.168.1.254


Dan -- did you run the above test? This may help isolate if the problem
is Debian 10 or your AT gateway."



The five lines immediately above are incorrectly formatted -- they 
should be prefixed/ indented one more level.  Please configure your 
e-mail client to prefix/ indent the text of messages that you reply to.




$ host -v -t A www.debian.org 192.168.1.254
Trying "www.debian.org"
;; connection timed out; no servers could be reached



$ host -v -t A www.debian.org
Trying "www.debian.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46537
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.debian.org.IN  A

;; ANSWER SECTION:
www.debian.org. 260 IN  A   149.20.4.15
www.debian.org. 260 IN  A   128.31.0.62

Received 64 bytes from 1.1.1.1#53 in 30 ms



Thank you.  Those test results should be useful for isolating and 
debugging the issue.




HTH, but would it help isolate the problem to temporarily put
nameserver 192.168.1.254 back in resolv.conf and retry the above?



AIUI, no.  See Greg Wooledge's reply for an explanation.



BTW, I just saw your earlier (revised?) post about using Windows on the
laptop. Yikes! If you don't mind, I'd like to skip that. Besides, my > local 
network is much simpler since there is only one ethernet
connection. Sorry if I misled you.



On 3/30/21 7:21 PM, Dan Norton wrote:
> My desktop is a wifi server for laptop access using windows


Connecting the Debian computer to the AT gateway and connecting the 
laptop to the gateway is a simpler network (star topology) than 
connecting Debian to the gateway, configuring Debian as a Wi-Fi router, 
and connecting the laptop to Debian (router-behind-router topology).



Interactive desktop usage and network routing are two functions that are 
best fulfilled by two separate devices.  While one device can do both, 
complexity and risk are greater in one device than their sums with two 
devices.



It is possible that your name resolution issues are due to some 
misconfiguration of Debian in its networking role.  Please document how 
you have installed and configured Debian -- ISO, tasksel, packages, 
Ethernet interface, Wi-Fi interface, routing, address and/or port 
translation, firewall, DHCP proxy/ forwarding, DNS proxy/ forwarding, etc..



David

Re: Temporary failure in name resolution

[Alexander V. Makartsev]

On 03.04.2021 21:59, Dan Norton wrote:

Isn't there a tidier way besides making resolv.conf immutable,
resulting in lots of /etc/resolv.conf.dhclient-new.* files? Maybe
stopping dhclient from overwriting resolv.conf[1]?

  - Dan

[1]https://wiki.debian.org/resolv.conf#Modifying_.2Fetc.2Fdhcp.2Fdhclient.conf


"resolv.conf" being overwritten is by design.
In your case it's a problem with misconfigured DSL modem that is the 
root of your problems.
You can't reconfigure it to send valid information, since you don't have 
administrative access, so this solution is unavailable.
That alternative solution I was suggesting is exactly what you may call 
"tidy".
If you implement it, your system will still receive invalid DNS IP 
address from DSL modem, but it will be "superseded" by valid IP 
addresses taken from "dhclient.conf", so when "resolv.conf" will be 
created it will contain valid DNS IP addresses you want.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Temporary failure in name resolution

[Greg Wooledge]

On Sat, Apr 03, 2021 at 12:59:04PM -0400, Dan Norton wrote:
> Isn't there a tidier way besides making resolv.conf immutable,
> resulting in lots of /etc/resolv.conf.dhclient-new.* files? Maybe
> stopping dhclient from overwriting resolv.conf[1]?
> 
>  - Dan
> 
> [1]https://wiki.debian.org/resolv.conf#Modifying_.2Fetc.2Fdhcp.2Fdhclient.conf

There's a whole wiki page full of alternatives.  You're already on it.

Re: Temporary failure in name resolution

[Dan Norton]

Greg Wooledge on Fri, 2 Apr 2021 23:24:43 -0400 wrote:

"On Fri, Apr 02, 2021 at 10:48:09PM -0400, Dan Norton wrote:
> # cat /etc/resolv.conf
> domain attlocal.net
> search attlocal.net
> nameserver 1.1.1.1
> nameserver 1.0.0.1
> ...and this works very well. I like it because it cuts out more
> of google's monitoring of my browsing (I use Brave browser and
> DuckDuckGo).
> 
> Now what about the first two lines? What purpose? Can I cut out AT
> also? ;)

man resolv.conf

   search Search list for host-name lookup.
  By default, the search list contains one entry, the local
   domain name.   It  is  determined  from  the local hostname
   returned by gethostname(2); the local domain name is taken to
   be  everything after  the first '.'.  Finally, if the hostname
   does not contain a '.', the root domain is assumed as the local
   domain name.

  [...]

  The  domain  directive is an obsolete name for the search
  direc‐ tive that handles one search list entry only.

Those lines do nothing, unless you routinely type commands like
"ssh lemon" or "ping pineapple" with no dots in the hostname.  In that
case, assuming the hosts are not defined in /etc/hosts, the resolver
will try to look up "lemon.attlocal.net" or "pineapple.attlocal.net" or
whatever."

I see. Thanks for pointing that out.

"Remember that something will probably overwrite your changes to the
resolv.conf file, unless you take preemptive steps."

Isn't there a tidier way besides making resolv.conf immutable,
resulting in lots of /etc/resolv.conf.dhclient-new.* files? Maybe
stopping dhclient from overwriting resolv.conf[1]?

 - Dan

[1]https://wiki.debian.org/resolv.conf#Modifying_.2Fetc.2Fdhcp.2Fdhclient.conf

Re: Temporary failure in name resolution

[Greg Wooledge]

On Sat, Apr 03, 2021 at 12:05:54PM -0400, Dan Norton wrote:
> On 3/31/21 1:33 PM, David Christensen wrote:
> 
> "$ host -v -t A www.debian.org 192.168.1.254
> 
> 
> Dan -- did you run the above test? This may help isolate if the problem
> is Debian 10 or your AT gateway."
> 
> $ host -v -t A www.debian.org 192.168.1.254
> Trying "www.debian.org"
> ;; connection timed out; no servers could be reached
> 
> That's to be expected I guess since nameserver 192.168.1.254 is no
> longer in resolv.conf.

*facepalm*

I don't understand what you don't understand.  It's so frustrating.

When you do a command like

  host www.debian.org

This uses the "nameserver" line(s) in resolv.conf to decide where to
send the requests.

When you OVERRIDE THIS WITH AN IP ADDRESS ON THE COMMAND LINE, it uses
that IP address as the nameserver (recursive resolver) instead.

SYNOPSIS
   host  [-aACdlnrsTUwv]  [-c  class] [-N ndots] [-p port] [-R number] [-t
   type] [-W wait] [-m flag] [ [-4] | [-6] ] [-v] [-V] {name} [server]

   [...]

   server is an optional argument which is either the name or  IP  address
   of  the  name  server  that  host should query instead of the server or
   servers listed in /etc/resolv.conf.

See there?  You've specified a {name} (www.debian.org) and an optional
[server] (192.168.1.254).  Therefore it uses that instead of whatever
is written in resolv.conf.

The entire point of running this command was to probe the nameserver
at 192.168.1.254 and see whether it's working correctly.

> $ host -v -t A www.debian.org 192.168.1.254
> Trying "www.debian.org"
> ;; connection timed out; no servers could be reached

It's not working correctly.  Now you know.

Re: Temporary failure in name resolution

[Dan Norton]

On 3/31/21 1:33 PM, David Christensen wrote:

"$ host -v -t A www.debian.org 192.168.1.254


Dan -- did you run the above test? This may help isolate if the problem
is Debian 10 or your AT gateway."

$ host -v -t A www.debian.org 192.168.1.254
Trying "www.debian.org"
;; connection timed out; no servers could be reached

That's to be expected I guess since nameserver 192.168.1.254 is no
longer in resolv.conf.

$ host -v -t A www.debian.org
Trying "www.debian.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46537
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.debian.org.IN  A

;; ANSWER SECTION:
www.debian.org. 260 IN  A   149.20.4.15
www.debian.org. 260 IN  A   128.31.0.62

Received 64 bytes from 1.1.1.1#53 in 30 ms
 
HTH, but would it help isolate the problem to temporarily put
nameserver 192.168.1.254 back in resolv.conf and retry the above?

BTW, I just saw your earlier (revised?) post about using Windows on the
laptop. Yikes! If you don't mind, I'd like to skip that. Besides, my
local network is much simpler since there is only one ethernet
connection. Sorry if I misled you.

 - Dan

Re: Temporary failure in name resolution

[Joe]

On Sat, 3 Apr 2021 10:21:08 +0200
 wrote:

> On Sat, Apr 03, 2021 at 08:57:20AM +0100, Joe wrote:
> 
> [...]
> 
> > think even then that most of them had oriental firmware, and my
> > opinion of even Japanese code is that it isn't wonderful. Hardware
> > great,  
>  
> Given the generally pitiful state of the software trade all over the
> place, the geographically biased slurs you indulge in in the above
> phrases seem less-than-warranted for.
> 
> It's not as if there weren't *cough* *Microsoft* western *cough*
> *Cisco* examples of *cough* *Apple* stellar failures in soft- and
> firmware.

Agreed, one of the many 'spare' routers I have is a Cisco-badged one,
bought specifically because it advertised Radius compatibility. Yes, I
know most routers do now, but this was a while ago. It took me a while
to work it out, but it had a bug which under most circumstances forgot
the Radius configuration. I spent some time with iptables and wireshark
before working this out, along with the workaround, bearing in mind
this was also my first attempt at running freeradius. Too many things
to get right all at once. Yes, I did it in the end.

But I've been associated with a household-name Japanese company for
around forty years, and I've used many examples of their software,
both public and private. I know what I'm talking about. And I've
recently had experience of several examples of software in Chinese
products, which was presumably written either in China or somewhere
even cheaper.

-- 
Joe

Re: Temporary failure in name resolution

[tomas]

On Sat, Apr 03, 2021 at 08:57:20AM +0100, Joe wrote:

[...]

> think even then that most of them had oriental firmware, and my opinion
> of even Japanese code is that it isn't wonderful. Hardware great,
 
Given the generally pitiful state of the software trade all over the
place, the geographically biased slurs you indulge in in the above
phrases seem less-than-warranted for.

It's not as if there weren't *cough* *Microsoft* western *cough* *Cisco*
examples of *cough* *Apple* stellar failures in soft- and firmware.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Temporary failure in name resolution

[Joe]

On Fri, 2 Apr 2021 20:14:41 -0400
Greg Wooledge  wrote:


> 
> Home router DNS services tend to be mediocre at best, and usually they
> simply forward your requests to your ISP's nameservers, and *those*
> tend to be problematic at times too (depending on the ISP).  That's
> two layers of questionable things to worry about.
> 

I once had a router (can't remember which make) which failed to return
*some* MX records. That took me some time to track down, as it was fine
with nearly all of them, and I was fairly new to networking.

In my time working on MS Small Business Server (early 2000s) there were
a number of routers which claimed to handle PPTP VPNs but didn't. I
think even then that most of them had oriental firmware, and my opinion
of even Japanese code is that it isn't wonderful. Hardware great,
software poor.

-- 
Joe

Re: Temporary failure in name resolution

[David Christensen]

On 3/31/21 1:33 PM, David Christensen wrote:


$ host -v -t A www.debian.org 192.168.1.254



Dan -- did you run the above test?  This may help isolate if the problem 
is Debian 10 or your AT gateway.



David

Re: Temporary failure in name resolution

[Greg Wooledge]

On Fri, Apr 02, 2021 at 10:48:09PM -0400, Dan Norton wrote:
> # cat /etc/resolv.conf
> domain attlocal.net
> search attlocal.net
> nameserver 1.1.1.1
> nameserver 1.0.0.1
> ...and this works very well. I like it because it cuts out more
> of google's monitoring of my browsing (I use Brave browser and
> DuckDuckGo).
> 
> Now what about the first two lines? What purpose? Can I cut out AT
> also? ;)

man resolv.conf

   search Search list for host-name lookup.
  By default, the search list contains one entry, the local domain
  name.   It  is  determined  from  the local hostname returned by
  gethostname(2); the local domain name is taken to be  everything
  after  the first '.'.  Finally, if the hostname does not contain
  a '.', the root domain is assumed as the local domain name.

  [...]

  The  domain  directive is an obsolete name for the search direc‐
  tive that handles one search list entry only.

Those lines do nothing, unless you routinely type commands like
"ssh lemon" or "ping pineapple" with no dots in the hostname.  In that
case, assuming the hosts are not defined in /etc/hosts, the resolver
will try to look up "lemon.attlocal.net" or "pineapple.attlocal.net" or
whatever.

Remember that something will probably overwrite your changes to the
resolv.conf file, unless you take preemptive steps.

Re: Temporary failure in name resolution

[Dan Norton]

Alexander V. Makartsev on Sat, 3 Apr 2021 01:17:59 +0500 wrote:

"On 02.04.2021 22:56, Dan Norton wrote:
Alexander V. Makartsev wrote Wed, 31 Mar 2021 10:16:08 +0500:

"Is "192.168.1.254" an IP address of your DSL modem?
If you don't need to resolve hostnames from you local network, like
"somepc1.attlocal.net" and only want to access the Internet, you can
configure one or more of the public DNS servers. From Google [1]:
8.8.8.8 8.8.4.4
>From CloudFlare [2]:
1.1.1.1"

I don't know. I did not put that line in /etc/resolv.conf. When I get
more time I may remove it and see what happens.
If you didn't put that line in /etc/resolv.conf, then probably it was
configured by DHCP client, which used the information send by your DSL
modem. That would explain "attlocal.net" lines. Do you have
administrative access to your DSL modem's configuration web interface?
Or is it a leased device that was configured by your ISP and you don't
have the option to configure it?"

The modem is leased from my ISP. It was installed by an AT employee
contracted by the ISP. It's possible he configured it but I don't know.

Alexander also said:

"If you have the access to DSL modem, you can configure its DHCP server
to always send proper DNS server addresses, like "1.1.1.1", "8.8.8.8",
instead of "192.168.1.254". Alternatively, and if you don't have the
access to DSL modem, you can modify "dhclient.conf" file to effectively
override name server addresses sent by your modem with known good ones.
This procedure is described in Debian Wiki. [1] Basically, all you have
to do is add at the end of the file this string: supersede
domain-name-servers 1.1.1.1,1.0.0.1,8.8.8.8,8.8.4.4;"

After looking at dhclient.conf and reading the comments, I decided to
leave dhclient.conf alone remove the line: nameserver 192.168.1.254 from
resolv.conf so that now:

# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 1.1.1.1
nameserver 1.0.0.1
...and this works very well. I like it because it cuts out more
of google's monitoring of my browsing (I use Brave browser and
DuckDuckGo).

Now what about the first two lines? What purpose? Can I cut out AT
also? ;)

 - Dan

Re: Temporary failure in name resolution

[Greg Wooledge]

On Fri, Apr 02, 2021 at 05:36:51PM -0400, rhkra...@gmail.com wrote:
> On Friday, April 02, 2021 04:35:58 PM Greg Wooledge wrote:
> > >2) would the caching feature be bypassed if your computer used the
> > >public
> > > 
> > > DNS name servers (e.g., 8.8.8.8, 8.8.4.4, and 1.1.1.1)?  (Or if they were
> > > listed before the modem IP address?)
> > 
> > You would be using the cached results stored by those external
> > nameservers.  Those are *extremely* popular nameservers, so one may
> > assume they will have basically the entire Internet namespace cached
> > most of the time.
> 
> Thanks!
> 
> I guess I phrased my question poorly -- I wondered if that would bypass the 
> cache (if present) in the DSL modem?

Yes.  You would not be talking to the router's nameserver at all.

Home router DNS services tend to be mediocre at best, and usually they
simply forward your requests to your ISP's nameservers, and *those*
tend to be problematic at times too (depending on the ISP).  That's two
layers of questionable things to worry about.

That's why multiple people have suggested editing your resolv.conf, to
stop using the router's nameserver which seems to be causing (or at least
contributing to) the problem.

If you don't want to use Google's or Cloudflare's public nameservers,
you can always run your own.  There are several different caching
recursive nameserver packages available in Debian.  Pick one, install
it, put "nameserver 127.0.0.1" in your resolv.conf, and you're all set...
until your DHCP client overwrites your changes.  That's when you use
one of the wiki's suggestions for how to keep your changes intact.

Re: Temporary failure in name resolution

[rhkramer]

On Friday, April 02, 2021 05:15:55 PM Alexander V. Makartsev wrote:
> On 03.04.2021 01:15, rhkra...@gmail.com wrote:
> > Sort of building on this question, and just trying to educate myself, if
> > the
> > 
> > DSL modem had a caching nameserver:
> > 1) would your computer need to specify the IP of that modem
> > (presumably)
> > 
> > 192.168.1.254 to take advantage of the caching?
> 
> Most of SOHO class routers\modems don't offer fully-fledged DNS server
> and domain name caching features.
> They act as relays, simply redirecting DNS requests to the nearest
> configured domain name server.
> But if some device offers such features like domain name caching, then
> yes, you will have to specify the IP of that device to take advantage of
> the caching.

Ahh, ok, good, thanks (that answers my question).

> > 2) would the caching feature be bypassed if your computer used the
> > public
> > 
> > DNS name servers (e.g., 8.8.8.8, 8.8.4.4, and 1.1.1.1)?  (Or if they were
> > listed before the modem IP address?)
> 
> Yes, it would be bypassed since you asking completely different domain
> name server to resolve your DNS requests.

Ahh, ok, good, thanks (that answers my question).
 
> An example: If you have a local network with a several hosts and want to
> address these hosts by their domain names,
> you will have to setup local domain name server which will resolve local
> domain name requests and redirect non-local domain ones.
> In this case, you will have to specify only one IP address of that local
> DNS, because public domain name servers don't know anything about host
> names in your local domain.

Re: Temporary failure in name resolution

[rhkramer]

On Friday, April 02, 2021 04:35:58 PM Greg Wooledge wrote:
> On Fri, Apr 02, 2021 at 04:15:07PM -0400, rhkra...@gmail.com wrote:
> > Sort of building on this question, and just trying to educate myself, if
> > the
> > 
> > DSL modem had a caching nameserver:
> >1) would your computer need to specify the IP of that modem
> >(presumably)
> > 
> > 192.168.1.254 to take advantage of the caching?
> 
> Regardless of whether the router's nameserver is forward-only or caching,
> you would still need to put its IP address in the resolv.conf file of
> each client that intends to use it.  Normally this is done by advertising
> it via DHCP.
> 
> >2) would the caching feature be bypassed if your computer used the
> >public
> > 
> > DNS name servers (e.g., 8.8.8.8, 8.8.4.4, and 1.1.1.1)?  (Or if they were
> > listed before the modem IP address?)
> 
> You would be using the cached results stored by those external
> nameservers.  Those are *extremely* popular nameservers, so one may
> assume they will have basically the entire Internet namespace cached
> most of the time.

Thanks!

I guess I phrased my question poorly -- I wondered if that would bypass the 
cache (if present) in the DSL modem?

Re: Temporary failure in name resolution

[Alexander V. Makartsev]

On 03.04.2021 01:15, rhkra...@gmail.com wrote:

Sort of building on this question, and just trying to educate myself, if the
DSL modem had a caching nameserver:

1) would your computer need to specify the IP of that modem (presumably)
192.168.1.254 to take advantage of the caching?
Most of SOHO class routers\modems don't offer fully-fledged DNS server 
and domain name caching features.
They act as relays, simply redirecting DNS requests to the nearest 
configured domain name server.
But if some device offers such features like domain name caching, then 
yes, you will have to specify the IP of that device to take advantage of 
the caching.



2) would the caching feature be bypassed if your computer used the public
DNS name servers (e.g., 8.8.8.8, 8.8.4.4, and 1.1.1.1)?  (Or if they were
listed before the modem IP address?)

Yes, it would be bypassed since you asking completely different domain 
name server to resolve your DNS requests.


An example: If you have a local network with a several hosts and want to 
address these hosts by their domain names,
you will have to setup local domain name server which will resolve local 
domain name requests and redirect non-local domain ones.
In this case, you will have to specify only one IP address of that local 
DNS, because public domain name servers don't know anything about host 
names in your local domain.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Temporary failure in name resolution

[Greg Wooledge]

On Fri, Apr 02, 2021 at 04:15:07PM -0400, rhkra...@gmail.com wrote:
> Sort of building on this question, and just trying to educate myself, if the 
> DSL modem had a caching nameserver:
> 
>1) would your computer need to specify the IP of that modem (presumably) 
> 192.168.1.254 to take advantage of the caching?

Regardless of whether the router's nameserver is forward-only or caching,
you would still need to put its IP address in the resolv.conf file of
each client that intends to use it.  Normally this is done by advertising
it via DHCP.

>2) would the caching feature be bypassed if your computer used the public 
> DNS name servers (e.g., 8.8.8.8, 8.8.4.4, and 1.1.1.1)?  (Or if they were 
> listed before the modem IP address?)

You would be using the cached results stored by those external
nameservers.  Those are *extremely* popular nameservers, so one may
assume they will have basically the entire Internet namespace cached
most of the time.

Re: Temporary failure in name resolution

[Alexander V. Makartsev]

On 02.04.2021 22:56, Dan Norton wrote:

Alexander V. Makartsev wrote Wed, 31 Mar 2021 10:16:08 +0500:

"Is "192.168.1.254" an IP address of your DSL modem?
If you don't need to resolve hostnames from you local network, like
"somepc1.attlocal.net" and only want to access the Internet, you can
configure one or more of the public DNS servers. From Google [1]:
8.8.8.8 8.8.4.4
 From CloudFlare [2]:
1.1.1.1"

I don't know. I did not put that line in /etc/resolv.conf. When I get
more time I may remove it and see what happens.
If you didn't put that line in /etc/resolv.conf, then probably it was 
configured by DHCP client, which used the information send by your DSL 
modem.

That would explain "attlocal.net" lines.
Do you have administrative access to your DSL modem's configuration web 
interface?
Or is it a leased device that was configured by your ISP and you don't 
have the option to configure it?


If you have the access to DSL modem, you can configure its DHCP server 
to always send proper DNS server addresses, like "1.1.1.1", "8.8.8.8", 
instead of "192.168.1.254".
Alternatively, and if you don't have the access to DSL modem, you can 
modify "dhclient.conf" file to effectively override name server 
addresses sent by your modem with known good ones.

This procedure is described in Debian Wiki. [1]
Basically, all you have to do is add at the end of the file this string:
    supersede domain-name-servers 1.1.1.1,1.0.0.1,8.8.8.8,8.8.4.4;


[1] 
https://wiki.debian.org/resolv.conf#Modifying_.2Fetc.2Fdhcp.2Fdhclient.conf


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Temporary failure in name resolution

[rhkramer]

On Friday, April 02, 2021 01:56:19 PM Dan Norton wrote:
> Alexander V. Makartsev wrote Wed, 31 Mar 2021 10:16:08 +0500:
> 
> "Is "192.168.1.254" an IP address of your DSL modem?
> If you don't need to resolve hostnames from you local network, like
> "somepc1.attlocal.net" and only want to access the Internet, you can
> configure one or more of the public DNS servers. From Google [1]:
> 8.8.8.8 8.8.4.4
> From CloudFlare [2]:
> 1.1.1.1"
> 
> I don't know. I did not put that line in /etc/resolv.conf. When I get
> more time I may remove it and see what happens.

Sort of building on this question, and just trying to educate myself, if the 
DSL modem had a caching nameserver:

   1) would your computer need to specify the IP of that modem (presumably) 
192.168.1.254 to take advantage of the caching?

   2) would the caching feature be bypassed if your computer used the public 
DNS name servers (e.g., 8.8.8.8, 8.8.4.4, and 1.1.1.1)?  (Or if they were 
listed before the modem IP address?)

Re: Temporary failure in name resolution

[Dan Norton]

Alexander V. Makartsev wrote Wed, 31 Mar 2021 10:16:08 +0500:

"Is "192.168.1.254" an IP address of your DSL modem?
If you don't need to resolve hostnames from you local network, like
"somepc1.attlocal.net" and only want to access the Internet, you can
configure one or more of the public DNS servers. From Google [1]:
8.8.8.8 8.8.4.4
From CloudFlare [2]:
1.1.1.1"

I don't know. I did not put that line in /etc/resolv.conf. When I get
more time I may remove it and see what happens.

 - Dan

Re: Temporary failure in name resolution

[Dan Norton]

David Wright wrote on Thu, 1 Apr 2021 11:50:56 -0500:

"I don't recall your answering Alexander's question: what benefit are
you getting from those two lines? Do you have a number of machines
at home that are being placed in that domain, whose names you
resolve with att's help?"

I don't know, except that having nameserver 1.1.1.1 and 1.0.0.1
in /etc/resolv.conf as Felix suggested results in successful name
resolution. My setup is an AT BGW210 modem connected by ethernet
cable to a desktop which serves wifi for printing and ISP access to my
wife's Windows laptop. Before I tried solving the name resolution
problem, systemd-resolved may have been disabled(?). I might have
enabled it, I'm not sure. 

# cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: compat systemd
group:  compat systemd
shadow: compat
gshadow:files

hosts:  files mdns4_minimal [NOTFOUND=return] dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis

HTH - Dan

Re: Temporary failure in name resolution

[Greg Wooledge]

On Thu, Apr 01, 2021 at 11:50:56AM -0500, David Wright wrote:
> > domain attlocal.net
> > search attlocal.net
> 
> I don't recall your answering Alexander's question: what benefit are
> you getting from those two lines? Do you have a number of machines
> at home that are being placed in that domain, whose names you
> resolve with att's help?

Most likely these lines simply do nothing at all.  They probably don't
have a conventional LAN with hosts that interact with each other.

For most home users, the contents of the search/domain lines are simply
unimportant.

Re: Temporary failure in name resolution

[David Wright]

On Wed 31 Mar 2021 at 18:28:52 (-0400), Dan Norton wrote:
> David Christensen wrote on Wed, 31 Mar 2021 13:49:56 -0700:
> 
> I would do 'apt-get update' and 'apt-get upgrade' ('autoremove',
> 'clean', etc.). Once apt-get(8) is done, I would revert the changes
> to /etc/resolv.conf and see if name resolution breaks or remains
> working. (I would test by renaming /etc/resolve.conf and rebooting.)
> 
> Here is what I did:
> # apt update
> # apt upgrade
> # apt autoremove
> # apt-get clean
> # cp /etc/resolv.conf /etc/resolv.confX
> # chattr -i /etc/resolv.conf
> ## to make resolv.conf *not* immutable
> # cat /etc/resolv.conf
> domain attlocal.net
> search attlocal.net

I don't recall your answering Alexander's question: what benefit are
you getting from those two lines? Do you have a number of machines
at home that are being placed in that domain, whose names you
resolve with att's help?

> nameserver 1.1.1.1
> nameserver 1.0.0.1
> nameserver 192.168.1.254

Yes, BT do this (use the highest host number rather than the lowest).

> Shutdown then power-on boot
> 
> ## rebooted with /etc/resolv.conf *not* immutable
> root@deb4:~# ping google.com
> ping: google.com: Temporary failure in name resolution
> root@deb4:~# cat /etc/resolv.conf
> domain attlocal.net
> search attlocal.net
> nameserver 192.168.1.254
> ## showing that /etc/resolv.conf has been clobbered

Normally, I would say that you'd expect that, because dhclient would
overwrite it with DHCP information returned from your router.

But we've a clue that your system is very different from, say, mine:

   '# systemctl status systemd-resolved
shows it being active and "Processing requests...".'

and in a parallel thread "Moritz Kempe: DNS problems on Raspberry Pi 400
(Debian 10.9)" we saw:

   "hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines"

which smells of nss-resolve and, hence, systemd-resolved.

I notice that   man nss-resolve   also mentions placing "resolve"
early in the hosts: line.

Now, I'm not saying that any of this last applies to your system, but
it does suggest that, because you're using systemd-resolved, some of
the advice being given by users who aren't, might not directly apply.
BTW we haven't seen your own nsswitch.conf.

> After restoring resolv.conf so that it looks like this:
> # cat /etc/resolv.conf
> domain attlocal.net
> search attlocal.net
> nameserver 1.1.1.1
> nameserver 1.0.0.1
> nameserver 192.168.1.254
> # chattr +i /etc/resolv.conf
> ## making it immutable
> 
> Rebooted and posted this.

If you're going to file a bug, I would first start by reading up on
systemd-resolved, and checking that your configuration matches what
that service expects. If that doesn't fix it, then I'd file the bug
against systemd-resolved, ie libnss-resolve. I'm not sure whether
that was in the point-release, but the DDs can always reassign it.

Cheers,
David.

Re: Temporary failure in name resolution

[David Christensen]

On 3/31/21 3:28 PM, Dan Norton wrote:

David Christensen wrote on Wed, 31 Mar 2021 13:49:56 -0700:

I would do 'apt-get update' and 'apt-get upgrade' ('autoremove',
'clean', etc.). Once apt-get(8) is done, I would revert the changes
to /etc/resolv.conf and see if name resolution breaks or remains
working. (I would test by renaming /etc/resolve.conf and rebooting.)

Here is what I did:
# apt update
# apt upgrade
# apt autoremove
# apt-get clean
# cp /etc/resolv.conf /etc/resolv.confX
# chattr -i /etc/resolv.conf
## to make resolv.conf *not* immutable
# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 192.168.1.254

Shutdown then power-on boot

## rebooted with /etc/resolv.conf *not* immutable
root@deb4:~# ping google.com
ping: google.com: Temporary failure in name resolution
root@deb4:~# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 192.168.1.254
## showing that /etc/resolv.conf has been clobbered

After restoring resolv.conf so that it looks like this:
# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 192.168.1.254
# chattr +i /etc/resolv.conf
## making it immutable

Rebooted and posted this.



Thank you for following through with that information.


It looks like Greg Wooledge is correct -- Debian 10.9 has problems with 
the DNS forwarding service on certain residential gateways.  A bug 
report would seem to be appropriate, but I do not know which package to 
file it against.



David

Re: Temporary failure in name resolution

[Dan Norton]

David Christensen wrote on Wed, 31 Mar 2021 13:49:56 -0700:

I would do 'apt-get update' and 'apt-get upgrade' ('autoremove',
'clean', etc.). Once apt-get(8) is done, I would revert the changes
to /etc/resolv.conf and see if name resolution breaks or remains
working. (I would test by renaming /etc/resolve.conf and rebooting.)

Here is what I did:
# apt update
# apt upgrade
# apt autoremove
# apt-get clean
# cp /etc/resolv.conf /etc/resolv.confX
# chattr -i /etc/resolv.conf
## to make resolv.conf *not* immutable
# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 192.168.1.254

Shutdown then power-on boot

## rebooted with /etc/resolv.conf *not* immutable
root@deb4:~# ping google.com
ping: google.com: Temporary failure in name resolution
root@deb4:~# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 192.168.1.254
## showing that /etc/resolv.conf has been clobbered

After restoring resolv.conf so that it looks like this:
# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 192.168.1.254
# chattr +i /etc/resolv.conf
## making it immutable

Rebooted and posted this.

 - Dan

Re: Temporary failure in name resolution

[David Christensen]

On 3/31/21 1:58 PM, Greg Wooledge wrote:

On Wed, Mar 31, 2021 at 01:43:23PM -0700, David Christensen wrote:

Is there technical documentation that explains how name resolution works in
Linux 4.19.0-16-amd64 and/or Debian 10?  (e.g. design and implementation,
userland tools, etc..)


It's not the kernel.  At all.

The standard name resolution in Debian is done by a modular system
called NSS (Name Service Switch).  The configuration file for this
is /etc/nsswitch.conf.

NSS is responsible for several different kinds of name resolution.  For
hostnames, the line in question is "hosts:".  This tells NSS whether to
use DNS, NIS, plain files, or other modules, in which order, and whether
a failure should abort or continue.

nsswitch.conf(5)
gethostbyname(3)
resolver(3)
hosts(5)
resolv.conf(5)

If you want to test the *standard* name resolution as documented by the
pages above, the correct shell tool is getent(1).

unicorn:~$ getent hosts www.debian.org
2603:400a::bb8::801f:3e www.debian.org
2001:4f8:1:c::15 www.debian.org

This uses the configuration from nsswitch.conf, so it will consult
/etc/hosts and/or DNS, or whatever you've configured your system to use.

There are other tools that specifically probe DNS, such as host(1)
and dig(1).  These bypass nsswitch.conf and go straight to DNS, because
they're designed to help an administrator test their DNS configuration.
(These are just two of the most common tools for this purpose -- there
are many more.)

unicorn:~$ host unicorn
Host unicorn not found: 3(NXDOMAIN)
unicorn:~$ getent hosts unicorn
127.0.1.1   unicorn.wooledge.org unicorn



Thank you for the clarification.


David

Re: Temporary failure in name resolution

[Greg Wooledge]

On Wed, Mar 31, 2021 at 01:43:23PM -0700, David Christensen wrote:
> Is there technical documentation that explains how name resolution works in
> Linux 4.19.0-16-amd64 and/or Debian 10?  (e.g. design and implementation,
> userland tools, etc..)

It's not the kernel.  At all.

The standard name resolution in Debian is done by a modular system
called NSS (Name Service Switch).  The configuration file for this
is /etc/nsswitch.conf.

NSS is responsible for several different kinds of name resolution.  For
hostnames, the line in question is "hosts:".  This tells NSS whether to
use DNS, NIS, plain files, or other modules, in which order, and whether
a failure should abort or continue.

nsswitch.conf(5)
gethostbyname(3)
resolver(3)
hosts(5)
resolv.conf(5)

If you want to test the *standard* name resolution as documented by the
pages above, the correct shell tool is getent(1).

unicorn:~$ getent hosts www.debian.org
2603:400a::bb8::801f:3e www.debian.org
2001:4f8:1:c::15 www.debian.org

This uses the configuration from nsswitch.conf, so it will consult
/etc/hosts and/or DNS, or whatever you've configured your system to use.

There are other tools that specifically probe DNS, such as host(1)
and dig(1).  These bypass nsswitch.conf and go straight to DNS, because
they're designed to help an administrator test their DNS configuration.
(These are just two of the most common tools for this purpose -- there
are many more.)

unicorn:~$ host unicorn
Host unicorn not found: 3(NXDOMAIN)
unicorn:~$ getent hosts unicorn
127.0.1.1   unicorn.wooledge.org unicorn

Re: Temporary failure in name resolution

[David Christensen]

On 3/31/21 11:58 AM, Dan Norton wrote:

Thank you, Felix. This post is coming from Debian with names resolved:
#1 SMP Debian 4.19.181-1 (2021-03-19)

Also resolv.conf is un-messed with:
$ cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 192.168.1.254

All is well again. Thanks again and thanks to everyone who responded.



Okay.


I would do 'apt-get update' and 'apt-get upgrade' ('autoremove', 
'clean', etc.).  Once apt-get(8) is done, I would revert the changes to 
/etc/resolv.conf and see if name resolution breaks or remains working. 
(I would test by renaming /etc/resolve.conf and rebooting.)



David

Re: Temporary failure in name resolution

[David Christensen]

On 3/31/21 10:37 AM, Greg Wooledge wrote:


As of right now, we have at least two people posting to debian-user
about DNS failures involving what appears to be their home router's
forwarding DNS service, and Debian 10.9.

Switching the nameserver lines in resolv.conf to something *other than*
the home router's DNS seems like a reasonable workaround.  Many of us
do that full-time anyway.

If anyone knows of a change to libc6 or libnss* in Debian 10.9 that might
be the underlying cause of these issues, please file a bug report or
something so it can be fixed.


Then I would

sudo chattr +i /etc/resolv.conf


That's *one* of the methods listed on the wiki.  Just be aware that it
can leave a whole bunch of /etc/resolv.conf.dhclient-new.* files sitting
around, and be prepared to remove them.

(I use a weekly crontab job.)



Is there technical documentation that explains how name resolution works 
in Linux 4.19.0-16-amd64 and/or Debian 10?  (e.g. design and 
implementation, userland tools, etc..)



David

Re: Temporary failure in name resolution

[David Christensen]

I have reorganized the content below to improve comprehension.


On 3/31/21 9:46 AM, Dan Norton wrote:
Thanks to all who responded. 

> Thanks for your detailed help. Let me know if I can dig out more.

YW.  We are making progress.  See below.



Have not changed any of the gateway settings that I'm aware of.



Okay.



This problem makes me post from a Windows laptop and transfer terminal output 
via thumb drive to the laptop. Not pretty.



Sneakernet works. :-)


> This laptop is the only other computer but it runs Windows. Is that 
testing name resolution with another computer?



Shutdown the Debian computer.  Shutdown the Windows laptop.  Look at the 
LED's on the AT gateway so that you know their state when it is 
operating.  Power off the gateway.  Unpatch the Ethernet cable connected 
to the laptop (e.g. disconnect both ends).  Wait at least 2 minutes. 
Boot the laptop and disable or delete all network connections.  Reboot 
Windows and verify that all network connections are down or gone.  Power 
up the gateway.  Wait for the LED's to return to the operating state. 
Patch the laptop to the gateway with an Ethernet cable.  Configure or 
create an Ethernet network connection to the gateway in Windows.  Fix 
any problems and verify everything works (contact AT technical support 
if necessary).  Stop the Ethernet connection in Windows.  Configure or 
create a Wi-Fi network connection to the gateway in Windows.  Fix any 
problems and verify everything works (contact AT technical support if 
necessary).  Turn off the Wi-Fi connection in Windows.  Choose either 
the Ethernet network connection or the Wi-Fi network connection, and 
enable one.



Ensure that the Debian computer is connected to the gateway with an 
Ethernet cable via the primary Ethernet port.  Unpatch all cables 
connected to all other Ethernet ports.  Boot the Debian computer.



> Yes, I have done a cold reboot [of the Debian computer] since upgrading.


Okay.


> # cat /etc/debian_version ; uname -a
> 10.9
> Linux deb4 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) 
x86_64 GNU/Linux



Okay.  Those are current.


> # ifconfig eno1
> eno1: flags=4163  mtu 1500
>  inet 192.168.1.66  netmask 255.255.255.0  broadcast 
192.168.1.255
>  inet6 ::***:::::  prefixlen 64 
scopeid 0x0
>  inet6 :::::  prefixlen 64  scopeid 
0x20

>  ether **:**:**:**:**:**  txqueuelen 1000  (Ethernet)
>  RX packets 10009  bytes 1101640 (1.0 MiB)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 1734  bytes 180973 (176.7 KiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Okay.


> # cd /etc
> # cat resolv.conf
> domain attlocal.net
> search attlocal.net
> nameserver 192.168.1.254
> [something removes additional nameserver lines that I add]


Okay.  For now, do not try to edit that file.



# apt update
0% [Connecting to deb.debian.org] [Connecting to qgis.org] [Connecting to 
brave-browser-apt-release.s3.brave.com]^C
[cancelled early]

# apt update
Err:1 http://deb.debian.org/debian buster InRelease
   Temporary failure resolving 'deb.debian.org'
Err:2 https://qgis.org/debian buster InRelease
   Temporary failure resolving 'qgis.org'
Err:3 https://brave-browser-apt-release.s3.brave.com stable InRelease
   Temporary failure resolving 'brave-browser-apt-release.s3.brave.com'
0% [Working]^C
[cancelled later]

# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
   libqgis-3d3.18.0 libqgis-analysis3.18.0 libqgis-app3.18.0 libqgis-core3.18.0 
libqgis-gui3.18.0
   libqgis-native3.18.0 libqgis-server3.18.0 libqgisgrass7-3.18.0 
libqgispython3.18.0
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
   libqgis-3d3.18.1 libqgis-analysis3.18.1 libqgis-app3.18.1 libqgis-core3.18.1 
libqgis-gui3.18.1
   libqgis-native3.18.1 libqgis-server3.18.1 libqgisgrass7-3.18.1 
libqgispython3.18.1
The following packages will be upgraded:
   libqgis-customwidgets python3-qgis python3-qgis-common qgis qgis-common 
qgis-plugin-grass
   qgis-plugin-grass-common qgis-provider-grass qgis-providers 
qgis-providers-common
10 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 105 MB of archives.
After this operation, 91.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Err:1 https://qgis.org/debian buster/main amd64 qgis-plugin-grass amd64 
1:3.18.1+15buster
   Temporary failure resolving 'qgis.org'
[this continues to Err:19 then more]



So, the updates/ upgrades are incomplete because you need packages and 
the DNS problems are preventing apt-get(8) from fetching the packages 
needed to complete the updates/ upgrades.  A Catch-22 situation...



Have you modified /etc/apt/sources.list or added any configuration 

Re: Temporary failure in name resolution

[Dan Norton]

Thank you, Felix. This post is coming from Debian with names resolved:
#1 SMP Debian 4.19.181-1 (2021-03-19)

Also resolv.conf is un-messed with:
$ cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 192.168.1.254

All is well again. Thanks again and thanks to everyone who responded.

 - Dan

Re: Temporary failure in name resolution

[Greg Wooledge]

On Wed, Mar 31, 2021 at 01:26:32PM -0400, Felix Miata wrote:
> Dan Norton composed on 2021-03-31 12:46 (UTC-0400):
> 
> > # cd /etc
> > # cat resolv.conf
> > domain attlocal.net
> > search attlocal.net
> > nameserver 192.168.1.254
> > [something removes additional nameserver lines that I add]  
> > 
> I can't tell why this happens, or suggest a proper fix,

https://wiki.debian.org/resolv.conf

> but if it was happening to
> me, I would replace
> 
>   nameserver 192.168.1.254
> 
> with
>   nameserver 1.1.1.1
>   nameserver 1.0.0.1
> 
> and possibly add
> 
>   nameserver 192.168.1.1
> 
> or whatever the IP of your router is.

I'm assuming 192.168.1.254 is his router.

As of right now, we have at least two people posting to debian-user
about DNS failures involving what appears to be their home router's
forwarding DNS service, and Debian 10.9.

Switching the nameserver lines in resolv.conf to something *other than*
the home router's DNS seems like a reasonable workaround.  Many of us
do that full-time anyway.

If anyone knows of a change to libc6 or libnss* in Debian 10.9 that might
be the underlying cause of these issues, please file a bug report or
something so it can be fixed.

> Then I would
> 
>   sudo chattr +i /etc/resolv.conf

That's *one* of the methods listed on the wiki.  Just be aware that it
can leave a whole bunch of /etc/resolv.conf.dhclient-new.* files sitting
around, and be prepared to remove them.

(I use a weekly crontab job.)

Re: Temporary failure in name resolution

[Felix Miata]

Dan Norton composed on 2021-03-31 12:46 (UTC-0400):

> # cd /etc
> # cat resolv.conf
> domain attlocal.net
> search attlocal.net
> nameserver 192.168.1.254
> [something removes additional nameserver lines that I add]
> 
I can't tell why this happens, or suggest a proper fix, but if it was happening 
to
me, I would replace

nameserver 192.168.1.254

with
nameserver 1.1.1.1
nameserver 1.0.0.1

and possibly add

nameserver 192.168.1.1

or whatever the IP of your router is. Then I would

sudo chattr +i /etc/resolv.conf

and expect no further need for thumb drive or Windows.


Is resolvconf installed?

What is output from

systemctl status systemd-resolved.service

In Bullseye right now I have neither resolvconf installed, nor systemd-resolvd
enabled, and am running static IP.
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Temporary failure in name resolution

[Dan Norton]

Thanks to all who responded. This problem makes me post from a Windows laptop 
and transfer terminal output via thumb drive to the laptop. Not pretty.

To David: Yes, I have done a cold reboot since upgrading.
# apt update
0% [Connecting to deb.debian.org] [Connecting to qgis.org] [Connecting to 
brave-browser-apt-release.s3.brave.com]^C
[cancelled early]

# apt update
Err:1 http://deb.debian.org/debian buster InRelease 
 
  Temporary failure resolving 'deb.debian.org'
Err:2 https://qgis.org/debian buster InRelease  
 
  Temporary failure resolving 'qgis.org'
Err:3 https://brave-browser-apt-release.s3.brave.com stable InRelease   
  
  Temporary failure resolving 'brave-browser-apt-release.s3.brave.com'
0% [Working]^C 
[cancelled later]

# apt upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  libqgis-3d3.18.0 libqgis-analysis3.18.0 libqgis-app3.18.0 libqgis-core3.18.0 
libqgis-gui3.18.0
  libqgis-native3.18.0 libqgis-server3.18.0 libqgisgrass7-3.18.0 
libqgispython3.18.0
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  libqgis-3d3.18.1 libqgis-analysis3.18.1 libqgis-app3.18.1 libqgis-core3.18.1 
libqgis-gui3.18.1
  libqgis-native3.18.1 libqgis-server3.18.1 libqgisgrass7-3.18.1 
libqgispython3.18.1
The following packages will be upgraded:
  libqgis-customwidgets python3-qgis python3-qgis-common qgis qgis-common 
qgis-plugin-grass
  qgis-plugin-grass-common qgis-provider-grass qgis-providers 
qgis-providers-common
10 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 105 MB of archives.
After this operation, 91.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Err:1 https://qgis.org/debian buster/main amd64 qgis-plugin-grass amd64 
1:3.18.1+15buster
  Temporary failure resolving 'qgis.org'
[this continues to Err:19 then more]

Have not changed any of the gateway settings that I'm aware of.

This laptop is the only other computer but it runs Windows. Is that testing 
name resolution with another computer?

# ifconfig eno1
eno1: flags=4163  mtu 1500
inet 192.168.1.66  netmask 255.255.255.0  broadcast 192.168.1.255
inet6 ::***:::::  prefixlen 64  scopeid 
0x0
inet6 :::::  prefixlen 64  scopeid 0x20
ether **:**:**:**:**:**  txqueuelen 1000  (Ethernet)
RX packets 10009  bytes 1101640 (1.0 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 1734  bytes 180973 (176.7 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# cd /etc
# cat resolv.conf
domain attlocal.net
search attlocal.net
nameserver 192.168.1.254
[something removes additional nameserver lines that I add]

# cat /etc/debian_version ; uname -a
10.9
Linux deb4 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 
GNU/Linux

$ nmcli g status
$ nmcli c show
$ nmcli d show
[I don't seem to have nmcli]

# host -v -t A www.debian.org 8.8.8.8
Trying "www.debian.org"
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58963
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.debian.org.IN  A

;; ANSWER SECTION:
www.debian.org. 299 IN  A   128.31.0.62
www.debian.org. 299 IN  A   149.20.4.15

Received 64 bytes from 8.8.8.8#53 in 102 ms

# host -v -t A www.debian.org
Trying "www.debian.org"
;; connection timed out; no servers could be reached

Thanks for your detailed help. Let me know if I can dig out more.

 - Dan

Re: Temporary failure in name resolution

[Moritz Kempe]

I am experiencing a potential related issue, (Subject: DNS problems on 
Raspberry Pi 400 (Debian 10.9)" on this list)


can you please install dnsutils (sudo apt-get install dnsutils)

and try to use dig to get an ip from a domain and send us your output?

Because if i try to use host it returns

-- host github.com
Host github.com not found: 2(SERVFAIL)
--

But dig is able to get the ip

-- dig github.com
; <<>> DiG 9.16.13-Debian <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32657
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
github.com.        27    IN    A    140.82.121.3

;; Query time: 459 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Wed Mar 31 13:04:57 CEST 2021
;; MSG SIZE  rcvd: 55
--


Kind Regards

Moritz Kempe

Re: Temporary failure in name resolution

[john doe]

On 3/31/2021 4:21 AM, Dan Norton wrote:

After the 10.9 upgrade, name resolution is not working for me. Does anyone else 
see this?

My desktop is a wifi server for laptop access using windows. That works OK but 
the server, attached by ethernet to the DSL modem does not get names resolved 
since the upgrade. The resolvconf program is not


With a desktop environment (Mate/Gnome...)?

installed according to whereis.


# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 192.168.1.254

If that's not the right nameserver then what is?


IS the DNS serverat 192.168.1.254 working?



$ ping google.com
ping: google.com: Temporary failure in name resolution

$ ping -c2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=21.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=21.2 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 21.148/21.188/21.229/0.151 ms



Are those pings done on the server or on the clients?


# systemctl status systemd-resolved
shows it being active and "Processing requests...".
>
Nothing in history.log and term.log is obviously wrong to me FWIW.

# journalctl -b0
gives no clue to me.

No doubt it is something simple(tm). Where should I look or what should I 
re-read?

  - Dan Norton



Did you do a 'systemctl reboot' to restart the server?

--
John Doe

Re: Temporary failure in name resolution

[David Christensen]

On 3/30/21 7:21 PM, Dan Norton wrote:

After the 10.9 upgrade, name resolution is not working for me. Does anyone else 
see this?

My desktop is a wifi server for laptop access using windows. That works OK but 
the server, attached by ethernet to the DSL modem does not get names resolved 
since the upgrade. The resolvconf program is not installed according to whereis.

# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 192.168.1.254



Have you done a cold reboot since upgrading Debian?


Do the following commands indicate everything is up to date?

# apt-get update

# apt-get upgrade


Have you changed any of the gateway settings recently?


Please verify that the DNS proxy server on the gateway is working by 
testing name resolution with another computer.



I have a ~2007 Dell Inspiron E1505 laptop with Debian 10:

2021-03-30 22:29:53 dpchrist@dipsy ~
$ cat /etc/debian_version ; uname -a
10.9
Linux dipsy 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 
GNU/Linux



I have AT U-verse residential VDSL service.  When I connect the E1505 
to the gateway via Ethernet and DHCP:


2021-03-30 22:47:40 root@dipsy ~
# ifconfig eth0
eth0: flags=4163  mtu 1500
inet 192.168.1.149  netmask 255.255.255.0  broadcast 192.168.1.255
inet6 :::::  prefixlen 64  scopeid 0x20
inet6 2600:170*::::::  prefixlen 64 
scopeid 0x0

ether **:**:**:**:**:**  txqueuelen 1000  (Ethernet)
RX packets 11184  bytes 935656 (913.7 KiB)
RX errors 0  dropped 41  overruns 0  frame 0
TX packets 1911  bytes 24 (249.5 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 17

2021-03-30 22:48:19 root@dipsy ~
# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net
nameserver 192.168.1.254
nameserver 2600:170*::::1


Both IPv4 and IPv6 "nameserver" addresses correspond to the LAN side of 
the gateway.  ('*' is for redacted characters.)




If that's not the right nameserver then what is?

$ ping google.com
ping: google.com: Temporary failure in name resolution

$ ping -c2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=21.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=21.2 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 21.148/21.188/21.229/0.151 ms

# systemctl status systemd-resolved
shows it being active and "Processing requests...".

Nothing in history.log and term.log is obviously wrong to me FWIW.

# journalctl -b0
gives no clue to me.

No doubt it is something simple(tm). Where should I look or what should I 
re-read?



Please run the following commands.  Use Ctrl+C to interrupt any commands 
that hang.  Reply with your complete console session -- prompts, 
keystrokes entered, and output displayed.  Redact as desired:


$ cat /etc/debian_version ; uname -a

$ ping -c 3 192.168.1.254

$ nmcli g status

$ nmcli c show

$ nmcli d show

$ host -v -t A www.debian.org 8.8.8.8

$ host -v -t A www.debian.org


David

Re: Temporary failure in name resolution

[Alexander V. Makartsev]

On 31.03.2021 07:21, Dan Norton wrote:

After the 10.9 upgrade, name resolution is not working for me. Does anyone else 
see this?

My desktop is a wifi server for laptop access using windows. That works OK but 
the server, attached by ethernet to the DSL modem does not get names resolved 
since the upgrade. The resolvconf program is not installed according to whereis.

# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 192.168.1.254

If that's not the right nameserver then what is?


Is "192.168.1.254" an IP address of your DSL modem?
If you don't need to resolve hostnames from you local network, like 
"somepc1.attlocal.net" and only want to access the Internet, you can 
configure one or more of the public DNS servers.

From Google [1]:
8.8.8.8
8.8.4.4
From CloudFlare [2]:
1.1.1.1

[1] https://developers.google.com/speed/public-dns/docs/using
[2] https://one.one.one.one/

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Temporary failure in name resolution

[Dan Norton]

After the 10.9 upgrade, name resolution is not working for me. Does anyone else 
see this?

My desktop is a wifi server for laptop access using windows. That works OK but 
the server, attached by ethernet to the DSL modem does not get names resolved 
since the upgrade. The resolvconf program is not installed according to whereis.

# cat /etc/resolv.conf
domain attlocal.net
search attlocal.net
nameserver 192.168.1.254

If that's not the right nameserver then what is?

$ ping google.com
ping: google.com: Temporary failure in name resolution

$ ping -c2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=21.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=21.2 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 21.148/21.188/21.229/0.151 ms

# systemctl status systemd-resolved
shows it being active and "Processing requests...".

Nothing in history.log and term.log is obviously wrong to me FWIW.

# journalctl -b0
gives no clue to me.

No doubt it is something simple(tm). Where should I look or what should I 
re-read?

 - Dan Norton

Temporary failure in name resolution (PPPoE)

[Masatran (Rajasekaran Deepak)]

I am using PPPoE to connect to the internet. For a few minutes after booting
the computer and running pppoe-start, I get this error:

$ ssh research.iiit.ac.in
ssh: research.iiit.ac.in: Temporary failure in name resolution

How can I avoid this problem?
-- 
Masatran (Rajasekaran Deepak) http://research.iiit.ac.in/~masatran/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Temporary failure in name resolution (PPPoE)

[Bob Hutchinson]

On Sunday 06 Nov 2005 17:14, Masatran (Rajasekaran Deepak) wrote:
 I am using PPPoE to connect to the internet. For a few minutes after
 booting the computer and running pppoe-start, I get this error:

 $ ssh research.iiit.ac.in
 ssh: research.iiit.ac.in: Temporary failure in name resolution

 How can I avoid this problem?

sounds like your service provider's dns is lousy, you could set up a dnscache, 
google for djbdns for a good one.

 --
 Masatran (Rajasekaran Deepak) http://research.iiit.ac.in/~masatran/

-- 
-
Bob Hutchinson
Midwales dot com
-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Apache PHP DNS : Temporary failure in name resolution

[François TOURDE]

Yannick [EMAIL PROTECTED] writes:

 Bonjour,

Bonjour

 Je suis un peu perdu dans la configuration de PHP sur ma woody :
 
 J'ai besoin de récupérer un fichier sur le net avec PHP. Or PHP me renvoie 
 une erreur quand je lui donne l'adresse normale (comme www.free.fr) :
 
 Warning: php_network_getaddresses: getaddrinfo failed: Temporary failure in 
 name resolution in /home/yan/public_html/testdns.php on line 13
 
 Warning: fopen(http://www.free.fr/;, r) - Bad file descriptor in 
 /home/yan/public_html/testdns.php on line 13
 
 
 Par contre si je lui donne l'adresse IP, alors cela fonctionne :
 
 $URL = http://213.228.0.42/;;
 //$URL = http://www.free.fr/;;
 $pointeur_fichier = fopen ($URL, r);

Juste pour essayer (mais je suis pas convaincu), essaye la commande:

$ host www.free.fr

Déjà si tu as une bonne réponse, tu sauras que c'est pas la config DNS de
ton système qui est mauvaise.


 Je précise qu'avec un navigateur quelconque (galeon ou konqueror) je n'ai pas 
 ce problème de résolution des noms.

J'ai souvenir que certains navigateurs (Mozilla je crois), gérait son propre 
cache
de DNS. Si tu fais le test alors que les DNS de ton provider sont dans le gaz, 
il
se peut que PHP/host se plaignent, alors que ton navigateur utilise son cache.

-- 
And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies.
(By Linus Torvalds, [EMAIL PROTECTED])
-- 
François TOURDE - tourde.org - 23 rue Bernard GANTE - 93250 VILLEMOMBLE
Tél: 01 49 35 96 69 - Mob: 06 81 01 81 80
eMail: mailto:[EMAIL PROTECTED] - URL: http://francois.tourde.org/

Re: Apache PHP DNS : Temporary failure in name resolution

[Yannick]

On Saturday 8 February 2003 18:54, François TOURDE wrote:
 Yannick [EMAIL PROTECTED] writes:
  Bonjour,

 Bonjour

  Je suis un peu perdu dans la configuration de PHP sur ma woody :
 
  J'ai besoin de récupérer un fichier sur le net avec PHP. Or PHP me
  renvoie une erreur quand je lui donne l'adresse normale (comme
  www.free.fr) :
 
  Warning: php_network_getaddresses: getaddrinfo failed: Temporary failure
  in name resolution in /home/yan/public_html/testdns.php on line 13
 
  Warning: fopen(http://www.free.fr/;, r) - Bad file descriptor in
  /home/yan/public_html/testdns.php on line 13
 
 
  Par contre si je lui donne l'adresse IP, alors cela fonctionne :
 
  $URL = http://213.228.0.42/;;
  //$URL = http://www.free.fr/;;
  $pointeur_fichier = fopen ($URL, r);

 Juste pour essayer (mais je suis pas convaincu), essaye la commande:

 $ host www.free.fr

$ host www.free.fr
www.free.fr has address 213.228.0.42

Ma config DNS semble bonne. Je pense que c'est spécifique à PHP/apache.

Des idées ?


 Déjà si tu as une bonne réponse, tu sauras que c'est pas la config DNS de
 ton système qui est mauvaise.

  Je précise qu'avec un navigateur quelconque (galeon ou konqueror) je n'ai
  pas ce problème de résolution des noms.

 J'ai souvenir que certains navigateurs (Mozilla je crois), gérait son
 propre cache de DNS. Si tu fais le test alors que les DNS de ton provider
 sont dans le gaz, il se peut que PHP/host se plaignent, alors que ton
 navigateur utilise son cache.

Re: ssh: localhost: Temporary failure in name resolution

[Andre Berger]

kmself@ix.netcom.com writes:

 on Sat, Dec 16, 2000 at 10:41:05AM +0100, Andre Berger ([EMAIL PROTECTED]) 
 wrote:
  kmself@ix.netcom.com writes:
  
   on Sat, Dec 16, 2000 at 12:36:17AM +0100, Andre Berger ([EMAIL 
   PROTECTED]) wrote:
I get ssh: localhost: Temporary failure in name resolution with

ssh_1%3a2.2.0p1-1.1progeny1_i386.deb
ssh-askpass-gnome_1%3a2.2.0p1-1.1progeny1_i386.deb

but I can ping localhost, and I can still access other machines with
ssh. Any ideas? I've just upgraded from potato and its ssh.
   
   Possibly reverse-DNS lookup from the sshd server -- check your logs.  Is
   your DNS server (named) running, if you are using local DNS?  I've had
   issues with servers failing to restart during/after recent updates, tend
   to go through them by hand or script these days.
 Shit, I don't know, I just roll into /var/logs, do an 'ls -t | head
 -number' to see what's reporting current activity, and grep for the
 daemon I'm looking for.  Usually /var/log/daemon.
 
 You're looking for any sshd refused connect errors.  If you're not
 seeing these messages, you're not even getting there.
 
 Other thing to try is 'ssh -v host' -- this will give verbose output on
 the status of the connection, allowing you to troubleshoot from the
 client end.

I found nothing in any log or additional information with 'ssh -v',
but I found a work-around. I added

Host localhost
HostName 127.0.0.1

to /etc/ssh/ssh_config, and 'ssh localhost' now gives
[EMAIL PROTECTED]'s password: and access.

But still I don't understand what's wrong.

-- 
Andre Berger   [EMAIL PROTECTED]

Re: ssh: localhost: Temporary failure in name resolution

[Andre Berger]

kmself@ix.netcom.com writes:

 on Sat, Dec 16, 2000 at 12:36:17AM +0100, Andre Berger ([EMAIL PROTECTED]) 
 wrote:
  I get ssh: localhost: Temporary failure in name resolution with
  
  ssh_1%3a2.2.0p1-1.1progeny1_i386.deb
  ssh-askpass-gnome_1%3a2.2.0p1-1.1progeny1_i386.deb
  
  but I can ping localhost, and I can still access other machines with
  ssh. Any ideas? I've just upgraded from potato and its ssh.
 
 Possibly reverse-DNS lookup from the sshd server -- check your logs.  Is
 your DNS server (named) running, if you are using local DNS?  I've had
 issues with servers failing to restart during/after recent updates, tend
 to go through them by hand or script these days.
 
 -- 
 Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
  Evangelist, Zelerate, Inc.  http://www.zelerate.org
   What part of Gestalt don't you understand?  There is no K5 cabal
http://gestalt-system.sourceforge.net/http://www.kuro5hin.org

It's a dial-up machine, DNS assigned for each PPP connection. As soon
as I am connected to my ISP, everything works. Which logs am I
supposed to check?  /var/log/{auth.log,messages,syslog} don't tell
much, just that key generation was successful.

Andre

Re: ssh: localhost: Temporary failure in name resolution

[kmself]

on Sat, Dec 16, 2000 at 10:41:05AM +0100, Andre Berger ([EMAIL PROTECTED]) 
wrote:
 kmself@ix.netcom.com writes:
 
  on Sat, Dec 16, 2000 at 12:36:17AM +0100, Andre Berger ([EMAIL PROTECTED]) 
  wrote:
   I get ssh: localhost: Temporary failure in name resolution with
   
   ssh_1%3a2.2.0p1-1.1progeny1_i386.deb
   ssh-askpass-gnome_1%3a2.2.0p1-1.1progeny1_i386.deb
   
   but I can ping localhost, and I can still access other machines with
   ssh. Any ideas? I've just upgraded from potato and its ssh.
  
  Possibly reverse-DNS lookup from the sshd server -- check your logs.  Is
  your DNS server (named) running, if you are using local DNS?  I've had
  issues with servers failing to restart during/after recent updates, tend
  to go through them by hand or script these days.
  
  -- 
  Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
   Evangelist, Zelerate, Inc.  http://www.zelerate.org
What part of Gestalt don't you understand?  There is no K5 cabal
 http://gestalt-system.sourceforge.net/http://www.kuro5hin.org
 
 It's a dial-up machine, DNS assigned for each PPP connection. As soon
 as I am connected to my ISP, everything works. Which logs am I
 supposed to check?  /var/log/{auth.log,messages,syslog} don't tell
 much, just that key generation was successful.

Shit, I don't know, I just roll into /var/logs, do an 'ls -t | head
-number' to see what's reporting current activity, and grep for the
daemon I'm looking for.  Usually /var/log/daemon.

You're looking for any sshd refused connect errors.  If you're not
seeing these messages, you're not even getting there.

Other thing to try is 'ssh -v host' -- this will give verbose output on
the status of the connection, allowing you to troubleshoot from the
client end.

-- 
Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
 Evangelist, Zelerate, Inc.  http://www.zelerate.org
  What part of Gestalt don't you understand?  There is no K5 cabal
   http://gestalt-system.sourceforge.net/http://www.kuro5hin.org


pgpCl4u8JU5An.pgp
Description: PGP signature

ssh: localhost: Temporary failure in name resolution

[Andre Berger]

I get ssh: localhost: Temporary failure in name resolution with

ssh_1%3a2.2.0p1-1.1progeny1_i386.deb
ssh-askpass-gnome_1%3a2.2.0p1-1.1progeny1_i386.deb

but I can ping localhost, and I can still access other machines with
ssh. Any ideas? I've just upgraded from potato and its ssh.

Andre

Re: ssh: localhost: Temporary failure in name resolution

[kmself]

on Sat, Dec 16, 2000 at 12:36:17AM +0100, Andre Berger ([EMAIL PROTECTED]) 
wrote:
 I get ssh: localhost: Temporary failure in name resolution with
 
 ssh_1%3a2.2.0p1-1.1progeny1_i386.deb
 ssh-askpass-gnome_1%3a2.2.0p1-1.1progeny1_i386.deb
 
 but I can ping localhost, and I can still access other machines with
 ssh. Any ideas? I've just upgraded from potato and its ssh.

Possibly reverse-DNS lookup from the sshd server -- check your logs.  Is
your DNS server (named) running, if you are using local DNS?  I've had
issues with servers failing to restart during/after recent updates, tend
to go through them by hand or script these days.

-- 
Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
 Evangelist, Zelerate, Inc.  http://www.zelerate.org
  What part of Gestalt don't you understand?  There is no K5 cabal
   http://gestalt-system.sourceforge.net/http://www.kuro5hin.org


pgpG4FooW8AIW.pgp
Description: PGP signature