Caching name server setup problems

[Michael Varre]

> -----Original Message-----
> From: Chris Buxton [mailto:cbuxton at menandmice.com]
> Sent: Tuesday, July 15, 2008 1:51 PM
> To: mike at jirc.com
> Cc: bind-users at isc.org
> Subject: Re: Caching name server setup problems
> 
> By default, recursion is on (which you want), and forwarding is off.
> If you set a nonempty forwarders list, the default is "forward first",
> as opposed to "forward only".
> 
> In any of these cases, if you ask it a question, it looks at your own
> authoritative data first. If that doesn't contain the answer, it looks
> at cached data. If that doesn't contain the answer, then it (depending
> on settings) performs recursion, forwards first, or just forwards.
> 
> Forward first: Send a recursive query upstream and wait a short time.
> If no answer is received, perform recursion directly. If the forwarded
> query is answered before recursion finishes, use that, otherwise
> complete recursion and use that answer.
> 
> Forward only: Send a recursive query upstream and wait for an answer.
> Do not perform recursion, ever.
> 
> In either of the above cases, with modern versions of BIND, multiple
> forwarders are queried according to the RTT algorithm - the fastest
> one is generally tried first.
> 
> Given that you're able to get recursion to complete in about 100 ms,
> you may not want to bother with forwarding. It just makes everything
> more brittle, and it makes you reliant on the security measures of
> your ISP.
> 
> To answer your other questions:
> 
> 1. With redundant resolvers, there is no way to share a cache. (You
> could use forwarding between them, but this is not a good solution -
> it's ugly, and it ends up being counterproductive.)
> 
> 2. Yes there is. Forward, either "first" (the default) or "only". You
> need to leave recursion on (the default); turning it off also turns
> off forwarding.
> 
> Chris Buxton
> Professional Services
> Men & Mice
> 

[Michael P. Varre] 

Thanks Chris that all makes perfect sense and I would agree that I might as
well keep my upstream ISP servers out of the loop.  It would just add an
extra place for something to fail.

I do have some issues with this working in practice however. I stress that
there is no firewall in between these, just a wide open point to point vpn
tunnel.  Port 53 is wide open and talking correctly and there are no views
created except for the default "single view".

I have recursion turned on, NO views (just the default of course). I don't
have any forwarders listed at all.  And I have several local test zones
added for this server to be authoritative for.

****When I dig @localhost.com publicdomain.com from the mynsserver, I get
the proper answer and it is cached.

****When I dig @mynsserver publicdomain.com from a server on the same 172
subnet as mynsserver I get the right answer and it gets cached.

****when I dig @mynsserver publicdomain.com from a machine on a different
subnet, yet still internal, and no firewall in between, I get:

; <<>> DiG 9.3.2 <<>> @172.16.0.60 dumb.com a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 2022
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dumb.com.                      IN      A

;; Query time: 17 msec
;; SERVER: 172.16.0.60#53(172.16.0.60)
;; WHEN: Tue Jul 15 14:30:42 2008
;; MSG SIZE  rcvd: 26


****but when I dig @mynsserver localzone-on-mynssserver I get the correct
address.