[Dnsmasq-discuss] dnsmasq 2.90 reply truncated

Mon Apr 8 11:02:25 UTC 2024

On Mon, 8 Apr 2024, Petr Menšík wrote:

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

Sorry, this is missunderstanding, this was a local firewall problem that 
did not allow a TCP DNS querries for Windows machines. This setup was 
happily working for many years... but was not correct and manifestate only 
when dnsmasq stopped support for large EDNS UDP querries.

> 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

Adam Pribyl

> 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
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>