Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DNS problems on Raspberry Pi 400 (Debian 10.9)
333 views
Skip to first unread message
Moritz Kempe
Mar 30, 2021, 6:40:05 PM3/30/21
to
Hello,
since i upgraded my Raspberry Pi 400 (with regular Debian 10, not
Raspberry PI OS) to the latest buster version, i am experiencing
problems with dns, which i cannot replicate with any of my other devices
(Debian Stretch amd64 workstation, Debian Buster amd64 server, Raspberry
Pi 3b armhf raspberrypi OS). But i can replicate this behavior with
another another micro sd flashcard with Twister OS on the (same)
Raspberry Pi 400. Twister OS is an Debian / Raspberry Pi OS based OS
which helps you to game on the Raspberry Pi 400.
I noticed the problem, while i was browsing the internet and got
confused because after a while some domains could not longer be
found/connected to by the browser. (On both, Firefox and Chromium)
-- Firefox
Hmm. We’re having trouble finding that site.
We can’t connect to the server at github.com.
If that address is correct, here are three other things you can try:
Try again later.
Check your network connection.
If you are connected but behind a firewall, check that Firefox has
permission to access the Web.
--
-- Chromium
This site can’t be reachedCheck if there is a typo in github.com.
DNS_PROBE_FINISHED_NXDOMAIN
--
And as time passes, more and more website will disappear.
Which means, that after a hour only barely visited domains are left.
And even stranger is the output of different dns tools:
-- host github.com
moke@rpi4-20201112:~$ host github.com
Host github.com not found: 2(SERVFAIL)
--
-- dig github.com
; <<>> DiG 9.16.13-Debian <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30900
;; 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: 343 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Tue Mar 30 23:31:01 CEST 2021
;; MSG SIZE rcvd: 55
--
Dig seems to be able to get the ip from github.com but (the program)
host, firefox and chromium can't.
Some system information
--
moke@rpi4-20201112
------------------
OS: Debian GNU/Linux bullseye/sid aarch64
Host: Raspberry Pi 400 Rev 1.0
Kernel: 5.10.0-5-arm64
Resolution: 1440x900, 1280x1024
WM: awesome
CPU: (4) @ 1.800GHz
Memory: 606MiB / 3791MiB
--
My Raspberry Pi 400 is connected over Ethernet to my home router.
Is there someone else, who experiences / has experienced this problem?
PS: After i reboot the system all domains get unlocked (until they get
locked again).
Kind Regards
Moritz Kempe
since i upgraded my Raspberry Pi 400 (with regular Debian 10, not
Raspberry PI OS) to the latest buster version, i am experiencing
problems with dns, which i cannot replicate with any of my other devices
(Debian Stretch amd64 workstation, Debian Buster amd64 server, Raspberry
Pi 3b armhf raspberrypi OS). But i can replicate this behavior with
another another micro sd flashcard with Twister OS on the (same)
Raspberry Pi 400. Twister OS is an Debian / Raspberry Pi OS based OS
which helps you to game on the Raspberry Pi 400.
I noticed the problem, while i was browsing the internet and got
confused because after a while some domains could not longer be
found/connected to by the browser. (On both, Firefox and Chromium)
-- Firefox
Hmm. We’re having trouble finding that site.
We can’t connect to the server at github.com.
If that address is correct, here are three other things you can try:
Try again later.
Check your network connection.
If you are connected but behind a firewall, check that Firefox has
permission to access the Web.
--
-- Chromium
This site can’t be reachedCheck if there is a typo in github.com.
DNS_PROBE_FINISHED_NXDOMAIN
--
And as time passes, more and more website will disappear.
Which means, that after a hour only barely visited domains are left.
And even stranger is the output of different dns tools:
-- host github.com
moke@rpi4-20201112:~$ host github.com
Host github.com not found: 2(SERVFAIL)
--
-- dig github.com
; <<>> DiG 9.16.13-Debian <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30900
;; 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: 343 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Tue Mar 30 23:31:01 CEST 2021
;; MSG SIZE rcvd: 55
--
Dig seems to be able to get the ip from github.com but (the program)
host, firefox and chromium can't.
Some system information
--
moke@rpi4-20201112
------------------
OS: Debian GNU/Linux bullseye/sid aarch64
Host: Raspberry Pi 400 Rev 1.0
Kernel: 5.10.0-5-arm64
Resolution: 1440x900, 1280x1024
WM: awesome
CPU: (4) @ 1.800GHz
Memory: 606MiB / 3791MiB
--
My Raspberry Pi 400 is connected over Ethernet to my home router.
Is there someone else, who experiences / has experienced this problem?
PS: After i reboot the system all domains get unlocked (until they get
locked again).
Kind Regards
Moritz Kempe
Nicholas Geovanis
Mar 30, 2021, 6:50:05 PM3/30/21
to
Never saw that before said the man on fire :-) So just guesses:
Some weird DNS TTL issue? Or TTL incompatibility?
Strange DNS local caching issue? Maybe check resolv.conf and name service config for new options or something.
Do you see any unexpected DHCP messages in the logs, maybe further upstream from the pi's?
Klaus Singvogel
Mar 31, 2021, 3:30:05 AM3/31/21
to
Moritz Kempe wrote:
[...]
I enabled on my DSL router: TLS for DNS, and, parallel, switched to
public, non-censored DNS servers, as suggested by a large German computer
magazine.
Those DNS servers were independent and respect more privacy, compared to
my ISP. But after a while I noticed, that those public DNS servers drop
requests and I saw your error messages at my side too, especially if there
were a lot of name resolutions in a short time period.
Those errors vanished after a while (several minutes) and everything
worked as expected. But then, when resolving again a lot of domain names,
the issues were back. Especially when I download from S3 Amazon, because
the IP address for s3.[...].amazon.com changes every 10 seconds or so.
Don't know, if both are related.
But my suggestion is to look at your DSL router: if you changed the
defaults for DNS, and, if so, switch back to original, default setting for
testing purpose.
Regards,
Klaus.
--
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D 1994-06-27
[...]
> I noticed the problem, while i was browsing the internet and got confused
> because after a while some domains could not longer be found/connected to by
> the browser. (On both, Firefox and Chromium)
I had similar issues, when I changed DNS configuration at my DSL router.
> because after a while some domains could not longer be found/connected to by
> the browser. (On both, Firefox and Chromium)
I enabled on my DSL router: TLS for DNS, and, parallel, switched to
public, non-censored DNS servers, as suggested by a large German computer
magazine.
Those DNS servers were independent and respect more privacy, compared to
my ISP. But after a while I noticed, that those public DNS servers drop
requests and I saw your error messages at my side too, especially if there
were a lot of name resolutions in a short time period.
Those errors vanished after a while (several minutes) and everything
worked as expected. But then, when resolving again a lot of domain names,
the issues were back. Especially when I download from S3 Amazon, because
the IP address for s3.[...].amazon.com changes every 10 seconds or so.
Don't know, if both are related.
But my suggestion is to look at your DSL router: if you changed the
defaults for DNS, and, if so, switch back to original, default setting for
testing purpose.
Regards,
Klaus.
--
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D 1994-06-27
Moritz Kempe
Mar 31, 2021, 5:00:05 AM3/31/21
to
Am 31.03.21 um 09:23 schrieb Klaus Singvogel:
server in my router but i haven't mentioned it because it, doesn't
seemed like there was any connection between these changes. On all other
devices this works just fine. And even when i change my dns server to
the default one, the raspberry pi still has these problems. (I tested
this before i wrote the first mail)
PC it works just fine.
I do experience these issues only on my raspberry pi 400, with both of
my operating systems.
> Those errors vanished after a while (several minutes) and everything
> worked as expected. But then, when resolving again a lot of domain names,
> the issues were back. Especially when I download from S3 Amazon, because
> the IP address for s3.[...].amazon.com changes every 10 seconds or so.
On my raspberry pi 400 they occurre and rarely fix themselves but the
majority of these stays up for all eternity (or up to an shutdown).
It don't feels, like you described, it is more like an blocklist which
is getting longer and longer (and forces me to use google when my
favorite search engines are blocked).
> Don't know, if both are related.
>
> But my suggestion is to look at your DSL router: if you changed the
> defaults for DNS, and, if so, switch back to original, default setting for
> testing purpose.
I switched my routers dns server back to the ISPs and also rebootet my
device.
But i wasn't able to get on github.com but at the same time i was able
to get on the by the (German) CUII (Clearingstelle Urheberrecht im
Internet) censored site s.to [0] which shouldn't be accessible because
of the censoring from my ISP.
This worked with both my browsers, firefox and chromium.
>
> Regards,
> Klaus.
[0] i do not encourage anyone to watch (illegal) content on s.to, i only
chose this domain to test if i am able to visit censored websites.
> Moritz Kempe wrote:
> [...]
>> I noticed the problem, while i was browsing the internet and got confused
>> because after a while some domains could not longer be found/connected to by
>> the browser. (On both, Firefox and Chromium)
> I had similar issues, when I changed DNS configuration at my DSL router.
>
> I enabled on my DSL router: TLS for DNS, and, parallel, switched to
> public, non-censored DNS servers, as suggested by a large German computer
> magazine.
I've done this too. I also activated dns over tls with a privacy dns
> [...]
>> I noticed the problem, while i was browsing the internet and got confused
>> because after a while some domains could not longer be found/connected to by
>> the browser. (On both, Firefox and Chromium)
> I had similar issues, when I changed DNS configuration at my DSL router.
>
> I enabled on my DSL router: TLS for DNS, and, parallel, switched to
> public, non-censored DNS servers, as suggested by a large German computer
> magazine.
server in my router but i haven't mentioned it because it, doesn't
seemed like there was any connection between these changes. On all other
devices this works just fine. And even when i change my dns server to
the default one, the raspberry pi still has these problems. (I tested
this before i wrote the first mail)
> Those DNS servers were independent and respect more privacy, compared to
> my ISP. But after a while I noticed, that those public DNS servers drop
> requests and I saw your error messages at my side too, especially if there
> were a lot of name resolutions in a short time period.
On my raspberry pi 400, this could be the case, but on my Debian Stretch
> my ISP. But after a while I noticed, that those public DNS servers drop
> requests and I saw your error messages at my side too, especially if there
> were a lot of name resolutions in a short time period.
PC it works just fine.
I do experience these issues only on my raspberry pi 400, with both of
my operating systems.
> Those errors vanished after a while (several minutes) and everything
> worked as expected. But then, when resolving again a lot of domain names,
> the issues were back. Especially when I download from S3 Amazon, because
> the IP address for s3.[...].amazon.com changes every 10 seconds or so.
majority of these stays up for all eternity (or up to an shutdown).
It don't feels, like you described, it is more like an blocklist which
is getting longer and longer (and forces me to use google when my
favorite search engines are blocked).
> Don't know, if both are related.
>
> But my suggestion is to look at your DSL router: if you changed the
> defaults for DNS, and, if so, switch back to original, default setting for
> testing purpose.
device.
But i wasn't able to get on github.com but at the same time i was able
to get on the by the (German) CUII (Clearingstelle Urheberrecht im
Internet) censored site s.to [0] which shouldn't be accessible because
of the censoring from my ISP.
This worked with both my browsers, firefox and chromium.
>
> Regards,
> Klaus.
[0] i do not encourage anyone to watch (illegal) content on s.to, i only
chose this domain to test if i am able to visit censored websites.
Moritz Kempe
Mar 31, 2021, 5:00:06 AM3/31/21
to
Greg Wooledge
Mar 31, 2021, 7:30:04 AM3/31/21
to
On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
> -- Firefox
> Hmm. We’re having trouble finding that site.
>
> We can’t connect to the server at github.com.
> -- Firefox
> Hmm. We’re having trouble finding that site.
>
> We can’t connect to the server at github.com.
> -- Chromium
> This site can’t be reachedCheck if there is a typo in github.com.
> DNS_PROBE_FINISHED_NXDOMAIN
grep ^hosts: /etc/nsswitch.conf
> This site can’t be reachedCheck if there is a typo in github.com.
> DNS_PROBE_FINISHED_NXDOMAIN
ls -ld /etc/resolv.conf
cat /etc/resolv.conf
dig @8.8.8.8 www.debian.org
Moritz Kempe
Mar 31, 2021, 7:50:06 AM3/31/21
to
On 3/31/21 1:25 PM, Greg Wooledge wrote:
> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
>> connect to the server at github.com.
>> -- Chromium This site can’t be reachedCheck if there is a typo in
>> github.com. DNS_PROBE_FINISHED_NXDOMAIN
>> moke@rpi4-20201112:~$ host github.com Host github.com not found:
>> 2(SERVFAIL)
> grep ^hosts: /etc/nsswitch.conf
--
> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
>> connect to the server at github.com.
>> -- Chromium This site can’t be reachedCheck if there is a typo in
>> github.com. DNS_PROBE_FINISHED_NXDOMAIN
>> moke@rpi4-20201112:~$ host github.com Host github.com not found:
>> 2(SERVFAIL)
> grep ^hosts: /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
--
> ls -ld /etc/resolv.conf
--
-rw-r--r-- 1 root root 54 Mar 31 13:28 /etc/resolv.conf
--
> cat /etc/resolv.conf
--
domain fritz.box
search fritz.box
nameserver 10.0.0.1
--
> dig @8.8.8.8 www.debian.org
--
; <<>> DiG 9.16.13-Debian <<>> @8.8.8.8 www.debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269
;; Got answer:
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.debian.org. IN A
;; ANSWER SECTION:
www.debian.org. 229 IN A 130.89.148.77
www.debian.org. 229 IN A 149.20.4.15
www.debian.org. 229 IN A 128.31.0.62
;; Query time: 35 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Mar 31 13:38:10 CEST 2021
;; MSG SIZE rcvd: 91
--
I hope i interpreted your mail in the right way.
Lee
Mar 31, 2021, 8:00:05 AM3/31/21
to
On 3/31/21, Moritz Kempe <deblist...@moke12g.de> wrote:
> On 3/31/21 1:25 PM, Greg Wooledge wrote:
>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
>>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
>>> connect to the server at github.com.
>>> -- Chromium This site can’t be reachedCheck if there is a typo in
>>> github.com. DNS_PROBE_FINISHED_NXDOMAIN
>>> moke@rpi4-20201112:~$ host github.com Host github.com not found:
>>> 2(SERVFAIL)
>> grep ^hosts: /etc/nsswitch.conf
> --
> hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
I don't trust multicast dns, so in addition to turning it off I've also got
> On 3/31/21 1:25 PM, Greg Wooledge wrote:
>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
>>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
>>> connect to the server at github.com.
>>> -- Chromium This site can’t be reachedCheck if there is a typo in
>>> github.com. DNS_PROBE_FINISHED_NXDOMAIN
>>> moke@rpi4-20201112:~$ host github.com Host github.com not found:
>>> 2(SERVFAIL)
>> grep ^hosts: /etc/nsswitch.conf
> --
> hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
$ grep host /etc/nsswitch.conf
# hosts: files mdns4_minimal [NOTFOUND=return] dns
hosts: files dns
Maybe worth a shot?
Regards,
Lee
Greg Wooledge
Mar 31, 2021, 8:50:04 AM3/31/21
to
On Wed, Mar 31, 2021 at 01:42:36PM +0200, Moritz Kempe wrote:
> > grep ^hosts: /etc/nsswitch.conf
> --
> hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
I don't know what "mymachines" is. I don't see it in the man page.
> > grep ^hosts: /etc/nsswitch.conf
> --
> hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
What happens if you get rid of the "mymachines" field?
> -rw-r--r-- 1 root root 54 Mar 31 13:28 /etc/resolv.conf
> domain fritz.box
> search fritz.box
> nameserver 10.0.0.1
You're using a local caching resolver, or at least something that
> search fritz.box
> nameserver 10.0.0.1
forwards requests. That's fine, if it works. You might try probing
the DNS resolver at 10.0.0.1 to see whether it actually does work.
(There's a really good chance that 10.0.0.1 is your router, and that
your router implements a forwarding nameserver, which just passes
your requests to your ISP. These router-based forwarding resolvers
can be a bit flaky sometimes.)
> ; <<>> DiG 9.16.13-Debian <<>> @8.8.8.8 www.debian.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.debian.org. IN A
>
> ;; ANSWER SECTION:
> www.debian.org. 229 IN A 130.89.148.77
> www.debian.org. 229 IN A 149.20.4.15
> www.debian.org. 229 IN A 128.31.0.62
>
> ;; Query time: 35 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Mar 31 13:38:10 CEST 2021
> ;; MSG SIZE rcvd: 91
that. If the weird entry in nsswitch.conf doesn't turn out to be the
problem, and 10.0.0.1 turns out to be non-functional in some way, you
could use Google's resolvers as a fallback.
Moritz Kempe
Mar 31, 2021, 9:10:05 AM3/31/21
to
On 3/31/21 1:55 PM, Lee wrote:
> On 3/31/21, Moritz Kempe <deblist...@moke12g.de> wrote:
>> On 3/31/21 1:25 PM, Greg Wooledge wrote:
>>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
>>>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
>>>> connect to the server at github.com.
>>>> -- Chromium This site can’t be reachedCheck if there is a typo in
>>>> github.com. DNS_PROBE_FINISHED_NXDOMAIN
>>>> moke@rpi4-20201112:~$ host github.com Host github.com not found:
>>>> 2(SERVFAIL)
>>> grep ^hosts: /etc/nsswitch.conf
>> --
>> hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
> I don't trust multicast dns, so in addition to turning it off I've also got
> $ grep host /etc/nsswitch.conf
> # hosts: files mdns4_minimal [NOTFOUND=return] dns
> hosts: files dns
>
> Maybe worth a shot?
Changed my /etc/nsswitch.conf to
> On 3/31/21, Moritz Kempe <deblist...@moke12g.de> wrote:
>> On 3/31/21 1:25 PM, Greg Wooledge wrote:
>>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
>>>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
>>>> connect to the server at github.com.
>>>> -- Chromium This site can’t be reachedCheck if there is a typo in
>>>> github.com. DNS_PROBE_FINISHED_NXDOMAIN
>>>> moke@rpi4-20201112:~$ host github.com Host github.com not found:
>>>> 2(SERVFAIL)
>>> grep ^hosts: /etc/nsswitch.conf
>> --
>> hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
> I don't trust multicast dns, so in addition to turning it off I've also got
> $ grep host /etc/nsswitch.conf
> # hosts: files mdns4_minimal [NOTFOUND=return] dns
> hosts: files dns
>
> Maybe worth a shot?
--
..
#hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
hosts: files dns
..
--
and rebooted the system. The behavior hasn't changed.
github.com is still blocked. And dig is still able to find the ip address.
Or do i have done something wrong?
I have found out, that i can restore some domains when running
"/sbin/dhclient" as root but not all. Github is still not accessible.
Note: I haven't changed any networking configuration on this device. I
haven't even enabled wifi.
Moritz Kempe
Mar 31, 2021, 9:30:05 AM3/31/21
to
On 3/31/21 2:44 PM, Greg Wooledge wrote:
> On Wed, Mar 31, 2021 at 01:42:36PM +0200, Moritz Kempe wrote:
>>> grep ^hosts: /etc/nsswitch.conf
>> --
>> hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
> I don't know what "mymachines" is. I don't see it in the man page.
>
> What happens if you get rid of the "mymachines" field?
I have restarted my device with "mymachines" commented out.
> On Wed, Mar 31, 2021 at 01:42:36PM +0200, Moritz Kempe wrote:
>>> grep ^hosts: /etc/nsswitch.conf
>> --
>> hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
> I don't know what "mymachines" is. I don't see it in the man page.
>
> What happens if you get rid of the "mymachines" field?
It seems like, it behaviors the same.
>> -rw-r--r-- 1 root root 54 Mar 31 13:28 /etc/resolv.conf
>> domain fritz.box
>> search fritz.box
>> nameserver 10.0.0.1
> You're using a local caching resolver, or at least something that
> forwards requests. That's fine, if it works. You might try probing
> the DNS resolver at 10.0.0.1 to see whether it actually does work.
--
moke@rpi4-20201112:~$ dig @10.0.0.1 debian.org
; <<>> DiG 9.16.13-Debian <<>> @10.0.0.1 debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13415
;; global options: +cmd
;; Got answer:
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;debian.org. IN A
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;; ANSWER SECTION:
debian.org. 300 IN A 149.20.4.15
debian.org. 300 IN A 130.89.148.77
debian.org. 300 IN A 128.31.0.62
;; Query time: 351 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Wed Mar 31 15:11:15 CEST 2021
;; MSG SIZE rcvd: 87
--
> (There's a really good chance that 10.0.0.1 is your router, and that
> your router implements a forwarding nameserver, which just passes
> your requests to your ISP. These router-based forwarding resolvers
> can be a bit flaky sometimes.)
>> ; <<>> DiG 9.16.13-Debian <<>> @8.8.8.8 www.debian.org
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 512
>> ;; QUESTION SECTION:
>> ;www.debian.org. IN A
>>
>> ;; ANSWER SECTION:
>> www.debian.org. 229 IN A 130.89.148.77
>> www.debian.org. 229 IN A 149.20.4.15
>> www.debian.org. 229 IN A 128.31.0.62
>>
>> ;; Query time: 35 msec
>> ;; SERVER: 8.8.8.8#53(8.8.8.8)
>> ;; WHEN: Wed Mar 31 13:38:10 CEST 2021
>> ;; MSG SIZE rcvd: 91
> That's good. At least you're not blocking UDP packets or something like
> that. If the weird entry in nsswitch.conf doesn't turn out to be the
> problem, and 10.0.0.1 turns out to be non-functional in some way, you
> could use Google's resolvers as a fallback.
Yes, i could add a fallback resolver to every device but the advantage
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 512
>> ;; QUESTION SECTION:
>> ;www.debian.org. IN A
>>
>> ;; ANSWER SECTION:
>> www.debian.org. 229 IN A 130.89.148.77
>> www.debian.org. 229 IN A 149.20.4.15
>> www.debian.org. 229 IN A 128.31.0.62
>>
>> ;; Query time: 35 msec
>> ;; SERVER: 8.8.8.8#53(8.8.8.8)
>> ;; WHEN: Wed Mar 31 13:38:10 CEST 2021
>> ;; MSG SIZE rcvd: 91
> That's good. At least you're not blocking UDP packets or something like
> that. If the weird entry in nsswitch.conf doesn't turn out to be the
> problem, and 10.0.0.1 turns out to be non-functional in some way, you
> could use Google's resolvers as a fallback.
of the router is, that you can set a dns server for a whole network
which is a feature i do not want to miss. Also is there still the
question, why Debian on the Raspberry Pi 400 can't use a dns server,
which can be used by all other devices.
Nicholas Geovanis
Mar 31, 2021, 9:30:05 AM3/31/21
to
That's why I suggested checking for DHCP messages in the logs. But also logs upstream from your pi's. Each time you get a DHCP grant, potentially you've switched DNS servers.
Moritz Kempe
Mar 31, 2021, 4:50:04 PM3/31/21
to
On 3/31/21 3:22 PM, Nicholas Geovanis wrote:
> On Wed, Mar 31, 2021, 8:08 AM Moritz Kempe <deblist...@moke12g.de
> <mailto:deblist%2Bde...@moke12g.de>> wrote:
>
> On 3/31/21 1:55 PM, Lee wrote:
> > On 3/31/21, Moritz Kempe <deblist...@moke12g.de
> On Wed, Mar 31, 2021, 8:08 AM Moritz Kempe <deblist...@moke12g.de
> <mailto:deblist%2Bde...@moke12g.de>> wrote:
>
> On 3/31/21 1:55 PM, Lee wrote:
> > On 3/31/21, Moritz Kempe <deblist...@moke12g.de
> <mailto:deblist%2Bde...@moke12g.de>> wrote:
> >> On 3/31/21 1:25 PM, Greg Wooledge wrote:
> >>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
> >>>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
> >>>> connect to the server at github.com <http://github.com>.
> >> On 3/31/21 1:25 PM, Greg Wooledge wrote:
> >>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
> >>>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
> >>>> -- Chromium This site can’t be reachedCheck if there is a typo in
> >>>> github.com <http://github.com>. DNS_PROBE_FINISHED_NXDOMAIN
> >>>> moke@rpi4-20201112:~$ host github.com <http://github.com>
> Host github.com <http://github.com> not found:
> >>>> 2(SERVFAIL)
> >>> grep ^hosts: /etc/nsswitch.conf
> >> --
> >> hosts: files mdns4_minimal [NOTFOUND=return] dns
> mymachines
> > I don't trust multicast dns, so in addition to turning it off
> I've also got
> > $ grep host /etc/nsswitch.conf
> > # hosts: files mdns4_minimal [NOTFOUND=return] dns
> > hosts: files dns
> >
> > Maybe worth a shot?
>
> Changed my /etc/nsswitch.conf to
>
> --
>
> ..
>
> #hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
> hosts: files dns
> ..
>
> --
>
> and rebooted the system. The behavior hasn't changed.
>
> github.com <http://github.com> is still blocked. And dig is still
> >>> grep ^hosts: /etc/nsswitch.conf
> >> --
> >> hosts: files mdns4_minimal [NOTFOUND=return] dns
> mymachines
> > I don't trust multicast dns, so in addition to turning it off
> I've also got
> > $ grep host /etc/nsswitch.conf
> > # hosts: files mdns4_minimal [NOTFOUND=return] dns
> > hosts: files dns
> >
> > Maybe worth a shot?
>
> Changed my /etc/nsswitch.conf to
>
> --
>
> ..
>
> #hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
> hosts: files dns
> ..
>
> --
>
> and rebooted the system. The behavior hasn't changed.
>
> able to find the ip address.
>
> Or do i have done something wrong?
>
>
> I have found out, that i can restore some domains when running
> "/sbin/dhclient" as root but not all. Github is still not accessible.
>
>
> That's why I suggested checking for DHCP messages in the logs. But
> also logs upstream from your pi's. Each time you get a DHCP grant,
> potentially you've switched DNS servers.
Do you mean the logs at /var/log/syslog?
>
> Or do i have done something wrong?
>
>
> I have found out, that i can restore some domains when running
> "/sbin/dhclient" as root but not all. Github is still not accessible.
>
>
> That's why I suggested checking for DHCP messages in the logs. But
> also logs upstream from your pi's. Each time you get a DHCP grant,
> potentially you've switched DNS servers.
And for what i look out for?
Here are some entries, maybe you see something important for this issue.
--
Mar 31 14:39:04 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to
255.255.255.255 port 67 interval 7
Mar 31 14:39:11 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to
255.255.255.255 port 67 interval 20
Mar 31 14:39:31 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to
255.255.255.255 port 67 interval 12
Mar 31 14:39:43 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to
255.255.255.255 port 67 interval 19
Mar 31 14:40:02 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to
255.255.255.255 port 67 interval 3
Mar 31 14:40:05 rpi4-20201112 dhclient[5538]: No DHCPOFFERS received.
Mar 31 14:40:05 rpi4-20201112 dhclient[5538]: No working leases in
persistent database - sleeping.
-- This was logged for many times.
--
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Internet Systems Consortium
DHCP Client 4.4.1
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Copyright 2004-2018
Internet Systems Consortium.
Mar 31 15:05:49 rpi4-20201112 ifup[478]: For info, please visit
https://www.isc.org/software/dhcp/
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: All rights reserved.
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: For info, please visit
https://www.isc.org/software/dhcp/
Mar 31 15:05:49 rpi4-20201112 dhclient[478]:
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Listening on
LPF/eth0/##:##:##:##:##:## # censored by me
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Sending on
LPF/eth0/##:##:##:##:##:## # censored by me
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Sending on Socket/fallback
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 8
Mar 31 15:05:50 rpi4-20201112 NetworkManager[417]: <info>
[1617195950.2281] dhcp-init: Using DHCP client 'internal'
Mar 31 15:05:57 rpi4-20201112 dhclient[478]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 14
Mar 31 15:05:58 rpi4-20201112 dhclient[478]: DHCPOFFER of 10.0.0.70 from
10.0.0.1
Mar 31 15:05:58 rpi4-20201112 dhclient[478]: DHCPREQUEST for 10.0.0.70
on eth0 to 255.255.255.255 port 67
Mar 31 15:05:58 rpi4-20201112 dhclient[478]: DHCPACK of 10.0.0.70 from
10.0.0.1
Mar 31 15:06:38 rpi4-20201112 dhclient[478]: bound to 10.0.0.70 --
renewal in 3831703 seconds.
--
I used the command "cat /var/log/syslog | grep dhc"
And you said
> But also logs upstream from your pi's.
i haven't found one yet.
Or do you mean that i should use Wireshark to analyze my DHCP requests?
I haven't looked into networking on that level.
I would be nice, if you would give me an explanation or link a website
which could do that.
Moritz Kempe
Mar 31, 2021, 5:30:05 PM3/31/21
to
Up until now i used my AVM Fritz!Box (my router) with the (supported)
firmware version FRITZ!OS-Version 07.21.
Just now, i upgraded the firmware to FRITZ!OS-Version 07.25 and the DNS
is now working on my Raspberry Pi 400.
I cannot yet say, if my problem is solved but it seems like it. I will
reply to this mail if the problem will reoccur.
Here is an changelog
https://en.avm.de/fritz-lab/fresh-from-development/updates-improvements/
> *Improved *- Update process more robust for potential DNS problems
Or here in the German changelog
https://avm.de/service/downloads/update-news/download/show/eyJkaXNwbGF5IjoiRlJJVFohQm94IDc1OTAiLCJ1cmwiOiJodHRwOlwvXC9kb3dubG9hZC5hdm0uZGVcL2ZyaXR6Ym94XC9mcml0emJveC03NTkwXC9kZXV0c2NobGFuZFwvZnJpdHoub3NcL2luZm9fZGUudHh0IiwiaGFzaCI6IjNiYmQ1ZTI5YTg4N2NjM2U3ZjRhZTRhOTY4YjE3OTNmYTA2MWU1NzA1Y2NkYjZlYjA2ODM2NWYwNjEzYWMzZjcifQ%3D%3D/
*Behoben* IPv6: Im IPv6 Router Advertisement (RA) mit Option 25
(Recursive DNS Server) wurden zum Teil Bits des Feldes "Reserved" gesetzt
[EN] Fixed: IPv6 Router Advertisement (RA) with Option 25 (Recursive DNS
Server) got manipulated bits at the field "Reserved"
*Behoben* DNS-Anfragen des Typs "PTR" wurden teilweise nicht korrekt
aufgelöst
[EN] Fixed: DNS Querries with Type "PTR" wouldn't get resolved right.
Could on of this changes be the cause of my problems, or the problems
other people are also getting?
firmware version FRITZ!OS-Version 07.21.
Just now, i upgraded the firmware to FRITZ!OS-Version 07.25 and the DNS
is now working on my Raspberry Pi 400.
I cannot yet say, if my problem is solved but it seems like it. I will
reply to this mail if the problem will reoccur.
Here is an changelog
https://en.avm.de/fritz-lab/fresh-from-development/updates-improvements/
> *Improved *- Update process more robust for potential DNS problems
Or here in the German changelog
https://avm.de/service/downloads/update-news/download/show/eyJkaXNwbGF5IjoiRlJJVFohQm94IDc1OTAiLCJ1cmwiOiJodHRwOlwvXC9kb3dubG9hZC5hdm0uZGVcL2ZyaXR6Ym94XC9mcml0emJveC03NTkwXC9kZXV0c2NobGFuZFwvZnJpdHoub3NcL2luZm9fZGUudHh0IiwiaGFzaCI6IjNiYmQ1ZTI5YTg4N2NjM2U3ZjRhZTRhOTY4YjE3OTNmYTA2MWU1NzA1Y2NkYjZlYjA2ODM2NWYwNjEzYWMzZjcifQ%3D%3D/
*Behoben* IPv6: Im IPv6 Router Advertisement (RA) mit Option 25
(Recursive DNS Server) wurden zum Teil Bits des Feldes "Reserved" gesetzt
[EN] Fixed: IPv6 Router Advertisement (RA) with Option 25 (Recursive DNS
Server) got manipulated bits at the field "Reserved"
*Behoben* DNS-Anfragen des Typs "PTR" wurden teilweise nicht korrekt
aufgelöst
[EN] Fixed: DNS Querries with Type "PTR" wouldn't get resolved right.
Could on of this changes be the cause of my problems, or the problems
other people are also getting?
Nicholas Geovanis
Mar 31, 2021, 8:30:05 PM3/31/21
to
On Wed, Mar 31, 2021, 4:26 PM Moritz Kempe <deblist...@moke12g.de> wrote:
Up until now i used my AVM Fritz!Box (my router) with the (supported)
firmware version FRITZ!OS-Version 07.21.
Just now, i upgraded the firmware to FRITZ!OS-Version 07.25 and the DNS
is now working on my Raspberry Pi 400.
I cannot yet say, if my problem is solved but it seems like it. I will
reply to this mail if the problem will reoccur
Wow, you're fast :-)
I feared you would find exactly those long DHCP discover sequences that you noticed. I was just going back to see if the server that granted you was at the address you were expecting.
Gruß Gott
0 new messages