- dns-wg - mailman.ripe.net

Erroneous Domain Cleanup Messages
by Olaf Kolkman 13 Jan '04

13 Jan '04

Dear Colleagues, Apologies for duplicate mails. == Introduction We recently informed the Working Groups about the start of a cleanup of inconsistencies between data in our reverse DNS and data in the Whois Database [1]. Since Wednesday 7 January, 2004 we have been sending out warning messages. Unfortunately a number of messages were sent out in error. == The Problem Due to a bug in the script, messages have been sent to contacts for /24 DOMAIN objects that have a more specific /16 object, stating that there are no matching NS RRs in the zone files and that the DOMAIN object will be deleted. This has been done in error and these DOMAIN objects will remain unaltered. The contacts for these /24 DOMAIN objects will be sent a message shortly confirming that their objects will remain unaltered and that no further action is required on their part. == Background The Whois Database holds informational data for domains in the reverse tree. The database holds information about reverse domains corresponding to /8, /16 and /24 address space. The '/8 domain' zone files at the RIPE NCC only contain NS RRs for the delegation corresponding to the most less specific address block. If there is a /16 DOMAIN object and a number of more specific /24 DOMAIN objects in the database only a delegation will be created corresponding to the /16 DOMAIN object. In other words, if the /16 domain has been delegated one cannot delegate its children any longer. Therefore, the absence of the NS resource records corresponding to the "nserver:" attributes in the /24 DOMAIN objects is not an error. Note: for End Users it is not obvious if an NS RR is in the zone files of the RIPE NCC since ns.ripe.net is a secondary DNS server for the /16 zones. Our apologies for any confusion and extra work this may have caused. For further clarification please do not hesitate to contact <ripe-dbm(a)ripe.net>. --Olaf Kolkman New Projects RIPE NCC [1]: http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00000.html Further information about the cleanup project can be found at: http://www.ripe.net/reverse/rdns-project/cleanup.html

1 0

Domail Clean-up
by RIPE Database Manager 06 Jan '04

06 Jan '04

Dear Colleagues, As of 6 January, 2004, messages concerning inconsistencies between "nserver:" attributes in DOMAIN objects and delegation NS RRs in our zone files will be sent out. The messages will be mailed to various contact addresses for the relevant DOMAIN objects. In addition to the description of the inconsistencies, an indication of the 'default actions' will also be provided. We kindly request data be updated so that the inconsistencies are corrected before 1 March, 2004. About two weeks before 1 March, 2004 we will send a second set of warnings for the remaining inconsistencies. By 1 March, 2004 all remaining inconsistencies will be cleaned by the RIPE NCC, using the 'default actions'. If you receive a warning about inconsistencies we recommend that you fix the data yourself. It may be that you receive multiple mails for multiple domains with multiple inconsistencies. If you want to configure a dedicated mail filter the messages will contain the subject header "Subject: Reverse DNS inconsistencies in the RIPE Database" and originate "From: <ripe-dbm(a)ripe.net>". If you have further questions please contact <ripe-dbm(a)ripe.net>. Background The cleanup is part of the effort to streamline reverse DNS operations [1] and make it easier for network range users to manipulate related DOMAIN objects. The goal of the cleanup [2] is to streamline the contents of DOMAIN objects and zone configuration files so that we can create zone files from the Whois Database. An explanation of the various possible inconsistencies can be found at: http://www.ripe.net/reverse/rdns-project/Cleanup.html. ----- [1]: Original proposal http://www.ripe.net/reverse/proposal.html. Discussion on this proposal has taken place on the RIPE NCC Services WG mailing list and was summarized in: http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2003/msg00361.html [2]: Original cleanup proposal http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html. ----- Can Bican Software Engineering Department Olaf Kolkman New Projects Group RIPE NCC

1 0

RIPE-47, dn* wg aganda items wanted
by Jaap Akkerhuis 10 Dec '03

10 Dec '03

We did already have some reactions, but we are always looking for items. So if you missed our first annponcement, feel free to send in your proposals. We will have a real good Xmas when we will be able to produce a preliminary agenda when Santa comes. jaap PS. A gentleman from Spain was thinking about a report to present on dns measurements. I lost his card. My fault, but can you please contct me?

1 0

Announcement: Redirecting reverse DNS updates
by RIPE Database Manager 08 Dec '03

08 Dec '03

Dear Colleagues, From 8 December 2003, as part of the effort to streamline reverse DNS operations, domain updates that contain in-addr.arpa or ip6.arpa type entries sent to <auto-dbm(a)ripe.net> will automatically be forwarded to <auto-inaddr(a)ripe.net> for processing. This will continue until the two processes are combined into one. Such updates will be processed as follows: - If the update contains only domain objects whose "domain:" attributes end with 'in-addr.arpa', 'ip6.arpa' or 'ip6.int', it will be redirected to: <auto-inaddr(a)ripe.net> - If the update contains a mixture of domain objects whose "domain:" attributes end with 'in-addr.arpa', 'ip6.arpa', 'ip6.int' as well as other types of database objects, the message will be rejected. The user will receive an e-mail requesting that the objects be separated and re-submitted. - All other e-mails will be processed as normal. - It will not be possible to update these domain objects using syncupdates. Please don't hesitate to contact <ripe-dbm(a)ripe.net> for questions, comments or suggestions. Regards, -- Can Bican Software Engineering Department RIPE NCC

1 0

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