DNS Racing -Multi ISP load balancing with failover using DNS.

Matus UHLAR - fantomas uhlar at fantomas.sk
Thu Jun 2 11:19:27 UTC 2011

>>> On 31/05/11 09:28, Matus UHLAR - fantomas wrote:
>>>> This problem could be avoided by providing the same data, but differently
>>>> sorted, correct?
>> On 31.05.11 12:27, Phil Mayers wrote:
>>> Not really. Client side sorting may take place (e.g. to comply with RFC
>>> 3484 policies in calls to getaddrinfo) and destroy any server-side
>>> sorting.

> On 01/06/11 08:11, Matus UHLAR - fantomas wrote:
>> by "this problem" I mean the DNSSEC. Providing all the data just differently
>> sorted would cause them to be DNSSEC compliant, wouldn't it?

On 01.06.11 10:55, Phil Mayers wrote:
> Yes, but the client would then re-sort the data, so it wouldn't achieve  
> the original purpose. Sorting the data server side gives you essentially  
> no control over which record the client will pick if they are calling  
> getaddrinfo, as is likely.

Aha, I've got it. However data sorting at client's side should not affect
much clients, only where
- the client has sorting set up
- the sorting client prefers one of IP's used in RRset.

We have set that up to prefer IPs from our network over foreign.

> As Mark has already pointed out, the approach is not intrinsically  
> DNSSEC-hostile. It's perfectly legitimate to serve different data with  
> different, valid, signatures. This is what happens with signature regen  
> and key rollover. In this case, it would just be a permanent case of  
> rollover - one KSK, one ZSK per "dns server" and different copies of the  
> zone.

With sorting, they need only one copy of each zone.

> I withhold judgement on whether it's a good approach in general. I  
> suspect it's just GSLB-lite personally.

Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
42.7 percent of all statistics are made up on the spot. 

More information about the bind-users mailing list