[Unbound-users] answer consistency in case of forked mode

[lst_hoe02 at kwsoft.de]

Zitat von Gábor Lénárt <lgb at lgb.hu>:

> 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