My Domain name is been appended to queries it shouldn't

[kingamajick]

Apologies is the title is a bit misleading, I'm not sure how I would exactly describe this problem.

I've been trying to get some Sonos speakers working on my system and they keep failing during registration.

After running a package capture, I've noticed the following in the logs that doesn't seem correct.

LAN
vtnet1   2025-05-21
14:12:16.892595   38:42:0b:9e:f9:92   72:a9:94:69:59:9a   ethertype IPv4 (0x0800), length 105: (tos 0x0, ttl 64, id 48566, offset 0, flags [DF], proto UDP (17), length 91)
    192.168.1.140.50520 > 192.168.1.1.53: [udp sum ok] 26539+ A? registration.ws.sonos.com.lan.mydomain.com. (63)
LAN
vtnet1   2025-05-21
14:12:16.892744   72:a9:94:69:59:9a   d4:3a:2c:a4:72:75   ethertype IPv4 (0x0800), length 164: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 150)
    192.168.1.1.53 > 192.168.1.140.50520: [udp sum ok] 26539 NXDomain q: A? registration.ws.sonos.com.lan.mydomain.com. 0/1/0 ns: mydomain.com. SOA norm.ns.cloudflare.com. dns.cloudflare.com. 2372644829 10000 2400 604800 1800 (122)

It appears registration.ws.sonos.com has .lan.mydomain.com appended to it.

I'm using ISC DHCPv4 which has the domain name set as lan.mydomain.com and domain search list as lan.mydomain.com;mydomain.com.

And Unbound DNS has DHCP Domain Override set to lan.mydomain.com.

Can any one point me in the direction of what may be causing this issue?


Full packet capture https://pastebin.com/raw/3YLntRAV

Thanks :)

 

[Patrick M. Hausen]

It's clients who do this and there is nothing you can do to keep them from doing so other than not providing a domain and/or a domain search path at all.


- client asks for "foo.com" and receives NXDOMAIN because either that does not exist or is filtered.
- it will then by the standard append each domain in the search path to "foo.com" in turn and ask for these.

Problems arise if the DNS server delivers an answer which it should not - unless "foo.com.my.appended.domain" does indeed exist.

If the initial retry of the client is caused by a filtering mechanism it is probably preferable to deliver "IN A 0.0.0.0" instead of "NXDOMAIN" thus breaking the loop.

HTH,
Patrick

[kingamajick]

Thanks for the info, that's good to understand! I thought I was on the path to the root cause :) The issue with the speakers seems is a bit of a head scratcher. 1 worked, the other two didn't on my network, but did on the neighbour's (simple ISP router type setup).

In the logs there are requests for the domain without my local domain appended, which IIUC returns 23.215.236.36 so I assume in this case it shouldn't continue to add the various domains?

LAN
vtnet1   2025-05-21
14:10:12.669479   72:a9:94:69:59:9a   d4:3a:2c:a4:72:75   ethertype IPv4 (0x0800), length 189: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 175)
    192.168.1.1.53 > 192.168.1.140.59440: [udp sum ok] 745 q: A? registration.ws.sonos.com. 3/0/0 registration.ws.sonos.com. CNAME registration.ws.sonos.com-v2.edgekey.net., registration.ws.sonos.com-v2.edgekey.net. CNAME e8047.e2.akamaiedge.net., e8047.e2.akamaiedge.net. A 23.215.236.36 (147)

(Per chance did you see anything else in the logs that sticks out as a incorrectly configured network on my end?)

Thanks

[Patrick M. Hausen]

It should not but crappy software does all sorts of things.

Did it in the second exchange? What did it initially receive as an answer im the first exchange you posted?

[kingamajick]

It looks like it's just repeating this sequence from the logs

LAN
vtnet1   2025-05-21
14:10:07.665756   38:42:0b:9e:f9:92   72:a9:94:69:59:9a   ethertype IPv4 (0x0800), length 85: (tos 0x0, ttl 64, id 35643, offset 0, flags [DF], proto UDP (17), length 71)
    192.168.1.140.59440 > 192.168.1.1.53: [udp sum ok] 745+ A? registration.ws.sonos.com. (43)
LAN
vtnet1   2025-05-21
14:10:07.665899   72:a9:94:69:59:9a   d4:3a:2c:a4:72:75   ethertype IPv4 (0x0800), length 189: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 175)
    192.168.1.1.53 > 192.168.1.140.59440: [udp sum ok] 745 q: A? registration.ws.sonos.com. 3/0/0 registration.ws.sonos.com. CNAME registration.ws.sonos.com-v2.edgekey.net., registration.ws.sonos.com-v2.edgekey.net. CNAME e8047.e2.akamaiedge.net., e8047.e2.akamaiedge.net. A 23.215.236.36 (147)
LAN
vtnet1   2025-05-21
14:10:12.669364   38:42:0b:9e:f9:92   72:a9:94:69:59:9a   ethertype IPv4 (0x0800), length 85: (tos 0x0, ttl 64, id 35644, offset 0, flags [DF], proto UDP (17), length 71)
    192.168.1.140.59440 > 192.168.1.1.53: [udp sum ok] 745+ A? registration.ws.sonos.com. (43)
LAN
vtnet1   2025-05-21
14:10:12.669479   72:a9:94:69:59:9a   d4:3a:2c:a4:72:75   ethertype IPv4 (0x0800), length 189: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 175)
    192.168.1.1.53 > 192.168.1.140.59440: [udp sum ok] 745 q: A? registration.ws.sonos.com. 3/0/0 registration.ws.sonos.com. CNAME registration.ws.sonos.com-v2.edgekey.net., registration.ws.sonos.com-v2.edgekey.net. CNAME e8047.e2.akamaiedge.net., e8047.e2.akamaiedge.net. A 23.215.236.36 (147)
LAN
vtnet1   2025-05-21
14:10:12.670359   38:42:0b:9e:f9:92   72:a9:94:69:59:9a   ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.140, length 46
LAN
vtnet1   2025-05-21
14:10:12.670373   72:a9:94:69:59:9a   38:42:0b:9e:f9:92   ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 72:a9:94:69:59:9a, length 28
LAN
vtnet1   2025-05-21
14:10:17.671490   38:42:0b:9e:f9:92   72:a9:94:69:59:9a   ethertype IPv4 (0x0800), length 105: (tos 0x0, ttl 64, id 36644, offset 0, flags [DF], proto UDP (17), length 91)
    192.168.1.140.48368 > 192.168.1.1.53: [udp sum ok] 37908+ A? registration.ws.sonos.com.lan.mydomain.com. (63)
LAN
vtnet1   2025-05-21
14:10:17.671623   72:a9:94:69:59:9a   d4:3a:2c:a4:72:75   ethertype IPv4 (0x0800), length 164: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 150)
    192.168.1.1.53 > 192.168.1.140.48368: [udp sum ok] 37908 NXDomain q: A? registration.ws.sonos.com.lan.mydomain.com. 0/1/0 ns: mydomain.com. SOA norm.ns.cloudflare.com. dns.cloudflare.com. 2372644829 10000 2400 604800 1800 (122)
LAN
vtnet1   2025-05-21
14:10:22.675586   38:42:0b:9e:f9:92   72:a9:94:69:59:9a   ethertype IPv4 (0x0800), length 105: (tos 0x0, ttl 64, id 36645, offset 0, flags [DF], proto UDP (17), length 91)
    192.168.1.140.48368 > 192.168.1.1.53: [udp sum ok] 37908+ A? registration.ws.sonos.com.lan.mydomain.com. (63)
LAN
vtnet1   2025-05-21
14:10:22.675691   72:a9:94:69:59:9a   d4:3a:2c:a4:72:75   ethertype IPv4 (0x0800), length 164: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 150)
    192.168.1.1.53 > 192.168.1.140.48368: [udp sum ok] 37908 NXDomain q: A? registration.ws.sonos.com.lan.mydomain.com. 0/1/0 ns: mydomain.com. SOA norm.ns.cloudflare.com. dns.cloudflare.com. 2372644829 10000 2400 604800 1800 (122)

The only other thing that looks different to that cycle is

LAN
vtnet1   2025-05-21
14:11:26.809292   38:42:0b:9e:f9:92   01:00:5e:00:00:fb   ethertype IPv4 (0x0800), length 704: (tos 0x0, ttl 255, id 57310, offset 0, flags [DF], proto UDP (17), length 690)
    192.168.1.140.5353 > 224.0.0.251.5353: [udp sum ok] 0*- [0q] 1/0/7 _sonos._tcp.local. PTR RINCON_38420B9EF99201400@Kitchen 2._sonos._tcp.local. ar: Sonos-38420B9EF992.local. (Cache flush) A 192.168.1.140, Sonos-38420B9EF992.local. (Cache flush) AAAA 2a02:6b67:eef7:a200:3a42:bff:fe9e:f992, Sonos-38420B9EF992.local. (Cache flush) AAAA fe80::3a42:bff:fe9e:f992, RINCON_38420B9EF99201400@Kitchen 2._sonos._tcp.local. (Cache flush) TXT "mdnssequence=0" "variant=2" "infohash=y881jLo4YXcbbmrapGmjGt4BWqbiDmgBk4HluQZBP9I" "hhsslport=1843" "wss=/websocket/api" "location=http://192.168.1.140:1400/xml/device_description.xml" "hhid=Sonos_hZinSZqUrDP5MEi7uDkoEmWttu" "bootseq=2" "uuid=RINCON_38420B9EF99201400" "minApiVersion=1.1.0" "sslport=1443" "protovers=1.46.0" "mhhid=Sonos_hZinSZqUrDP5MEi7uDkoEmWttu.Diewi8GJ33Z5IYI9Z7LA" "vers=5" "info=/api/v1/players/RINCON_38420B9EF99201400/info", RINCON_38420B9EF99201400@Kitchen 2._sonos._tcp.local. (Cache flush) SRV Sonos-38420B9EF992.local.:1443 0 0, Sonos-38420B9EF992.local. (Cache flush) NSEC, RINCON_38420B9EF99201400@Kitchen 2._sonos._tcp.local. (Cache flush) NSEC (662)

https://pastebin.com/raw/3YLntRAV <-- Complete logs

[Patrick M. Hausen]

Looks like it does not like or cannot handle the CNAME entries.

Again, you cannot keep the client from throwing these requests at your server, only configure the server in a way not to answer them.

I only use Unbound and AGH. In Unbound you can set the local zone type to e.g. "static" instead of the default "transparent", so Unbound will refuse to try and resolve unknown local zone requests across the Internet.

[kingamajick]

Thanks for your help.

I've send the package capture over to Sonos to see if they can work out whats happening with the speakers, and at least I know this is a dead end in term of the problem (the adding lan.mydomain.com) and learnt something in the process.

Thanks

[Patrick M. Hausen]

But then again why is this even a problem? Let them request and just ignore the stuff. Not an option?

[kingamajick]

I didn't release this wasn't a problem, I thought that the issue with the speakers was it was doing some weird requests with my domain stuck on the end, I didn't know this was a standard thing that occurred in this sistuation.

Just for context, I've bought a few Sonos speakers recently and 1 or 2 or them are proving problematic and not registering with the Sonos system so I was seeing if I could see anything in the package capture, and that looked strange to me, but turns out it's completely normal.