Open aershey-git opened 3 years ago
The strange thing is that edns-packet-max setting defaults to 4096 in dnsmasq since long. But applying --edns-packet-max=4096 in the configuration of dnsmasq apparently has no effect. I can still see the message " daemon.warn dnsmasq[]: reducing DNS packet size for nameserver 127.0.0.1 to 1280" in my syslog. Maybe there is a difference between activating DNSSEC in dnsmasq or in stubby. According to https://forum.openwrt.org/t/stubby-dns-over-tls-using-dnsmasq-full-for-dnssec-caching/19107 one should enable DNSSEC preferably in dnsmasq. However https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md states it should have the same outcome. I will check that later. BTW, there was a similar issue in DNS behavior with dnscrypt-proxy in the past. See https://github.com/DNSCrypt/dnscrypt-proxy/issues/956 I think this thread is f.i. related to https://github.com/getdnsapi/getdns/issues/495
Did not see a change in the syslog when enabling dnssec in Stubby. According to RFC6891 6.2.5. Payload Size Selection : .. A requestor SHOULD choose to use a fallback mechanism that begins with a large size, such as 4096. If that fails, a fallback around the range of 1280-1410 bytes SHOULD be tried, as it has a reasonable chance to fit within a single Ethernet frame. .. Unfortunately I don't know if there was a fallback before with a larger size. I suppose that would have shown in the syslog as well.
OpenWrt 19.07.6 stubby 0.3.0-1 dnsmasq-full 2.80-16.3
Dnsmasq reducing DNS packet size when forwarding request to stubby. Mostly with Microsoft domains. Upstream TLS DNS server is 9.9.9.11 eDNS0 enables with ECS. Changing edns_client_subnet_private to 0 from 1 does not change behavior.