Hi Tijs!
First thing is, Simon wants changes here in form of patches present in
mails. If you have a code to share, include [PATCH] in subject and use
git format-patch master on your branch to generate patches and attach
them to message. Yes, it is old school, but the correct way to get
patches reviewed and eventually merged. I have created private pull
request on github, but without patches nothing gets merged.
Interesting work however. I admit when proposing joining multiple
queries for the same name, I never thought about cookies and that they
cannot work with current algorithm.
Though I admit it seems strange to use bind servers with dnsmasq in the
middle. Can you share what dnsmasq does, which bind itself cannot do?
From bind9 maintainer view, maybe turn off dns cookies for dnsmasq
forwarder? send-cookie in server block in named.conf might help, if you
control those servers.
I do not see a simple way to solve it.
- Ideally dnsmasq should track upstream server cookie for each server
and add it into queries forwarded by any client. But then it would have
to generate own server cookie for each client answer. But TCP
implmentation might be tricky. dnsmasq uses forked process so it needs
to send updates to main process via pipe.
- Removing cookies from any client queries would be safest start.
- Alternatively it could be removed only for joined frec clients, ie 2nd
and additional client to already existing forward record. Or just the
different clients, which did not send query being responded to. That
probably means you would need to remember cookies for each client
involved. But that would be hard to debug properly and maybe bad idea.
I would reset server cookie when flushing cache maybe. At least with NM
configuration that would make sense if servers have changed. It may
ensure it is done often enough, at least in some cases. But that is just
fine tuning to do after the code is good enough. I think this is not a
small feature.
I think first two patches are ready to be merged. Remaining stuff is
more complex and probably needs detailed review of more eyes. Ideally
also some repeatable tests.
Cheers,
Petr
On 14. 03. 24 15:51, Tijs Van Buggenhout wrote:
Hi,
We use dnsmasq as a DNS filter in a chain of forwarders (multiple bind servers
forward to dnsmasq which in turn forwards to a bind (cache) server which
forwards to multiple TSIG enabled DNS servers on the internet).
The bind servers report 'bad cookies' and/or 'missing cookies' from time to
time. This can happen due to an optimization in dnsmasq to reuse the same
forwarder for multiple sources. These sources all have a unique client
cookie, that is forwarded as-is by dnsmasq to the bind cache server which
responds with a server cookie that is passed back to the originating server.
However due to the reuse of the forwarder, the one-to-one relationship
between client and (cache) server is lost, which may result in a cookie
incorrectly passed to an origin server (the client cookie, as part of the DNS
cookie, originated from another client server).
One (work-around) solution to this problem is to avoid the optimization in
dnsmasq (reuse). We used the 'add-subnet=1,1' as a workaround, so that
queries are treated as "not cacheable", avoiding the above.
A better solution to this problem is for dnsmasq to not forward the DNS client
cookie altogether, so that the bind cache server never returns a DNS cookie
and so the problem disappears. We achieved this by patching dnsmasq in
the 'add_edns0_config' function, removing the EDNS0_OPTION_COOKIE option, if
any.
These solutions avoid the "bad cookie", but not yet the "missing cookies". For
this we added support for DNS cookies in dnsmasq for local and forwarded
queries for both UDP and TCP protocols, as described in rfc7873 and 9018 -
see https://github.com/axsguard/dnsmasq/tree/support_dns_cookies.
We are currently running this version in the described scenario without
issues. There are still some things missing, for which we may need some
input/advice.
* Bad cookie retry in TCP mode when UDP retry failed
* Regularly changing the server and/or cilent secrets (e.g. once a month/year)
We would like to request more reviews/comments/suggestions and some plan
forward to have this included on master. If not, to at least consider the
change to 'add_edns0_config' as to remove any cookie from forwarded queries.
# dnsmasq --version
Dnsmasq version 2.91test1 Copyright (c) 2000-2024 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN2 no-DHCP
no-scripts no-TFTP no-conntrack ipset no-nftset no-auth no-cryptohash no-DNSSEC
Cookie no-loop-detect inotify no-dumpfile
# dig thekelleys.org.uk
;; BADCOOKIE, retrying.
; <<>> DiG 9.18.15 <<>> thekelleys.org.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64892
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0298755806e389e70100000065f2f100a7431d9cc031584a (good)
;; QUESTION SECTION:
;thekelleys.org.uk. IN A
;; ANSWER SECTION:
thekelleys.org.uk. 900 IN A 85.119.82.65
;; Query time: 39 msec
;; SERVER: 192.168.10.2#53(192.168.10.2) (UDP)
;; WHEN: Thu Mar 14 13:43:44 CET 2024
;; MSG SIZE rcvd: 90
# dig +cookie=0298755806e389e70100000065f2f100a7431d9cc031584a thekelleys.org.uk
; <<>> DiG 9.18.15 <<>> +cookie thekelleys.org.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36828
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0298755806e389e70100000065f2f100a7431d9cc031584a (good)
;; QUESTION SECTION:
;thekelleys.org.uk. IN A
;; ANSWER SECTION:
thekelleys.org.uk. 859 IN A 85.119.82.65
;; Query time: 0 msec
;; SERVER: 192.168.10.2#53(192.168.10.2) (UDP)
;; WHEN: Thu Mar 14 13:44:25 CET 2024
;; MSG SIZE rcvd: 90
# dig +cookie=0298755806e389e70100000065f2f100a7431d9cc031584a
thekelleys.org.uk @127.0.0.2
;; BADCOOKIE, retrying.
; <<>> DiG 9.18.15 <<>> +cookie thekelleys.org.uk @127.0.0.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37824
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0298755806e389e70100000065f2f13eee4760ca63aa7570 (good)
;; QUESTION SECTION:
;thekelleys.org.uk. IN A
;; ANSWER SECTION:
thekelleys.org.uk. 838 IN A 85.119.82.65
;; Query time: 0 msec
;; SERVER: 127.0.0.2#53(127.0.0.2) (UDP)
;; WHEN: Thu Mar 14 13:44:46 CET 2024
;; MSG SIZE rcvd: 90
Regards,
Tijs Van Buggenhout
_______________________________________________
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, http://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
