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?
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@sidn.nl W http://www.sidn.nl/
-----Original Message----- From: dns-wg-admin@ripe.net [mailto:dns-wg-admin@ripe.net] On Behalf Of Jim Reid Sent: Sunday, April 27, 2008 7:41 PM To: dns-wg@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?
Jim Reid wrote:
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?
I was hoping to have more time to give detailed review of the recommendations, but I haven't yet. I do have an overall concern that the document is too BIND-centric, and by mixing the discussion of the concepts with the discussion of the implementation it makes the document much more difficult to understand, particularly for those who do not use BIND. My first suggestion would be to split the document into concept and implementation pieces. In my mind the ideal way to handle the implementation (i.e., the BIND-specific instructions) would be in an appendix. You could refer to the appropriate section of the appendix at the end of the section that discusses the concept. This would also make it easier for people who want to contribute additional appendices with implementation instructions for other software to do so. I'll try to follow up with more detailed discussion of the concepts discussed in the document if time allows. Doug
On May 2, 2008, at 19:10, Doug Barton wrote:
My first suggestion would be to split the document into concept and implementation pieces. In my mind the ideal way to handle the implementation (i.e., the BIND-specific instructions) would be in an appendix. You could refer to the appropriate section of the appendix at the end of the section that discusses the concept. This would also make it easier for people who want to contribute additional appendices with implementation instructions for other software to do so.
I'll try to follow up with more detailed discussion of the concepts discussed in the document if time allows.
This looks like the document has at long last found a new editor! :-) I can live with the document as it is, modulo minor tweaks for clarifications or typos. So if the WG wants to continue work on the document, I think it has to find someone with the time and inclination to do that. Doug, are you willing to become the document's owner/shepherd? Of course this also assumes that the WG has a wish to keep the document alive. It's not yet clear what, if anything, should be the next steps for it and I'd like to get a feel for that when the WG meets next week.
Jim, On 27 Apr, Jim Reid wrote: | 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? ==> I know, it's quite late but I have just found time to review this document. In case it's not too late, please find below my remarks and suggestions. It's up to the authors to take all or part of it into account. First, I have some general comments: 1) I would recommend to use RFC3330 addresses for example IPv4 addresses. That's to say, within: 192.0.2/24 2) It would be a good idea (and also helpful by the way for administrators) to give examples of Name Servers supporting IPv6 transport (numbering within 2001:db8::/32, RFC 3849) In that case, all illustrations with IPv4 addersses would be completed by IPv6 addresses, when needed. 3) I think that it would be better to choose an NS list for example.com zone, such that not all of them be inside the zone itself For example: example.com. IN NS master.example.com. IN NS slave.example.net. and later "slave.example.org" (for the replacement). Attached below are my comments and suggestions (with '^' for locating the context and "==>" for my text). For readers only interested in the "diffs" a diff file is also attached. Mohsen.
Hi Regarding the first point. (use of RFC3330 address), this was a doubt I had when creating the original document. But using only this range would introduce confusion in the document, because I would need to subnet it and the different address ranges would all look the same. So after speaking with other RIPE people we decided to use algo RFC 1918. I think it¹s use doesn¹t create any problem if examples are literally used and help the reader to understand the document. Regarding the other two points. I agree with them. If I can help in rewriting this elements (the examples and graphs, because my english is not so good), I¹ll be glad to do it. The corrections to the document look ok to me in a first sight. Regards, Fernando Garcia El 09/06/08 14:27, "Mohsen Souissi" <mohsen.souissi@nic.fr> escribió:
Jim,
On 27 Apr, Jim Reid wrote: | 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?
==> I know, it's quite late but I have just found time to review this document. In case it's not too late, please find below my remarks and suggestions. It's up to the authors to take all or part of it into account.
First, I have some general comments:
1) I would recommend to use RFC3330 addresses for example IPv4 addresses. That's to say, within: 192.0.2/24
2) It would be a good idea (and also helpful by the way for administrators) to give examples of Name Servers supporting IPv6 transport (numbering within 2001:db8::/32, RFC 3849)
In that case, all illustrations with IPv4 addersses would be completed by IPv6 addresses, when needed.
3) I think that it would be better to choose an NS list for example.com zone, such that not all of them be inside the zone itself
For example:
example.com. IN NS master.example.com. IN NS slave.example.net.
and later "slave.example.org" (for the replacement).
Attached below are my comments and suggestions (with '^' for locating the context and "==>" for my text). For readers only interested in the "diffs" a diff file is als <<image.png>> o attached.
Mohsen.
-- Fernando García Fernández Responsable de Dominios D.G. Telecomunicaciones, Redes y Sistemas Josefa Valcarcel, 26 Edificio Merrimack III Madrid - 28027 Tel. Fijo: (+34) 901900900 ext 40383 Fax: (+34) 914313240 Tel. Móvil: (+34) 649428591 E-mail: fernando.garcia@tecnocom.es http://www.tecnocom.es Por favor, antes de imprimir este mensaje, asegúrate de que es necesario. Ayudemos a cuidar el medio ambiente Confidencial. Para uso exclusivamente interno. Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente.Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.El correo electrónico vía Internet no permite asegurar la confidencialidad de los mensajes que se transmiten ni su integridad o correcta recepción. Tecnocom no asume ninguna responsabilidad por estas circunstancias. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by a professional privilege or whose disclosure is prohibited by law. If you are not the intended recipient you are hereby notified that any read, dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it.Internet e-mail neither guarantees the confidentiality nor the integrity or proper receipt of the messages sent. Tecnocom does not assume any liability for those circumstances.
participants (5)
-
Antoin Verschuren -
Doug Barton -
García Fernández, Fernando -
Jim Reid -
Mohsen Souissi