Can Someone Please Ping

[ejolson]

It doesn't sound like there is anything wrong with your Pi. It is the router itself that is acting very strange.

Until I get that sorted I won't know if re-enabling avahi helped or not. Before resetting the router the resolv.conf was correct.

Avahi will have no effect on resolv.conf. You still had your Pi connected to the network which meant they picked up the new DNS address from DHCP.

Did you restart the router before you did the factory reset? If you hadn't then the restart as part of the factory reset is likely to be what has fixed the problem for you.

Yes, I tried a reboot of the router before the factory reset but the problem persists.

I agree it appears to be the router's problem but now I have both the Pi4's back to correct ips, nameservers, avahi running etc I am trying to figure out why my PC chooses MDNS for names without decimal points whereas the Pis go for DNS. If the Pi's did an MDNS request then I'd be able to address them by name again.

Why are names without decimal points are treated differently to names with, if they should be treated differently then the Pi's aren't behaving properly, if they shouldn't be treated differently then the the PC is not behaving properly.

On Linux you used to be able to change the order in which the different name services are tried using nsswitch.conf in the /etc directory. If you are running systemd in full borg mode this may have changed, but Raspberry Pi OS still uses nsswitch.conf as far as I know. There is probably a similar configuration in the Windows registry, but I don't know how to find it. It seems you have uncovered something strange about your router. I wonder how widespread the problem is and how deep it really goes.

[epoch1970]

I am trying to figure out why my PC chooses MDNS for names without decimal points whereas the Pis go for DNS. If the Pi's did an MDNS request then I'd be able to address them by name again.

It certainly does perform an mDNS request, which fails (esp. if you disable multicast...) and then DNS is tried.
When presented with a "dotless" name, the resolver will append what's specified by keywords "domain" or "search" in /etc/resolv.conf, and start querying. But it doesn't stop there, and it also queries available servers for the name alone.
Looks a bit dubious to me but I suppose the rationale is that the query is received by a local DNS server/cache, which will do the right thing. Note that systemd-resolved by default would not forward names without any domain part. There is an option to revert to forwarding...

Anyways, on raspios, if you want to avoid sending a query to DNS servers for a non existing host/domain "foobar", the following works for me.

First the situation before the fix

Code: Select all

root@pi:~# cat /etc/resolv.conf
# Generated by resolvconf
domain dyn.domain
search domain dyn.domain
nameserver 172.17.0.2

root@pi:~# tcpdump -n -i any udp port 53 &
root@pi:~# getent hosts foobar
18:36:29.639703 IP 172.17.255.230.52816 > 172.17.0.2.53: 13279+ AAAA? foobar.domain. (31)
18:36:29.641083 IP 172.17.0.2.53 > 172.17.255.230.52816: 13279 NXDomain* 0/1/0 (95)
18:36:29.641360 IP 172.17.255.230.58432 > 172.17.0.2.53: 58325+ AAAA? foobar.dyn.domain. (35)
18:36:29.641727 IP 172.17.0.2.53 > 172.17.255.230.58432: 58325 NXDomain 0/0/0 (35)
18:36:29.641898 IP 172.17.255.230.39363 > 172.17.0.2.53: 7382+ AAAA? foobar. (24)
18:36:29.642266 IP 172.17.0.2.53 > 172.17.255.230.39363: 7382 0/0/0 (24)

See the third query for "foobar." as a top-level domain name?

So,

Code: Select all

root@pi:~# man resolv.conf
root@pi:~# man resolvconf.conf
root@pi:~# nano /etc/resolvconf.conf

Added to the end of the file:

Code: Select all

# No DNS query for names without domain
resolv_conf_options=no-tld-query

and rebooted.

Same test, with option no-tld-query now present in resolv.conf:

Code: Select all

root@pi:~# cat /etc/resolv.conf
# Generated by resolvconf
domain dyn.domain
search domain dyn.domain
nameserver 172.17.0.2
options no-tld-query

root@pi:~# tcpdump -n -i any udp port 53 &
root@pi:~# getent hosts foobar
18:56:01.749397 IP 172.17.255.230.58238 > 172.17.0.2.53: 38623+ AAAA? foobar.domain. (31)
18:56:01.750974 IP 172.17.0.2.53 > 172.17.255.230.58238: 38623 NXDomain* 0/1/0 (95)
18:56:01.751257 IP 172.17.255.230.37884 > 172.17.0.2.53: 10183+ AAAA? foobar.dyn.domain. (35)
18:56:01.751618 IP 172.17.0.2.53 > 172.17.255.230.37884: 10183 NXDomain 0/0/0 (35)

2 domains specified by option search, 2 queries. All good now.

[pidd]

It certainly does perform an mDNS request, which fails (esp. if you disable multicast...) and then DNS is tried.

That could be part of the problem, neither Pi is putting out an MDNS request, I've checked on wireshark. This is probably my fault for disabling avahi in the past, I have some multicast devices on the network and I don't want the Pi's interacting with them.

[pidd]

Now confirmed that router received an update which had a bug in dealing with tld domain names. However there are other issues as to why the Pi isn't using MDNS which is the problem that exposed the router bug.

If someone could post a copy of their standard /etc/avahi/avahi-daemon.conf it would be greatly appreciated, these days by the time I've read the second paragraph of documentation I've usually forgotten the first, or even what I was trying to achieve in the first place.

[DougieLawson]

Code: Select all

root@ulysses:~ # cd /etc
root@ulysses:/etc # cat avahi/avahi-daemon.conf
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

# See avahi-daemon.conf(5) for more information on this configuration
# file!

[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000

[wide-area]
enable-wide-area=yes

[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no

[reflector]
#enable-reflector=no
#reflect-ipv=no

[rlimits]
#rlimit-as=
#rlimit-core=0
#rlimit-data=8388608
#rlimit-fsize=0
#rlimit-nofile=768
#rlimit-stack=8388608
#rlimit-nproc=3
root@ulysses:/etc #

[pidd]

Code: Select all

root@ulysses:~ # cd /etc
root@ulysses:/etc # cat avahi/avahi-daemon.conf
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

# See avahi-daemon.conf(5) for more information on this configuration
# file!

[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000

[wide-area]
enable-wide-area=yes

[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no

[reflector]
#enable-reflector=no
#reflect-ipv=no

[rlimits]
#rlimit-as=
#rlimit-core=0
#rlimit-data=8388608
#rlimit-fsize=0
#rlimit-nofile=768
#rlimit-stack=8388608
#rlimit-nproc=3
root@ulysses:/etc #

Thanks very much Dougie

I've also managed confirm that talktalk's DNS servers (79.79.79.79 and 79.79.79.80) send all unknown tlds and subdomains of unknown tlds to the rogue Serbian IP. Two of talktalks mods have tried to hush me down, I guess I should be talking to Ofcom and/or the ICO instead

[trejan]

I've also managed confirm that talktalk's DNS servers (79.79.79.79 and 79.79.79.80) send all unknown tlds and subdomains of unknown tlds to the rogue Serbian IP. Two of talktalks mods have tried to hush me down, I guess I should be talking to Ofcom and/or the ICO instead

Either you've made a typo or somebody at TalkTalk has misconfigured it as the catch-all IP for non-existent domains on TalkTalk should be 92.242.132.16. The Serbian IP is completely innocent and not malicious. 92.242.132.16 is owned by Barefruit who are "Generating highly targeted traffic by replacing DNS and HTTP errors with relevant advertising" i.e. they're serving you ads and paying TalkTalk. I did mention this was a possibility in my first reply in this thread.

Complaining to the ICO is unlikely to get you anywhere. TalkTalk and other ISPs have been doing this for years now as evident by https://manurevah.com/blah/en/blog/DNS- ... and-Others

Bypass this stupid system by changing your router to not use the TalkTalk DNS servers and use quad9 or Google Public DNS.

[pidd]

Either you've made a typo or somebody at TalkTalk has misconfigured it as the catch-all IP for non-existent domains on TalkTalk should be 92.242.132.16. The Serbian IP is completely innocent and not malicious. 92.242.132.16 is owned by Barefruit who are "Generating highly targeted traffic by replacing DNS and HTTP errors with relevant advertising" i.e. they're serving you ads and paying TalkTalk. I did mention this was a possibility in my first reply in this thread.

Complaining to the ICO is unlikely to get you anywhere. TalkTalk and other ISPs have been doing this for years now as evident by https://manurevah.com/blah/en/blog/DNS- ... and-Others

Bypass this stupid system by changing your router to not use the TalkTalk DNS servers and use quad9 or Google Public DNS.

I normally use OpenDNS but in one of the talktalk routers (DG8041W) I can't find where to set the default routers and I don't have control over the all the devices that use that router - there are three internet connections here. It looks like I forgot to set the Pi's dns servers amongst all the playing around constructive exercises I've been doing

92.242.132.16 doesn't serve anything, talktalk routing now says it cannot be found . Perhaps they have stopped using this because it was possibly in breach of GDPR?

The talktalk DNS servers don't go to this address if the tld is known eg ibetthisdoesntexistzz.uk returns unknown but ibetthisdoesntexistzz.gggg returns 92.242.132.16

[trejan]

I normally use OpenDNS but in one of the talktalk routers (DG8041W) I can't find where to set the default routers and I don't have control over the all the devices that use that router - there are three internet connections here. It looks like I forgot to set the Pi's dns servers amongst all the playing around constructive exercises I've been doing

Some routers won't let you configure DNS as the ISP has locked it down to prevent tinkering. You have to use the ISP supplied settings. If you have one of these routers and want to use a custom DNS then your options are to replace the router, manually configure all your devices or see if you can disable DHCP on the router so you can run your own server.

92.242.132.16 doesn't serve anything, talktalk routing now says it cannot be found . Perhaps they have stopped using this because it was possibly in breach of GDPR?

No. It is still active. It serves a tiny redirection page via HTTP which points you towards error.talktalk.co.uk along with a whole load of data encoded into the URI. Barefruit has been used for years now by all the major UK ISPs such as BT, Virgin and TalkTalk so it isn't new. You get untargeted ads based on the typoed URL but presumably they're not storing any personal data so there is no GDPR violation.

Anyway, this is working as intended even if it is awful. Your router and Pi hasn't been hacked. You can go to https://www.talktalk.co.uk/optout/ or chat/call TalkTalk to opt-out your account. Apparently the web page to opt-out doesn't always work. The opt-out method listed on Barefruit's site is to use an alternate DNS.

[pidd]

I normally use OpenDNS but in one of the talktalk routers (DG8041W) I can't find where to set the default routers and I don't have control over the all the devices that use that router - there are three internet connections here. It looks like I forgot to set the Pi's dns servers amongst all the playing around constructive exercises I've been doing

Some routers won't let you configure DNS as the ISP has locked it down to prevent tinkering. You have to use the ISP supplied settings. If you have one of these routers and want to use a custom DNS then your options are to replace the router, manually configure all your devices or see if you can disable DHCP on the router so you can run your own server.

92.242.132.16 doesn't serve anything, talktalk routing now says it cannot be found . Perhaps they have stopped using this because it was possibly in breach of GDPR?

No. It is still active. It serves a tiny redirection page via HTTP which points you towards error.talktalk.co.uk along with a whole load of data encoded into the URI. Barefruit has been used for years now by all the major UK ISPs such as BT, Virgin and TalkTalk so it isn't new. You get untargeted ads based on the typoed URL but presumably they're not storing any personal data so there is no GDPR violation.

Anyway, this is working as intended even if it is awful. Your router and Pi hasn't been hacked. You can go to https://www.talktalk.co.uk/optout/ or chat/call TalkTalk to opt-out your account. Apparently the web page to opt-out doesn't always work. The opt-out method listed on Barefruit's site is to use an alternate DNS.

Ok, thank you for all that info, its good to have an awareness of the games being played. I see the ads now, they've been there so long that I overlooked them as background noise - its amazing how you auto-filter without realising.

There is still a bug in the FAST5364 router's latest firmware in that it's DNS doesn't serve local tld domain names of its statics - it took me a while to realise there were two things going on, not just one.

[pidd]

To put the final details on this.

The IP is in Northern Ireland not Serbia and is barefruit's who provide advertising to talktalk, the morality of the way this is done is off-topic for this forum.

Talktalk and Sagemcom have intentionally removed DHCP from the DNS server in the router to fix other issues and claim very few people use it -which may be true. Most people have mDNS running. The legality and morality of letting LAN traffic onto the WAN again is off-topic for this forum.

I'm left with a number of options:-

• Add a DNS server to my existing Pi4 server and use that for DNS
• Live with having to type in "mydesktop.local" though I'm sure I should be able to use "mydomain" by itself with some config somewhere
• Stick to using the static IPs, which I do most of the time anyway but I may be putting more devices on the lan and my brain will burst at some point
• Getting another modem-router but I can't justify the cost of a VSDL dual-band gigabit router

I'd like to do option 1, upgrade my net server to DNS server but I'd need a solid backup/restore system in place which so far I haven't felt comfortable with - I've seen loads of backup systems prove near enough worthless when it comes to a forced restore. But that is for another thread which I'll probably raise tomorrow.

[trejan]

Talktalk and Sagemcom have intentionally removed DHCP from the DNS server in the router to fix other issues and claim very few people use it -which may be true.

RFC2136 dynamic DNS update is a security vulnerability as it allows zone poisoning.

The legality and morality of letting LAN traffic onto the WAN again is off-topic for this forum.

The DNS they're talking about is the local DNS resolver inside the router. You're not registering to a server out on the internet.

[pidd]

Talktalk and Sagemcom have intentionally removed DHCP from the DNS server in the router to fix other issues and claim very few people use it -which may be true.

RFC2136 dynamic DNS update is a security vulnerability as it allows zone poisoning.

The legality and morality of letting LAN traffic onto the WAN again is off-topic for this forum.

The DNS they're talking about is the local DNS resolver inside the router. You're not registering to a server out on the internet.

If I enter a legitimate LAN TLD hostname, the router returns a fixed WAN IP which is where the traffic will be sent. Before their intentional change it would serve the correct LAN IP.

[trejan]

If I enter a legitimate LAN TLD hostname, the router returns a fixed WAN IP which is where the traffic will be sent. Before their intentional change it would serve the correct LAN IP.

Ah right. I thought you meant the DNS dynamic update feature. Redirecting all lookups out to an ad server is awful and TalkTalk need to get it fixed ASAP. Did none of the opt-out methods work?

[pidd]

If I enter a legitimate LAN TLD hostname, the router returns a fixed WAN IP which is where the traffic will be sent. Before their intentional change it would serve the correct LAN IP.

Ah right. I thought you meant the DNS dynamic update feature. Redirecting all lookups out to an ad server is awful and TalkTalk need to get it fixed ASAP. Did none of the opt-out methods work?

blast, I forgot you posted about the optout, sorry, mixture of poor memory and finding other bugs in the router software. Its so annoying because the router hardware performs excellently as far as I'm concerned and it doesn't keep falling off my desk like previous routers (bonus!).

I'll try optout now .... if I don't get distracted and forget again

[ejolson]

I'd like to do option 1, upgrade my net server to DNS server but I'd need a solid backup/restore system in place which so far I haven't felt comfortable with

Setting up a DNS server on a Pi is as simple as apt-get, so there really isn't much that needs backing up. The main difficulty is making sure the Pi has the correct time before starting the server and stays synchronised after that.

This is a bit of a chicken and egg problem as you may need to make a DNS querry to resolve the name of the ntp server but then need the correct time in order to start bind to resolve the names. As usual, systemd seemed to make a mess of this, so it may be necessary to add a few lines to rc.local to make it work.

[pidd]

Clicked the talktalk optout, talktalk page said the service has been updated to opt-out the alternative error handling service and the router needs to be rebooted.

rebooted .... and it still redirects unknown DNS to barefruit IP, was I surprised? Not really!

Whatever, I'll change default DNS back to Opendns for the moment, I think Opendns was a bit hesitant one day so I temporarily changed it back to router ..... and forgot to change it back.

Setting up a DNS server on a Pi is as simple as apt-get so there really isn't much that needs backing up. The main difficulty is making sure the Pi has the correct time before starting the server and stays synchronised after that.

This is a bit of a chicken and egg problem as you need to make a DNS querry to resolve the name of the ntp server but then need the correct time in order to start bind to resolve names. As usual, systemd seemed to make a mess of this, so I added a few obvious lines to rc.local to make it work.

I've been thinking of the merits of putting a RTC on my server Pi, as it looks like its going to be taking a more central role.

Can't NTP run off an IP rather than a hostname?

[ejolson]

Clicked the talktalk optout, talktalk page said the service has been updated to opt-out the alternative error handling service and the router needs to be rebooted.

rebooted .... and it still redirects unknown DNS to barefruit IP, was I surprised? Not really!

Whatever, I'll change default DNS back to Opendns for the moment, I think Opendns was a bit hesitant one day so I temporarily changed it back to router ..... and forgot to change it back.

Setting up a DNS server on a Pi is as simple as apt-get so there really isn't much that needs backing up. The main difficulty is making sure the Pi has the correct time before starting the server and stays synchronised after that.

This is a bit of a chicken and egg problem as you need to make a DNS querry to resolve the name of the ntp server but then need the correct time in order to start bind to resolve names. As usual, systemd seemed to make a mess of this, so I added a few obvious lines to rc.local to make it work.

I've been thinking of the merits of putting a RTC on my server Pi, as it looks like its going to be taking a more central role.

Can't NTP run off an IP rather than a hostname?

Yes, using an IP number is possible.

I think ntp usually contacts some sort of server pool. It's been a while since I set things up but distinctly remember there being trouble with DNS because the time was wrong and the time being wrong because there was trouble with DNS.

[DougieLawson]

Can't NTP run off an IP rather than a hostname?

Of course it can run off an IP address. If you give it a name the first thing ntpd will do is a gethostbyname() call to get the IP address.

[bls]

I'd like to do option 1, upgrade my net server to DNS server but I'd need a solid backup/restore system in place which so far I haven't felt comfortable with

Setting up a DNS server on a Pi is as simple as apt-get, so there really isn't much that needs backing up. The main difficulty is making sure the Pi has the correct time before starting the server and stays synchronised after that.

This is a bit of a chicken and egg problem as you may need to make a DNS querry to resolve the name of the ntp server but then need the correct time in order to start bind to resolve the names. As usual, systemd seemed to make a mess of this, so it may be necessary to add a few lines to rc.local to make it work.

There are tools to help configure and manage DNS and DHCP servers so that there's very little to back up. My tool keeps everything in a single json file, and creates the DHCP/DNS config files as you want. There are others, obviously you'll need to evaluate backup requirements in addition to whatever other requirements you have.

As far as a time server, I run chronyd on the same system as DNS/DHCP, and all the systems on my LAN are quite happy to get their time from it using an IP address. In fact, all my systems get their IP address from DHCP (where I've statically set them in the config file), and they also get the time server address, along with the DNS address. Quite elegant, if I do say so myself