From mohsen.souissi at nic.fr Mon Jun 9 14:27:23 2008 From: mohsen.souissi at nic.fr (Mohsen Souissi) Date: Mon, 9 Jun 2008 14:27:23 +0200 Subject: [dns-wg] Updated DNS migration document In-Reply-To: <298D662B-2646-4197-99E0-5145484ECFC1@rfc1035.com> References: <298D662B-2646-4197-99E0-5145484ECFC1@rfc1035.com> Message-ID: <20080609122723.GE61974@kerkenna.nic.fr> 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. -------------- next part -------------- # # $Id: DNSmigration,v 1.7 2008/04/27 17:38:31 jim Exp $ # Recommended DNS Administration Procedure for Domain Name Migration Fernando Garcia Abstract The configuration and maintenance of DNS zones offer many degrees of freedom and thus several opportunities for making mistakes. One of the most complex and error prone situations that can arise is moving a domain name from one set of name servers to another. This can happen for a variety of reasons: technical, administrative and procedural. These problems can be even more awkward when the domain name concerns reverse lookups of IP addresses: for instance when a renumbering exercise is under way. One common reason for renumbering is when an an organisation changes its Internet Service Provider. An orderly sequence of changes has to be carefully co-ordinated to ensure the minimum disruption to important services such as those offered by email and web servers. Since this is not a situation which network or systems administrators need to handle very often, it is painfully easy to make mistakes when undertaking the migration process, These mistakes can have serious consequences for the services that depend on DNS service. This document is offers a step by step guide to system and network ^^^^^^^^^^^^^^^^^^ ==> document offers administrators, so they can have a problem free migration with full continuity of all services. Although the procedures described here do not require in-depth knowledge of the DNS protocol and its implementations, it is necessary to have some understanding of DNS fundamentals, notably name server configuration. The examples shown are specific to BIND but should be readily applied to other DNS implementations. 1. Conventions used in this document Domain names used in this document are for explanatory purposes only and should not be expected to lead to useful information in real life [RFC2606]. 2. Slave Server Migration The simplest form of name server migration is to move from one slave (secondary) server to another. In this case, the main effort is co-ordinating the reconfiguration of the name servers. For this example a new slave name server, ns1.example.com, is added for the example.com zone. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ==> rather "is going to replace slave.example.com" 2.1 Make new server authoritative for the zone For BIND, this is simply a matter of adding a new zone{} statement to the new name server's configuration file /etc/named.conf. [It is assumed that this file has already been created and a minimal but properly configured name server has been set up and is running. A suitable zone statement would resemble: zone "example.com" { type slave; file "slave-zones/example.com"; masters { 10.1.2.3; }; }; This instructs the new name server to be a slave server for the example.com zone and answer authoritatively for it. The server should check the zone's SOA record on the master server at IP address 10.1.2.3 and transfer the zone whenever it is updated on the master server. A copy of the transferred zone will be stored in the file slave-zones/example.com. Once /etc/named.conf has been updated, the configuration file should be checked with BIND9's named-checkconf utility. This should ensure the file contains no syntax errors or other mistakes which could leave the name server in an undefined or unknown state. Some form of version control should also be used at this point so /etc/named.conf should get committed to the organisation's preferred version control system, typically CVS or Subversion. The name server should now be forced to read the updated /etc/named.conf. This would normally be done with an rndc reconfig: % rndc reconfig The name server's logs should be checked to ensure that it has picked up the new configuration information and successfully transferred the example.com zone from the master server at 10.1.2.3. The obvious difficulties that could occur at this point should be readily identified from the name server's logs: some form of file system access permission issues ; connectivity problems; a non-authoritative master server; or incorrect name access controls on the master server. A discussion on how to resolve these problems is out of scope for this document. 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 +norecurse ^^^^^^^^ ==> 10.40.5.2 ? Which server is quried and which server is responding? Update text below accordingly... ; <<>> DiG 9.4.2 <<>> @10.40.5.2 www.example.com ^^^^^^^^^ ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26413 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.example.com. IN SOA ;; ANSWER SECTION: example.com. 3600 IN SOA master.example.com. hostmaster.example.com. 2007032700 86400 7200 3600000 172800 ;; AUTHORITY SECTION: example.com. 3600 IN NS master.example.com. example.com. 3600 IN NS slave.example.com. ;; ADDITIONAL SECTION: master.example.com. 3600 IN A 10.1.2.3 slave.example.com. 3600 IN A 10.11.12.13 ;; Query time: 4 msec ;; SERVER: 10.9.8.7#53(10.40.5.2) ^^^^^^^^ ^^^^^^^^^ ;; WHEN: Sun Mar 27 21:47:15 2007 ;; MSG SIZE rcvd: 131 Note that the new slave server's IP address (10.9.8.7) is queried directly instead of dig defaulting to whatever name server would be used by for routine DNS queries. The value of the returned SOA record should be identical to that found on the existing authoritative servers for the zone, master.example.com and slave.example.com. 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. The +norecurse option is used to clear the RD bit (Recursion Denied) ^^^^^^ ==> Desired on the query. This shouldn't be necessary, especially when querying up-to-date name servers. However some DNS implementations such as BIND8 sometimes erroneously set the AA bit on answers. This may arise when the server also acts as a resolver. It can pass on the AA bit in the answer from a remote authoritative server when it resolves the query even though it was not authoritative for that data. If the new slave server suffers from this broken behaviour, it can lead the operator to assume that the new slave server is correctly configured with authoritative data even when it is not. Querying the new server with the RD bit cleared should ensure that the AA bit is only set on responses from servers that geunuinely are authoritative. ^^^^^^^^^^^^^^ ==> are genuinely If possible, the next check would be to query the name name server from different locations on the network. This could identify any connectivity problems or firewall issues that might prevent general access to the new slave server for DNS lookups. It may be advisable to check that EDNS0 queries work properly: some firewalls and middleware boxes are known to erroneously prevent these queries and responses. The +bufsize option to dig will generate EDNS0 queries. ie: % dig @10.9.8.7 example.com soa +bufsize=1024 +norecurse 2.3 Make the new slave server visible The next step is to make the newly-added slave server visible to the DNS. This is a two stage process. First the zone is updated. Then the delegation is updated, if necessary. 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 an address record (A or AAAA record) is needed for the new slave server, it should be added at this point. When the name of the new slave server is within the example.com zone, its address records must be added to the example.com zone. In this example, an address record for ns1.example.com is needed because this name lives in the example.com zone. Before the update, the zone file on the master server would resemble: example.com. IN NS master.example.com. example.com. IN NS slave.example.com. ... master.example.com. IN A 10.1.2.3 slave.example.com. IN A 10.11.12.13 After the update, the NS and glue records would look like: ^^^^ ==> it is not "glue", it's in-zone data ! instead of "glue", rather "A/AAA" example.com. IN NS master.example.com. example.com. IN NS slave.example.com. example.com. IN NS ns1.example.com. ... master.example.com. IN A 10.1.2.3 slave.example.com. IN A 10.11.12.13 ns1.example.com. IN A 10.9.8.7 Since the example.com has been updated, the zone's SOA record would be given a new serial number. The modified zone file would presumably be committed to the version control system. BIND9's named-checkzone should also be used to check for errors in the updated zone file: master% named-checkzone example.com example.com If all is well, the next step would be to make the master server load the new zone file with rndc: master% rndc reload example.com The master server's logs should be checked at this point. These should show that the server has successfully loaded the updated example.com zone. The logs should also indicate that it has sent out NOTIFY messages to the slave servers and that those slave servers have picked up the new version of the zone with a zone transfer. Ultra-cautious DNS administrators will use dig at this point to query the master server ^^^^^^^^^^^^^ ==> master and slave servers to ensure that the correct data is now being served: ^^ ==> "are" ? % dig @10.1.2.3 example.com ns Aside from mistakes when updating the example.com zone, likely errors at this stage will concern possible connectivity problems such as a routing or network fault or perhaps an incorrect name server or firewall access control list. As before, the logs should indicate what went wrong and resolution of those faults are beyond the scope of this document. With BIND 9.4, it is also possible for an authoritative name server to send NOTIFY messages with rndc: master% rndc notify example.com It is also possible to make a slave server schedule an immediate SOA serial number check on the master server without waiting for the zone's refresh interval to be reached: slave% rndc refresh example.com A slave server can be forced to transfer the zone from the master server irrespective of the value of the zone's SOA serial number. This tends to be used when the master and slave servers have inconsistent serial numbers caused by administrative error. slave: rndc retransfer example.com The notify, refresh and retransfer features offered by rndc are not needed for the process described here. They are just explained in case a DNS administrator makes a mistake and needs an easy way of correcting that error. 2.3.2 Update the delegation The new name server, ns1.example.com, is now answering queries for the example.com zone and is listed in its NS RRset. However the job is not yet done. The parent zone, in this case .com, needs to be updated. The parent zone contains delegation information for example.com and this has to reflect the NS records and any relevant glue records that are present in the child zone, example.com. How this update gets performed depends on the parent zone. In the case of .com, this involves the registrar sending an EPP transaction to the registry to update its database. Most TLDs operate on this model. In general registrars provide a web-based interface to allow their customers to update their delegations, renew domain name registrations, amend contact data and so on. Some registries offer other mechanisms such as email-based text templates. As will be seen later, RIRs use email-based templates for updating delegation information for reverse zones assigned to their LIRs. Though these updates can also be done through web-based systems like RIPE NCC's LIR portal service. Since there are so many options here, it is impractical to describe these in detail here. In simple terms, the DNS administrator can login to some web page and select the option that allows delegation information to be updated. At this point the name of the new server, ns1.example.com, is added. Its IP address will have to be added as a ^^^^^^^ glue record too. The .com zone needs to advertise the IP address of ^^^^^^ ns1.example.com even though this under the example.com zone cut. ^^+is ==> Comment: if ns1.example.com. has got an IPv6 address, update the paragraph above accordingly. After the update has been entered into the registry database, the new DNS data get added to the parent zone and propagated to its name servers. The time for this change to take effect varies. Some registries do this immediately or within 10 to 15 minutes. Others generate a new zone file every few hours or perhaps just once or twice a day. DNS administrators need to take account of these propagation delays when moving name servers for a zone. 2.4 Delete the old slave server ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ==> I would suggest to rename this section as: "Remove the old slave server from the name servers list" Once the parent zone has been updated and the new delegation information propagated to its name servers, the old name server can be removed. The process is essentially the reverse of the steps above. First, the NS record for the old server, slave.example.com is removed from the example.com zone on the master server. Version control and checks as described earlier should be carried out. The A record for slave.example.com should be removed at this point. However if that name is used elsewhere -- say as the target of an MX or CNAME record -- the A record should remain. With the NS record deleted from the example.com zone, the delegation should be updated. The procedure outlined in 2.3.2 would be followed, except to remove the NS record for slave.example.com and any relevant glue records. It is important to ensure that the glue records for a retired name server are removed from the parent. If this is not done, discrepancies can arise. For instance, the DNS administrator for example.com adds a new A or AAAA record for slave.example.com but there's a stale glue record for slave.example.com in the .com zone which points at the old IP address of the now long gone name server. 2.5 Switch off the old name server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ==> Would suggest to rename this section as: "Stop serving the DNS zone on the old slave 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. ------------------------------------------------------------------------ ==> Generally speaking, the real action is just "reconfiguring the old slave to stop serving the zone". Any further action (such as switching off the server) is specific to some contexts (for example, if the slave was serving only that zone... and not being used as a recurisve name server... And yes, even if such recursive functionality is discouraged on an authoritative nameserver, it is not forbidden). So I would rather prefer rewriting the sentence above as: "The final step of the process to reconfigure the old sevrer to stop serving the example.com zone. The server may even be switched off if it does not serve othe DNS zones." ------------------------------------------------------------------------ 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. It is possible of course to reduce these TTLs so that the old server can be switched off sooner. However this will require further changes ^^^^^^^^^^^^ to the zone and its parent delegation: for instance to reduce the TTL for the NS and any address records for the old name server. This introduces extra steps into the migration process and may not be worth the effort. In the final analysis, the old name server shouldn't be switched off after the migration for at least the TTL value for the ^^^^^^^^^^^^ server that may have been cached anywhere. ==> Same remarks as to "switch off" vs "stop serving the zone" Even after a reasonable transition period of a few days, it is always possible for the old name server to still receive queries for example.com. The most likely cause of this are forwarding name servers that have been configured with the IP address of the old name server. Checking the name server's query logs will indicate if the old server receives such queries. If it does, the logs will identify the source of these queries. The DNS administrator can then arrange for these systems to be fixed or at least investigate why they are still sending queries to the wrong name server. It would be prudent to ensure that no harm would result from shutting down the old name server or stopping it from serving the example.com zone before taking that course of action. Removing the zone is simply the reverse of the procedure described in 2.1 above. However this applies to the old slave server, slave.example.com, and not the new one, ns1.example.com, that is now in use. The zone{} statement for example.com in /etc/named.conf on slave.example.com is removed and the usual version control process and configuration file checks with named-checkconf applied. The name server is made to re-read its configuration file with rndc and the server's logs checked to ensure the change has been carried out. Finally, any old copies of the zone file can be removed if necessary. 2.6 Documentation Once the new slave server or servers are in use, the organisation's DNS documentation should be updated. This should reflect the details of the slave servers: where they are located, what software they run; contact details for whoever is responsible for them; information about change procedures, change windows and any service level agreements that are in place. 2.7 Observations Although this procedure may be over-cautious, it does ensure that stable DNS service is maintained throughout the procedure. First, the new server is configured to serve the zone and then tested. This makes sure it can communicate with the zone's master server, there are no connectivity or firewall issues and that the new server is performing satisfactorily. It is only at this point that a go/no go decision is made about adding the new server to the zone's NS RRset. Further checks can then be made to ensure the server is properly handling queries from other name servers on the network. If anything goes wrong, the NS record can be ^^^^^^^ ==> and clients... removed. Everything then continues as normal on the existing DNS infrastructure for the zone. Once the new server is handling queries satisfactorily, the delegation information in the parent zone is updated. At this point the new slave server is fully activated. The old slave server can be removed once it no longer receives queries for the zone. This can be verified by checking its query logs. Other name servers may be holding on to stale delegation information that is still to expire from their caches. Or they may have been configured to forward to the old slave server. Deleting that zone from the slave is simply a matter of removing the corresponding zone{} statement from its named.conf file once it is considered safe for the slave server to no longer serve that zone. Another approach might be to switch off the slave server, provided of course it is not serving other zones or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ being queried by stub resolvers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ==> This remark is important, that's why I proposed to insert it earlier (above) in the text. Although this procedure could be carried out in parallel whenever several slave servers have to be changed, this is probably unwise. It is simpler and less error-prone for the servers to be migrated one at a time rather than in bulk. That way, there is less co-ordination to be done at any given moment, so there is less chance of something going wrong or being overlooked. On the other hand, this can mean that changing several name servers takes longer elapsed time than might be desirable. In principle, the same procedure could be followed for moving a zone's master server. However there are some additional steps that need to be taken for that and these are discussed in the next section. 3 Moving a master server The safest way to move the master server for a zone is to configure a new name server at the new location. Perhaps the easiest way to do this is instantiate the new server with the configuration data -- zone files, named.conf, version control logs, ticketing system references -- from the backups/archives of the current master server. Once the new master server is set up, it should be checked that it is answering authoritatively for example.com and that it has the same data that is found on the existing master server for the zone. This cannot be one by transferring the zone from both servers and comparing ^^^ ==> done the zone files because there is no guarantee the two files will be identical. The files should of course have the same DNS data but there is no DNS protocol requirement for that data to be presented in a single, canonical order when a zone transfer is performed. It should be remembered that a zone transfer replicates zone data and it is not a file transfer protocol. Although ensuring the same DNS data exists is the most important consideration, the actual master file can be important too. For example it may contain comments that would not be visible when a zone transfer is performed. The new master server should be checked to ensure it is answering correctly and authoritatively for example.com. Zone transfers and EDNS0 queries should be used to ensure that there are no connectivity problems or access control lists which prevent the new server being ^^^^^^ ==> "from being"? used. The checks illustrated in Section 2.2 can be applied here. Once the new server is running correctly, there is a potential problem. There are now two servers which are master for the zone and these can get out of synchronisation with each other. Updates made to the zone on one will not be seen by the other. The simplest way to do that is to only permit updates on one server, the new master server, or to decide no changes can be made to the zone until the new master server is fully activated. This may mean temporarily preventing dynamic updates or other changes to the zone. 3.1 SOA Record Values Before the new master server is brought on-line, the zone's SOA record should have a sensible expire interval: 30 days is reasonable. Short expire intervals are unwise in general. They are especially unwise when the master server is moved. If the slave servers cannot contact the master server within one expire interval, they will no longer answer authoritatively for the zone, creating a lame delegation. A suitably long expire interval allows plenty of time to correct any master-slave connectivity issues before they can cause serious trouble. 3.2 Notification of the Slave Servers With the new server answering authoritatively for the zone, all the slave servers for the zone need to be reconfigured. They should be told to use the IP address(es) of the new server for zone transfers and SOA refresh checks. This will be done by some out-of-band means. Usually the DNS administrator will inform the DNS administrators of the slave servers about the migration by email. They will then update their name server's configurations with the details of the new server. If the master server for example.com was being moved from 10.1.2.3 to 172.16.1.1, the appropriate zone{} statement in the slave server's named.conf would look like: zone "example.com" { type slave; file "slave-zones/example.com"; masters { 172.16.1.1; 10.1.2.3; }; }; As always, version control, a ticketing system and a check with named-checkconf would be done before the slave server loads the new named.conf file. The above entry would tell the slave server to try the new IP address (172.16.1.1) as well as the old one when checking for fresh versions of example.com and transferring them. At this point it is crucial that both the old and new master servers for example.com have identical versions of the zone. If not, slave servers could be picking up different versions of example.com from either server, resulting in inconsistent data being published in the DNS. This is why it is safest to prevent any changes to the example.com zone until all the slave servers are now using the new master server. Updates to the slave server configurations should be carefully planned. The operators of the slave servers may have change windows, perhaps just once a week or month, where name server configurations can be altered. The slave server administrators may have their own ticketing systems and procedures for making those changes. So the DNS administrator should take account of these and give plenty of notice, perhaps as long as a month, of the impending move of the zone's master server. There may be service level agreements with the slave service providers which document the procedure and turn-round times for responding to such change requests. Putting the IP addresses of both servers in the masters{} clauses of the zone{} statement is a fail-safe. If the new server is unreachable for some reason, the zone can still be checked and transferred from the old master server. Assuming of course the old master server still has an up to date copy of the zone. And if the new master server is misbehaving, it can be switched off immediately. The slave servers will automatically fall back to using the IP address of the old master server for their checks. 3.3 Activating the new master server The logs on the slave servers and the new master server should be checked to ensure that they are being used for zone transfers and refresh checks, not the old master server. Once this has been verified, the slave servers can be reconfigured to only use the new master server. That simply means a repeat of the process in Section 3.2, except this time to remove the old IP address (10.1.2.3) from the masters{} clauses of the relevant zone{} statement. From this point onwards, the new master server will be the only place for any updates to the zone to be performed. 3.4 Update the example.com zone With the slave servers now using the new master server, the zone file will probably have to be updated. If the zone's master server has been renamed, that should be shown in the SOA record's MNAME field. The zone's NS RRset may have to be updated too and any "glue" for the new master server added. ^^^^^ ------------------------------------------------------------------------ ==> once again, it is not "glue", it is in-zone data! If the new master was already published in the DNS zone, its IP address(es) will remain unchanged. Otherwise, (an) A/AAAA entr{y,ies} will be added. OTOH, I think you should mention as early as in the paragraph above, the "hidden master option", in which case, nothing would be updated in the SOA record. ------------------------------------------------------------------------ In the example used for this document, the new master server retains the same name, master.example.com, but gets renumbered to a new IP address, 172.16.1.1. The relevant updates to the zone file would be similar to the following: example.com. 3600 SOA master.example.com. hostmaster.example.com. ( 2007032701 ; serial number 86400 ; refresh (24 hours) 7200 ; retry (2 hours) 3600000 ; expire (1000 hours) 172800 ; minimum (2 days) example.com. IN NS master.example.com. example.com. IN NS ns1.example.com. ... master.example.com. IN A 172.16.1.1 ns1.example.com. IN A 10.9.8.7 As before, changes to the example.com should be linked to the organisation's ticketing system, its change control procedure and checks with named-checkzone before the name server loads the new zone file. Once loaded, the name server's logs should be inspected to make sure that the new zone propagates to the zone's slave servers. Stealth master servers are commonly used. These are master servers ^^^^^^^ ==> AFAIK, it's the term "Hidden" which is rather used with masters. For slaves, it is indeed "stealth" which is used. see: http://www.oreillynet.com/pub/a/network/excerpt/dnsbindcook_ch07/ (search for "stealth") that are not listed in the zone's NS RRset or SOA record's MNAME field or in any parent zone's delegation information. This means the location of the master name server is not readily disclosed in the zone file and it is not found in the DNS metadata. The name and address of that server is only known to the authoritative slave servers for the zone and any utilities that are permitted to send dynamic updates to the server. If a stealth master configuration is in place, there ^^^^^^^ ==> hidden will be no need to update the zone's NS RRset or SOA MNAME field. 3.5 Update the delegation If the master server was part of the delegation information in the parent zone, that zone will need to be updated too. The name and address of the new master server will need to be in the parent zone. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ==> Only in case of "glue" and that's not the general case. An outline of the procedure to be followed for updating the parent zone is given in Section 2.3.2. There is no need to update the delegation if a stealth master configuration is used: the name and ^^^^^^^ ==> hidden address of the master server will not be in the parent zone and do not need to be added to it. 3.6 Update tools and clients Any tools or procedures which are used to modify the zone contents will have to be updated and tested for use on the new server. These changes will have to be documented. Clients which issue dynamic updates -- for example a DHCP server -- may need to be reconfigured to use the master server's new IP address. ^^^^^^^^ ==> addresse(s). However they may be able to find the new location of the master server from the MNAME field in the zone's SOA record. Dynamic update tools like nsupdate will do this automatically. 3.7 Decommission the old master server Finally, the procedure described in Section 2.5 can be used to stop the old master server from serving the zone. There will be additional steps to take however. The organisation's documentation should be updated to reflect the change of location for the master server. Administrative measures should be put in place to ensure no updates for the zone get made on the old server. These could include blocking or rejecting any dynamic update requests, preventing the old master zone file from being modified, training for DNS operations staff or perhaps all of these measures. 4 Renumbering When hosts get renumbered or renamed, it is not always the case that this can be done by simply updating the DNS. This is of course a major component of the renaming or renumbering. But it is by no means the only one. Any changes to the DNS should be carefully co-ordinated and integrated with the other aspects of the renumbering or renaming exercise. These can include the reconfiguration and testing of web servers and mail systems, changes to router and firewall configurations, updates to application-level access control lists, server downtime and the replacement of X.509 certificates. Changing the name or IP address of a host can be straightforward. It's unlikely anyone cares what name or IP address is assigned by a DHCP server to some host. All that is likely to matter in that sort of example is that the forward and reverse entries match up: ie a reverse lookup of the IP address returns a name that when looked up returns that IP address. Even that might not be essential. Though it is of course desirable. There are examples where the names and addresses of hosts are significant, particularly servers. POP and IMAP client will want to connect to the appropriate server. Similarly, mail clients will have to connect to the correct SMTP or ESMTP server when delivering or submitting email. This paradigm obviously extends to web servers, database servers and so on. When these sorts of critical network resources get moved or renamed, some careful planning is needed. For illustrative purposes below, the mail server for example.com, oldbox.example.com on 10.20.30.40 is going to be moved to newbox.example.com which has IP address 172.16.0.1. Before the DNS is updated, it can be assumed that the new mail server has been tested thoroughly and any accompanying addressing or numbering requirements have been resolved: for instance, the installation of new X.509 certificates. 4.1 Changing the forward zone Before this change, there will be MX and A records like the ones below in the example.com zone file: example.com. 3600 MX 10 oldbox.example.com. ... oldbox.example.com. 3600 A 10.20.30.40 Some time before the switch to the new mail server, the TTL values for the above resource records should be reduced to a few minutes. This will ensure old and possibly stale data does not live for more than a few minutes in the caches of other name servers. The absolute minimum time for this to be done is 1 refresh interval (24 hours in Section 3.4) plus the maximum TTL value for these resource records: 1 hour. This means that the TTL should be decreased no later than 25 hours before the planned switch. The rationale for this is a slave server may have just performed its refresh check just before the zone was updated. So if it does not support NOTIFY (or doesn't get any NOTIFY messages from the master server), the slave will take one refresh interval before it does another refresh check and picks up a new copy of the zone. Assuming that the zone transfer takes no time, the slave server will still be responding to lookups for example.com's MX records with data that has a one hour TTL value for one expire interval after the zone was updated. A ticket should be opened and the zone file updated in the usual manner with version control and zone file syntax checks with named-checkzone. Even though only the TTL for the records below are modified, the zone's SOA record serial number should be updated according to local convention. In the example below, the updated MX and A records now have a TTL of 5 minutes. Not that no other data for ^^^ ==> Note these records is changed ^^are? example.com. 300 MX 10 oldbox.example.com. ... oldbox.example.com. 300 A 10.20.30.40 The new zone is loaded on the master server and propagated to the slave servers in the usual way. Subsequent lookups for the MX records for example.com will only be cached for 5 minutes unless they'd already been cached from an earlier lookup. This means that there will probably be more DNS queries for example.com's MX records because this ^^ese? data does not get cached for as long as it used to. However within 25 ^^^^do? ^^they? hours of this zone update, no name server should be caching these MX records for longer than 5 minutes. Any data that was cached prior to ^^^were? the change should have expired from name server caches by then. This now means there is a 5 minute window for changing the mail server to the new system on a new IP address. At this point, the old mail server should be stopped from accepting inbound email. This will prevent it from processing incoming mail and storing it on mailboxes that have probably been migrated to the new server. With the old mail server not accepting email, all the mailboxes and other configuration data can be moved to the new server. Describing how this would be done is beyond the scope of this document. The new mail server can now be started. Once that has been done, the DNS can be updated. The MX and A records above would be replaced with the entries shown below: example.com. 300 MX 10 newbox.example.com. ... oldbox.example.com. 300 A 172.16.0.1 As before, the zone file should undergo version control and a check with named-checkzone. It should also get a new SOA serial number. Once this zone has propagated to the slave servers for example.com, incoming mail should start to be delivered to the new server. This is one example where the use of NOTIFY is a great benefit to get the slave servers to quickly converge on the new version of the zone. This could also be achieved by reducing the SOA record's refresh interval but this should only be necessary for legacy DNS implementations that do not implement NOTIFY. Those legacy implementations are likely to be so out of date that they need to be replaced anyway. Note that the TTL for the MX and A records above are still set to 5 minutes. This is to allow for a quick back-out in case of unforeseen problems with the new servers. The DNS administrator can revert to the old data and the old mail server restarted if there are problems. Since the DNS data for the new server has a short TTL, this will not be cached for too long by other name servers, reducing the potential for mail to go astray by being delivered to the new server when it is not performing correctly. Once mail operations have bedded down, the example.com zone file can be updated once more and the above MX and A records given more suitable TTL values. 4.2 Reverse zones For reverse zones, things can be somewhat simpler. The DNS administrator can prepare the reverse zones and populate them with PTR records before the corresponding IP addresses are actually used. The zone file for 16.172.in-addr.arpa could contain the following PTR record: 1.0.16.172.in-addr.arpa. 600 PTR newbox.example.com. Note that the PTR has the same TTL as the A record in the forward zone. This is not a DNS protocol requirement. It is an administrative convenience so that reverse lookups of 172.16.0.1 expire from the world's name server caches in no longer than the corresponding A record in example.com would. As with the forward zone, the reverse zone should be updated and propagated to its slave servers no later than 1 expire interval + the ^^^^^^ ==> refresh! PTR TTL value before the new IP address is used. The SOA record for 16.172.in-addr.arpa is not shown here, but it can be assumed that its expire interval is 8 hours and the PTR record previously had a TTL of ^^^^^^ ==> refresh 1 hour. [There is no requirement for SOA timer values and TTLs in reverse zones to be identical to forward zones or vice versa.] The rationale for the short TTL is the same as that given in Section 4.1: the data won't hang around caches for long if the change has to be backed out for some reason. In practice, reverse DNS entries are rarely critical to email operations (or any server operations in general). However some anti-spam defences use the absence of a working reverse DNS entry as a good rule of thumb for identifying a spam source. As with the forward zone, the PTR record in the 16.172.in-addr.arpa can be given a more reasonable TTL once everyone is happy that the new mail server is performing satisfactorily. 4.4 Other servers The same procedure can be applied to other network services that get moved or renumbered. Well in advance of the change, the TTL values on the corresponding resource records in the DNS should be reduced to a few minutes. This should be done to allow for any already cached data for those entries to expire from the caches of any other name servers. They will then lookup the names again and get the same responses, albeit with much shorter TTLs. This will mean more traffic to the name servers for the forward and reverse zones while the migration is in progress. The reduced TTL provides the window for switching from one server to another. While this switch is actually in progress, it may be necessary to stop the old server. For instance to ensure transactions are not sent to the wrong database or email delivered to the old mail store instead of the new one. Once the new server is ready, the DNS should be updated with the new addressing and naming data. This should still have a short TTL in case the new system has to be backed out. That can be done without the new DNS data staying in name server caches for too long. Finally, once the new server is shown to be working correctly, the TTLs for the new DNS data can be increased to more normal values. 4.5 Changes to service infrastructure Changes to DNS are often coupled to other changes to an organisation's service infrastructure. For example the replacement of web servers or mail servers may involve a change of ISP, some renumbering and DNS migration. Or some combination of these. A common scenario is that the new web site does not become visible until the DNS is updated and the delegation information in the parent zone has been updated too. This can put the organisation at the mercy of several external parties: for instance the old and new DNS service providers and ISPs, registrars, parent registry and so on. There is likely to be limited direct control over those parties, so careful co-ordination and communication will be needed to synchronise and sequence each part of the update process with any procedures or maintenance windows that these parties have. If there are any delays or errors happen during the DNS change, the ^ing resulting problems may be severe. These changes of course tend to take place at weekends or other quiet periods when key technical staff may not be available. Minimising the number of parties in a given change or migration reduces the risk of something going wrong and simplifies any recovery or back-out procedures when a problem occurs. As far as is practically 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: DNSmigration.diff Type: text/x-diff Size: 17442 bytes Desc: not available URL: From Fernando.Garcia at tecnocom.es Mon Jun 9 15:05:02 2008 From: Fernando.Garcia at tecnocom.es (=?iso-8859-1?Q?Garc=EDa_Fern=E1ndez=2C_Fernando?=) Date: Mon, 9 Jun 2008 15:05:02 +0200 Subject: [dns-wg] Updated DNS migration document In-Reply-To: <20080609122723.GE61974@kerkenna.nic.fr> Message-ID: 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" 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 <> 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 5371 bytes Desc: image.png URL: From jakob at rfc.se Tue Jun 24 09:56:45 2008 From: jakob at rfc.se (Jakob Schlyter) Date: Tue, 24 Jun 2008 09:56:45 +0200 Subject: [dns-wg] .ORG DNSSEC Survey References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> Message-ID: Dear RIPE Working Group Member, You are invited to complete the following DNSSEC Survey conducted by .ORG, The Public Interest Registry. The purpose of this survey is to evaluate DNSSEC preparedness and to gain more information on current and future plans to implement DNSSEC. We would greatly appreciate your response, so we hope you are able to take a few minutes to complete this survey. Your responses will remain anonymous as no identity information will be recorded. To participate in the survey, please visit http://guest.cvent.com/v.aspx?1A,Q3,95818ada-0ceb-4ea2-bce2-c2d94d68da13 We look forward to your response, Sincerely, Jakob Schlyter, Kirei AB for .ORG, The Public Interest Registry From Niall.oReilly at ucd.ie Tue Jun 24 10:45:18 2008 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 24 Jun 2008 09:45:18 +0100 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> Message-ID: <472D016F-BD1C-48E2-B79A-2C0C6653C70E@ucd.ie> On 24 Jun 2008, at 08:56, Jakob Schlyter wrote: > We look forward to your response, I'll pass. Binary answer-sets to questions which need a more nuanced answer force respondents to give misleading replies. I'ld prefer not to do that. /Niall -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From randy at psg.com Tue Jun 24 10:48:49 2008 From: randy at psg.com (Randy Bush) Date: Tue, 24 Jun 2008 17:48:49 +0900 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <472D016F-BD1C-48E2-B79A-2C0C6653C70E@ucd.ie> References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> <472D016F-BD1C-48E2-B79A-2C0C6653C70E@ucd.ie> Message-ID: <4860B4F1.2090905@psg.com> > Binary answer-sets to questions which need a more nuanced > answer force respondents to give misleading replies. for same reason, i gave up on the second or third page and javascript? shame! randy From jakob at kirei.se Mon Jun 23 14:24:12 2008 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Jun 2008 14:24:12 +0200 Subject: [dns-wg] .ORG DNSSEC Survey Message-ID: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> Dear RIPE Working Group Member, You are invited to complete the following DNSSEC Survey conducted by .ORG, The Public Interest Registry. The purpose of this survey is to evaluate DNSSEC preparedness and to gain more information on current and future plans to implement DNSSEC. We would greatly appreciate your response, so we hope you are able to take a few minutes to complete this survey. Your responses will remain anonymous as no identity information will be recorded. To participate in the survey, please visit http://guest.cvent.com/v.aspx?1A,Q3,95818ada-0ceb-4ea2-bce2-c2d94d68da13 We look forward to your response, Sincerely, Jakob Schlyter, Kirei AB for .ORG, The Public Interest Registry From paf at cisco.com Tue Jun 24 13:36:37 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 24 Jun 2008 13:36:37 +0200 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <472D016F-BD1C-48E2-B79A-2C0C6653C70E@ucd.ie> References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> <472D016F-BD1C-48E2-B79A-2C0C6653C70E@ucd.ie> Message-ID: <3226C3A1-3C58-4217-86D8-5A08B17F4D00@cisco.com> On 24 jun 2008, at 10.45, Niall O'Reilly wrote: > > On 24 Jun 2008, at 08:56, Jakob Schlyter wrote: > >> We look forward to your response, > > I'll pass. > > Binary answer-sets to questions which need a more nuanced > answer force respondents to give misleading replies. > > I'ld prefer not to do that. I responded, but many of my responses for this reason ended up being "other". Jakob, I am happy to talk with you instead, and answer the questions with more words. Patrik From randy at psg.com Tue Jun 24 13:39:16 2008 From: randy at psg.com (Randy Bush) Date: Tue, 24 Jun 2008 20:39:16 +0900 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <3226C3A1-3C58-4217-86D8-5A08B17F4D00@cisco.com> References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> <472D016F-BD1C-48E2-B79A-2C0C6653C70E@ucd.ie> <3226C3A1-3C58-4217-86D8-5A08B17F4D00@cisco.com> Message-ID: <4860DCE4.6010403@psg.com> why do we need a survey? you don't need a weatherman to know which way the wind blows. sign the bleeping root already. randy From bmanning at vacation.karoshi.com Tue Jun 24 14:44:00 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 24 Jun 2008 12:44:00 +0000 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> Message-ID: <20080624124400.GA24458@vacation.karoshi.com.> On Mon, Jun 23, 2008 at 02:24:12PM +0200, Jakob Schlyter wrote: > Dear RIPE Working Group Member, > > You are invited to complete the following DNSSEC Survey conducted > by .ORG, The Public Interest Registry. The purpose of this survey is > to evaluate DNSSEC preparedness and to gain more information on > current and future plans to implement DNSSEC. > > We would greatly appreciate your response, so we hope you are able to > take a few minutes to complete this survey. Your responses will > remain anonymous as no identity information will be recorded. > > To participate in the survey, please visit > http://guest.cvent.com/v.aspx?1A,Q3,95818ada-0ceb-4ea2-bce2-c2d94d68da13 > > > We look forward to your response, > > Sincerely, > Jakob Schlyter, Kirei AB for > .ORG, The Public Interest Registry question #20 asks, if the respondent needs assistance and if so, rank order the replies. There is no way to say, "no, i don't need assistance" - one must answer and rank order the proffered responses. so when you finally get to my survey, note well that #20 is completely bogus. --bill From bmanning at vacation.karoshi.com Tue Jun 24 14:45:27 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 24 Jun 2008 12:45:27 +0000 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <4860DCE4.6010403@psg.com> References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> <472D016F-BD1C-48E2-B79A-2C0C6653C70E@ucd.ie> <3226C3A1-3C58-4217-86D8-5A08B17F4D00@cisco.com> <4860DCE4.6010403@psg.com> Message-ID: <20080624124527.GB24458@vacation.karoshi.com.> On Tue, Jun 24, 2008 at 08:39:16PM +0900, Randy Bush wrote: > why do we need a survey? you don't need a weatherman to know which way > the wind blows. sign the bleeping root already. > > randy go for it Patrick! --bill From lutz at iks-jena.de Tue Jun 24 15:00:18 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 24 Jun 2008 13:00:18 +0000 (UTC) Subject: [dns-wg] .ORG DNSSEC Survey References: <4860DCE4.6010403@psg.com> Message-ID: * Randy Bush wrote: > why do we need a survey? Because it burns money. All successful things need to burn venture captial first. > sign the bleeping root already. Use the signed root. Don't talk about. Sorry ... From bmanning at vacation.karoshi.com Tue Jun 24 15:12:42 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 24 Jun 2008 13:12:42 +0000 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> Message-ID: <20080624131242.GC24458@vacation.karoshi.com.> On Tue, Jun 24, 2008 at 01:00:18PM +0000, Lutz Donnerhacke wrote: > > sign the bleeping root already. > > Use the signed root. Don't talk about. > > Sorry ... which one? --bill From paul at xelerance.com Tue Jun 24 16:16:17 2008 From: paul at xelerance.com (Paul Wouters) Date: Tue, 24 Jun 2008 10:16:17 -0400 (EDT) Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <20080624131242.GC24458@vacation.karoshi.com.> References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> Message-ID: On Tue, 24 Jun 2008, bmanning at vacation.karoshi.com wrote: > On Tue, Jun 24, 2008 at 01:00:18PM +0000, Lutz Donnerhacke wrote: >>> sign the bleeping root already. >> >> Use the signed root. Don't talk about. >> >> Sorry ... > > > which one? https://ns.iana.org/dnssec/root.zone.signed :) Paul From bmanning at vacation.karoshi.com Tue Jun 24 16:21:29 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 24 Jun 2008 14:21:29 +0000 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> Message-ID: <20080624142129.GA25104@vacation.karoshi.com.> On Tue, Jun 24, 2008 at 10:16:17AM -0400, Paul Wouters wrote: > On Tue, 24 Jun 2008, bmanning at vacation.karoshi.com wrote: > > >On Tue, Jun 24, 2008 at 01:00:18PM +0000, Lutz Donnerhacke wrote: > >>>sign the bleeping root already. > >> > >>Use the signed root. Don't talk about. > >> > >>Sorry ... > > > > > > which one? > > https://ns.iana.org/dnssec/root.zone.signed > > :) > > Paul well, it seems that Randy's admonition to Patrick to "sign the bleeping root already" has ben OBE'd. :) Of course, he could sign it -again- --bill From lutz at iks-jena.de Tue Jun 24 18:37:16 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 24 Jun 2008 16:37:16 +0000 (UTC) Subject: [dns-wg] .ORG DNSSEC Survey References: Message-ID: * Paul Wouters wrote: > On Tue, 24 Jun 2008, bmanning at vacation.karoshi.com wrote: >> On Tue, Jun 24, 2008 at 01:00:18PM +0000, Lutz Donnerhacke wrote: >>> Use the signed root. Don't talk about. >> which one? > > https://ns.iana.org/dnssec/root.zone.signed Or any other, you trust. It's *your* validating resolver. From Ray.Bellis at nominet.org.uk Tue Jun 24 18:42:54 2008 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Tue, 24 Jun 2008 17:42:54 +0100 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> Message-ID: > https://ns.iana.org/dnssec/root.zone.signed Does anyone happen to know what all of the "bert" entries are in there? badbert. 180 IN NS NS.XTCN.COM. fallbert. 180 IN NS NS.XTCN.COM. goodbert. 180 IN NS NS.XTCN.COM. lazybert. 180 IN NS NS.XTCN.COM. Ray From Ed.Lewis at neustar.biz Tue Jun 24 19:24:01 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 24 Jun 2008 13:24:01 -0400 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> Message-ID: At 17:42 +0100 6/24/08, Ray.Bellis at nominet.org.uk wrote: >> https://ns.iana.org/dnssec/root.zone.signed > >Does anyone happen to know what all of the "bert" entries are in there? Perhaps this is related... http://bert.secret-wg.org/Root/index.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From drc at virtualized.org Tue Jun 24 23:47:03 2008 From: drc at virtualized.org (David Conrad) Date: Tue, 24 Jun 2008 23:47:03 +0200 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> Message-ID: So, the signed root made available at ns.iana.org is a demonstration/ test service. Originally, the plan was that it was going to be a production-quality signed root with its own set of secondaries that would allow folks who wanted to test DNSSEC in actual use to modify their root hints appropriately and go about their business. As part of this demonstration/test service, I felt it appropriate to require the secondaries for that service to enter into an agreement that would require those secondaries to meet a base service level commitment and (more importantly) to agree to discontinue use when the real root was signed. Some of the existing root server operators whom I contacted to provide secondary service felt this threatened their continued operation of their root servers. They requested the service be made non-production quality, e.g., that IANA would take the service down periodically or otherwise make the service unreliable. I personally thought this would render the service essentially unusable for the purposes of validating caching resolver experimentation/testing as it would mean ISPs who wanted to play couldn't point to the signed root in their customer facing resolvers. Instead, Rick Lamb of IANA added some bogus TLDs with various failure modes (e.g., bad signatures, expired signatures, etc.) In the end, I gave up trying to push the ns.iana.org experiment as I got extremely tired of the root server operator politics. The signed root continues to be provided with a very elaborate and secure signing mechanism, but I wouldn't call the service provided at ns.iana.org production quality. FWIW. Regards, -drc On Jun 24, 2008, at 6:42 PM, Ray.Bellis at nominet.org.uk wrote: >> https://ns.iana.org/dnssec/root.zone.signed > > Does anyone happen to know what all of the "bert" entries are in > there? > > badbert. 180 IN NS NS.XTCN.COM. > fallbert. 180 IN NS NS.XTCN.COM. > goodbert. 180 IN NS NS.XTCN.COM. > lazybert. 180 IN NS NS.XTCN.COM. > > Ray > > From randy at psg.com Wed Jun 25 00:27:41 2008 From: randy at psg.com (Randy Bush) Date: Wed, 25 Jun 2008 07:27:41 +0900 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> Message-ID: <486174DD.80101@psg.com> > In the end, I gave up trying to push the ns.iana.org experiment as I got > extremely tired of the root server operator politics. the little club killed things again. how sad for the internet. randy From bmanning at vacation.karoshi.com Wed Jun 25 01:34:11 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 24 Jun 2008 23:34:11 +0000 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> Message-ID: <20080624233411.GA29727@vacation.karoshi.com.> On Tue, Jun 24, 2008 at 11:47:03PM +0200, David Conrad wrote: > So, the signed root made available at ns.iana.org is a demonstration/ > test service. and a fine service too. > Some of the existing root server operators whom I contacted to provide > secondary service felt this threatened their continued operation of > their root servers. too bad you did not poll more of the operator community. > In the end, I gave up trying to push the ns.iana.org experiment as I > got extremely tired of the root server operator politics. > > FWIW. > > Regards, > -drc those darned checks and balances get in the way again eh? --bill From lutz at iks-jena.de Wed Jun 25 01:37:43 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 24 Jun 2008 23:37:43 +0000 (UTC) Subject: [dns-wg] .ORG DNSSEC Survey References: Message-ID: * David Conrad wrote: > Originally, the plan was that it was going to be a production-quality > signed root with its own set of secondaries that would allow folks who > wanted to test DNSSEC in actual use to modify their root hints > appropriately and go about their business. Please start at a.dnssec.thur.de. AXFR is open. It runs for more than two years now for us and our customers. From drc at virtualized.org Wed Jun 25 04:53:40 2008 From: drc at virtualized.org (David Conrad) Date: Tue, 24 Jun 2008 19:53:40 -0700 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <20080624233411.GA29727@vacation.karoshi.com.> References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> <20080624233411.GA29727@vacation.karoshi.com.> Message-ID: On Jun 24, 2008, at 4:34 PM, bmanning at vacation.karoshi.com wrote: > those darned checks and balances get in the way again eh? The irony of this statement by this individual in this context is _truly_ amusing. Regards, -drc From Ed.Lewis at neustar.biz Wed Jun 25 21:28:09 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 25 Jun 2008 15:28:09 -0400 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> <20080624233411.GA29727@vacation.karoshi.com.> Message-ID: At 19:53 -0700 6/24/08, David Conrad wrote: >On Jun 24, 2008, at 4:34 PM, bmanning at vacation.karoshi.com wrote: >> those darned checks and balances get in the way again eh? > >The irony of this statement by this individual in this context is >_truly_ amusing. Given http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf and as far as I know, no response back from ICANN to that, followed by the exchange above perhaps the WG should ask about this situation. (But ask whom?) If indeed the (ICANN) root server operators have misgiving about the experiment, could someone operating a root server express the reasons? I realize that the context of the claim (that the root server operators disapproved) is within the confines of the experiment and not (necessarily) production, but perhaps there's a link. Just real curious at this point. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From lutz at iks-jena.de Thu Jun 26 01:21:40 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 25 Jun 2008 23:21:40 +0000 (UTC) Subject: [dns-wg] .ORG DNSSEC Survey References: Message-ID: * Edward Lewis wrote: > Given http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf and as > far as I know, no response back from ICANN to that, followed by the > exchange above perhaps the WG should ask about this situation. (But > ask whom?) After the DNSSEC session yesterday on the ICANN meeting in Paris, I had some lengthy discussions with several board members on this subject. My impression is, that ICANN is faced with serios concerns by the US Gov. I think the right way is to prepare a policy proposal for the Cairo meeting later this year. It might be worth thinking who should prepare the proposal. > If indeed the (ICANN) root server operators have misgiving about the > experiment, could someone operating a root server express the reasons? According the the talk today (slides are available on htp://par.icann.org), there are no technical or operational issues anymore. From bmanning at vacation.karoshi.com Thu Jun 26 17:01:57 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 26 Jun 2008 15:01:57 +0000 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> <20080624233411.GA29727@vacation.karoshi.com.> Message-ID: <20080626150157.GA29871@vacation.karoshi.com.> >On Wed, Jun 25, 2008 at 03:28:09PM -0400, Edward Lewis wrote: >> At 19:53 -0700 6/24/08, David Conrad wrote: >> ...polled -some- root server operators.. Emphasis mine > > If indeed the (ICANN) root server operators have misgiving about the > experiment, could someone operating a root server express the reasons? > two things here. DRC didn't not poll -all- the operators, only some subset that he selected. re misgivings about sanctioned alternate roots that remain persistant... discusssions go back atleast a decade - details in old rssac minutes. in this case, (one) of the concerns is the defacto hijacking of the root zone editorial function - which is still done under contract/MOU wiht DoC and VSGN. Just one POV. --bill From drc at virtualized.org Thu Jun 26 19:34:37 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 26 Jun 2008 10:34:37 -0700 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <20080626150157.GA29871@vacation.karoshi.com.> References: <4860DCE4.6010403@psg.com> <20080624131242.GC24458@vacation.karoshi.com.> <20080624233411.GA29727@vacation.karoshi.com.> <20080626150157.GA29871@vacation.karoshi.com.> Message-ID: On Jun 26, 2008, at 8:01 AM, bmanning at vacation.karoshi.com wrote: >> On Wed, Jun 25, 2008 at 03:28:09PM -0400, Edward Lewis wrote: >>> At 19:53 -0700 6/24/08, David Conrad wrote: >>> ...polled -some- root server operators.. > Emphasis mine Actually, the sentence you attribute to me was also yours. >> If indeed the (ICANN) root server operators have misgiving about the >> experiment, could someone operating a root server express the >> reasons? > > two things here. DRC didn't not poll -all- the > operators, only some subset that he selected. Indeed (ignoring the presumably spurious 'not' in the above sentence). I also spoke to folks who weren't root server operators (gasp) to provide the secondary service for the demo/test DNSSEC- signed root zone. The goal wasn't to replicate the root server "system" (what would be the point of that?), rather it was to obtain secondaries for a production-quality demo/test service that would go away once the real root zone was signed. I was specifically looking for professionally-operated widely distributed anycast services that had a track record of knowing how to provide root-level DNS and who could spell DNSSEC. As you yourself are aware, there are folks other than the existing root server operators who can do that sort of thing... > re misgivings about sanctioned alternate roots that > remain persistant... Hence the requirement for an agreement, the exact thing into which some of the root server operators I spoke to refused to enter (the non- root server operator folks I spoke to understood the rationale and had no such qualms). > in this case, (one) of the concerns is the defacto > hijacking of the root zone editorial function - which > is still done under contract/MOU wiht DoC and VSGN. Riiight. Funny: the data served by ns.iana.org for the DEMO/TEST (hint: not the root name service the data for which is published by VeriSign) service was derived from ftp://ftp.internic.net/domains/root.zone. Of course, discussions with the root server operators didn't get very far once the term "agreement" came up and I quickly lost interest trying to pursue it. My patience for purely non-technical politics isn't what it used to be (and it wasn't that good to begin with). Regards, -drc From fw at deneb.enyo.de Fri Jun 27 04:05:30 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 27 Jun 2008 04:05:30 +0200 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: (Jakob Schlyter's message of "Tue, 24 Jun 2008 09:56:45 +0200") References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> Message-ID: <87k5gbmy39.fsf@mid.deneb.enyo.de> * Jakob Schlyter: > We would greatly appreciate your response, so we hope you are able to > take a few minutes to complete this survey. Your responses will > remain anonymous as no identity information will be recorded. I don't think there's a clear distinction between primary and secondary DNS service these days. Do you mean "primary" == "fed over non-AXFR protocols" and "secondary" == "fed over AXFR/IXFR"? From jakob at rfc.se Mon Jun 30 17:16:32 2008 From: jakob at rfc.se (Jakob Schlyter) Date: Mon, 30 Jun 2008 17:16:32 +0200 Subject: [dns-wg] .ORG DNSSEC Survey In-Reply-To: <87k5gbmy39.fsf@mid.deneb.enyo.de> References: <11930E35-B44C-4C38-9E0A-503A6A090B01@kirei.se> <87k5gbmy39.fsf@mid.deneb.enyo.de> Message-ID: On 27 jun 2008, at 04.05, Florian Weimer wrote: > * Jakob Schlyter: > >> We would greatly appreciate your response, so we hope you are able to >> take a few minutes to complete this survey. Your responses will >> remain anonymous as no identity information will be recorded. > > I don't think there's a clear distinction between primary and > secondary > DNS service these days. Do you mean "primary" == "fed over non-AXFR > protocols" and "secondary" == "fed over AXFR/IXFR"? I would define primary as the "zone editing function" and secondary as someone doing AXFR/IXFR from a primary. jakob