- dns-wg - mailman.ripe.net

Agenda for RIPE47
by Jim Reid 27 Nov '03

27 Nov '03

You are all invited to suggest agenda items and presentations for the WG Agenda at the next meeting. Please let your chairs know what you'd like discussed at RIPE47.

1 0

rMX and rDNS together make spamming more difficult ?
by use.signature.ripe＠awot.fi 27 Nov '03

27 Nov '03

27 Nov 2003 I got mail, which include hint to look MTAmark. So look also MTAmark draft http://www.space.net/~maex/draft-irtf-asrg-mtamark-00.txt -jukka- Jukka do.t Inkeri at Awot do.t Fi

1 0

"adding IPv6 glue to root zone" document
by Ronald van der Pol 17 Nov '03

17 Nov '03

At RIPE 46 we presented measurements about the effects of adding IPv6 glue to the root zone. As promised, we made more measurements and have written a document: http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf rvdp

3 6

SUCCESS: re:.@.......z...^..
by ripe-dbm＠ripe.net 27 Oct '03

27 Oct '03

> From: "dns-wg" <dns-wg(a)ripe.net> > Subject: re:.@.......z...^.. > Date: Mon, 27 Oct 03 07:44:52 .x._........ > Reply-To: dns-wg(a)ripe.net > Message-ID: <20031027071211.832234EFC8(a)postman.ripe.net> SUMMARY OF UPDATE: Number of objects found: 0 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 0 Create: 0 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: re:.@.......z...^.. ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE TEST Database Administration <ripe-dbm(a)ripe.net>

1 0

SUCCESS: re:.@.......z...^..
by ripe-dbm＠ripe.net 27 Oct '03

27 Oct '03

> From: "dns-wg" <dns-wg(a)ripe.net> > Subject: re:.@.......z...^.. > Date: Mon, 27 Oct 03 07:44:52 .x._........ > Reply-To: dns-wg(a)ripe.net > Message-ID: <20031027071211.832234EFC8(a)postman.ripe.net> SUMMARY OF UPDATE: Number of objects found: 0 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 0 Create: 0 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: re:.@.......z...^.. ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net>

1 0

[kc@caida.org: requesting hard data sources on ramifications of verisign wildcard] (fwd)
by Henk Uijterwaal (RIPE-NCC) 20 Oct '03

20 Oct '03

FYI and apologies for duplicate mails. ----- Forwarded message from k claffy <kc(a)caida.org> ----- Date: Thu, 16 Oct 2003 12:26:15 -0700 From: k claffy <kc(a)caida.org> Subject: requesting hard data sources on ramifications of verisign wildcard To: nanog(a)nanog.org as already mentioned, fascinating public policy theatre is going on in DC on the verisign wildcard issue, see http://secsac.icann.org/ [all video and even transcripts of both meetings online. go icann.] you are encouraged to read through all of it before making public comments on this issue at nanog. (or, hope springs eternal, to this list.) caida has the following request on behalf of icann's secsac committee [an exceptionally competent group who is approaching this issue with impressive speed, equaniminity, and integrity. http://www.icann.org/committees/security/ i believe we're in good hands here. let's give the process a chance and constructively contribute where we can.] a common theme over the last week is an admitted lack of hard data [rather than lists of theoretical breakages, and anecdotal evidence, and predictions] from the operational community on actual loss of stability in Internet performance or functionality. david from XO gave an outstanding talk on 7 oct, http://www.icann.org/presentations/shairer-secsac-dc-07oct03.ppt but, as with many other providers, he deployed the bind patch within 24 hours so he didn't really have useful hard data to put on the table. i get similar comments from others. ben from harvard also gave some hard alexa data, fwiw http://www.icann.org/presentations/edelman-secsac-dc-15oct03.ppt but from a specific vantage point. we need more of these. icann's secsac committee is in a much stronger position to provide technically sound and equitable guidance if we can provide them with as specific, concrete examples (*hard data*) that indicate extent of various types of breakage. please save the arguments regarding the legitimacy and short notice of this request until you've read the hours of discussion about it that has already occurred among many qualified folks in DC (and in any case the meta-issue still stretches AUP of nanog list). the inconvenient reality is that the secsac committee needs concrete data (imagine), in addition to bulleted lists of things that break, for the policy process to work most effectively here. and nanog is in a position to make a difference. you are hereby encouraged to do so. please send any hard data reflecting observed ramifications on security and stability of Internet infrastructure to secsac-comment(a)icann.org no hard data will be refused service k ----- End forwarded message -----

1 0

Upcoming change of source AS for i.root-servers.net
by Johan Ihren 19 Oct '03

19 Oct '03

Friends, As part of the long term ambition to provide the Internet root nameservers with extremely stable homes in all possible respects we plan to change the source autonomous system for i.root-servers.net from AS8674 (NETNOD INTERNET EXCHANGE) to AS29216 (dedicated as I.ROOT-SERVERS.NET). We hope that after this change i.root-servers.net will never have to change source AS again. We intend to implement this change next week during the NANOG29 conference. Please note: a) This is a planned operation, not an emergency. b) We will not change the IP adress of the i.root-servers.net service, only the source AS. c) We will not change any of the several servers providing the i.root-servers.net service in any way. It will be the same servers at the same locations providing exactly the same service as usual. Regards, Johan Ihrén Autonomica

1 0

DNS RMX records - e-mail sender authorization
by Hadmut Danisch 17 Oct '03

17 Oct '03

Hi, I don't know whether this was discussed on this mailing list before. I just subscribed and would like to hear your opinion about http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt which describes the RMX records, a method to store authorization records about who is authorized to send e-mails with sender addresses of the zone. It is intended to protect against spam, worms, and such rubbish. regards Hadmut

7 14

Reverse DNS Restructuring Project
by Olaf M. Kolkman 01 Oct '03

01 Oct '03

Dear Colleagues, I have just posted a proposal about the restructuring of the reverse DNS setup to the ncc-services-wg mailing list. I'd like to point out that this proposal has relevance to both the dns-wg and db-wg. You can find the proposal on http://www.ripe.net/reverse/proposal.html Please provide your feedback on the ncc-services-wg mailing list. With excuses for the cross-post, -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC

1 0

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