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/[email protected]/
[dns-wg] Updated DNS migration document
- Previous message (by thread): [dns-wg] Updated DNS migration document
- Next message (by thread): [dns-wg] DNS WG Agenda for RIPE 56
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Antoin Verschuren
Antoin.Verschuren at sidn.nl
Mon Apr 28 10:08:04 CEST 2008
Hi Jim, all, Following the observations made on the IETF DNS-operations mailinglist (http://lists.oarci.net/pipermail/dns-operations/2008-February/002526.html) I think we're missing a step in chapter 3. In order for the old and new master server to serve the same data, and to give caches the opportunity to update to the new NS set, it is advised that an old master server starts serving the zone as a secondary for a period of time at least equal to the expire time of the zone once the delegation has been changed at the parent. It will prevent the undesired behavior that caches keep updating against the old master. One could say that deleting the zone from the old master will also update the caches, but this will require more queries and involves queries to the parents which are not needed when the old master replies the correct data when running secondary. Also, changing a master server usually also involves competitive dns-operators. Usually the change is done because the new operator offers a service the old operator could not, and they want this change in the zone as soon as possible. They will not wait for the change to be fully propagated, which results in 2 master servers serving different data. I would say to change 3.7 and include that an old master server should run secondary for a period of time at least equal to the expire time once the parent changed the delegation, before deprovisioning it and no longer answering for the zone, as the most optimal solution. The last paragraph in section 3.0 is also not clear enough on this. Should one not update, or update on the new master only ? And how should these changes be propagated to the old master ? Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ > -----Original Message----- > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of > Jim Reid > Sent: Sunday, April 27, 2008 7:41 PM > To: dns-wg at ripe.net > Subject: [dns-wg] Updated DNS migration document > > Here is the latest version of the DNS migration document. I've > included the comments made by Joao and Jarle. Does anyone have > anything else to add?
- Previous message (by thread): [dns-wg] Updated DNS migration document
- Next message (by thread): [dns-wg] DNS WG Agenda for RIPE 56
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]