[dns-operations] forwarding to a forwarder

[Dave Warren]

On 2016-01-18 11:13, Doug Barton wrote:
> On 1/17/2016 8:43 PM, Randy Bush wrote:
>> A is a bind 9 where foo.bar is forwarded to B
>> can an unbound on C forward foo.bar to A?
>
> Yes. The only disadvantage to this configuration is that you get 
> double-caching, so on average you'll have a full TTL period for a 
> change to make it all the way back to C. For this reason I always 
> recommend slaving instead of forwarding, but when that's not possible 
> this is the next-best solution.

I'm not sure that changes caching vs a single resolver, does it? 
Shouldn't a caching resolver age the TTL on entries in it's cache, such 
that subsequent queries shouldn't end up over-caching, but rather, they 
should just get the remaining cache based on the original resolution.

To test this, I picked www.google.dk and verified that it's not yet 
cached on any server (we have no .dk users here, so it seemed like a 
good example). I checked against three servers here, 172.24.0.1 is the 
"real" resolver, 172.24.0.20 and 172.24.0.40 are configured to forward 
to 172.24.0.1 (and otherwise cache on their own)

Initially I just ask dig to work out www.google.dk:

; <<>> DiG 9.9.5-W1 <<>> www.google.dk a
;; ANSWER SECTION:
www.google.dk.          300     IN      A       173.194.33.184
www.google.dk.          300     IN      A       173.194.33.191
www.google.dk.          300     IN      A       173.194.33.183
www.google.dk.          300     IN      A       173.194.33.175
;; SERVER: 172.24.0.20#53(172.24.0.20)

I then waited a bit, and repeated the query, but now against all three 
servers: with .1 and .20 having cached entries, but .40 does not (I 
checked, again), and I still get the same TTL:

; <<>> DiG 9.9.5-W1 <<>> www.google.dk a @172.24.0.1 +noall +answer
www.google.dk.          142     IN      A       173.194.33.184
www.google.dk.          142     IN      A       173.194.33.191
www.google.dk.          142     IN      A       173.194.33.183
www.google.dk.          142     IN      A       173.194.33.175

; <<>> DiG 9.9.5-W1 <<>> www.google.dk a @172.24.0.20 +noall +answer
www.google.dk.          142     IN      A       173.194.33.175
www.google.dk.          142     IN      A       173.194.33.184
www.google.dk.          142     IN      A       173.194.33.191
www.google.dk.          142     IN      A       173.194.33.183

; <<>> DiG 9.9.5-W1 <<>> www.google.dk a @172.24.0.40 +noall +answer
www.google.dk.          142     IN      A       173.194.33.191
www.google.dk.          142     IN      A       173.194.33.183
www.google.dk.          142     IN      A       173.194.33.175
www.google.dk.          142     IN      A       173.194.33.184

 From a caching perspective, this is no different than if we didn't have 
multiple resolvers forwarding and instead just had everyone directly 
query one single Unbound resolver instance. I also reproduced this in 
another case, where 172.24.0.1 itself was configured to forward a 
particular zone across a VPN, the results are the same.

Or are there cases where a forwarding resolver obtains the original TTL 
from an upstream resolver's cache somehow? I didn't see an obvious case 
in my infrastructure (which includes BIND, unbound and Windows DNS 
resolvers), although I could easily have missed it and would appreciate 
knowing if I've misunderstood something here.

The only real issue I did bump into was that this effectively breaks 
pre-caching schemes since the forwarding resolvers don't see the full 
TTL and therefore pre-cache based on smaller values.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren