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@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
--
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
--
Matus UHLAR - fantomas, uh...@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
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss