This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/dns-wg@ripe.net/
[dns-wg] NOTIFY
- Previous message (by thread): [dns-wg] Analysis of NSD
- Next message (by thread): [dns-wg] NOTIFY
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jim Reid
jim at rfc1035.com
Thu Oct 28 11:08:22 CEST 2004
>>>>> "Peter" == Peter Koch <pk at TechFak.Uni-Bielefeld.DE> writes: >> As it happens we use probing not NOTIFY since it gives a >> greater level of control over the number of secondaries being >> updated at once (and the Peter> NOTIFY already specifies precautions against a 'rush', Peter> although implementations may differ and depending on the Peter> size of the zone 'at once' may have different meanings. Yes. But BIND's implementation of this feature is meant for the case when there are lots of zones that get changed and reloaded. [And there are no control hooks for setting the delay interval IIRC.] The server staggers the sending of NOTIFYs to reduce the potential for an axfr storm. The feature doesn't really help when there's a huge zone. Like co.uk... >> bandwidth) and the order in which they are updated. This does >> rely on strict calculations of the timings of changes and >> probes but that is fairly easy to do. Peter> How about sending the NOTIFY messages out of band instead Peter> of relying upon retry (and not refresh?)? There's a little Peter> 'DoS' potential, though. How about rndc refresh or rndc retransfer in 9.3? It's not really an out of band NOTIFY, though the effect is the same. Note the new Subject since this thread isn't talking abouut an analysis of NSD any more.
- Previous message (by thread): [dns-wg] Analysis of NSD
- Next message (by thread): [dns-wg] NOTIFY
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]