- dns-wg - mailman.ripe.net

Domain cleanup proposal
by RIPE Database Manager 04 Dec '03

04 Dec '03

[apologies for duplicate messages] Dear Colleagues, Please be aware that a Domain Clean-up Proposal has been sent to the Database WG mailing list: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html To comment on the proposal and to follow the discussion please use the Database WG mailing list. Regards, -- Can Bican Software Engineering Department RIPE NCC

1 0

Re: [SPAM] Re: [dns-wg] rMX and rDNS together make spamming more difficult ?
by use.signature.ripe＠awot.fi 28 Nov '03

28 Nov '03

Jaap Akkerhuis wrote: > I m waiting feedback, have I missed something ? > > Probably. The dns-wg is about dns, not about anti-spam. Maybe you > should take your ideas to the antispam group first. > I think that is very limited thinking. If we all only think that I only care my sandbox then we have this kind of problem. It was one of RIPE s person said after I was published this idea in a antispamlist that maybe also open discuss on dns-wg list ... Maybe he saw that this kind of co-operate is needed to build more rules to take care of that our nets works in future. I hate rules. But we need rules, because Internet is not any more that nice environment what it was ex. on 90 s. Some people think that net is free place todo and TRY everything. Somebody must take care build more rules that those who like to use net like it has planned, build something to take care it. Why dns-wg ? Because if we (operator, ISP,...) like to build better working net, we need dns help also in this kind of solution. And my ideas (and MTAmark) need in-addr.arpa domains updating. That the reason why I published my idea also in this forum. And only (except J rgen) feedback what I have got is something like is this correct forum, why you don t use your real email, or why write my email some stupid format on ... but I have not yet got any real feedback where has analyze base idea. Is that possible that it give some more than current methods ? So most feedbacks has been personal, no need to send maillist and cause noice. If some mail not belongs some maillist, simpliest way is say nothing. Then it s only one line ... My idea give posibilities to limit acceptable mta s, not stop. But if somebody server like to make selection to accept connection only from in in-addr-arpa. domain registered mta s, then it can do it. Selection is server priviledge. And if youlike to send mail to that server, you must use registered mta. So it is one more tool to smtp rule stack. Or are you saying that everything is okay, we have no risk that something crash ? Ex. if Finlands biggest operator route smtp packet even 5 weeks, our network is okay ? This is true in year 2003. -jukka-

2 1

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

27 Nov '03

My idea is check senders (MTA s) ip and priviledges to use smtp, not using protocol headers or other content filtering method. My idea is control connection (ip) using reverse dns lookup database, not dns lookup. My proposal include also method to handle roaming mta. Mail sending is done from ip, not from domain. Reverse dns is mostly controlled by operators and "big companies", so we have less players as in domain structure and I believe that it is easier to make "operator blacklist" as domains. This idea is simple (too simple to be true ? That I m asking) to add every access control level : firewall, proxies, filters, wrappers, smtp servers, ... Proposal rMX using rDNS: http://www.awot.fi/sf/browser/showfile?cust=awkoulutus&subdir=dns&doc=rever… I m waiting feedback, have I missed something ? -jukka- Jukka do.t Inkeri at Awot do.t Fi

4 3

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