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

[to...@tuxteam.de]

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

[Rodolfo Medina]

<to...@tuxteam.de> writes:

> On Wed, Jan 10, 2024 at 06:13:55PM +0000, 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

[Greg Wooledge]

On Wed, Jan 10, 2024 at 06:34:53PM +0000, Rodolfo Medina wrote:
> <to...@tuxteam.de> 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"?

[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

[Rodolfo Medina]

Greg Wooledge <gr...@wooledge.org> writes:

> On Wed, Jan 10, 2024 at 06:34:53PM +0000, Rodolfo Medina wrote:
>> <to...@tuxteam.de> 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

[Greg Wooledge]

On Wed, Jan 10, 2024 at 07:19:41PM +0000, Rodolfo Medina wrote:
> Greg Wooledge <gr...@wooledge.org> 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.

[Max Nikulin]

On 11/01/2024 03:25, Greg Wooledge wrote:
> On Wed, Jan 10, 2024 at 07:19:41PM +0000, Rodolfo Medina wrote:
>> Greg Wooledge <gr...@wooledge.org> 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

[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 +0000, Rodolfo Medina wrote:
> > > Greg Wooledge <gr...@wooledge.org> 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.

[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.

[to...@tuxteam.de]

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

> Greg Wooledge <gr...@wooledge.org> writes:
>
> > On Wed, Jan 10, 2024 at 06:34:53PM +0000, Rodolfo Medina wrote:
> >> <to...@tuxteam.de> 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

[Curt]

On 2024-01-11, Max Nikulin <mani...@gmail.com> 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

[Marco Moock]

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

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

[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 +0000, Rodolfo Medina wrote:
>>>> Greg Wooledge <gr...@wooledge.org> 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.

[debia...@howorth.org.uk]

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

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

:P

[Byung-Hee HWANG]

Oh thanks for information!


Sincerely, Byung-Hee

[Curt]

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
>
>


--

[Jeffrey Walton]

And to muddy the waters a little more, IANA has some reserved domain
names, too: <https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml>.
Also see <https://www.iana.org/domains/reserved>.

Jeff

[Jeffrey Walton]

On Fri, Jan 12, 2024 at 12:33 PM <debia...@howorth.org.uk> wrote:

> 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

[debia...@howorth.org.uk]

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

home.arpa. [RFC8375]

> Jeff
>

[debia...@howorth.org.uk]

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'.

[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
jo...@sugarbit.com
Elmwood, WI USA