From andrei at ripe.net Mon Oct 1 10:04:03 2007 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 01 Oct 2007 10:04:03 +0200 Subject: [dns-wg] Re: [enum-wg] Deploying DNSSEC in e164.arpa zone In-Reply-To: <200709281008.l8SA8cJU087117@bartok.nlnetlabs.nl> References: <200709281008.l8SA8cJU087117@bartok.nlnetlabs.nl> Message-ID: <4700A9F3.40302@ripe.net> Jaap Akkerhuis wrote on 28-09-2007 12:08: > > this domain is signed, ALL servers respond with DNSSEC data EXCEPT the > RIPE server which do not support DNSSEC.... > > so if you resolve domains from 8.4.e164.arpa zone using RIPE server, you > can't get DNSSEC enabled answers. > > we will remove ns.ripe.net and the problem will be solved today. > > Ah, I might have hit that one, I just only tried it once. But there > is at least one lesson in this: you make sure al servers support > DNSSEC when you roll it out. > We are tracking down the problem together with NASK; as far as we can see ns.ripe.net returns the right dnssec information. > jaap > Andrei Robachevsky CTO, RIPE NCC From sjoerdoo at ripe.net Mon Oct 8 15:28:13 2007 From: sjoerdoo at ripe.net (Sjoerd Oostdijck) Date: Mon, 08 Oct 2007 15:28:13 +0200 Subject: [dns-wg] DNS Maintenance on ns.ripe.net, 10 Okt Message-ID: <470A306D.6090807@ripe.net> [Apologies for duplicate e-mails.] Dear Colleagues, On Wednesday, 10 Oktober 2007, we will update our DNS server ns.ripe.net between 17:00 and 18:00 (UTC). During this period, it will not be able to answer DNS queries. We apologise for any inconvenience this may cause. If you have any questions or concerns about this, please send an e-mail to . Regards, Sjoerd Oostdijck, DNS Services RIPE NCC From jim at rfc1035.com Tue Oct 16 23:50:00 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 16 Oct 2007 22:50:00 +0100 Subject: [dns-wg] DNS Migration document Message-ID: <9AC240CA-915D-40BF-A0C2-CE54EEE44C6C@rfc1035.com> 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. My hope is that the WG does not discuss the document in detail at next week's meeting. There will probably be some revisions needed -- send text! -- so a line-by-line dissection at RIPE55 will not be productive. Though if that's what the WG wants to do.... IMO it would be better if the WG discussed next week what to do with the document. ie Should sections be added or removed, should it be made less implementation-specific and what should happen to the document once the WG is finished reviewing it. In other words, should it be published as a RIPE document or not and what, if anything, needs to be done to get it to that state. These sorts of things would perhaps be a better focus for discussions next week. -------------- next part -------------- A non-text attachment was scrubbed... Name: DNSmigration Type: application/octet-stream Size: 36287 bytes Desc: not available URL: -------------- next part -------------- From jarle at uninett.no Wed Oct 17 20:28:36 2007 From: jarle at uninett.no (Jarle Greipsland) Date: Wed, 17 Oct 2007 20:28:36 +0200 (CEST) Subject: [dns-wg] DNS Migration document In-Reply-To: <9AC240CA-915D-40BF-A0C2-CE54EEE44C6C@rfc1035.com> References: <9AC240CA-915D-40BF-A0C2-CE54EEE44C6C@rfc1035.com> Message-ID: <20071017.202836.83585719.jarle@uninett.no> Jim Reid 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). 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. [ ... ] > 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 the actual transition period can be deduced from the published TTL values. Should the document cover this? [ ... ] > 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 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." From jim at rfc1035.com Thu Oct 18 10:01:21 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 18 Oct 2007 09:01:21 +0100 Subject: [dns-wg] DNS Migration document In-Reply-To: <20071017.202836.83585719.jarle@uninett.no> References: <9AC240CA-915D-40BF-A0C2-CE54EEE44C6C@rfc1035.com> <20071017.202836.83585719.jarle@uninett.no> Message-ID: <6B3A5390-89D3-4174-89FA-9B2ACD36F530@rfc1035.com> Thanks very much Jarle for going through the document so thoroughly and for contributing improved text. I'll see these get incorporated into the next release. From denic at eng.colt.net Thu Oct 18 11:59:20 2007 From: denic at eng.colt.net (Ralf Weber) Date: Thu, 18 Oct 2007 11:59:20 +0200 Subject: [dns-wg] RIPE-55 coming up -- Agenda's items sought In-Reply-To: <200709040910.l849A1lo028879@bartok.nlnetlabs.nl> References: <200709040910.l849A1lo028879@bartok.nlnetlabs.nl> Message-ID: <793D184B-D41B-4034-B3C8-1695E7C85839@eng.colt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin! On 04.09.2007, at 11:10, Jaap Akkerhuis wrote: > Yes, it is that time of the year. In seven weeks we will have another > RIPE meeting. We have the usual two slots. Please provide agenda > items or suggestions for such items. Mail them to the list or just > to the chairs. Well it's less than a week now, and I want to add a topic that either Peter has forgotten to add or that he wants to be handled within Topic C on the first session on Wednesday: - - DNSSEC reverse delegations from RIPE NCC - experiences, problems, challenges Also on the meeting plan for next week in the weekly overview there is a DNSSEC Key Repository Task Force session on Monday at 11, however this does not appear on the Monday overview, but instead as Topic F in the first session on Wednesday. Am I right that Monday session will not take place (Would be ok as my train just arrives at that time ;-)? So long - -Ralf - --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFHFy55Enqpqs8vDM8RAgV4AJ4w8AstO/xtIgKWYRAz6xEjw7K9tgCdEr/N MaOUsDlK5cm1sjcfPvkVYAI= =mqr6 -----END PGP SIGNATURE----- From jim at rfc1035.com Thu Oct 18 13:44:47 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 18 Oct 2007 12:44:47 +0100 Subject: [dns-wg] RIPE-55 coming up -- Agenda's items sought In-Reply-To: <793D184B-D41B-4034-B3C8-1695E7C85839@eng.colt.net> References: <200709040910.l849A1lo028879@bartok.nlnetlabs.nl> <793D184B-D41B-4034-B3C8-1695E7C85839@eng.colt.net> Message-ID: <314476DB-DE87-46BE-951A-1B464D7C102F@rfc1035.com> On Oct 18, 2007, at 10:59, Ralf Weber wrote: > Also on the meeting plan for next week in the weekly overview there is > a DNSSEC Key Repository Task Force session on Monday at 11, however > this does not appear on the Monday overview, but instead as Topic F in > the first session on Wednesday. Am I right that Monday session will > not take place (Would be ok as my train just arrives at that time ;-)? Ralf, the slot on Monday is intended for the people who volunteered to be on this Task Force. Though if somebody else happens to wander into the room during that session and make a positive contribution to the discussion, I can't see why anyone would want to complain about that. The outcome of that Monday morning Task Force session will be summarised and reported to the DNS WG just like the regular reporting we do about latest IETF developments, liaisons from other WGs, etc, etc. I hope this clarifies things. From pk at DENIC.DE Wed Oct 24 10:50:30 2007 From: pk at DENIC.DE (Peter Koch) Date: Wed, 24 Oct 2007 10:50:30 +0200 Subject: [dns-wg] Finally: first draft for RIPE203bis Message-ID: <20071024085030.GB20148@denics7.denic.de> Dear DNS WG, there is no real good excuse I could come up with for the long delay, so I won't try. With apologies, please find attached the ASCII version of a first draft document of an update to RIPE-203 "Recommended DNS SOA Values" and a diff to the original(*) version. Changes are a new value for the negative TTL, an explicit hint that the recommended values should not be unconditionally enforced and some editorial updates. Feedback welcome, with one early opportunity during this afternoon's WG session. -Peter (*) the "original" version was based on the text version of an Internet-Draft and thus contains some potentially confusing headers and footers. These were edited away before applying the "diff" function. -------------- next part -------------- Peter Koch DENIC eG October 2007 Recommendations for DNS SOA Values Abstract The configuration and maintainance of DNS zones offer many degrees of freedom and thus several opportunities for making mistakes. Most DNS zones today are small and have to be set up and maintained by non- experts. This document gives recommendations on which values to use for the SOA resource record of small, stable DNS zones to aid novice administrators and to contribute to DNS stability end efficiency. 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. Background Various DNS surveying activities show that the vast majority of today's DNS zones are populated by very few hosts. In most cases there is only an HTTP server announced under the common name "www", sometimes accompanied by distinct mail or DNS servers or a bastion host. For many of these zones the configuration is touched once when it is set up and then left alone without modification for a long time. These recommendations are aimed at small and stable DNS zones. There are many legitimate reasons to use different values, e.g. proposed changes or special purpose applications. Administrators of those zones should consult one of the various more detailed DNS guidelines or books. Several other recommendations for SOA values exist [RFC1537, RFC1912], which are not obsoleted by this document but which have a different focus. At the time of their writing DNS zones were usually more densely populated and their target audience was supposed to be responsible for a broader range of DNS zones. ISPs and DNS server vendors are encouraged to use this information for their customers, in configuration tools or as default values. However, the values used here should not be strictly enforced by DNS registries or registrars, since they only apply to a limited, albeit large, subset of DNS zones. Additional hints for initial name server setup and configuration of this type of zone can be found in [RIPE192]. 3. Recommended SOA Values example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( 2007102401 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 3600 ) ; negTTL ( 1 hour) 4. Remarks and Explanation The values presented in the example.com SOA RR are discussed in detail. One main goal was to provide for fixed cut-and-paste values wherever possible instead of intervals to reduce the chance of operational problems caused by unfortunate combinations. Other values or sets of values will work as well, this is one set of values which reflects successful current practice with respect to scalability and stability. 4.1. The MNAME Value The DNS specification explicitly states that the primary master server be named here. The value must be determined and used. Especially it is a mistake to repeat the zone name in this field, unless that also leads to a valid address of the primary master. Note that neither the primary master nor any other authoritative name server necessarily have to reside within the zone. 4.2. The RNAME Value The RNAME is to publish a mail address of a person or role account dealing with this zone with the "@" converted to a ".". The best practice is to define (and maintain) a dedicated mail alias "hostmaster" [RFC2142] for DNS operations. 4.3. The Serial Number The most important issue is that this value be incremented after any modification to the zone data. For debugging purposes it has shown to be helpful to encode the modification date into the serial number. The value "2007102401" so is an example of the YYYYMMDDnn scheme and must be replaced by proper values for the year (YYYY, four digits), month (MM, two digits), day of month (DD, two digits) and version per day (nn, two digits). The first version of the day should have the value "01". It is important to preserve the order year - month - day. People using this as a debugging aid must, however, not rely on the date informnation, since experience shows that after initial setup maintainance of this value is often left to the auto-increment feature the software sometimes provides. Other schemes exist - documentation of which is out of the scope of this document. 4.4. The Refresh and Retry Values The refresh and retry values primarily affect the zone maintainer and the secondary service providers and may be negotiated between them. The values chosen here are aimed at scalability. Modern DNS software implements NOTIFY [RFC1996] and reduces the need for frequent SOA checks, as does the assumption of stability of the zone. While lower values would only slightly increase the bandwidth usage, they would increase the load on servers which are slaves for very large numbers of zones. 4.5. The Expire Value The primary goal is to ensure stability of the zone data, even if a mistake invalidating (non-authorizing) the zone or a network outage last for several days. A value of a week or two has proven to be way too short, so a longer time must be used. The specific value was chosen for aesthetic and historic reasons and to disambiguate between the different proposed values of "long". 4.6. The Minimum TTL Value Even though this field has the name "minimum TTL", today the predominant function is to specify the default negative TTL as per [RFC2308]. Therefore, the recommended value is one hour and it is also recommended that the TTL of the SOA record itself has the exact same value. Other resource records within the zone, especially the NS RRSet, should have a longer TTL to be cache-friendly. It is recommended that be achieved by use of the "$TTL" directive at the top of the zone, e.g. "$TTL 86400". 5. Security Considerations Filling in the recommended values will not directly influence security of the name servers for the particular zone, any system with a name in that zone or any other system in the Internet. However, following these guidelines will likely contribute to DNS stability and thus to reachability. Maintaining proper contact information in the SOA RNAME field helps people in reporting problems, although the address distributed there is not recommended as a primary security contact. 6. Acknowledgements This work is a product of the RIPE DNS working group. 7. References [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987 [RFC1035] Mockapetris,P., "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RFC1123] Braden,R., "Requirements for Internet Hosts -- Application and Support", RFC 1123, STD 3, October 1989 [RFC1537] Beertema,P., "Common DNS Data File Configuration Errors", RFC 1537, October 1993 [RFC1912] Barr,D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996 [RFC1996] Vixie,P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996 [RFC2142] Crocker,D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997 [RFC2308] Andrews,M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998 [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", RFC 2606, BCP 32, June 1999 [RIPE192] RIPE DNS WG, "SIMPLE DNS CONFIGURATION EXAMPLE", RIPE-192, February 2000 8. Author's Address Peter Koch DENIC eG Wiesenhuettenplatz 26 60329 Frankfurt Germany -------------- next part -------------- --- ripe-203ASCII.txt Wed Oct 24 09:46:52 2007 +++ ripe-203bisASCII.txt Wed Oct 24 10:34:42 2007 @@ -1,8 +1,9 @@ Peter Koch - Universitaet Bielefeld - June 1999 + DENIC eG + October 2007 Recommendations for DNS SOA Values + Abstract @@ -27,33 +28,35 @@ there is only an HTTP server announced under the common name "www", sometimes accompanied by distinct mail or DNS servers or a bastion host. For many of these zones the configuration is touched once when - it is set up and then left alone without modification for a long - time. + it is set up and then left alone without modification for a long time. These recommendations are aimed at small and stable DNS zones. There are many legitimate reasons to use different values, e.g. proposed changes or special purpose applications. Administrators of those zones should consult one of the various more detailed DNS guidelines or books. Several other recommendations for SOA values exist - [RFC1535, RFC1912], which are not obsoleted by this document but + [RFC1537, RFC1912], which are not obsoleted by this document but which have a different focus. At the time of their writing DNS zones were usually more densely populated and their target audience was - supposed to have more interest in DNS. + supposed to be responsible for a broader range of DNS zones. ISPs and DNS server vendors are encouraged to use this information for their customers, in configuration tools or as default values. + However, the values used here should not be strictly enforced by DNS + registries or registrars, since they only apply to a limited, albeit + large, subset of DNS zones. Additional hints for initial name server setup and configuration of - this type of zone can be found in [DNSGUIDE1], [DNSGUIDE2]. + this type of zone can be found in [RIPE192]. 3. Recommended SOA Values example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( - 1999022301 ; serial YYYYMMDDnn + 2007102401 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) - 172800 ) ; minimum ( 2 days) + 3600 ) ; negTTL ( 1 hour) 4. Remarks and Explanation @@ -69,8 +72,10 @@ The DNS specification explicitly states that the primary master server be named here. The value must be determined and used. - Especially it is a mistake to repeat the zone name here, unless this - also leads to a valid address of the primary master. + Especially it is a mistake to repeat the zone name in this field, + unless that also leads to a valid address of the primary master. + Note that neither the primary master nor any other authoritative + name server necessarily have to reside within the zone. 4.2. The RNAME Value @@ -85,7 +90,7 @@ The most important issue is that this value be incremented after any modification to the zone data. For debugging purposes it has shown to be helpful to encode the modification date into the serial number. - The value "1999022301" so is an example of the YYYYMMDDnn scheme and + The value "2007102401" so is an example of the YYYYMMDDnn scheme and must be replaced by proper values for the year (YYYY, four digits), month (MM, two digits), day of month (DD, two digits) and version per day (nn, two digits). The first version of the day should have the @@ -106,7 +111,8 @@ implements NOTIFY [RFC1996] and reduces the need for frequent SOA checks, as does the assumption of stability of the zone. While lower values would only slightly increase the bandwidth usage, they would - increase the load on servers which are slaves for thousands of zones. + increase the load on servers which are slaves for very large numbers + of zones. 4.5. The Expire Value @@ -119,14 +125,14 @@ 4.6. The Minimum TTL Value - There are two meanings for this value with practical relevance. - First, it serves as a default value for the TTL of all RRs without a - given value. To be cache-friendly this value was chosen to be two - days, which also follows the stability assumption. The second meaning - is the default negative TTL [RFC2308], which would call for a lower - value. We are in a transition phase now with software implementing - either of both meanings, so the TTL of one hour is recommended for - the SOA itself, which will lead to nearly the same effect. + Even though this field has the name "minimum TTL", today the predominant + function is to specify the default negative TTL as per [RFC2308]. + Therefore, the recommended value is one hour and it is also recommended + that the TTL of the SOA record itself has the exact same value. + Other resource records within the zone, especially the NS RRSet, + should have a longer TTL to be cache-friendly. It is recommended that + be achieved by use of the "$TTL" directive at the top of the zone, + e.g. "$TTL 86400". 5. Security Considerations @@ -174,21 +180,14 @@ [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", RFC 2606, BCP 32, June 1999 - [DNSGUIDE1] Liman,L., "SIMPLE DNS CONFIGURATION EXAMPLE", work in - progress - - [DNSGUIDE2] Koch,P., "RIPE Guide To Setting Up a DNS Server", work in - progress - - + [RIPE192] RIPE DNS WG, "SIMPLE DNS CONFIGURATION EXAMPLE", RIPE-192, + February 2000 8. Author's Address Peter Koch - Universitaet Bielefeld - Technische Fakultaet - Postfach 10 01 31 - D-33501 Bielefeld + DENIC eG + Wiesenhuettenplatz 26 + 60329 Frankfurt Germany - +49 521 106 2902 - + From kim.davies at icann.org Wed Oct 24 22:29:43 2007 From: kim.davies at icann.org (Kim Davies) Date: Wed, 24 Oct 2007 13:29:43 -0700 Subject: [dns-wg] Advisory - L.ROOT-SERVERS.NET changing to 199.7.83.42 on 2007-11-01 Message-ID: <471FAB37.408@icann.org> Colleagues, This is advance notice that there is a scheduled change to the IP address for one of the authorities listed for the DNS root zone. The change is to L.ROOT-SERVERS.NET, which is administered by ICANN. The new IPv4 address for this authority is: 199.7.83.42 This change is anticipated to be implemented in the root zone on 1 November 2007, however the new address is operational now. It will replace the previous IP address of 198.32.64.12. We encourage operators of DNS infrastructure to update any references to the old IP address, and replace it with the new address. In particular, many DNS resolvers have a DNS root "hints" file. This should be updated with the new IP address. New hints files will be available at the following URLs once the change has been formally executed: ftp://rs.internic.net/domain/db.cache ftp://rs.internic.net/domain/named.cache ftp://rs.internic.net/domain/named.root ftp://ftp.internic.net/domain/db.cache ftp://ftp.internic.net/domain/named.cache ftp://ftp.internic.net/domain/named.root It is expected that the old address will continue to work for at least six months after the transition, but will ultimately be retired from service. With kindest regards, Kim Davies Internet Assigned Numbers Authority From hiromi at inetcore.com Thu Oct 25 10:07:24 2007 From: hiromi at inetcore.com (Ruri Hiromi) Date: Thu, 25 Oct 2007 17:07:24 +0900 Subject: [dns-wg] v6 DNS testbed for TLD? Message-ID: <2ACB7FC0-5515-4E68-A995-F92A3D42B42B@inetcore.com> Hello, I just join this mailing-list and I am very new to the DNS- WG at ARIN. As I said in my presentation "what can I do for dns grue record?", If we share some test environment/simulator for conformance and stable operation for TLD name servers, will it go a step forward? Or does ARIN community already have such testbed? Regards, ------------------------------- Ruri Hiromi hiromi at inetcore.com From hiromi at inetcore.com Fri Oct 26 09:05:26 2007 From: hiromi at inetcore.com (Ruri Hiromi) Date: Fri, 26 Oct 2007 16:05:26 +0900 Subject: [dns-wg] v6 DNS testbed for TLD? In-Reply-To: <2ACB7FC0-5515-4E68-A995-F92A3D42B42B@inetcore.com> References: <2ACB7FC0-5515-4E68-A995-F92A3D42B42B@inetcore.com> Message-ID: <23CBBEA8-F069-4E71-816C-939B0A1780C7@inetcore.com> I Made terrible typo! @ARIN should be @RIPE... deeply apologize to you all. and thanks to the all of you gave me precious comments at off-line. On 2007/10/25, at 17:07, Ruri Hiromi wrote: > Hello, I just join this mailing-list and I am very new to the DNS- > WG at ARIN. > > As I said in my presentation "what can I do for dns grue record?", > If we share some test environment/simulator for conformance and > stable operation for TLD name servers, will it go a step forward? > Or does ARIN community already have such testbed? > > Regards, > ------------------------------- > Ruri Hiromi > hiromi at inetcore.com > > > ------------------------------- Ruri Hiromi hiromi at inetcore.com