Jim Reid <jim@rfc1035.com> writes:
At long last, there is progress on AP49.1. I have revised the document that Fernando presented to the WG. It's attached below. Comments and feedback are welcome. Some comments below: [ ... ] 2.2 Check the new server is authoritative for the zone
Once the new slave server is answering authoritatively for example.com, this should be verified with a DNS query utility such as dig: % dig @10.9.8.7 example.com soa [ ... ] It is also important to check that the AA (Authoritative Answer) bit is set in the response from the new slave server. This is indicated by the "aa" entry in the flags header shown in the above output from dig. Some name servers, e.g. older versions of BIND, will, if also acting as resolvers, pass on the AA flag from a remote, authoritative server, even if not authoritative itself. This can lead the operator to assume that the new slave server is correctly configured with authoritative data even when it is not. The query should be sent without the RD (Recursion Desired) flag set, i.e. the command should be: % dig +norecurse @10.9.8.7 example.com soa
I think this change should also be applied to most other occurances of dig query commands in this document. [ ... ]
2.3.1 Updating the zone
This is straightforward. An NS record for the new slave server is added to the example.com zone. If glue is needed, this would be added at this point. This would be required for the case of ns1.example.com because this name lives in the example.com. [Technically speaking, ns1.example.com lives under the example.com zone cut so an A or AAAA record for ns1.example.com needs to be added as "glue".] The data in the example in this section does not correspond to the definition of "glue" in rfc1034. The A RRs for the example.com domain within the example.com zone are authoritative data (unless of course there exist further delegations not shown in the example).
2.5 Switch off the old name server
The final step of the process is to switch off the old name server or reconfigure it to stop serving the example.com zone. This should not be done immediately. First of all, other name servers may still be cacheing the old NS and address records for slave.example.com. These may not expire from the caches for some time: the TTL values in either the example.com or .com zones for slave.example.com. This transition period can be controlled by the name server operator and registry by adjusting the TTLs for the relevant RR sets. Even if no adjusting takes place, at least the duration of
3 Moving a master server I find the described procedure unnecessarily cumbersome. What I would normally do is (rough outline): o Prepare the necessary infrastructure on the new master server o Prohibit further updates on the old master server; freeze the zone if it's being dynamically updated; transfer zone file to new master and add it to the active configuration. o Re-configure the old master as a slave server, slaving the zone file from the new master. Add also-notify directives to both
Suggested new text: This is straightforward. An NS record for the new slave server is added to the example.com zone. Do also ensure that there exists at least one address record (A or AAAA) for the new slave server. If the RR set for the new slave server name is managed within the example.com zone, the required address records must be added to the example.com zone. [ ... ] the actual transition period can be deduced from the published TTL values. Should the document cover this? [ ... ] the new and old master if desired. o Enable updates on the new master server. o Notify slave server operators, and ask that the zone be slaved directly from the new master. The step of slaving from a dual master setup may possibly be skipped, although following the two step slave configuration procedure may guard against some configuration errors and inadequate testing. The considerations regarding the SOA values as well as the procedures for updating the delegations etc. from the original text still applies. Would the document benefit from having a more detailed description of this procedure in addition to or instead of the current text? Also, although the procedure above has worked fine for my master changes, maybe it has flaws that my operational environment hasn't triggered? [ ... ] As a registry operator, there is one additional topic that I think the document should cover. The most severe problems in association with name servers changes occur when the registrant closely links significant changes to his service infrastructure (web, mail ...) with a full change of the domain delegation/name servers. I.e. the brand new web shop will not be available to the customers until the change in the DNS _delegation_ has taken effect. This put the registrant at the mercy of several external parties (old and new DNS operators, registrars, registry), over whose systems he may have limited direct control. If there are any delays, or errors happen during the DNS change, the resulting problems will be severe (and these changes of course always take place during the weekend, when delays and errors are more likely to occur...). My advice is that, to the extent possible, changes to the DNS delegation should be performed separately from changes to the other service infrastructure. Then, for the service infrastructure changes, the zone administrator is free to manage the zone contents without being dependent on other parties. Does anyone else think we should add text to the document to address this problem? Or is it beyond the scope (in its current form, it mostly covers changing one server at a time)? -jarle -- "There's too much blood in my caffeine system."