Zitat von Gábor Lénárt <[email protected]>:
Hi,
We're using unbound in forked mode, according to our tests, it gives the
best performance for us. This setup has been running since months without
any problem. However we've just got an interesting question:
A user with his authoritative zone on a server has changes one of his
records. When he used our caching-only nameserver running unbound his
experienced that quering the same name server of us cause to get different
results if he repeat the test (of course this situation only lasts for
a time maximized by the TTL of the old record, if I am right).
I guessed it's because the feature that in forked mode, unbound has
separated caches for each processes, so if the customer's request is got by
process "A", then process "B", then again process "A", he can get different
answers.
Now I am wondering that this kind of behaviour is a problem, isn't it banned
by any kind of RFCs? For sure, that's clear that two different name servers
can give different results for a while after some change in the
authoritative name server, since recursive servers can caches result.
However this case is a bit different as user can think that he queried the
same nameserver, so it shouldn't result with 'flapping' result. Sure, he
does not need to think about the internal structure of our unbound setup.
I have the idea that it's some kind of similar case as I would have a load
balancer and multiple name servers behind it. But again: I am not sure, it's
a good example, as load balancers may "remember" that a connecting peer's
connection should be forwarded for the same backend server, to achive
consistancy.
Please share your opinions about this topic with me, and sorry if I am
off-topic with this one ...
The user which is not aware of the TTL problem will not choose a
nameserver to use but let the system configured resolvers do its job.
As by other means it could be different which resolver actually get
used the results will differ anyway. It is therefore good practices to
lower the TTL at least 2*old-TTL before the change and raise it
afterwards. User which choose the resolver to use "by hand" should be
aware that results within $TTL are inconsistent after a change.
Regards
Andreas
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
