Fail-over

[Kevin Darcy]

I'm not sure what you're describing here. Let's say I have a nameserver 
that's only authoritative for the  "foo.com" zone. It gets a query for 
"bar.com", and it has this new "failover" feature enabled. How does the 
query get resolved and what response is given back to the client?

Or, did you actually mean "if I cannot find a record *in* a zone [for 
which] I am authoritative ..."? That's quite a different thing. In that 
case, please explain how this "failover" would work in the NODATA case 
(the name exists in the zone, but none of the records with that name 
match the QTYPE of the query), or when the zone contains a wildcard 
record which, in the absence of this new feature, would otherwise match 
the query.

Moreover, if it is your intention to enable recursion to other 
nameservers even for queries of a zone defined as authoritative on your 
server, please clarify whether you would perform this recursion even 
when the client's query did not ask for that capability (RD=0). Please 
explain how you intend to handle failures (timeouts, SERVFAIL from the 
authoritative server(s)) of the recursive part of this query. How do you 
communicate those types of failures back to the client, if at all?

What if you get inconsistent data from the authoritative servers for 
this "failover" zone? Do you give inconsistent answers back to the 
clients? Do you increment the SOA serial # whenever you give an 
inconsistent answer to indicate that the contents of the queried zone 
have "changed" in some way? After all, you are claiming authority for 
that zone, so the only way you should be giving inconsistent answers 
from that zone is if the zone data itself is changing, and if it is 
changing, then the SOA serial # should be changing also to reflect that...

                                                                         
                                                      - Kevin

Nicola Canepa wrote:

>I am writing a little patch for BIND which would allow failover between
>a DNS server and another: you do a query, and if I cannot find a record
>for a zone I am authoritative, I look in another zone/domain.
>
>Could this be useful?
>
>Nicola
>
>On Tue, 2005-02-22 at 21:35 -0500, Kevin Darcy wrote:
>  
>
>>Norman Zhang wrote:
>>
>>    
>>
>>>>>I've a dual WAN router, currently some of my servers are 
>>>>>bound with static IPs to ISP1. I like them to remain 
>>>>>available on ISP2 if ISP1 goes down. Do I need dynDNS service 
>>>>>for this? Or I can type in 2 different IPs for 1 serivce.
>>>>>
>>>>>e.g.,
>>>>>
>>>>>1.2.3.4 IN www.example.com #ISP1
>>>>>2.3.4.5 IN www.example.com #ISP2.
>>>>>
>>>>>But internet may still resolve to 1.2.3.4 despite ISP1 being 
>>>>>down. May I ask what the best way to go about this?
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Probably the best way to do this would be to do BGP to both of the ISPs.
>>>>With BGP, people will be able to get to your servers (with ISP1 IP
>>>>addresses) through ISP2 when ISP1 is down.
>>>>   
>>>>
>>>>        
>>>>
>>>Thanks for your suggestion. I can't use BGP. ISP1 and ISP2 are 
>>>competitors. 8( Is there some way of doing this with BIND?
>>>
>>>      
>>>
>>No good way, no. You could have a script automatically change the A 
>>record (Dynamic Update would probably be the cleanest way) if it senses 
>>a failure on the ISP1 connection. Unfortunately, you'd have to lower 
>>your TTLs to low levels -- perhaps anti-socially low levels -- in order 
>>to provide any kind of reasonable failover time for Internet clients.
>>
>>The long-term solution is for browsers to use SRV records (think a level 
>>of indirection above A records, with preferences and weighting, or, if 
>>you prefer, MX records on steroids that aren't limited to mail 
>>exchange). But adoption of the SRV mechanism seems to be taking a long time.
>>
>>                                                                         
>>                                          - Kevin
>>
>>
>>
>>    
>>