[Dnsmasq-discuss] dnsmasq 2.90 reply truncated

Mon Apr 8 08:32:28 UTC 2024

Are you sure DNS over TCP were disabled by default? Were it not some 
local applied policy?

TCP is mandatory for a long time, I am not even sure it ever was just 
optional. Can you share where this is set and where it can be checked, 
whether TCP is enabled already?

Great test examples are:

- nslookup -type=txt google.com
- nslookup -type=txt cisco.com

On 3/19/24 08:36, Adam Pribyl wrote:
> Seems the problem is solved by allowing a DNS over TCP for clients.
>
> While inability to forward larger EDNS querries ove UDS in 2.90 is 
> certainly a change, I understand that dnsmasq is now following the DNS 
> flag day suggestion instead RFC.
>
> I'd like to still point out, that the --edns-packet-max option does 
> not workaround the problem for me as dnsmasq "shrinks" the value to 
> the 1232 even this is set larger.
>
> Regards
>
> 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 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

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB