[Dnsmasq-discuss] dnsmasq 2.90 reply truncated
Matus UHLAR - fantomas
uhlar at fantomas.sk
Mon Apr 8 10:23:00 UTC 2024
On 08.04.24 10:32, Petr Menšík wrote:
>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.
AFAIK it was never optional.
While the EDNS reduces the need for TCP usage, it SHOULD work all the time.
>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
>
>
>_______________________________________________
>Dnsmasq-discuss mailing list
>Dnsmasq-discuss at lists.thekelleys.org.uk
>https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
--
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
More information about the Dnsmasq-discuss
mailing list