Default content of hosts files

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] from
Jul 20 13:27:49 dnsmasq[23400]: /etc/pihole/custom.list is skyqhub.lan
Jul 20 13:27:52 dnsmasq[23400]: query[PTR] from
Jul 20 13:27:52 dnsmasq[23400]: /etc/pihole/custom.list is skyqhub.lan
Jul 20 13:27:55 dnsmasq[23400]: query[PTR] from
Jul 20 13:27:55 dnsmasq[23400]: /etc/pihole/custom.list 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, 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 pihole and localhost entry in /etc/hosts
should this be 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
pi@pihole:~ $ cat /etc/hosts       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters       pihole
pi@pihole:~ $ cat /etc/pihole/custom.list skyqhub skqqextender

Yes. The hosts file is correct.

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

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	localhost
::1		localhost ip6-localhost ip6-loopback
ff02::1		ip6-allnodes
ff02::2		ip6-allrouters	Pi-Dev-3B

And on Armbian Buster:

cat /etc/hosts   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	NanoPi

Thank for checking. That has put me at ease a 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.

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

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?

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.

It might.

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


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 (

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

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

dig +noall +answer @localhost ptr

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.

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

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

pi@pihole:~ $ dig +noall +answer @localhost ptr
pi@pihole:~ $

if i run with no flags or options:

pi@pihole:~ $ dig                             
; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>>
;; 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

; EDNS: version: 0, flags:; udp: 1472
;      IN      A

;; AUTHORITY SECTION:   10800   IN      SOA     localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 5 msec
;; 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
;; Warning: Message parser reports malformed message packet.

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

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

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

dig +noall +answer @localhost -x

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] from
09:54:48: config is NXDOMAIN
09:54:50: query[PTR] from ::1
09:54:50: config is NXDOMAIN
09:54:51: query[PTR] from
09:54:51: config is NXDOMAIN
09:54:54: query[PTR] from
09:54:54: config is NXDOMAIN

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

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.

That has been answered:

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.

1 Like

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

; <<>> DiG 9.16.22-Raspbian <<>> @localhost -x
; (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

; EDNS: version: 0, flags:; udp: 1232
;      IN      PTR

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

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

Yes, I suppose you are right

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

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?

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

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

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
pi@pihole:~ $

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

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

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

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

Without condional forwarding:

pi@pihole:~ $ dig +noall +answer @localhost -x 60    IN      PTR     skyqhub.lan.

With condional forwarding:

pi@pihole:~ $ dig +noall +answer @localhost -x 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?

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.

1 Like

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.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.