I think I found the change:
git diff eb92fb3 efbf80be src/config.h
diff --git a/src/config.h b/src/config.h
index 37b374e..1e7b30f 100644
--- a/src/config.h
+++ b/src/config.h
@@ -19,7 +19,7 @@
#define CHILD_LIFETIME 150 /* secs 'till terminated (RFC1035 suggests >
120s) */
#define TCP_MAX_QUERIES 100 /* Maximum number of queries per incoming TCP
connection */
#define TCP_BACKLOG 32 /* kernel backlog limit for TCP connections */
-#define EDNS_PKTSZ 1232 /* default max EDNS.0 UDP packet from from
/dnsflagday.net/2020 */
+#define EDNS_PKTSZ 4096 /* default max EDNS.0 UDP packet from RFC5625 */
#define SAFE_PKTSZ 1232 /* "go anywhere" UDP packet size, see
https://dnsflagday.net/2020/ */
#define KEYBLOCK_LEN 40 /* choose to minimise fragmentation when storing
DNSSEC keys */
#define DNSSEC_WORK 50 /* Max number of queries to validate one question
*/
EDNS packet size was set to 4096, now is set same as SAFE_PKTSZ.
I've also read the paper for http://www.dnsflagday.net/2020/
and I may understand the problem - after this "fragmentation" of UDS is
more-or-less disabled by
setting max EDNS UDS packet size to 1232, it is necessary for the DNS to
be enabled over TCP, so the
resolving client may switch to TCP DNS resolution. This was not the case
for Windows clients.
@Petr Menšík: seem your first assumption may be correct. Thanks for this
pointer...
Let's see if that helps.
Adam Pribyl
On Mon, 18 Mar 2024, Adam Pribyl wrote:
I tried to increase the --edns-packet-max=1450, did not work, set it to 2048
now resolution seems to work. Interestingly only temporarily, because this
appears in the dnsmasq log soon
reducing DNS packet size for nameserver 10.101.255.253 to 1232
and the resolution is not working again.
So it seems this is related to that change in dnsmasq and Windows name
resolution as with Linux clients there is no problem, but even using this
option does not fix the problem as for some reason dnsmasq decides to
override the override..
Still it is not obvious to me, what edns packet size was used in dnsmasq
before 2.90 version.
Adam Pribyl
On Tue, 12 Mar 2024, Adam Pribyl wrote:
In this case the query is from Windows 10 machine->dnsmasq server on Fedora
38 forwards to -> bind on debian.
The result on Windows nslookup
Server: UnKnown
Address: 192.168.34.1
*** UnKnown can't find login.microsoftonline.com: Unspecified error
In dnsmasq there is this "reply is truncated" for this forwarded query.
I do not think the problem is the Windows client, because from the time I
downgraded the dnsmasq on Fedora to 2.89, I did not get any "reply is
truncated" dnsmasq log message anymore.
I can not judge if client should do anything else in this case thou..
Adam Pribyl
On Tue, 12 Mar 2024, Petr Menšík wrote:
The response seems correct and acceptable in size. It should not truncate,
at least what I see. It should also retry with TCP when truncated reply
arrives. I have verified even last release works with dig. Dnsmasq does
not do tcp query by itself, it expects client to do TCP query. What client
do you use?
$ dig login.microsoftonline.com a
; <<>> DiG 9.18.24 <<>> login.microsoftonline.com a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20188
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
;; QUESTION SECTION:
;login.microsoftonline.com. IN A
;; ANSWER SECTION:
login.microsoftonline.com. 10360 IN CNAME login.mso.msidentity.com.
login.mso.msidentity.com. 30 IN CNAME ak.privatelink.msidentity.com.
ak.privatelink.msidentity.com. 30 IN CNAME
www.tm.ak.prd.aadg.trafficmanager.net.
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 40.126.31.71
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.0
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.68
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.71
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.73
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.75
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 40.126.31.67
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 40.126.31.69
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Mar 12 10:07:36 CET 2024
;; MSG SIZE rcvd: 303
I have tried dig +ignore +noedns -t txt on google.com or cisco.com. If
client does not retry, it gets no response. If it does, it does. It seems
to work as intended.
If might help querying your bind server by dig @10.101.255.253 txt ch
version.bind. But I suspect the problem is in client incorrectly omitting
TCP query retry. Is it glibc program? Can you tell us more about client
program making those queries?
Cheers,
Petr
On 3/11/24 09:27, Adam Pribyl wrote:
After upgrade of dnsmasq 2.89 to dnsmasq-2.90-1.fc38.x86_64 I started to
notice, that some queries won't resolve when asked thru dnsmasq, but work
asked directly to upstream nameserver.
I found that certain queries forwarded to anycast bind nameservers return
only a "reply is truncated" message and no record.
Mar 11 07:30:05 server dnsmasq[4054056]: query[A]
login.microsoftonline.com from 192.168.34.194
Mar 11 07:30:05 server dnsmasq[4054056]: forwarded
login.microsoftonline.com to 10.101.255.253
Mar 11 07:30:05 server dnsmasq[4054056]: reply is truncated
Downgrading to dnsmasq-2.89-1.fc38.x86_64 seems to solve the problem.
The response for login.microsoftonline.com is a long one.
In the dnsmasq changelog I found, there were some changes with edns max
size, but I can not find the commit to find out what was there before, to
set the --edns-packet-max.
The general question would be - what is the correct DNS setup then? I
probably need to change the bind config, as I do not want to fix every
dnsmasq "client" in the network.
Thanks
Adam Pribyl
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
