- dns-wg - mailman.ripe.net

draft minutes from RIPE 48 DNS WG sessions
by Peter Koch 04 Jul '04

04 Jul '04

Dear all, please find below the draft minutes for our RIPE 48 sessions. Thanks to Timur Bakeyev and Alessandro Bassi from the RIPE NCC for being the scribes. Please read these minutes and send in any necessary corrections either to the list or, if minor, to the chairs at dns-wg-chair(a)ripe.net. We plan to have the minutes taken to the wg's files by July, 25th. There's also an action items list at http://www.ripe.net/ripe/wg/dns/action-list.html -Peter ======================================================== RIPE Meeting: 48 Working Group: DNS Working Group Status: 2nd Draft Revision Number: 3 * content to the Chair of the working group. * format to webmaster(a)ripe.net. ======================================================== DNS Working Group, Session 1 (DRAFT) RIPE 48 Amsterdam Date: Tuesday, 4 May 2004 Time: 16:00 - 17:30 Location: Grand Ballroom Chair: Jim Reid Scribe: Timur Bakeyev, RIPE NCC - Administrivia. Introduction Session is going to be Web casted as well as reflected in Jabber. Request to participants to hold their question till the end of presentation. Thanks to Nominet, who sponsored the chair of this group. Swap of the presentations: Instead of "DNSSEC forum" by Suzanne Woolf -> "DNS an MCI, another type of large DNS server" by Andre Koopal. - "Proposed new charter", Peter Koch http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-charter.… The DNS Working Group discusses current DNS related issues in technology and operations. The WG encourages deployment of DNS and DNS-related protocol components by collecting experience and documenting current practice and recommendations. It therefore provides a mechanism for exchanging practical and operational experience with organizations like CENTR and the IETF. The WG discusses DNS software implementations, especially security and scalability aspects as well as performance and interoperability considerations. DNS quality and other factors that may affect the stability of the DNS system are also discussed by the WG. The DNS WG provides a forum for the Registry and Registrar community. It discusses the technical and operational issues arising from registration policies with a specific focus on the deployment of new and emerging features. Charter was approved by the meeting. - "CENTR news", Kim Davies; CENTR http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-centr.pdf - "Implementation of the BACK ORDER service", Andrzej Bartosiewicz; NASK http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-backorde… This will be launched on 1st June, 2004. System of options - similar to stock exchange options. - "EPP implementation", Patrycja Wegrzynowicz; NASK http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-backorde… XML based Extensive Provision Protocol Q: Can you explain the slide: Registrar buys option for the Registrant. What are the terms used? A: Registrar is the agent of Registrant. Q: (Jim) What is the reaction of the customers on the new schema and how Registrars like it? A: As for Registrants, they hardly even notice the change. It's more attractive to the Registrars. They are quite happy :) - "Deploying IDNs in the .no domain", Jarle Greipsland; NorID. http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idns-no.… Q: (Jaap) What do you exactly register in your forms - UNICODE, Punycode or just US encoding? A: When register you have to fill out both in the forms. On update you can supply any of them. Q: And what is your Whois server accepts? A: It is either US-ASCII, ISO-Latin1 or UTF8. Q: And the input for the request? A: US-ASCII or Latin1 by default, but you can supply switch to use UTF8. Q: (Carsten) Speaking about legal terms - what is registration contract about? Is it about IDN in UTF8 or in Punycode? A: Both versions are on contract. Q: So, the contract actually is about bundle of two names? A: Yes, both names are defined there(Get two for the price of one:) - "IDN deployment in Germany", Marcos Sanz; DENIC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idn-de.p… Q: (Peter) That binary queries, you talked about - did you take a look onto second level labels or all the labels? A: All the labels(of course in .de) Q: And for those queries your DNS server received - did you try to cross check whether that binary, UTF, Latin1 names, what ever you found there - were that names actually registered within .de? A: I didn't do it systematically, but yes, most of them there registered? Q: Question remains, what names where queried before they have chance to be registered? A: Random words, general terms... In the last week we saw, that people mostly tried to reach that MAY exist on their opinion. - ".info support for German script", Desiree Miloshevic; Afilias http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idn-laun… Q: There have been reports, that there is a project to make IDN available without software upgrade? A: That was misinterpretation of our announces in the press. C: (Jaap) Charset names, used for IDNs should be standardized, possibly through the IANA or other Internet official bodies... - "DNS at MCI", Andre Koopal; MCI http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-mci.pdf Q: (Peter) You are acting as a secondary for customers. What happens when primary(at your customer) disappears? That should lead to the lame delegations and query storms... A: We do remove them from the configs after certain amount of time. No special actions are taken against query storms, though. C: (Jaap) You've said, that you don't use Bind 9 for NL TLD, because it's too picky about the standards. But that's the goal - to enforce standards for those lame delegations! Q: (Olaf) Are you sure that Bind 9 doesn't accept '/' in the domain names? A: Not really, maybe some other quite popular symbol, but the problem exists.. Q: (Jim) Are you making efforts to move to Bind 9? A: Not right now, at least. C: (Peter) there is clearly problem with disappearing customers for DNS integrity. Registrars refuse to remove them on ISPs requests. What can be done in such situation? What is the common practice? Would it be OK to make it an action point for WG? R: (Jim) That's a good idea! Peter, you've just volunteered to bring in to the DNS WG :) [ACTION 48.1] on Peter Koch: Collect experience with lameness problems, initiate BCP style document and wishlist for support by TLD registries. ======================================================== DNS Working Group, Session 2 (DRAFT) RIPE 48 Amsterdam Date: Thursday, 6 May 2004 Time: 9:00 - 12:30, Location: St. Johns II Chair: Peter Koch (09:00 - 10:30), Jim Reid (11:00 - 12:30) Scribe: Alessandro Bassi, RIPE NCC - "IETF Reports", Sam Weiler; TIS Labs http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-ietf.pdf Last IETF was held in Seoul, apparently was quite "boring". Next meeting in August, in San Diego. DNS discovery for IPv6: a summary comparing the alternatives must be done before august, otherwise the item will be removed. DNSOP: business as usual, several drafts in progress, several ones stopped or in stand by. DNSEXT: 9 open drafts DNSSEC: No recent problems. It has to be noted that there are no major protocol issues in the last year DNSEXT: most milestones are advanced to draft standards. There is an RFC 3597 interoprability testing coordinated by Jakob Schlyter Mailing list: https://www.rfc.se/mailman/listinfo/interop3597 or interop3597-request(a)rfc.se - "K-Root operations update", Dave Knight; RIPE NCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-kroot-up… Status: Global instances are in London and A'dam. Recently two more secondary have been installed in Frankfurt and Athens. Web site has been renewed completely, and a stats page has been added. More stats will come in the near future. The current query load is 7000 queries/second. Of these, the great majority is directed to London and Amsterdam. Future plans: - to have 4 more instances of primary servers, two in the US and two in Asia. - to deploy IPv6. Q: (Jim) Has any traffic analysis been done? Are the Greeks using the Athens server? A: Those kind of stats will be available in a couple of months. - "Reverse DNS status report", Olaf Kolkman; RIPE NCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-rdns-upd… New reverse DNS, for more fine-grain control, multiple interfaces, and simplification of policies. Today, because of the current policies, there might be inconsistencies and confusion. Policies will change drastically. Status: the cleanup (prerequisite) was made the first week of April. April 26, the new interface and new policy were put live. Marvin will die the 1st of July. the DNSSEC implementation has been deferred. In the new policy, there is no need for assignment (as before), and anybody authorized can do the Rev DNS. Another change is mnt-by, which becomes mandatory. When submitting the request, points will be added for warnings and errors; over a certain limit, the request will be rejected. Q: (Jim) Any plans to introduce TSIG ... A: No plans Q: Do people care about it? Why not? A: (Peter): Zone transfer restrictions are useless anyway for most zones. Restrictions can be IP based. [ACTION 48.2] An action item was created on Mans Nilsson to write up a proposal for the use of TSIG for zone transfers, when ns.ripe.net acts as a secondary. [ACTION 48.3] Olaf Kolkman was kindly asked to send to the list a pointer to the predelegation checks currently applied and to initiate review of those checks and, if necessary, propose changes. - "DNS-MODA", Jim Reid http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-moda.pdf There is a growing frustration with the IETF process, something different is needed. Something similar to what W3C is, so a W3C for DNS, no profit, impartial. MODA will not be a standards-making body, or introduce proprietary solutions, but will work with IETF to improve the current procedures. Q: (Geoff Huston) This is alien to what IETF does. IETF also hates Intellectual Rights problems, and being considered like a rubber stamp to somebody else's solution, especially if it's half-baked ideas. IETF must discuss things. A: The idea is to speed things up, not to have IETF as rubber stamp body. The work that comes out of MODA will be well-thought out and shouldn't be half-baked. Q: (Geoff Huston) IETF has a bad record in working with industry. IETF task is to work on new things; the risk is exacerbating problems and making alliances outside. Q: (Patrik) W3C is not a good example. For instance, let's take HTTP (IETF) and XML (W3C), there were lots of problems not to make the same thing twice and work on the same issues. Also, what is the decision making process of MODA? It is not clear at the moment. A: True enough: those processes will be determined by the membership. Q: (Rob Blokzijl) I agree in what Patrick just said, In IETF there's an open, unconditional participation. MODA is more like a closed Club. MODA is needed, but it's a bad idea to throw out the free participation. some re-thinking is needed. Q: (Patrik Faltstrom) If there is a need for MODA, then IETF does not work. You have to say it clearly. A: we are trying to to be collaborative and cooperative, not seeking confrontation. . Q: (Rob Blokzijl) There is no logo yet? And, what is the IETF reaction to this idea? A: The important thing was to announce MODA at this meeting and so start the efforts to recruit members. The web site and logo will come later. Discussions have been held with the IETF about MODA for some time. While there's been no formal response yet, the signs are good. Though both parties will need to see how things work out in practice. - "DNS AAAA measurements: How many sites have problems with IPv6",David Malone; CNRI http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-malone.p… Q: (Jim) Delegation -> capture the info and document it. Write a document about how to avoid config problems. [ACTION 48.4]: David agreed to write a document about this for the WG to consider. - "6over4 reverse Delegation",Geoff Huston; ICANN http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-sixxto4.… Individual draft submitted. Keith Moore submitted also some work in the past, with ideas ranging from reasonable to bizarre. Q: (Bernard Tuy) which kind of draft did you submit? A: Individual submission. Not against all the work that has already been done, but there has been a request to the reverse delegation community to do some more work on it. - "Reverse delegation in ip6.int", Andrei Robachevsky; RIPE NCCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-reverse-… Q: (Peter) You suggested to remove ip6.int delegation. What is the current load? A: around 3 queries per minute. == BREAK == - "ISC News", Joao Damas; ISC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-isc.pdf Advancement on Bind 9.3 Q: (Bernard Tuy) What does OARC mean? A: Operation Analysis Research Centre. Q: (Jim) What is the timescale for the release of 9.3? Does it depend on IETF work on DNSSEC? A: No, it does not. It will probably be next week. NLNet update - "DNSSEC forum",Suzanne Woolf; ISC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-dnssec-r… DNSSEC specs are done, but deployment is less formal and less well documented. There are problems in deployment. Privacy issues also still have to be tackled. Q: (Peter Koch) You mentioned a discussion of zone walking, which may be considered a deployment obstacle. Any solutions? A: Not yet. We are identifying issues but we don't know how serious they are and what needs to be done. A: (Olaf Kolkman) A protocol change at this point would mean that we'll be back to the drawing board. Changing the protocol would mean a delay of one year. There is no obvious solution in sight. - "Query load variation on ccTLD servers during delegation phases", Mans Nilsson; KTH http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-f2f.pdf Problems, delay introduced because of IANA. Q: (Doug Barton) First, some good news, we are working on v6; the board meeting in May will discuss it. About the delay, when was the request submitted? A: Well, not yet submitted Q: Then I accept your apologies for not blaming IANA to be late when no request have been submitted. Normally it takes 2 days. - "DNS Survey",Peter Koch; Universitaet Bielefeld http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-survey.p… Looking into the .de; Bind 8 by number has only 30%, but 60% by delegation, and 72% by weighted delegation. Q: (Jim) Why lots of people are still running Bind 8? A: Not really lots. Some of them are very large providers. There is a concern about load. Also, Bind until version 9.2 has a protocol problem, fixed with 9.3; so maybe, in the near future figures will change. - AOB Patrik Faltstrom is standing down as DNS WG co-chair. He will probably have some role in the ENUM WG that is expected to be formed. Jim thanked Patrik for his efforts in the DNS WG. He said that since this created a vacancy for a co-chair, he invited anyone who was interested in becoming a co-chair to get in touch. ========================================================

1 0

AAAA lookup misbehaviour
by David Malone 03 Jul '04

03 Jul '04

At the last RIPE meeting I was given an action item: Write up a draft RIPE document summarizing the observations made regarding AAAA resolution problems. Circulate to the list, initiate discussion what to, i.e. whom to approach with the list of errors/problems seen. I checked with Peter, and he says the documents are pretty freeform, so I've written a few paragraphs, included below. David This document is a short description of problems with certain DNS systems that have come to light with the deployment of IPv6 enabled software. --- One of the services that DNS provides is a facility for mapping host names to IPv4 addresses. This is probably the most common used service that DNS provides, and is achieved requesting a record of type "A" for the host name. Records of type A can only store an IPv4 address, and so with the introduction of IPv6, a new record type, AAAA has been introduced. It is becoming increasingly common for software to first issue a request of type AAAA, and if no record of that type is found then to issue a request for a record of type A. A request for a record of type AAAA causes no problems for most DNS servers, however some DNS servers have been found that have problems answering queries not of type A. The technical details of these problems are explained in the IETF draft document draft-ietf-dnsop-misbehavior-against-aaaa-01.txt. In 2004, about 0.5--1% of name servers seem to have to have a problem of this nature. The end result of these issues is that connecting to a site using a problematic name server may be impossible, intermittent or significantly delayed. To prevent introducing more DNS servers with such issues, testing of new DNS equipment should include checking that the response for records is in accordance with the RFCs. As DNS load balancing software has often fallen foul of these problems, particular care should be taken in testing and validating such systems. The fact that problematic nameservers exist is in itself a problem. Where these issues cause direct inconvenience, the maintainers of the server and the maintainers of the DNS data should be notified to allow a normal service to be restored. However, often it is difficult for end users to identify the source of these problems, (for example, where an image embedded in a web page being served from a host with a problem hostname). It is also possible to automatically produce lists of names and nameservers that exhibit these problems. Clearly it is possible to automatically mail hostmaters or to publish "hall of shame" lists based on such data. It is unclear if such actions would achieve any useful effect, as service maintainers are usually primarily concerned about complaints directly from paying users!

3 2

Re: [dns-wg] IANA proposal for changing TLD delegations
by Marcel Schneider 28 Jun '04

28 Jun '04

On Thursday, 24 Jun 2004, Jim Reid writes: > IANA has published a proposal on how it plans to deal with changes in > the root zone for TLD delegations. It's at > http://www.iana.org/procedures/delegation-data.html. > I would recommend that people read this and comment on it. TLD owners > in particular might want to pay special attention to the part headed > "IANA Procedures for Removing Problematic Delegation Data ". We have been checking the document before and found nothing to worry about. The part you are referring to deals with restoring the DNS in case of emergency. The title is of course not well chosen - it could be interpreted in different ways, as suggested by Jim, but the measures are sound. Marcel

1 0

Re: [dns-wg] IANA proposal for changing TLD delegations
by Jim Reid 25 Jun '04

25 Jun '04

>>>>> "Brad" == Brad Knowles <brad.knowles(a)skynet.be> writes: >> http://www.iana.org/procedures/delegation-data.html. Brad> I read the proposal on the web page. Except for their Brad> complete lack of discussion of things like IPv6, DNSSEC, Brad> etc..., I don't see anything specifically and obviously Brad> wrong with what they've got. Everything seems, more or Brad> less, fairly reasonable. Brad> Do you have some specific comments/views on the Brad> proposal? If so, could/would you be willing to share them Brad> with us? Well the section "IANA Procedures for Removing Problematic Delegation Data" suggests to me that IANA may unilaterally decide to change the delegation of a TLD without the consent of the TLD operator. And it's not at all clear what circumstances and criteria would prevail for IANA to justify taking that action. Not that this practice can ever be justified IMO. IANA can't possibly know what the best or correct name servers for some TLD will be. By definition only the TLD operator can decide that. I'm rather surprised that nobody seems to think this is part of the proposal could be more than a little controversial. And if IANA starts changing the root zone whenever it feels like doing so -- OK I exaggerate for effect -- that sets a very dangerous precedent. When it comes to the root zone, IANA must only act as the registry. It must always be someone/something else that decides what goes in the root zone. Of course this doesn't preclude IANA from checking delegations and making recommendations about changes. But there must be a seperate role that has the responsibility of instructing IANA to make changes to the root zone. IANA must not have that authority itself. Perhaps this section of the proposal is just badly written? However I fear it's badly thought out instead.

1 0

IANA proposal for changing TLD delegations
by Jim Reid 25 Jun '04

25 Jun '04

IANA has published a proposal on how it plans to deal with changes in the root zone for TLD delegations. It's at http://www.iana.org/procedures/delegation-data.html. I would recommend that people read this and comment on it. TLD owners in particular might want to pay special attention to the part headed "IANA Procedures for Removing Problematic Delegation Data ". Unfortunately the closing date for comments was June 21st -- I've only just seen this document. However a revised version is promised for June 28th, so there may still be an opportunity to comment on the current one.

3 2

Re: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Jim Reid 16 Jun '04

16 Jun '04

Not having seen the whole discussion thread, it's a bit hard to make sense of what's been said. However it appears to be that someone is saying that the need for anycasting (and more specifically special address allocations for anycast name servers) can be discounted if ENDS0 was more widely used. This is a flawed argument IMO. As Peter has said, resolvers that aren't EDNS0-aware will still be pounding on the parent zone's name servers. [They're also much more likely to be the resolvers that are misconfigured to go to the root to reverse lookup RFC1918 addresses, don't implement negative caching and so on....] Simply adding more NS records and glue in the parent zone's delegation for a child zone is no help. For one thing, most name server implementations have a limit on the number of name servers they can handle for a delegation. Adding extra NS records is even less help when those servers have IPv6 addresses => yet bigger DNS payloads. In fact adding extra servers and/or IPv6 addresses may be worse because there's an increased likelihood of truncated responses getting sent to these non-EDNS0 resolvers, resulting in retried queries over TCP. Nasty. Aside from these DNS protocol issues, there are plenty of other good reasons for deploying anycasting for important DNS infrastructure. That's why lots of the root and TLD name server operators are doing this already. Ironically, these include the NCC's root name server. Anycasting provides increased robustness, extra redundancy, improved performance, better scalability, extra capacity/throughput, defence in depth from DDoS attacks, etc, etc. Anycasting isn't going to go away even if all the world's DNS software implemented EDNS0. Anycasting is a fact of life. And it will become more prominent in future. So if the address policy WG is reluctant to endorse special address allocations for DNS anycasting, I'd ask them to reconsider. If it helps, we could ask the DNS WG to discuss the issue and perhaps make a recommendation to the address policy WG.

2 1

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Peter Koch 15 Jun '04

15 Jun '04

Hello, {I'm copying this to the DNS wg list, since the protocol issues may probably be better discussed there. Hey, I *love* these [tags] :-(} [address allocation for anycast of DNS nameservers] Havard Eidnes <he(a)uninett.no> wrote: > > ------------ snip ------------ > > "Operators providing DNS for a zone served by a number of name servers > > such that the total response size when including the list of > > nameservers for the zone is close to the UDP packet size limit may > > Hm, it's not "the UDP packet size limit", it is "the packet size limit > for DNS over UDP without the application of EDNS.0". I may not have > followed things too closely, but it makes me sort of wonder why a push towards EDNS.0 is not being advocated instead of polluting the routing > space to compensate for people who have not yet upgraded their > software... Of course, people may still dream up configurations which Isn't then the parent of those trying to do anycast suffering from those resolvers unaware of EDNS0? In other words: what could the applicant do? -Peter

1 0

reverse delegation of a /16 doesn't work with new interface
by Marc Pauls 17 May '04

17 May '04

Hello, trying to setup a reverse delegation for a /16 (where ns.ripe.net is required) through the new mnt-domains based interface at auto-dbm(a)ripe.net doesn't seem to work. After trying several times I decided to send the delegation mail to the old auto-inaddr(a)ripe.net and it worked fine. When creating a new delegation of a /16 I always thought that the mandatory ns.ripe.net becomes a delegated nameserver itself by passing it as one of the nserver: entries in the domain template. e.g: domain: 222.111.in-addr.arpa ... nserver: ns1.customer-ns nserver: ns2.customer-ns nserver: ns.ripe.net ... That always worked with auto-inaddr(a)ripe.net but doesn't with auto-dbm(a)ripe.net. The error messages given by the database: ***Warning: (related to ns2.coustomers-ns) The nameserver ns.ripe.net was found listed for the zone at ns2.comstomers-ns (10.10.10.10), but was not one of the delegated nameservers (ns2.customers-ns, ns1.customers-ns). Only the delegated nameservers should be listed anywhere for the zone. ***Warning: (related to set) Only 2 delegated nameserver(s) ns2.customers-ns, ns1.customers-ns. There should be at least 3. ***Warning: (related to set) The RIPE NCC nameserver exactly one was not present in the list of delegated nameservers for this zone (ns.ripe.net) This is required by the RIPE NCC for this type/size of zone. Of course the NS-entries in the zones are all okay and contain ns.ripe.net of course... how I wrote... with auto-inaddr(a)ripe.net it worked. All in all that means that ns.ripe.net doesn't become authorative itself by passing it to a new /16 delegation through the new interface and so the database returns error messages. kind regards, Marc.

3 2

DNSSEC road map development meeting during RIPE
by Jaap Akkerhuis 28 Apr '04

28 Apr '04

This is a synopsis of an announcement which might be interesting for those people planning to come to the Ripe meeting. The full invitation will be published the web site: http://www.sdl.sri.com/other/dnssec/ where some more info is available. If you want to come, please register via this site (and ignore the deadline). jaap ------- An Invitation: Building a Road Map for DNSSEC Deployment Steve Crocker (steve(a)shinkuro.com) Russ Mundy (russ(a)tislabs.com) April 2004 Synopsis What has to be done to move DNSSEC from the specification to deployment? It's time to build a road map and identify any difficulties that have to be overcome. The next step is for prospective vendors, network operators and large users to get involved. We are holding a pair of one day meetings, Monday, May 3 in Amsterdam in conjunction with the RIPE meeting, and Sunday, May 23 in San Francisco in conjunction with the NANOG meeting. These meetings will be small, interactive workshops to extend the DNSSEC community and identify the hurdles. We invite interested parties to come to one or both meetings. These meetings have put together on short notice and we recognize that not everyone who is interested will be able to come. These meetings are just a first step. Notes from the meeting will be posted and other meetings will take place over the next several months. This is a community based, international effort. These meetings are being organized with the support of the U.S. Department of Homeland Security, the U.S. National Institutes of Standards and ICANN. Sponsorship will expand over the next several months. This work is open and will be reported on the net at http://www.sdl.sri.com/other/dnssec/

1 0

K-root mirror instance deployed in Athens
by Dave Knight 27 Apr '04

27 Apr '04

Dear Colleagues, The RIPE NCC is pleased to announce the deployment of a new mirror instance of the K-root Internet root name server in Athens, Greece on April 26 2004. This node has been sponsored by the Greek Research and Technology Network (GRNET) and is located at the Athens Internet Exchange. The announcement can be found at: http://www.ripe.net/ripencc/kroot-athens-20040427.html Kind regards, Dave Knight RIPE NCC

1 0