Need help on delegation to subdomain/external servers

[Kevin Darcy]

RUOFF LARS wrote:
> Hello,
>
> Thanks for your detailed answer.
> I think I don't have enough DNS knowledge to understand every bit of it,
> but I'll try to clarify.
>  
> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Kevin Darcy:
>   
>> RUOFF LARS wrote:
>>     
>>> Hi,
>>>
>>> i'm using BIND9 on an Ubuntu-8.10-server.
>>> I'd like to configure the following:
>>> For a given name (eg. vega.lab.ts), I'd like to forward the 
>>>       
>> request to 
>>     
>>> two external DNS servers, *simultaneously*, and respond 
>>>       
>> with the first 
>>     
>>> response that i get.
>>>
>>> Is this possible?
>>>   
>>>       
>> Short answer: not possible with BIND currently, that I know of.
>>
>> Longer answer: why would you even want to do this? Sounds 
>> like you're barking up the wrong tree. Latency of DNS 
>> response may have little or nothing to do with the latency of 
>> whatever real-time connection (HTTP, LDAP, VoIP, video, 
>> audio, whatever) is being established using that DNS 
>> information. Trying to equate DNS response latency to 
>> anything else that a user would care about, is an exercise in 
>> futility, IMO.
>>
>>     
> The reason for this is:
> I have a hot-swap redundant system where 1 out of 2 servers is active at
> any given time and the other is standby. DNS is (mis?-)used to tell the
> clients which one is active at a given moment.
> The idea is that clients resolve a name of the server and the result is
> the address of the server that is currently active. (Only the current
> active server responds to DNS queries for its own name).
>   
DNS isn't really suited to this. If you control a node that the network 
paths to both servers share in common, then you could put a (simple) 
load-balancer or "traffic cop" of some sort at that node which 
dynamically directs the traffic to the currently active server. Of 
course, having a node in common like that represents a Single Point of 
Failure, so either you have more diversity or you accept that the Single 
Point of Failure exists and incorporate that into your availability 
expectations.

If the servers are completely diverse, then you might need a commercial 
load-balancing solution, "anycast", some sort of redirect scheme, etc.

You might want to check out the companion web pages 
http://www.tenereillo.com/GSLBPageOfShame.htm and 
http://www.tenereillo.com/GSLBPageOfShameII.htm>.

>   
>> Furthermore, have you considered caching? Once the answer is 
>> cached, then a BIND nameserver won't try to fetch the 
>> information from other servers *at*all*, until that cache 
>> entry expires.
>>     
>
> The server uses TTL=0 in order to inhibit any caching on clients.
>   
I hope this stays on a private network then, because TTL=0 is considered 
quite anti-social on the Internet. It makes everyone who queries your 
nameservers work significantly harder than they should.
>
>   
>> If your goal is to optimize application performance by always 
>> directing users to a "best" node, among a set or cluster of 
>> nodes, then put a load-balancer in front of this resource: on 
>> the back-end, it can measure latency or any other metric(s), 
>> which is most representative of the "user experience" for 
>> this resource (depending on the probing/measurement 
>> capabilities of the load-balancer device/package/subsystem). 
>> On the front-end, the load-balancer responds with whatever IP 
>> represents the "best" choice for that resource, at any 
>> particular point in time. As with any DNS-based 
>> load-balancing scheme, you might have to lower the TTLs of 
>> the relevant records to
>> ridiculously- (possibly anti-socially-)low values in order to 
>> provide sufficiently-dynamic load balancing.
>>
>>     
>>> I didn't see how to do it directly, so i tried using a 
>>>       
>> subdomain, (eg.
>>     
>>> x.vega.lab.ts) and specifiying the two DNS for this subdomain:
>>>
>>> Extract from the lab.ts zone file:
>>> [...]
>>> x.lab.ts.       IN      NS      vega-a.x.lab.ts.
>>> x.lab.ts.       IN      NS      vega-b.x.lab.ts.
>>> vega-a.x.lab.ts.        IN      A       172.25.32.252
>>> vega-b.x.lab.ts.        IN      A       192.168.2.3
>>> [...]
>>>
>>> But this doesnt seem to work:
>>> named-checkzone lab.ts /etc/bind/db.lab.ts says:
>>> zone lab.ts/IN: x.lab.ts/NS 'vega-a.x.lab.ts' (out of zone) has no 
>>> addresses records (A or AAAA) zone lab.ts/IN: x.lab.ts/NS 
>>> 'vega-b.x.lab.ts' (out of zone) has no addresses records (A 
>>>       
>> or AAAA) 
>>     
>>> zone lab.ts/IN: loaded serial 2 OK
>>>   
>>>       
>> I just ran a quick test, and it appears that named-checkzone 
>> actually goes out and tries to resolve glue records it 
>> encounters. Since you haven't delegated the zone yet, it's 
>> not surprising that the glue records don't resolve from the 
>> authoritative nameservers for the zone. 
>> In this respect, I think named-checkzone is being more 
>> rigorous than named itself would be, as it loads the zone. If 
>> these "no addresses records [sic]" errors are the *only* ones 
>> being reported for the zone, then I'd try to load it and see 
>> if those errors magically evaporate once you do that.
>>
>>     
> Well, I tried this, but it doesn't seem to work.
> I got no answer for vega.x.lab.ts, although the end serve was configured
> properly.
>   
Do I understand correctly? The zone loaded successfully, including the 
delegation of x.lab.ts from lab.ts, and at least one of the delegated 
nameservers can resolve its own name, but named-checkzone is *still* 
complaining about not being able to resolve the glue records into 
addresses?

What happens if you just look up that name from the command line on the 
same box? How about a dig +trace?

- Kevin