Recent content by wraithdu

Looks like you have DNSSEC enabled. Without it my answer is 467 bytes. Might be an option for you, I don't think DNSSEC gains much on top of DoT with a trusted upstream server. IMO DNSSEC makes more sense if you're running your own resolver like Unbound, or if you don't trust the upstream. Just...

Well that's no fun. Then it seems DNS truncation is a poorly supported standard. Curious, what's your test domain, and what's the DNS response directly from say 8.8.8.8? Is it >512 bytes and not truncated?

I think the root cause is understood... These IoT devices don't expect / support truncated responses. The getdns dev also said he'd create a feature to allow disabling truncation, which would restore prior behavior. I haven't seen that code checked in yet. Keep an eye on that getdns issue and...

Thanks. That USB removal is a nasty surprise. Odd, I didn't have problems when upgrading to test my .18 build, coming from Merlin's .18 build. But it all went to hell trying to go to .19.

384.19 beta 2 is working for name compression on the DNS response. I will have to remember however... remove any USB drives and reboot before flashing. I just spent 3 hours fighting through fw rescue mode and the restoration utility to recovery flash the fw to get my radios working again. How...

@john9527 , my test shows the getdns patch works. Can you try again and see what dig shows? If both of us can confirm the fix, maybe @RMerlin can pull it into 384.19 .

And an alternative to dns filter for those using postconf scripts. dhcp-mac=set:nestp,18:b4:30:*:*:* dhcp-option=tag:nestp,option:dns-server,8.8.8.8,8.8.4.4

So I spent last night getting the FW to build with the getdns patch, and it looks like it's working. The dig response size is what I would expect.

I didn't see anything in the dnsmasq release notes that would have mattered, but the getdns patch should work. Assuming it's working as intended and doesn't need a config to activate it. On your fork where you applied it, what's the dig response look like for frontdoor.nest.com ? If it's...

Does 384.19 beta 1 include this fix in getdns? It implements name compression from the upstream response, which would mitigate the IoT issues. https://github.com/getdnsapi/getdns/commit/bda845ce43e54f2aec14ecd4ddff2189b0bb4b06

The getdns dev replied in the issue. He has suggested he's going to add name compression and a config option to disable truncation.

That's an unrelated issue. I think what's going on here has been well identified at this point. The question is how to deal with it. I've posted on the issue in getdns's project, but no solution has yet been proposed. https://github.com/getdnsapi/getdns/issues/430

I don't think it's a bug, so I don't expect any upstream "fixes". I was thinking along the lines of config options... but I don't even know what to suggest. I mean, the IoT devices are bad DNS clients that don't follow spec. The only thing that could help and not be an ugly hack would be some...

I would really be interested to know what @RMerlin thinks about all this. While it's great we have a workaround, the getdns patch is the correct behavior according to spec. I feel like there has to be a better option.

I don't have DNSSEC enabled, but maybe this is a stubby thing. You can't see what's going on without Wireshark. Dig makes the request and the forward from dnsmasq to stubby has an OPT section with the EDNS buffer size at 4096. That buffer should come from the client I believe if it supports...