+
> 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+0
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
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/ht
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"
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 "h
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 real
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
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
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"
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 t
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"?
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
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
>
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 lovel
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.h
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'.
> > >
> > >
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
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
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 localhos
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 prog
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
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* occu
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
>
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
; 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.
quot;Successful vif-route ${command} for ${dev}."
>> if [ "${command}" = "online" ]
>> then
>> success
>> fi
>>
>>
>> B) on the guest os (Debian 12)
>>
>>
>> /etc/network/interfaces :
>>
>> source
worm:~# 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 co
;
>
> 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.
e: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.
>> 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
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
>>> 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 `dnsm
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 y
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
g/resolv.conf#Modifying_.2Fetc.2Fdhcp.2Fdhclient.conf
After the AT&T 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
> 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
sim
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 cl
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&T gateway."
The five lines immediately above are incorrectly forma
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.2Fdhc
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.co
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
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&T gateway."
>
> $ host -v -t A www.
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&T gateway."
$ host -v -t A www.debian.org 192.168.1.254
Trying "www.debian.org"
;; connection timed out; no s
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 p
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 geogra
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 questiona
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&T gateway.
David
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 a
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.a
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 t
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 I
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 sp
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 SOH
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 advanta
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
confi
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 th
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 server
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, exce
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
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
>
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
t
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 att
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
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 res
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
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
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
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
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]
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 c
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
b
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
-
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
eserver 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
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 t
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)
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:
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 Dee
t; > 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 lo
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 res
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-askpas
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 pin
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
83 matches
Mail list logo
