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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
