Guessing you're referring to frames 921, 937 and 947 in your sniffer capture where 192.168.0.102 asks 192.168.0.1 what the IP address of www.fitbit.com is? I guess my question at this point is does your sniffer capture ever return a response from anyone for an IP address of www.fitbit.com at all or not?
I'm really rusty on my DNS so I'd have to do a bit of refresher reading into this.
Taking a quick glance, I dont readily see anything off. That said, checksums are rarely disabled, so this is peculiar, and your transaction IDs are sequential, which is bad from a DNS security standpoint, so this is another red flag.
It's a stupid fitbit, so security isn't on the roadmap.
My guess... whatever 0.1 is doesn't like the "no checksum" udp packets. Technically, that would be a *bad* checksum, and the OS may drop it. All of my linux boxes will.
If I do a nslookup the computer will send a DNS request for www.fitbit.com with a proper checksum. This gets treated properly. Its when there is no checksum that things get strange.
I have resolved the issue down to my Zyxel USG. It seems to be confused by the lack of a checksum. I think its not opening a session, or prematurely closing it. The DNS reply appears on the WAN side, but the firewall tosses it out and sends the DNS server an ICMP saying it can't find the host...
The DNS query without the checksum is treated equally by the DNS servers. Its not the lack of checksum that was the problem. The device that was sending the request also has a bad habit of not responding to ARP requests.