Bugzilla Bug 31238

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 an attachment (id=22238) [edit]
/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

(From update of attachment 22238 [edit])
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.