I'm at the point of changing the existing and working djbdns to unbound.
This is due to an unsupporting DNSSEC by djbdns.
But unfortunately I've found that round-robin balancing don't really
works via unbound. It receives first reply from primary server,
puts it in the cache and then returns it always until the TTL is expired.
So, I think that it's a good idea to implement an availability of
'no-cache' option which will affect to defined zone.
There are enough of situations when some zone shouldn't be cached.
But unfortunately I've found that round-robin balancing don't really
works via unbound.
It doesn't always shuffle multiple A-Records around when it returns
them, but it does return all the records for round-robin names. Looks
compliant to me.
It receives first reply from primary server, puts it in the cache and
then returns it always until the TTL is expired.
So...it does exactly what it's supposed to be doing?
Does the name you're querying use real round-robin, that is, it returns
multiple A-records? Or does it return one record only, but a different
one every time you query? In that case, that zone is broken. That is
*not* what round-robin means, they're doing it wrong. They need to
either return all relevant A-records, or at the very least reduce the
TTL to only a few seconds to make sure their pseudo-round-robin isn't
killed by legitimate caching on recursors.
So, I think that it's a good idea to implement an availability of
'no-cache' option which will affect to defined zone.
There are enough of situations when some zone shouldn't be cached.
First of all, no, not really. Secondly, in this case that zone should
be announcing a very low TTL, not expect recursors to magically know
not to cache entries, even though they're announced as cacheable.
But unfortunately I've found that round-robin balancing don't really
works via unbound. It receives first reply from primary server, puts
it in the cache and then returns it always until the TTL is expired.
Reordering the records is supposed to be pointless these days because
clients are expected to sort them, basically according to the length
of the shared prefix. RFC 3484 has the details. Don't be fooled by
the title, the RFC is not (only) about default address selection, and
not about IPv6 either, it also deals with how DNS (stub) resolvers
report addresses to applications.
I think the RFC is fundamentally wrong, but the IETF has not updated
it, and the GNU libc folks (among others) treat it as gospel.
But unfortunately I've found that round-robin balancing don't really
works via unbound. It receives first reply from primary server, puts
it in the cache and then returns it always until the TTL is expired.
Reordering the records is supposed to be pointless these days because
clients are expected to sort them, basically according to the length
of the shared prefix. RFC 3484 has the details. Don't be fooled by
the title, the RFC is not (only) about default address selection, and
not about IPv6 either, it also deals with how DNS (stub) resolvers
report addresses to applications.
I think the RFC is fundamentally wrong, but the IETF has not updated
it, and the GNU libc folks (among others) treat it as gospel.
Thank you for your answer! I'm sorry, but I don't clearly understand
what you want to say? Does this feature limitation of unbound
is by-design? And can it be fixed by any reconfiguration of primary DNS
server which is running BIND? Or there is a hope that developers of unbound
will made a transparent-forward feature.
Just for note, djbdns works properly in this case, it gets by
including required zone to forward section. In other case it resolves
and cache zone via root servers.