the round-robin patch (standard to the djbdns-1.05-r8 ebuild) causes dnscache to generate RR queries, which negates the use of the FORWARDONLY env var that causes dnscache to treat root/servers/@ as forward-only caches, and incidentally invalidates the use of root/servers/@. This renders the dnscache incapable of acting as a forward-only cache. forward-only caches, incidentally, are useful because they let you have an external cache that queries your ISP's nameservers for cache misses, rather than doing the lookups from the root ns's. Reproducible: Always Steps to Reproduce: 1. compile/install/configure 2. throw your isp's NS's into root/servers/@ 3. echo 1 > env/FORWARDONLY 4. #> host name.to.look.for host.dnscache.runs.on 5. watch the rr-patch generate lots of RR queries to the rootservers with your favourite sniffer ('tcpdump -i externalinterface port 53' works) Actual Results: root servers are queried massively, and the servers/@ is not respected as a cache Expected Results: ONLY hits to your isp's NS's should be seen (servers/@) no other info needed for reproduction. contact me for additional info if needed.
Can these crappy patches please be removed. These custom patches are breaking things. At a minimum there needs to be new USE variables for them to optionally be added. I don't understand how these can be in stable when they are extraneous and breaking a stable package that is used in production systems. You are driving people crazy and making them look bad for using Gentoo because the last place they would look for a problem like a broken forwarding cache would be that some fool broke forwarding to install custom patches they thought were cool.
Still around, jhhudso? Can this please be moved to a local USE flag?
Created attachment 22238 [details] /usr/portage/net-dns/djbdns/djbdns-1.05-r10.ebuild Please consider this submission as a fix for the round robin bug. It only removes the round robin patch from the 1.05-r8 ebuild
Comment on attachment 22238 [details] /usr/portage/net-dns/djbdns/djbdns-1.05-r10.ebuild This is unnecesary as adding the sticky bit on /var/dnscachex/root/servers/@ seems to have fixed the problem. Sorry about the previous posts.
still - use of the sticky bit would seem to depart from standard djbdns behaviour, which means that by default this package still behaves in a way that is contrary to documentation, no? In this case seemingly the package should either warn the user about this departure, or not depart at all...
Yes, please turn off the non-standard patches by default. I've been banging my head against a wall for the last 2 weeks wondering why dnscache wasn't acting the way the docs said it would, I only discovered the patches when I started clutching at straws and thought that maybe remerging the package would help and noticed portage adding the patches. After modifying the ebuild to forget about the round robin and forward zone patch it now seems to work fine. If your going to put patches like this in, portage really should put a big warning at the end of the emerge letting users know that the behaviour may be significantly different to that which is described in the djbdns docs at cr.yp.to
If this package is unmaintained, I volunteer to maintain it. But one way or another we should really see that this gets fixed...
pyrania, please take care of this, as it seems jared is afk
Sorry, but I don't understand the actual problem and don't like to break packages like this one.
Just sent out a mail to -core to hopefully internally recruit a new maintainer.
Updated djbdns to use local use flags to enable fwdzone and roundrobin, but not both at the same time. Also changed ipv6 to use orig ipv6 patch, since the only other patch we have only works with all 3 patches.
