- ncc-services-wg - mailman.ripe.net

Reverse DNS Restructuring Project
by Olaf M. Kolkman 04 Nov '03

04 Nov '03

Dear Colleagues, Below you find a proposal for restructuring of parts of the reverse DNS services. The proposal can also be found on http://www.ripe.net/reverse/proposal.html We would appreciate your feedback on this (ncc-services-wg) list. -- Olaf Kolkman Reverse DNS Restructuring Project. Proposal: Restructuring of the reverse DNS setup. The Reverse DNS Restructuring Project involves a number of changes: - Modification of internal databases so that the RIPE Whois Database becomes the authoritative source for zone file generation. - Change of interface for the creation and maintenance of delegation of reverse domains. <auto-inaddr(a)ripe.net> will be deprecated while the Whois Database interfaces will be available for reverse database management. - The introduction of a new attribute, "mnt-domains:", in INETNUM and INET6NUM objects to be able to delegate the authority to create new domain objects. - The introduction of 'name' syntax checks for the ip6.arpa and in-addr.arpa domains, only allowing DOMAIN for names that make sense in the address hierarchy i.e. those that represent "reversed" addresses. - A cleanup of inconsistent data so that the who is Database reflects the data that is in the reverse zones. - Once address space has been allocated the reverse delegations can be made. There is no longer the requirement that address space has to be assigned before a reverse delegation is made. - The introduction of an attribute in the domain object used for storing public DNSSec keys. Background and Motivation: There are a number of issues that give rise to these changes. - LIRs must currently use a separate interface for the maintenance of their domain objects. Having a single entry point for the maintenance of all objects in the Whois Database is more efficient for LIRs and the RIPE NCC. - Deployment of DNSSec requires a method for the exchange of public keys. Using the Whois Database as the authoritative source for zone file creation enables the use of the Whois Database authorization mechanisms including the LIR Portal, PGP keys and X.509 certificates, for DNSSec public key exchanges. - Reverse zones are currently maintained though an e-mail robot, <auto-inaddr(a)ripe.net>, also referred to as 'Marvin'. When DOMAIN objects are submitted Marvin performs a number of DNS checks, updates the Whois database with the submitted object and then updates the zone files. Once a DOMAIN object exists in the Whois database it can be modified using the database interfaces. However changes to it will not end up in the zone file. This allows for the data in the Whois database being inconsistent with the data in the DNS. This leads to confusion and lameness problems in the DNS. - The motivation for introducing the "mnt-domains:" attribute is because the maintenance of the DNS is often done by a different set of people to those that maintain INETNUM objects. With the introduction of this new maintainer attribute and no longer having the restriction that address space is to be assigned before delegations are made, the setup of reverse space is easier and operational delays can be avoided. - The motivation for the 'name syntax check' is because there are currently DOMAIN objects that clearly cannot exist in the address hierarchy (e.g. 666.193.in-addr.arpa). - The Whois Database has several methods to interface with it, moving towards a system where the Whois Database is the authoritative source for reverse delegation information eases the development of web-based tools for zone maintenance. Besides, having uniform interfaces for all RIPE NCC services has benefits for the RIPE NCC and its customers. Details: - Introduction of the MNT-DOMAINS attribute for INETNUM/INET6NUM (INET[6]NUM for short) objects. An INET[6]NUM object can contain multiple instances of the "mnt-domains:" attribute. It is used for authorizing the creation of DOMAIN objects for the reverse DNS namespace to which the INET[6]NUM relates i.e. the smallest less specific range. It protects the creation of DOMAIN objects and allows for fine grained control of who requests a delegation. Once the DOMAIN object is created it is protected through the use of the "mnt-by" attribute. If there is no "mnt-domains:" attribute on a INET[6]NUM the authentication for the creation of a DOMAIN object is passed by the "mnt-lower:" attribute, when this is not available the "mnt-by:" attribute is used. This is a mechanism also used in RPSL and RPSS. - Reverse delegation interface The <auto-inaddr(a)ripe.net> e-mail interface will be deprecated. Reverse delegations can be maintained by submitting DOMAIN objects to the database. This allows for the use of existing database update interfaces in addition to the e-mail interface (<auto-dbm(a)ripe.net>). The RIPE NCC will create DNS zone files for the reverse space from the information in the DOMAIN objects. During the creation of the zone files a filter is applied to ensure that: - Reverse zone delegations are only created for address space allocated by the RIPE NCC (this takes into account ERX space). - Once a delegation at a /16 boundary is made the more specific /24 domain objects are ignored. - Delegations are only allowed on /16 and /24 boundaries (note that it remains possible to submit an object of the form 0-9.xxx.yyy.in-addr.arpa that will be expanded in 10 separate DOMAIN objects). RFC 2317 type 'delegations' for PI space smaller than /24 not allocated by a LIR cannot be handled via this interface but will need to be requested via <inaddr(a)ripe.net>. - Introduction of an attribute for storing DNSSec public key information in DOMAIN objects. When DNSSec is deployed not only the name servers that are authoritative for running a zone need to be registered but also the public key with which those reverse zones are signed. A mechanism is needed to authenticate the exchange of public keys. To avoid the deployment of DNSSec being prohibitively expensive the key exchange should be similar to the procedure used to exchange the information about the authoritative name servers. The authentication methods used during the key exchange should be at least as strong as the authentication methods used for making the actual delegation. Using the Whois Database, in combination with the "mnt-domains:" attribute, the users of address blocks have control over the authentication methods. We expect improved consistency and lower maintenance costs when, during the zone file generation, a single source of data for both DNSSec public keys and name server RRs can be used. - Database consistency and cleanup Currently there is a set of zone files that is the authoritative source for the reverse tree. In addition there are DOMAIN objects in the database. Appendix 1 shows the number and nature of the inconsistencies. The cleanup should not cause existing delegations to change i.e. the zone data has prevalence over Whois database information in case of inconsistencies. A somewhat more detailed cleanup plan will be presented to the DB-WG mailing list. Tentative milestones - A more detailed proposal for the "mnt-domains:" attribute and the cleanup. (October 2003) - Documentation and procedures. (October-November 2003) - Introduction of "mnt_domains:" and reverse delegation processing for <auto-dmb(a)ripe.net> while still allowing the use of <auto-inaddr(a)ripe.net> with the current authorization methods. (December 2003). - As soon as <auto-dbm(a)ripe.net> can handle reverse delegation requests, and the back-end systems have been modified not to introduce new inconsistencies the RIPE NCC will be sending out warnings about inconsistent data (as part of the cleanup process). There will be a 2 months interval to allow users to fix inconsistencies. - Deprecation of the <auto-inaddr(a)ripe.net> interface, allowing only updates via <auto-dbm(a)ripe.net>. (Around February 2004, Details to be worked out). - Around February 2004 (shortly after the previous step) the inconsistent data will be cleaned up. $Id: RDNS-Proposal.txt,v 1.8 2003/09/30 07:21:45 olaf Exp olaf $

10 20

RIPE NCC Dubai Meeting, Dec. 2003 - Updated Agenda
by Membership Liason Officer 29 Oct '03

29 Oct '03

[Apologies for duplicate mails] Dear Colleagues, The RIPE NCC Regional Meeting, Middle East, will be held 7 - 9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. The meeting will focus on Internet Resource management issues. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. UPDATED AGENDA The agenda has been updated with more information about speakers and presentations. The preliminary list of speakers includes: - Rob Blokzijl (RIPE Chair) - Tim Mertens (CENTR) - Keith Mitchell (XchangePoint) - Axel Pawlik (RIPE NCC) - Phillip Smith (Cisco Systems) The Director General of APNIC, Paul Wilson, will also give a presentation on IPv4 address lifetime expectancy. For the full agenda, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/plan.html The RIPE NCC has reserved several presentation opportunities for those with local knowledge of Internet management and operational issues affecting the Middle East. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: <contact(a)ripe.net>. ATTENDEE LIST The attendee list is regularly updated with new registrations and is now available online at: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/attendees.html HOTEL RESERVATIONS: The RIPE NCC has arranged for a block of rooms to be held for meeting attendees at the Metropolitan Palace Hotel and the Metropolitan Hotel Sheikh Zayed Road, Dubai. There are a limited number of rooms available, so we strongly suggest you book early to avoid disappointment. For more information about these hotels, and to reserve a room, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/hotel-information.… REGISTRATION To register for the RIPE NCC Regional Meeting, Middle East, please see: http://www.ripe.net/cgi-bin/dubai-reg Any further questions about the RIPE NCC Regional Meeting, Middle East, can be sent directly to: <contact(a)ripe.net>. Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC

1 0

Spammers using RIPE DB again ?
by Peter Galbavy 23 Oct '03

23 Oct '03

I got a couple of these today, to hostmaster(a)knowledge.com and hostmaster(a)knowtion.net. The only place I *think* these are commonly used are my RIPE DB records. Anyone else got spam like this that may be traced back to abuse of the RIPE DB ? If not there, other places I should look to alerting ? -- Peter Return-path: <help(a)internetdrive.com> Envelope-to: hostmaster(a)knowledge.com Delivery-date: Thu, 23 Oct 2003 14:07:41 +0100 Received: from exim by mailstore-1.mail.knowledge.com with spam-scanned (Exim 3.36 #1) id 1ACfBQ-0008T1-00 for hostmaster(a)knowledge.com; Thu, 23 Oct 2003 14:07:41 +0100 Received: from [195.174.147.143] (helo=abn147-143.interaktif.net.tr) by mailstore-1.mail.knowledge.com with smtp (Exim 3.36 #1) id 1ACfBN-0001q8-00 for hostmaster(a)knowledge.com; Thu, 23 Oct 2003 14:07:19 +0100 Received: from [19.129.99.202] by abn147-143.interaktif.net.tr; Thu, 23 Oct 2003 10:59:18 -0300 Message-ID: <2$08-38qd-wa78w84$ten53l@488ap9c> From: "Dot EU" <help(a)internetdrive.com> Reply-To: "Dot EU" <help(a)internetdrive.com> To: hostmaster(a)knowledge.com Subject: Domain Newsletter - Oct 22 Date: Thu, 23 Oct 03 10:59:18 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6BCB1CE1A456E.4372E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Status: No, hits=2.3 required=5.0 tests=FORGED_MUA_OUTLOOK,MISSING_MIMEOLE version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) --6BCB1CE1A456E.4372E Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable -------------- Domain Name News October 21st 2003 -------------- The European Union has approved the launch of .eu domain names, which are expected to go live in late 2003 or early 2004. We are now accepting orders for the new .eu domains. http://www.registereu.com See our web site for contact information. Do not reply to this email - the address is not monitored. --6BCB1CE1A456E.4372E--

4 4

RIPE NCC Dubai Meeting, Dec. 2003 - Reminder: Hotel Reservations
by Membership Liason Officer 20 Oct '03

20 Oct '03

Dear Colleagues, The RIPE NCC Regional Meeting, Middle East, will be held 7 - 9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. The meeting will focus on Internet Resource management issues specific to the Middle East. HOTEL RESERVATIONS: The RIPE NCC has arranged for a block of rooms to be held for meeting attendees at the Metropolitan Palace Hotel and the Metropolitan Hotel Sheikh Zayed Road, Dubai. There are a limited number of rooms available, so we strongly suggest you book early to avoid disappointment. For more information about these hotels, and to reserve a room, please see: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/hotel-information.… In addition to your hotel accommodation please remember to register for the RIPE NCC Regional Meeting, Middle East, at: http://www.ripe.net/cgi-bin/dubai-reg Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. Any further questions about the RIPE NCC Regional Meeting, Middle East, can be sent directly to: <contact(a)ripe.net>. Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC

1 0

Fwd: RE: [ncc-services-wg] Billing scheme
by Jochem de Ruig 15 Oct '03

15 Oct '03

Dear all, For all financial issues you can contact billing(a)ripe.net Please notify us before 1 November 2003 regarding any billing issue for 2004 for instance your billing score, your billing scheme and your billing category as all 2004 invoices will be generated in the beginning of November Best regards, Jochem de Ruig RIPE NCC > >At 12:07 PM 10/14/2003 +0400, you wrote: > > >Hi There! > > >We are ru.combellga > > >Now I try to update our billing scheme from HALF-YEARLY to QUARTERLY. > > > >But I cann't find where can I do it... In our LIR Portal I find this > > >option but it's not allowed to change! Pleace help with any advices > > > > > >-- > > >Best Regards > > >Dmitry N. Dmitrienko > > >Combellga Internet Team (CIT)

1 0

Billing scheme
by postmaster 14 Oct '03

14 Oct '03

Hi There! We are ru.combellga Now I try to update our billing scheme from HALF-YEARLY to QUARTERLY. But I cann't find where can I do it... In our LIR Portal I find this option but it's not allowed to change! Pleace help with any advices -- Best Regards Dmitry N. Dmitrienko Combellga Internet Team (CIT)

1 0

Re: [ncc-services-wg] Reverse DNS Restructuring Project
by Bruce Campbell 08 Oct '03

08 Oct '03

On Wed, 8 Oct 2003, Olaf M. Kolkman wrote: > I agree "Clarity good, Confusion bad". I have not yet had the change > to study all implications of getting rid of the "rev-srv:". But we'll > look at this and get back on this issue; probably in the clean-up proposal > that is to follow or in a separate proposal. In the context of the above I have some additional data that we have extracted from the database. As the wider audience may be aware, the 'rev-srv' attribute in the inetnum (and inet6num) objects is the rather early predecessor of using the 'domain' object and its 'nserver' attributes to represent a reverse delegation. The 'rev-srv' attribute, while it has never been depreciated and is not used as a source for authoritative DNS data, is still able to be used as an informational attribute. For purposes of this discussion, I've compared the contents of the inetnum 'rev-srv' attribute with the domain 'nserver' attribute. For the comparison I also introduce the concept of 'derived delegation'. A 'derived delegation' is essentially working out which 'in-addr.arpa' delegation would best match the inetnum. Effectively, a /15 inetnum becomes two /16-level 'derived delegations', and a /17 inetnum becomes 128 /24-level 'derived delegations'. First the data for reverse delegation information in inetnum objects. Total number of inetnum objects: 879691 Total number of inetnum objects with rev-srv: 54921 (6%) Total number of derived delegations: 27804 (3%) The fact that the number of derived delegations is smaller than the number of objects with rev-srv attributes is accounted for by inetnums which either cover very large ranges (/8 and greater) or smaller ranges (/25 and lesser) which we do not delegate directly. Secondly, the data for reverse delegation information in domain objects. Total number of domain objects: 113153 Total number of valid reverse domain objects: 105785 A valid reverse domain object is one that makes sense within the DNS; it has a set of nservers, and refers to a possible delegation (ie, its within in-addr.arpa and has numbers between 0 and 255). Comparing the two sets of delegation information. Total number of domain objects that do NOT match any derived delegation: 95051 Total number of derived delegations that do NOT match any domain object: 16523 Total number of matches between derived delegations and domain object: 18011 The number of domain objects is larger as the NCC has been using them to represent authoritative reverse delegations during the recent (6 years?) growth period of the internet. The number of derived delegations without a matching domain object is non-zero for two reasons; The statistics script has calculated the 'best' delegation possible, and hasn't taken into account the possibility of a /16 inetnum being delegated to 255 /24-level domain objects (etc), or there are old inetnums which had their corresponding delegations created before the current system of using domain objects. We now compare the 18,011 domain objects that have a matching derived delegation, and cross checking the NS sets (as are intended to be published in the DNS) of each. Total number of mismatches in NS sets: 10734 Total number of exact matches in NS sets: 7277 In summary; - rev-srv attributes are used infrequently at the moment, and the information within them has a low accuracy. - There would be a large cleanup of inetnum objects required to ensure that the rev-srv attributes matched the delegations in the domain objects, and thus be usable for the creation of authoritative DNS delegations. - In the current proposal effort is needed to make sure that "legacy" reverse delegations that do exist in the DNS, have a corresponding rev-srv attribute, but do not have a DOMAIN object in the database, get fixed. -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security

1 0

RIPE NCC Regional Meeting, Middle
by Membership Liason Officer 08 Oct '03

08 Oct '03

East, Dubai, 7-9 December 2003 Message-Id: <20031008155822.0e2b8155.contact(a)ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear Colleagues, The RIPE NCC is pleased to announce the RIPE NCC Regional Meeting, Middle East, to be held 7-9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. Registration for the Regional Meeting opens 8 October 2003. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. To register, please see: http://www.ripe.net/cgi-bin/dubai-reg The RIPE NCC Regional Meeting will focus on Internet resource allocation and Internet management issues including: - How to participate in and influence IP address management policy-making; - The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; - Are we running out of IPv4 address space? - Root name server operations: who is involved? - Domain Name management on the Internet; - The internationalisation of Domain Names. The Regional Meeting draft agenda can be found at: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/plan.html RIPE and the RIPE NCC will explain their roles in the administration of the Internet infrastructure as well as specific aspects in managing and operating the Internet infrastructure. The discussions will be directly related to the particular needs and concerns surrounding these issues in the Middle East region. The current meeting agenda reflects our intentions. However, it requires active participation from the local community to discuss specific issues of the region. The RIPE NCC has reserved several presentation opportunities for those with local knowledge of Internet management and operational issues affecting the Middle East. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: <contact(a)ripe.net> The RIPE NCC is one of four Regional Internet Registries (RIRs) that provide Internet resource allocation, registration services and co-ordination activities that support the operation of the Internet globally. The RIPE NCC is an independent, not-for-profit membership organisation that provides services to members in its service region currently covering Europe, the Middle East, Central Asia and African countries located north of the equator. Any further questions about the RIPE NCC Regional Meeting, Middle East can be sent directly to: <contact(a)ripe.net>. Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC

1 0

Re: [ncc-services-wg] ripe rejecting "valid" e-mail
by Wilfried Woeber, UniVie/ACOnet 08 Oct '03

08 Oct '03

> ... This goes back to my old example of "You must be >registered with your local Chamber of Commerce and send us a copy of the >certificate to join RIPE" arguement. This was changed - but only after many >years. Could you give us an example and/or timeframe for that? I am curious when/how/why an "organisation" (RIPE) - which doesn't have the concept of membership - would request any certificate. Puzzled... Regards, _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Never attribute to malice what can adequately be explained by incompetence.

2 2

ripe rejecting "valid" e-mail
by Peter Galbavy 08 Oct '03

08 Oct '03

I replied, in all innocence, to the recent e-mail from NCC about the change to allocation objects - commenting on how an LIR like me cannot actually update the object themselves. Don't point me to the LIR portal - without a working fax number I cannot get an account. Been there, done that. Anyhow, I get back: -- quote -- The RIPE-NCC hostmaster distribution robot has extracted the following additional information from it: RegID: No valid RegId found Ticket Number: NCC#2003101214 We will NOT handle this message. It is of type NOREGIDBOUNCE. It concerns an ongoing request. -- ... -- Er, when you have a valid ticket number *why the hell* do you need a regID as well ??? Some people really have too much spare time and write too much code that doesn't consider the real world. Anyone else object to the over-babying of inbound mail to the NCC ? The prices stay high, the work they are willing to do goes down. As usual. Peter

7 10