Default content of hosts files

[Valiceemo]

I have a device on my network, a Philips soundbar, that is making an obscene amount of PTR requests
Approx. 1 request every 3 seconds...20/21 requests per minute

Jul 20 13:27:49 dnsmasq[23400]: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
Jul 20 13:27:49 dnsmasq[23400]: /etc/pihole/custom.list 192.168.0.1 is skyqhub.lan
Jul 20 13:27:52 dnsmasq[23400]: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
Jul 20 13:27:52 dnsmasq[23400]: /etc/pihole/custom.list 192.168.0.1 is skyqhub.lan
Jul 20 13:27:55 dnsmasq[23400]: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
Jul 20 13:27:55 dnsmasq[23400]: /etc/pihole/custom.list 192.168.0.1 is skyqhub.lan

No amount of searching is leading me to any solutions or even reasons why.
So i am started to clutch at straws a little.
Factory resetting the soundbar does not help.
Contacting Philips customer support is fruitless, they're about as useful as a chocolate teapot.

So doing a bit of digging about, i want to make sure I haven't changed anything in my pihole setup that may cause this.
As i understand, the PTR request is the soundbar asking for the name of the client at 192.168.0.1, which is my ISP provided router.

The main question here, is are the contents of my hosts files correct?
I cannot remember if I have modified them at some point, or why I would...but its possible I over tinkered
Im looking specifically at the 127.0.1.1 pihole and 127.0.0.1 localhost entry in /etc/hosts
should this be 127.0.0.1 pihole
Is there any conflict here?

IPV6 is disabled, so i do not know why there are IPV6 lines here

pi@pihole:~ $ cat /etc/hostname
pihole

pi@pihole:~ $ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       pihole

pi@pihole:~ $ cat /etc/pihole/custom.list
192.168.0.1 skyqhub
192.168.0.2 skqqextender

[jfb]

@Valiceemo

are the contents of my hosts files correct?

Yes. The hosts file is correct.

And, Pi-hole is correctly answering the PTR with the name of the client.

@Valiceemo

IPV6 is disabled, so i do not know why there are IPV6 lines here

The OS installs them. Leave them in place.

For comparison, here is the beginning of the hosts file on one of my Pi's running Raspbian Bullseye:

cat /etc/hosts
127.0.0.1	localhost
::1		localhost ip6-localhost ip6-loopback
ff02::1		ip6-allnodes
ff02::2		ip6-allrouters

127.0.1.1	Pi-Dev-3B

And on Armbian Buster:

cat /etc/hosts
127.0.0.1   localhost nanopi-neo
::1         localhost nanopi ip6-localhost ip6-loopback
fe00::0     ip6-localnet
ff00::0     ip6-mcastprefix
ff02::1     ip6-allnodes
ff02::2     ip6-allrouters

127.0.1.1	NanoPi

[Valiceemo]

Thank for checking. That has put me at ease a little...at least I know I have accidently screwed something up

I totally agree that Pi-hole is doing what it should, I was just hoping there was something I had missed, that would explain why a device might be doing this.

[deHakkelaar]

@Valiceemo

I have a device on my network, a Philips soundbar, that is making an obscene amount of PTR requests

@Valiceemo

pi@pihole:~ $ cat /etc/pihole/custom.list
192.168.0.1 skyqhub

Try up the TTL for local records to 60 seconds instead of the default 0:

Queries for local DNS records exploding

I'm puzzled that didn't hit you earlier, as that should have been the case since Pi-hole FTL v5.10.1, Web v5.7 and Core v5.5 released from September 2021 (emphasis mine):

[Valiceemo]

hmm, thats interesting, i hadnt noticed this was a new option, thanks!

What impact would this have?
I guess it should reduce the PTR request frequency right?
Any ideas why a device would do this?

[deHakkelaar]

@Valiceemo

What impact would this have?

If the device honers the TTL, it should fetch the DNS/PTR record from local cache for the TTL duration instead of querying Pi-hole.

@Valiceemo

I guess it should reduce the PTR request frequency right?

It might.

@Valiceemo

Any ideas why a device would do this?

Thats the way TTL works and it being zero default OOTB for local DNS records.

[Valiceemo]

Thanks

I have changed the TTL time, and confirmed with dig that it is 60 secs.
Unfortunately, I still see the same level of PTR lookups

What would the advised setting be in the DNS section
My upstream is Unbound btw (127.0.0.1#5335)

In terns of advanced DNS settings...
Never forward non-FQDN is ticked
Never forward reverse lookups is ticked
Conditional forwarding = disabled

I have 2 DNS records set via the GUI:
skyqhub = 192.168.0.1
skyqextender = 192.168.0.2

[deHakkelaar]

@Valiceemo

I have changed the TTL time, and confirmed with dig that it is 60 secs.
Unfortunately, I still see the same level of PTR lookups

Am not sure what dig command you did run but,
if its the 1.0.168.192.in-addr.arpa queries that are excessive,
also check for this one if the TTL is 60 seconds now with below:

dig +noall +answer @localhost ptr 1.0.168.192.in-addr.arpa

If that all looks dandy, I have no idea why the soundbar is making that many reverse lookup(PTR) queries.
Best to contact Philips support for that.

@Valiceemo

My upstream is Unbound btw (127.0.0.1#5335)

In terns of advanced DNS settings...
Never forward non-FQDN is ticked
Never forward reverse lookups is ticked
Conditional forwarding = disabled

I have exactly the same settings while Pi-hole also does DHCP services for my LAN instead of the router.

[Valiceemo]

@deHakkelaar

Am not sure what dig command you did run but,
if its the 1.0.168.192.in-addr.arpa queries that are excessive,
also check for this one if the TTL is 60 seconds now with below:

dig +noall +answer @localhost ptr 1.0.168.192.in-addr.arpa

I have just tried running this dig command and it returns nothing at all:

pi@pihole:~ $ dig +noall +answer @localhost ptr 1.0.168.192.in-addr.arpa
pi@pihole:~ $

if i run with no flags or options:

pi@pihole:~ $ dig 1.0.168.192.in-addr.arpa                             
; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> 1.0.168.192.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64700
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;1.0.168.192.in-addr.arpa.      IN      A

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   10800   IN      SOA     localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 22 08:35:07 BST 2022
;; MSG SIZE  rcvd: 112

If I enable conditional forwarding:

pi@pihole:~ $ dig +noall +answer @localhost ptr 1.0.168.192.in-addr.arpa
;; Warning: Message parser reports malformed message packet.

[deHakkelaar]

That is odd.
And what if you live tail the logs first:

pihole -t

And do the query again in another SSH session (EDIT: ow plus a dot "." at the end this time just to be sure):

dig +noall +answer @localhost ptr 1.0.168.192.in-addr.arpa.

Does the query appear in the logs like you've posted previously:

@Valiceemo

Jul 20 13:27:49 dnsmasq[23400]: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
Jul 20 13:27:49 dnsmasq[23400]: /etc/pihole/custom.list 192.168.0.1 is skyqhub.lan

Ps to make things easier, you could also substitute above dig with below:

dig +noall +answer @localhost -x 192.168.0.1

[Valiceemo]

Its a little hard to catch it in the logs as it is flooded by the constant requests, but running the shortened dig command, it returns nothing in the terminal.

Looking at the tailed pihole log, I see:

09:54:48: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
09:54:48: config 192.168.0.1 is NXDOMAIN
09:54:50: query[PTR] 1.0.168.192.in-addr.arpa from ::1
09:54:50: config 192.168.0.1 is NXDOMAIN
09:54:51: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
09:54:51: config 192.168.0.1 is NXDOMAIN
09:54:54: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
09:54:54: config 192.168.0.1 is NXDOMAIN

I think it was the second query in the snippet at 09:54:50

[Bucking_Horn]

@Valiceemo

Jul 20 13:27:49 dnsmasq[23400]: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
Jul 20 13:27:49 dnsmasq[23400]: /etc/pihole/custom.list 192.168.0.1 is skyqhub.lan

@Valiceemo

09:54:48: query[PTR] 1.0.168.192.in-addr.arpa from 192.168.0.213
09:54:48: config 192.168.0.1 is NXDOMAIN

The answer your Pi-hole provided has changed since you've started the topic, suggesting that you've changed yor configuration.
It doesn't seem to matter much though, since your misbehaving device would issue those PTR requests regardless of the actual answer (be it an IP address or NXDOMAIN).

In any case, this is moving away from your original question.

@Valiceemo

The main question here, is are the contents of my hosts files correct?

That has been answered:

@jfb

Yes. The hosts file is correct.

Your further attempts to somehow educate your Philips soundbar to issue fewer DNS requests are not related to your hosts file.

I'm afraid that if that client isn't respecting TTLs, you're running out of Pi-hole's DNS configuration options to tackle this.

If you can't address this behaviour at the source, you may have to live with it, or return the device if its annoying you enough. Another option may be to configure that Philips soundbar to use a public DNS server, if you're ok with not filtering its requests.

[deHakkelaar]

@Bucking_Horn

It doesn't seem to matter much though, since your misbehaving device would issue those PTR requests regardless of the actual answer (be it an IP address or NXDOMAIN).

There is a difference between getting an NXDOMAIN or IP returned.
An NXDOMAIN is without TTL.
And if answered with an IP (EDIT: or name) , it does provide a TTL.

pi@ph5b:~ $ dig @localhost -x 10.20.30.40

; <<>> DiG 9.16.22-Raspbian <<>> @localhost -x 10.20.30.40
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37997
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;40.30.20.10.in-addr.arpa.      IN      PTR

;; Query time: 9 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Jul 22 13:07:12 CEST 2022
;; MSG SIZE  rcvd: 53

[Valiceemo]

@Bucking_Horn

The answer your Pi-hole provided has changed since you've started the topic, suggesting that you've changed yor configuration.

You are right, I was experimenting with conditional forwarding, initial post contained logs with forwarding enabled, subsequent with it disabled (my normal setup). I should have been clearer on this! My bad

@Bucking_Horn

@Valiceemo

The main question here, is are the contents of my hosts files correct?

That has been answered:

@jfb

Yes. The hosts file is correct.

Yes, I suppose you are right

@Bucking_Horn

I'm afraid that if that client isn't respecting TTLs, you're running out of Pi-hole's DNS configuration options to tackle this.
If you can't address this behaviour at the source, you may have to live with it, or return the device if its annoying you enough

It seems so, I fully understand its not a pihole issue, was more hoping pihole could help me diagnose. to be honest, at this stage, its more that the constant requests are flooding my logs, and skewing all my stats...soundbar connected

@Bucking_Horn

Another option may be to configure that Philips soundbar to use a public DNS server, if you're ok with not filtering its requests.

How would I go about this, as there are no options on the soundbar itself to set any network settings, nor on any connected Philips app.
Would using pihole groups to have the soundbar bypass pihole work?
Or is there a dnsmasq trick?

[jfb]

@Valiceemo

Or is there a dnsmasq trick?

Use Pi-hole as your DHCP server and use a dnsmasq configuration to assign this client a separate DNS server:

How can I use Pi-hole for all my devices except one (or more)?

Configuring your router's DHCP options to force clients to use Pi-hole as their DNS server is the quickest way to get all of your network devices to use Pi-hole. But what if you want a certain device to not use it? Perhaps a family member is frustrated with white or blacklisting sites. Or maybe you want to log queries for all network devices except for a few. Solution The solution is to manually set the DNS server to on the device you don't want to use Pi-hole with. Setting the DNS server o…

[Bucking_Horn]

@Valiceemo

@Bucking_Horn

I'm afraid that if that client isn't respecting TTLs, you're running out of Pi-hole's DNS configuration options to tackle this.
If you can't address this behaviour at the source, you may have to live with it, or return the device if its annoying you enough

It seems so, I fully understand its not a pihole issu

Before you switch to device-specific DNS servers, you may want to examine my aforementioned apprehension's condition: The output you've provided so far isn't conclusive as to whether your soundbar would honor TTLs or not. (I think that's also what deHakkelaar indirectly refers to when pointing out that NXDOMAIN has no TTL value associated to it.)

[Valiceemo]

Yes I think you're right.

Referring back to @deHakkelaar and his post

If I run the dig command without condional forwarding I get no result:

pi@pihole:~ $ dig +noall +answer @localhost -x 192.168.0.1
pi@pihole:~ $

If I run it with condional forwarding I get an error:

pi@pihole:~ $ dig +noall +answer @localhost -x 192.168.0.1
;; Warning: Message parser reports malformed message packet.

These are both with no local DNS record for the router @ 192.168.0.1

If I add a DNS record for my router 192.168.0.1 = skyqhub I get

Without condional forwarding:

pi@pihole:~ $ dig +noall +answer @localhost -x 192.168.0.1
1.0.168.192.in-addr.arpa. 60    IN      PTR     skyqhub.lan.

With condional forwarding:

pi@pihole:~ $ dig +noall +answer @localhost -x 192.168.0.1
1.0.168.192.in-addr.arpa. 60    IN      PTR     skyqhub.lan.

If I read this right, this means the TTL is set at 60 seconds, but the soundbar is not honouring it?

[deHakkelaar]

Yes your reading it right.
Do you still get those same PTR queries every few seconds?
If so, yes it appears the TTL has no effect for the soundbar.

[Valiceemo]

just to close the loop on this...

I have set the soundbar to use another upstream DNS server, via a dnsmasq config.

I now no longer see the multiple requests in my pihole log.
But i am certain they are still being made, so this is more of a 'out of sight, out of mind' workaround, rather than a fix.
I will try and push Philips tech support again, but I don't hold much hope.

As always pihole was working flawlessly, and doing exactly what it should be.