Better solution than making a recursive nameserver authoritative?

[David Coulthart]

On Jun 24, 2011, at 3:33 PM, Phil Mayers wrote:
> On 06/24/2011 06:39 PM, David Coulthart wrote:
> 
>> configure the zone as forward first, the recursive nameserver gets
>> back the NS delegation&  then uses that to perform an iterative query
>> against the authoritative nameserver for the subdomain.  This
>> actually seems like it might solve my issues.  Are there any problems
>> with this setup I'm not seeing (other than the quirk of sending a
>> recursive query to the forwarder when it is authoritative only)?
> 
> forward first is the wrong tool; if the upstream nameservers are down (or fail to answer) it'll go to the internet, which you don't want.

This was what I was worried might happen with forward first.  Thank you for confirming.

> static-stub, introduced in bind 9.8 are what you want (see below)
> 
>> There have been a few other, slightly crazier, ideas I've thought of
>> or have been suggested to me.  But I figured I would start with these
>> as they are likely the simplest.  However, other recommended
>> solutions are always appreciated.
> 
> "type static-stub". These are designed for this purpose - they send non-recursive queries to the server-{addresses,names} you define, and will honour delegations, as opposed to forward zones that send recursive queries and expect a full reply.

I was wondering about static-stub.  Based on my reading about stub zones, I thought a (static) stub zone would cause my recursive nameserver to return answers for the stub zone with the AA bit set.  I thought a stub zone was like a "mini-slave" zone where the nameserver doesn't have a local copy of the zone file but will answer authoritatively after directly querying the authoritative nameserver.

However, testing reveals that, as you describe, this does do exactly what I want.  Configuring my recursive name server with a static-stub zone, it sends a non-recursive query to the specified server-address & iteratively follows the delegation & returns an answer to the original client without the AA bit set.  Also, I see from the decreasing TTL when I repeat the query that the recursive nameserver is indeed answering from cache.

> I didn't really understand why you needed or thought you needed views, so if you can expand, possibly people can give you a fuller answer.

For the RFC 1918 reverse zones I don't really need views as I could just restrict allow-query in those specific zones to our local networks on our authoritative nameservers.  However, if I don't want my recursive nameservers to be authoritative for those RFC 1918 zones, I do need some way to configure them to use my authoritative nameservers for those zones instead of the ones listed in the delegation NS RRsets in the in-addr.arpa zone.  It looks like static-stub will solve this problem.

For my forward zones, this is where I end up needing views on my authoritative nameservers.  The reason we use views today is for the external world we want www.columbia.edu to be a CNAME pointing to an Akamai service that fails over to backup content on their servers if our Internet connection goes down.  For users on our network, we want www.columbia.edu to always point directly to our local load balancer, so that if our Internet connection goes down they can still get to our home page (e.g., for emergency announcements).

Additionally, a "problem" with our current zone data is we publish records in our external forward zones that point to RFC 1918 IP addresses.  For example, there is the server foobar.columbia.edu with a public IP address but it also has an IP accessible console at foobar-console.columbia.edu with a RFC 1918 IP address b/c it should only be accessible from within our network.  Currently, both of those A records are in both our external & internal views for the columbia.edu zone.  Since I already need two separate views for the reason given above, I was hoping to clean this up as well and only publish the foobar-console.columbia.edu A RR in the internal view of columbia.edu while foobar.columbia.edu would be in both views.

However, as I originally described, not all of our authoritative nameservers are completely under my control, so I can't configure them all with the two views.  So I need a way to force our local recursive nameservers to only use those authoritative nameservers that have both views.  Again, static-stub looks like it will do this nicely.

If there are ways to achieve the same results for my forward zones without views, I would love to know them.

Also, are there any caveats I should be aware of using static-stub?

Thanks,
Dave C.