As discussed ... relates to https://forum.mikrotik.com/viewtopic.php?t=200627 (Mikrotik bug). In short: DNS says that if TC (truncate) bit is set, to retry with TCP, Mikrotik (whilst handing it server-side) does not and simply ends up re-transmitting the UDP query. Workaround is to permit >512b responses such that we won't see truncation. With DNSSEC responses are generally >512b anyway, and the norm seems to have settled around allowing up to 4KB responses via UDP, which in a low-loss world should be fine. Reproducible: Always
Created attachment 873403 [details, diff] djbdns-dnscache-configurable-truncate-size.patch Actual patch. Tried to get naming etc so that you merely need to drop it into files/ and add it to the patch list. Will default to current behaviour, and clamp the configurable range to 512 <= truncate_size <= 16KB. Been using this for about a few days now and the client that have reported that the "internet is slow" has agreed that this has made a huge difference. We suspect because he's using MT on his premises with our caches as upstream from there due to MT not falling back that SOME of the responses were too large and getting truncated, with MT not falling back that would eventually result in the browser either specifically asking for A or AAAA records rather than ANY, get a response that fits and then move on (this portion is speculation
Uh oh :) * Applying configurable-truncate-size.patch ... patching file dnscache.c Hunk #1 succeeded at 51 (offset -7 lines). Hunk #2 FAILED at 85. Hunk #3 FAILED at 450. 2 out of 3 hunks FAILED -- saving rejects to file dnscache.c.rej patching file server.c Hunk #1 FAILED at 94. Hunk #2 succeeded at 105 with fuzz 2 (offset -49 lines). Hunk #3 FAILED at 176. 2 out of 3 hunks FAILED -- saving rejects to file server.c.rej
Created attachment 873470 [details, diff] ~/configurable-truncate-manpages.patch
jkroon@plastiekpoot ~/projects/gentoo/net-dns/djbdns (master) $ ebuild djbdns-1.05-r38.ebuild prepare Appending /home/jkroon/projects/gentoo to PORTDIR_OVERLAY... * djbdns-1.05.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] * djbdns-1.05-man.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] * djbdns-1.05-test32.diff.xz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking djbdns-1.05.tar.gz to /var/tmp/portage/net-dns/djbdns-1.05-r38/work >>> Unpacking djbdns-1.05-man.tar.gz to /var/tmp/portage/net-dns/djbdns-1.05-r38/work >>> Unpacking djbdns-1.05-test32.diff.xz to /var/tmp/portage/net-dns/djbdns-1.05-r38/work >>> Source unpacked in /var/tmp/portage/net-dns/djbdns-1.05-r38/work >>> Preparing source in /var/tmp/portage/net-dns/djbdns-1.05-r38/work/djbdns-1.05 ... * Applying dnsroots.patch ... [ ok ] * Applying dnstracesort.patch ... [ ok ] * Applying string_length_255.patch ... [ ok ] * Applying srv_record_support.patch ... [ ok ] * Applying increase-cname-recustion-depth.patch ... [ ok ] * Applying CVE2009-0858_0001-check-response-domain-name-length.patch ... [ ok ] * Applying CVE2012-1191_0001-ghost-domain-attack.patch ... [ ok ] * Applying AR-and-RANLIB-support.patch ... [ ok ] * Applying tinydns-softlimit.patch ... [ ok ] * Applying djbdns-1.05-test32.diff ... patching file FILES patching file Makefile .. (lots of offset stuff). * Applying CVE2008-4392_0001-dnscache-merge-similar-outgoing-queries-ipv6-test32.patch ... [ ok ] * Applying CVE2008-4392_0002-dnscache-cache-soa-records-ipv6-test29.patch ... [ ok ] >>> Source prepared. jkroon@plastiekpoot ~/projects/gentoo/net-dns/djbdns (master) $ cd /var/tmp/portage/net-dns/djbdns-1.05-r38/work/djbdns-1.05 jkroon@plastiekpoot /var/tmp/portage/net-dns/djbdns-1.05-r38/work/djbdns-1.05 $ patch -p1 < ~/src/patches/djbdns-dnscache-configurable-truncate-size.patch patching file dnscache.c patching file server.c jkroon@plastiekpoot /var/tmp/portage/net-dns/djbdns-1.05-r38/work/djbdns-1.05 $ What am I missing? Ordering issue perhaps? I did build this on top of existing patches to try and make sure you have as little as possible to do ...
I see what happened. Despite it being a "worst practice," we have several patches for djbdns that are conditionally applied. The ipv6 patch is only applied with USE=ipv6, but then it's so invasive that a few other patches need special ipv6/noipv6 versions as well. I tried adding your patch to the unconditional PATCHES variable, e.g. PATCHES=( "${FILESDIR}/dnsroots.patch" ... "${FILESDIR}/tinydns-softlimit.patch" "${FILESDIR}/djbdns-dnscache-configurable-truncate-size.patch" ) As a result it wound up being applied before the ipv6 patch and the other conditional patches, but it looks like it doesn't apply cleanly there. It does work if I append it to $PATCHES after the conditional patching takes place, but only with USE=ipv6. Have you tried it without USE=ipv6?
(In reply to Michael Orlitzky from comment #5) > I see what happened. Despite it being a "worst practice," we have several > patches for djbdns that are conditionally applied. The ipv6 patch is only > applied with USE=ipv6, but then it's so invasive that a few other patches > need special ipv6/noipv6 versions as well. > > I tried adding your patch to the unconditional PATCHES variable, e.g. > > PATCHES=( > "${FILESDIR}/dnsroots.patch" > ... > "${FILESDIR}/tinydns-softlimit.patch" > "${FILESDIR}/djbdns-dnscache-configurable-truncate-size.patch" > ) > > As a result it wound up being applied before the ipv6 patch and the other > conditional patches, but it looks like it doesn't apply cleanly there. > > It does work if I append it to $PATCHES after the conditional patching takes > place, but only with USE=ipv6. Have you tried it without USE=ipv6? I have not. How would you like me to do this to make it as easy as possible for you?
(In reply to Jaco Kroon from comment #6) > (In reply to Michael Orlitzky from comment #5) > > Have you tried it without USE=ipv6? > > I have not. > > How would you like me to do this to make it as easy as possible for you? How hard would it be to make the same patch apply both with and without the ipv6 patch? The ipv6 patch changes "frequently" (in djbdns terms) so having three or four patches that depend on it is kind of a headache.
Shouldn't be too hard ... as long as the places I touch doesn't need to be too close, just need to sit down and get it done.
Objections to rebasing the ipv6 patch off of the other patches and including in-tree or devspaces rather? Decompressed the patch is 182KB big though, so too big for files/ ... and I don't have devspaces, but I don't mind it being on https://downloads.uls.co.za/gentoo/djbdns/ (doesn't exist yet, or I can at least drop it for you there)? But rebasing the IPv6 patch certainly would make your work easier, with the downside that should the patch ever change it becomes a matter of porting those changes from patch to patch ... and I really don't like the idea of patching the patch ... however, the "simple" way to manage these patches IMHO is to use git, check them into a separate "upstream" branch which you then merge into master/ and fix up as and when needed, but no matter how you approach this it gets messy. The problem with my patch is that the call to trancate on the if() statement is just prior to lines touched by the ipv6 patch, so we'd need zero-context which is not going to fly in any world.
On the other hand ... shouldn't we just include ipv6 support unconditionally? Is there a good reason in this and age to make it optional? Which then leads onto DNSSEC ... whilst I'm still not convinced, it is getting pushed, and that's going to also conflict with the ipv6 patch (which btw does a LOT more than it really needs to, if you look at some of the touched header files it's doing things like changing types of stuff from char* to char[4] - which I agree with but it makes no functional change and effectively makes maintaining other patches harder). Sorry for the spam ... No, DNSSEC is not currently a big concern. The truncate size is.
(In reply to Jaco Kroon from comment #9) > Objections to rebasing the ipv6 patch off of the other patches and including > in-tree or devspaces rather? > ... > But rebasing the IPv6 patch certainly would make your work easier, with the > downside that should the patch ever change it becomes a matter of porting > those changes from patch to patch Yeah, that's the catch. The ipv6 patch is pretty much the only one that changes, and it does so relatively often (once or twice a year -- often for djbdns). The approach you suggested is basically what I do whenever there's a new ipv6 patch. It takes a few hours to get everything rebased and then I'm always terrified that I've left off some "if (safe)" line that's going to turn into a security vulnerability. > On the other hand ... shouldn't we just include ipv6 support unconditionally? Is there a good reason in this and age to make it optional? Two reasons for me. The first is that it doubles the attack surface, and for many people it doesn't provide any benefits in return. I've been doing Computer Stuff for 20+ years in the US and neither I nor anyone I know IRL has ever encountered IPv6 in the wild. It just doesn't exist here, so you're safer with it off. The second is that I don't really like to have a package called "djbdns" that quietly adds 182KB of code from someone other than DJB. The decision to use the patch in the first place was made long before I took over maintenance though, so that battle was half-lost from the beginning. > Which then leads onto DNSSEC There's an easy solution for this at least. We'll call it net-dns/tinydnssec (using https://www.tinydnssec.org/ as upstream) and start over.
(In reply to Michael Orlitzky from comment #11) > (In reply to Jaco Kroon from comment #9) > > Objections to rebasing the ipv6 patch off of the other patches and including > > in-tree or devspaces rather? > > ... > > But rebasing the IPv6 patch certainly would make your work easier, with the > > downside that should the patch ever change it becomes a matter of porting > > those changes from patch to patch > > Yeah, that's the catch. The ipv6 patch is pretty much the only one that > changes, and it does so relatively often (once or twice a year -- often for > djbdns). The approach you suggested is basically what I do whenever there's > a new ipv6 patch. OK. I'll give you two truncate patches then :). > It takes a few hours to get everything rebased and then I'm always terrified > that I've left off some "if (safe)" line that's going to turn into a > security vulnerability. If you want eyeballs :). > > On the other hand ... shouldn't we just include ipv6 support unconditionally? Is there a good reason in this and age to make it optional? > > Two reasons for me. > > The first is that it doubles the attack surface, and for many people it > doesn't provide any benefits in return. I've been doing Computer Stuff for > 20+ years in the US and neither I nor anyone I know IRL has ever encountered > IPv6 in the wild. It just doesn't exist here, so you're safer with it off. If you didn't say IRL then I'd say "you do now", but since ours is a virtual interaction ... working on the ISP/ITSP front here, v4 is getting depleted, and whilst IPv6 traffic is fairly low currently, a fair number of content providers are starting to provide v6, the bigger show stopper currently is that whilst IPv4 in TCAM (hardware) routing is fairly well explored, the sheer size of an IPv6 address makes in inherently more difficult to do (effectively you need to route up to /48 in HW compared to /24 at worst). So our experience are the routers are currently not performing as well, and since most of that hardware isn't exactly 64-bit ... > The second is that I don't really like to have a package called "djbdns" > that quietly adds 182KB of code from someone other than DJB. The decision to > use the patch in the first place was made long before I took over > maintenance though, so that battle was half-lost from the beginning. Yea sorry, if you disabled v6 completely now I'd scream very loudly. I'd estimate about 75% of our incoming DNS queries currently are incoming over v6, primarily from google and cloudflare. > > Which then leads onto DNSSEC > > There's an easy solution for this at least. We'll call it net-dns/tinydnssec > (using https://www.tinydnssec.org/ as upstream) and start over. Happy. If I ever get around to it (really not a priority currently) I reckon we do that. Then again, based on what I've read I'm sure of one thing: I need to re-investigate if DNSSEC actually solves any real-world problems or whether it's just another of those that is really misleading. Given DJBs status, I reckon that he's got very good reasons for NOT incorporating that into djbdns. Maybe at that point you can drop v6 from djbdns completely and just bat people saying if they want ipv6 they need to use tinydnssec instead?
(In reply to Jaco Kroon from comment #12) > > OK. I'll give you two truncate patches then :). Do you still want to do this? I didn't forget (not entirely anyway).
Created attachment 885762 [details, diff] djbdns-dnscache-configurable-truncate-size-nov6.patch Sorry, similar here, as in didn't "entirely forget", just been busy, just took the 10 min now and did it.
Created attachment 885763 [details, diff] djbdns-dnscache-configurable-truncate-size-v6.patch Just updated the changelog part to indicate that this only applies on top of the IPv6 patch (for avoidance of doubt). Otherwise identical. This one is well tested, the -nov6 patch is only compile tested, so please do give it a shot. We've published a largetxt.uls.co.za record that is just over 512 bytes to enable testing for Mikrotik so that they can fix the client bug (which they've finally ACKed after a few months of back and forth).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9c51d1e85c83c2c1af71f61cc2f003374ca902c9 commit 9c51d1e85c83c2c1af71f61cc2f003374ca902c9 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2024-02-24 12:07:59 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2024-02-24 12:32:24 +0000 net-dns/djbdns: new revision with configurable UDP response limit This new revision allows the user to set TRUNCATELEN in the environment to a value between 512 (per the RFC) and 16384. This affects only the dnscache daemon and is useful in some cases to work around implementation bugs; for example, https://forum.mikrotik.com/viewtopic.php?t=200627 Thanks to Jaco Kroon for the patches. Closes: https://bugs.gentoo.org/916209 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> net-dns/djbdns/djbdns-1.05-r39.ebuild | 136 +++++++++++++++++++++ ...s-dnscache-configurable-truncate-manpages.patch | 53 ++++++++ ...-dnscache-configurable-truncate-size-nov6.patch | 83 +++++++++++++ ...ns-dnscache-configurable-truncate-size-v6.patch | 87 +++++++++++++ 4 files changed, 359 insertions(+)
