>>> 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. Correct -- Matus UHLAR - fantomas, uh...@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. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
