September 2003 - dns-wg - mailman.ripe.net

Fwd: Re: against broken tld content
by Brad Knowles 23 Sep '03

23 Sep '03

Folks, I don't know if anyone here has seen this, but Ohta-san submitted this draft to IETF DNSOP a few days ago. Should we start discussing this here? >From: Masataka Ohta <mohta(a)necom830.hpcl.titech.ac.jp> >Subject: Re: against broken tld content >To: dnsop(a)cafax.se >Date: Tue, 23 Sep 2003 02:25:10 +0859 () >Sender: owner-dnsop(a)cafax.se > >Below is a revised draft ID with the following changes. > >1) "Content" is added to title. > > Distributed Actions Against Broken TLD Content > >2) some text added to "1. Introduction". > >< the problem, this memo describes distriburted actions as a short >< term solution to protect the Internet against broken TLD zone content. >--- >> the problem, this memo describes distributed actions as a short >> term solution to protect the Internet against broken TLD zone content >> and the damage caused by it. > >3) some text added to "3. Actions of ISPs". > >> If such action considerably reduces the number of available TLD servers, >> ISPs may operate their own servers overriding the IP addresses >> of formal TLD servers. >> Such overriding servers should have >> a copy of old zone content known not to be broken. >> Or, if the fix for the zone content is obvious and easy, the >> overriding servers may act as semi transparent proxies to >> formal servers (routing tricks necessary as IP addresses of >> the proxies and the formal servers are identical) modifying only >> the broken part. >> Considering that NAT-based network providers, >> which provide limited service such as web and e-mail with semi >> transparent DNS proxies, are often called ISP, it is fine >> for ISPs to use DNS proxies, especially when it improves web >> and/or e-mail environment of their customers. However, advance negotiation >> should be made, if the override affects other ISPs. > >Any further comment? > > Masataka Ohta > >-- > > > > > > >INTERNET DRAFT M. Ohta >draft-ohta-broken-tld--1.txt Tokyo Institute of Technology > September 2003 > > Distributed Actions Against Broken TLD Content > >Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html The list of Internet-Draft > Shadow Directories can be accessed at http://www.ietf.org/shadow.html > >Abstract > > This memo describes actions against broken content of a primary > server of a TLD. Without waiting for an action of some, if any, > central authority, distributed actions TLD server operators and ISPs > can settle the issue, for a short term. > >1. Introduction > > DNS is a fully distributed database of domain names and their > associated values with loose integrity. > > However, the primary server of a zone is a single point of failure of > the zone to hold the current most copy of the zone and such a failure > at TLD can cause a lot of damage to the Internet. > > As it may take time for a central authority, if any, take care of the > problem, this memo describes distributed actions as a short term > solution to protect the Internet against broken TLD zone content and > the damage caused by it. > > The long term solution is to let the primary server operator fix the > content or to change the primary server operator, which may involve a > > > >M. Ohta Expires on March 22, 2004 [Page 1] > >INTERNET DRAFT Broken TLD June 2003 > > > central authority. > > Similar technique is applicable to root servers with broken contents. > >2. Actions of TLD Server Operators > > A TLD server operator who have found that TLD zone content is broken > should disable zone transfer and use a copy of old zone content known > not to be broken. > > Or, if the fix for the zone content is obvious and easy, the operator > may manually or automatically edit the content of the current most > one without updating SOA serial number. In this case, zone transfer > may not be disabled, though actions of ISPs described in section 3 > may make the transfer from servers of broken content impossible. > >3. Actions of ISPs > > ISPs should disable routes to TLD servers with broken content and/or > filter packets to/from the TLD servers. > > If such action considerably reduces the number of available TLD > servers, ISPs may operate their own servers overriding the IP > addresses of formal TLD servers. Such overriding servers should have > a copy of old zone content known not to be broken. Or, if the fix > for the zone content is obvious and easy, the overriding servers may > act as semi transparent proxies to formal servers (routing tricks > necessary as IP addresses of the proxies and the formal servers are > identical) modifying only the broken part. Considering that NAT- > based network providers, which provide limited service such as web > and e-mail with semi transparent DNS proxies, are often called ISP, > it is fine for ISPs to use DNS proxies, especially when it improves > web and/or e-mail environment of their customers. However, advance > negotiation should be made, if the override affects other ISPs. > > ISPs should periodically check the servers, whether they still > contain broken content or not. > >4. Security Considerations > > As for security, TLD servers should never have broken content. > >5. Author's Address > > Masataka Ohta > Graduate School of Information Science and Engineering > Tokyo Institute of Technology > 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN > > > >M. Ohta Expires on March 22, 2004 [Page 2] > >INTERNET DRAFT Broken TLD June 2003 > > > Phone: +81-3-5734-3299 > Fax: +81-3-5734-3299 > EMail: mohta(a)necom830.hpcl.titech.ac.jp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >M. Ohta Expires on March 22, 2004 [Page 3] > >#---------------------------------------------------------------------- ># To unsubscribe, send a message to <dnsop-request(a)cafax.se>. > -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

2 1

Next phase in deploying anycast instances of k.root-servers.net
by Andrei Robachevsky 22 Sep '03

22 Sep '03

Dear colleague, After discussions at the last RIPE Meeting, we would like to clarify our current thinking about adding further anycast instances to k.root-servers.net. This message sets out the direction and further details the requirements for hosting such an instance and calls for expressions of interest from the Internet community to support this activity. I look forward to your support. Best regards, Andrei Robachevsky CTO, RIPE NCC General requirements and guidelines for expressions of interest for hosting a mirror instance of k.root-servers.net ============================================================== Introduction ------------ The RIPE NCC operates k.root-servers.net, one of the servers used as a name server for the DNS root zone. In order to further improve the distribution of the service in various Internet regions and its resilience against DDoS attacks the RIPE NCC is deploying mirror instances of the server worldwide as described in the ripe document "Distributing K-Root Service by Anycast Routing of 193.0.14.129" (RIPE 268). The first phase of this project included moving the cold standby instance of the server to service using anycast routing. This phase was completed in July 2003 and k.root-servers.net is currently deployed in two locations (LINX, London and AMS-IX, Amsterdam). The next phase will be mostly focused on the deployment of nodes with limited reachability in the RIPE NCC service region. The main motivation for this phase is: - Improving access to k.root-servers.net for a significant ISP community. - Isolating impact of an "external" DDoS attack. - Localising impact of a "local" DDoS attack. This document sets the direction and further details the requirements for hosting an instance of the k.root-servers.net server so that interested organisations may understand the general intentions and requirements of this phase of the project. Organisations wishing to express their interest in supporting this important activity may do so by following the guidelines below. Physical Sites -------------- Suitable sites for the location of mirror instances of the k.root-servers.net server will in most cases include an Internet exchange (IX) that offers a very high standard of infrastructure and Internet connectivity. The members of the IX should represent a significant ISP community in the region. In terms of physical infrastructure and services, a hosting site must satisfy the general requirements for root server locations, which are described in section 3.1 of RFC2870. Server Hardware --------------- All hardware for the instance of k.root-servers.net will be supplied at the host's expense. In most cases a typical configuration will be assembled by the RIPE NCC and shipped to the hosting site. The hardware will remain the property of the host, but will be operated solely by the RIPE NCC. The host will be asked to provide onsite physical support. However there is no requirement for the host to perform maintenance on the systems themselves, and administrative access will not be available. Connectivity and reachability ----------------------------- Though global reachability is not required for the instance of the k.root-servers.net server, it is critical that access to the server is provided in an open and non-discriminative manner to all members of the IX. However, it is important that global transit is co-ordinated with the RIPE NCC. Requirements for reachability are different for the management network of k.root-servers.net that is used by the RIPE NCC to perform system administration. It is required that connectivity of the management network is global and reliable. Expressions of Interest ----------------------- The RIPE NCC invites expressions of interest from organisations such as Internet Exchanges or other organisations that represent a significant ISP community in the region. Expressions of Interest should include details of the support which is being offered, such as hosting and connectivity. Please provide as much detail as possible, including physical infrastructure details, upstream and peer network connectivity details, and bandwidth availability. Please refer specifically to the provisions of RFC2870 in your response. Please send expressions of interest to: k-anycast(a)ripe.net If any further information is required, please also use this address.

1 0

Re: dnsmon / .org
by Wilfried Woeber, UniVie/ACOnet 12 Sep '03

12 Sep '03

I fail to see an "obvious", structural relationship between a LIR and the parties responsible for the reliable operation of a ccTLD name service? Wilfried. ______________________________________________________________________ >At 11:36 AM 10-09-03 +0200, Daniel Karrenberg wrote: >>On 10.09 12:18, Hank Nussbacher wrote: >> >> > RIPE NCC should only monitor those ccTLDs that are LIRs or that their LIR >> > is willing to endorse. -Hank >> >>I like the principle. However .... >> >>How would this endoresement be determined? > >Each LIR would be entitled to one ccTLD to be monitored. Most won't need >it. Assuming there are about 50 countries in the RIPE area, and about 3500 >LIRs, I am sure that one can find a LIR to support a ccTLD to be >monitored. That means that the other countries in ARIN/APNIC/LACLIC would >have to fund their own service. > >-Hank >LIR: il.iucc

1 0

dnsmon / .org
by Joerg Schumacher 11 Sep '03

11 Sep '03

Hi! Thanks for providing dnsmon. I think it's a useful service. Back on 18.07.2003 our own monitoring showed some trouble reaching dns.denic.de. Could be us, could be them. dsnmon gave the answer: it's not only us having the problem, so it's them. ops(a)denic.de confimed that the IOS upgrade on their DECIX routers caused the trouble. Mind adding the nameservers for .ORG to the monitoring? I'd be interested in the effects of the recent change in the root zone. Having only two nameservers for a tld and both of them in a single AS makes me kind of nervous. Regards, Joerg PS: http://www.pir.org/news/press_releases/pr_articles/2003-09-08-01 "[...] announced the implementation of a change that enables .ORG names to resolve through web browsers worldwide within 5 minutes [..] This change will enhance the speed of registration/modification-to-resolution of .ORG names to less than 5 minutes, from the previous average of 12-24 hours. [...]" makes me wonder if they'll also change the ttl of all NS record in the org-zone to 5 minutes somewhere in the near future. Ouch! -- Gaertner Datensysteme 38114 Braunschweig Joerg Schumacher Hamburger Str. 273a Tel: 0531-2335555 Fax: 0531-2335556

14 27

Re: [dns-wg] Re: dnsmon / .org
by Marcel Schneider 10 Sep '03

10 Sep '03

On Wednesday, 10 Sep 2003, Daniel Karrenberg writes: Daniel > While we so far have only monitored TLDs with whome we have some contact, > we can certainly also monitor any TLD if there is an expressed interest > from the RIPE community. Thechnically this is no problem at all. > Configuring it takes all of 5 minutes and even the alpha version > of the analysis web site on the development server box can easily take > the load. Here the views of a (small) ccTLD (CH): 1. Monitoring TLD name servers from different points on earth in a, let's say 'standardized' way, and publish such data is welcome. The points to clarify here are: standardized and 'such', the later designating a subset of all possible measurements or everything. The standardization aspect is is IMO more interesting: we need an RFC for these measurements. 2. Since this kind of monitoring can be bought from e.g. UltraDNS, it may be wise not enter in any competition, meaning it should have a price tag. 3. If it has aprice tag, people will want to know what to get for the money, meaning an SLA is required. An SLA is a contract with technical, organizational, legal and administrative definitions. 4. It is to be determined if RIPE NCC is the appropriate org to offer such services. Good: neutral, professional, some hard- and software already in place and can be used; bad: not really RIPE's core business, the competition with commercial firms. How about a RIPE-spin-off, Netlabs, etc. ? Summary: desirable service, still much to be defined. Marcel

1 0

New DNS server
by Abdelhamid Osman 10 Sep '03

10 Sep '03

Dear Ripe, We are here in Internet Egypt a LIR to RIPE NCC reg ID : eg.ie . We currently have two DNS servers : brainy1.ie-eg.com and brainy2.ie-eg.com We want to add a new DNS server brainy4.ie-eg.com We want to know if there is any thing that we should do with ripe in order to have this new DNS server registered and be able to add domain names to it ? Please advise us with the necessary procedures that should be taken. Best Regards, Abdelhamid Osman Network Manager Internet Egypt

4 4

RE: [ncc-services-wg] Re: dnsmon / .org
by Mike Norris 10 Sep '03

10 Sep '03

> I have had a number of questions like Joerg's already for all gTLDs > besides .MIL. I see little chance that we can get them all to agree to > pay a share of the cost. I also see that the overhead of making > agreements with some of the organisations involoved can be prohibitive. > If there is interest from the RIPE community it is easy to monitor these > domains. However it is very difficult to do it for some for free and > ask the others to pay. So doing that may lead to a situation where the > RIPE NCC membership ends up paying the whole bill. I would actually > like that because it makes the measurements even more independent > and I would not have to invest time into making agreements with the TLD admins, > billing, etc. pp. I agree; if people want accuracy and integrity, the measurements have to be taken independently. Mike Norris

1 0

Presentations at DNS meeting
by Patrik Fältström 09 Sep '03

09 Sep '03

An update: You can see yourself on http://rosie.ripe.net/ripe/meetings/ripe-46/presentations/ whether your presentations has been taken care of. If they are missing there, please resend. paf

3 4

v6 ns/glue naming bcp
by Jakob Schlyter 08 Sep '03

08 Sep '03

is there any operational considerations before putting both A and AAAA records on a name used glue? or, should one use separate names for v4 and v6 transport? e.g.: example.com. NS ns1.example.com. NS ns2.example.com. ns1.example.com. A 192.0.2.1 AAAA dead:beef::1 ns2.example.com. A 192.0.2.2 AAAA dead:beef::2 vs example.com. NS ns1.example.com. NS ns1.ipv6.example.com. NS ns2.example.com. NS ns2.ipv6.example.com. ns1.example.com. A 192.0.2.1 ns1.ipv6.example.com. AAAA dead:beef::1 ns2.example.com. A 192.0.2.2 ns2.ipv6.example.com. AAAA dead:beef::2 yours, jakob

8 14

re: IDN
by EUser＠t-online.de 05 Sep '03

05 Sep '03

Moin >>>Internationalized Domain Names are represented by local >>>language characters, available in more than 350 languages, from >>>Korean to Greek, Russian to Chinese "VeriSign" >>The domain names are sent with funny names (IDN) this may >>cause confusion in big companies for examples >>"Rob Blokzijl" >http://www.oojjoo.com/nn/eisvogel.htm is this a multilingual IDN or a definition thing ? (seems to be a Percentage for commissions, discounts, rebates . .) mfg Bernd c/o EUser(a)t-online.de

2 1