Forward vs Authoritative traffic

Chris Buxton clists at buxtonfamily.us
Fri Nov 7 21:41:36 UTC 2014


On Nov 7, 2014, at 1:32 PM, Nex6|Bill <n6ghost at yahoo.com> wrote:
> 
> 5 sec TTL, with a lot of  load balancer based rules. on a lot of servers…..

I'm not sure what difference that makes. You said the load balancer is authoritative for a child zone. Therefore, don't forward to it, send it iterative queries. You do that using a zone of any of the following types on your server: slave, stub (may not work with a LB), or static-stub.

Slave: You would slave the parent zone from your parent org. This way, your server has the delegation on hand to use when answering queries for the child zone on the LB. There are several potential pitfalls with this approach, such as not being able to slave the zone from the parent org.

Stub: You would stub the delegated subzone from the LB. May not work. You would be telling your server, "Ask this server (the LB) what servers are authoritative for this zone (the zone on the LB), and then when you get a query for this zone, if you don't have the answer in cache, send an iterative query to one of the indicated servers in order to resolve it." The LB may not support SOA and NS records, in which case the stub zone would fail.

Static-stub: You would be telling your server, "When you get a query for this zone (the zone on the LB), if you don't have the answer in cache, send an iterative query to the LB in order to resolve it." That sounds to me like it's exactly what you want.

Type forward is virtually identical to type static-stub, except it sends recursive queries instead of iterative queries. This is generally bad practice (it might work fine, or it might have unintended consequences or otherwise fail, in a hard-to-diagnose way) unless the forwarder accepts recursive queries. So type static-stub is probably what you want.

Chris

> On Nov 7, 2014, at 1:31 PM, Chris Buxton <clists at buxtonfamily.us> wrote:
> 
>> On Nov 7, 2014, at 1:29 PM, Nex6|Bill <n6ghost at yahoo.com> wrote:
>>> 
>>> our parent org, owns the  parent zone, and this zone is delegated from there to a load balancer onsite. which is authoritative.  but, the query path for a normal query crosses the internet gateway because thats where the parent
>>> is. ( very short TTL ).
>>> 
>>> any internet connection issue causes issues, so i am going to put a forward zone directly from my NS to the load balancer which is auth for the zone. that way, if the internet gateway is down or has issues the application will still function.
>> 
>> I suspect a static-stub zone is more what you want, but yes, that sounds like it should work.
>> 
>> Chris
>> 
>>> On Nov 7, 2014, at 1:04 PM, Chris Buxton <clists at buxtonfamily.us> wrote:
>>> 
>>>> On Nov 7, 2014, at 11:35 AM, Nex6|Bill <n6ghost at yahoo.com> wrote:
>>>>> 
>>>>> I am going to be adding a type forward zone for an important zone.  how can i test that the forward is working correctly? if i do a dig against the NS the record will return no matter if its auth or fwd zone. 
>>>> 
>>>> Will your server be receiving recursive or iterative queries (rd=1 or rd=0) for the zone? Forwarding zones like this don't work for iterative queries.
>>>> 
>>>> Chris
>>> 
>> 
> 



More information about the bind-users mailing list