[Dnsmasq-discuss] dnsmasq 2.90 reply truncated

Tue Mar 12 17:46:28 UTC 2024

Hi,

the lookup with dnsmasq 2.90 using Windows 10 works for me!

Version on Ubuntu Server:

sirius:~# dnsmasq --version
Dnsmasq version 2.90  Copyright (c) 2000-2024 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 
no-Lua TFTP conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect 
inotify dumpfile

Windows 10 Lookup:

 > nslookup login.microsoftonline.com
Server:  sirius.home
Address:  fd53::1

Nicht autorisierende Antwort:
Name:    www.tm.ak.prd.aadg.trafficmanager.net
Addresses:  2603:1026:3000:d0::b
           2603:1026:3000:d0::6
           2603:1026:3000:d0::d
           2603:1027:1:d8::9
           2603:1026:3000:c8::7
           2603:1026:3000:c8::b
           2603:1027:1:d8::4
           2603:1026:3000:d0::
           40.126.32.133
           40.126.32.136
           40.126.32.68
           20.190.160.20
           20.190.160.22
           40.126.32.140
           40.126.32.134
           20.190.160.14
Aliases:  login.microsoftonline.com
           login.mso.msidentity.com
           ak.privatelink.msidentity.com

Uwe

Am 12.03.2024 um 13:42 schrieb Adam Pribyl:
> 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 at 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 at lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

-- 
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: uwe at thetaphi.de