From olaf at ripe.net Wed Oct 1 17:39:28 2003 From: olaf at ripe.net (Olaf M. Kolkman) Date: Wed, 1 Oct 2003 17:39:28 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project Message-ID: <20031001173928.27e20e52.olaf@ripe.net> 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. 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, , 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 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 (). 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 . - 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 while still allowing the use of with the current authorization methods. (December 2003). - As soon as 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 interface, allowing only updates via . (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 $ From hank at att.net.il Wed Oct 1 19:35:32 2003 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 1 Oct 2003 20:35:32 +0300 (IDT) Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031001173928.27e20e52.olaf@ripe.net> Message-ID: On Wed, 1 Oct 2003, Olaf M. Kolkman wrote: > 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. Where is Appendix 1? > > 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. Shouldn't this proposal: http://www.ripe.net/reverse/proposal.html be linked into the reverse page at: http://www.ripe.net/reverse/ -Hank From dr at cluenet.de Thu Oct 2 14:08:34 2003 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 2 Oct 2003 14:08:34 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031001173928.27e20e52.olaf@ripe.net>; from olaf@ripe.net on Wed, Oct 01, 2003 at 05:39:28PM +0200 References: <20031001173928.27e20e52.olaf@ripe.net> Message-ID: <20031002140834.A9640@homebase.cluenet.de> On Wed, Oct 01, 2003 at 05:39:28PM +0200, Olaf M. Kolkman wrote: > Below you find a proposal for restructuring of parts of the reverse DNS > services. IMHO, a very good idea. > - Once a delegation at a /16 boundary is made the more specific > /24 domain objects are ignored. Hm. This has to consequences which I can see off-hand: - lesser delegations in the RIPE-operated zone files - higher resolution delays as more indirection is involved Is there something I'm missing? And: you're saying that this is part of a filter between the database and the actual zone file generation. Wouldn't this introduce possible inconsistencies between DNS data and database data? Best regards, Daniel From pk at TechFak.Uni-Bielefeld.DE Thu Oct 2 14:16:46 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 02 Oct 2003 14:16:46 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: Your message of "Thu, 02 Oct 2003 14:08:34 +0200." <20031002140834.A9640@homebase.cluenet.de> Message-ID: <200310021216.h92CGkq14240@grimsvotn.TechFak.Uni-Bielefeld.DE> > - lesser delegations in the RIPE-operated zone files Not really, since a delegation on a /16 boundary even now precludes any further delegation of "names" below that /16 out of the parenting /8. Ignoring the objects is just a consequence of how DNS works. -Peter From dr at cluenet.de Thu Oct 2 14:19:28 2003 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 2 Oct 2003 14:19:28 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <200310021216.h92CGkq14240@grimsvotn.TechFak.Uni-Bielefeld.DE>; from pk@TechFak.Uni-Bielefeld.DE on Thu, Oct 02, 2003 at 02:16:46PM +0200 References: <20031002140834.A9640@homebase.cluenet.de> <200310021216.h92CGkq14240@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20031002141928.A10229@homebase.cluenet.de> On Thu, Oct 02, 2003 at 02:16:46PM +0200, Peter Koch wrote: > > - lesser delegations in the RIPE-operated zone files > > Not really, since a delegation on a /16 boundary even now precludes any > further delegation of "names" below that /16 out of the parenting /8. > Ignoring the objects is just a consequence of how DNS works. You're right of course. No coffee yet. *sigh* Best regards, Daniel From daniel.karrenberg at ripe.net Thu Oct 2 14:43:07 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 2 Oct 2003 14:43:07 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031002141928.A10229@homebase.cluenet.de> References: <20031002140834.A9640@homebase.cluenet.de> <200310021216.h92CGkq14240@grimsvotn.TechFak.Uni-Bielefeld.DE> <20031002141928.A10229@homebase.cluenet.de> Message-ID: <20031002124307.GP5360@reifa-wave.karrenberg.net> On 02.10 14:19, Daniel Roesen wrote: ^^^^^^^ > > You're right of course. No coffee yet. *sigh* No coffee -> dormant clue. [sorry, could not resist] Daniel Karrenberg From ncc at ripe.net Thu Oct 2 16:08:10 2003 From: ncc at ripe.net (Nick Hyrka) Date: Thu, 02 Oct 2003 16:08:10 +0200 Subject: [ncc-services-wg] RIPE 46 Meeting Report Message-ID: <5.2.1.1.2.20031002154321.03b1bec0@mailhost.ripe.net> (Apologies for duplicate mails.) RIPE 46 Meeting Report Dear Colleagues: The RIPE 46 Meeting was held from 1 - 5 September 2003 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 307 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC and ICANN. HIGHLIGHTS ========== Highlights of RIPE 46 included the open discussion on the services of the RIPE NCC during the first session of the RIPE NCC Services Working Group; a presentation on current RIPE NCC services and plans for 2004 by Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; and an update on the changes to Test Traffic Measurement. The European Operators Forum (EOF) featured a full-day tutorial on Voice over Internet Protocol (VoIP) and ENUM that included an overview of current technologies and a focus on practical deployment aspects such as gateways, security, provisioning and use of the new ENUM standards. Geoff Huston, Telstra, gave a presentation on IPv4 Address Lifetime Expectancy. The RIPE NCC would like to thank SURFnet, BIT, FLAG Telecom and KPN EuroRings for the support they provided to the meeting. SUMMARY ======== ADDRESS POLICY ============== - Hans Petter Holen, Chair, requested community involvement to help revise ripe-152 ("Charging by Local Internet Registries") if necessary. - The RIPE NCC will resubmit the IPv4 policy document for community review. - There was a discussion on PI/PA issues and whether the distinction is still valid. - It was agreed that a more formal process was needed for the policy development process. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ap DATABASE ======== - Wilfried Woeber, Chair, will co-ordinate with the RIPE NCC to prepare a document summarising the basic assumptions about the use of the RIPE Database. - "status:" attribute values will change. Current efforts aim at consistency between the RIRs and having easy to understand values. - The organisation object proposal received positive feedback from the working group, with suggestions for other features. - The RIPE NCC will implement X.509 authentication before the next RIPE Meeting. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#db TEST TRAFFIC MEASUREMENTS (TTM) ========================= - As of 1/1/2004 changes will be made to the TTM service contract: Fees will be lowered, all data will be made public with lightweight Acceptable Use Policy (AUP). - Bandwidth measurements: tests showed that results are not conclusive enough so the TTM service will wait before delivering this new product. TTM Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#tt ANTI-SPAM ========= - Rodney Tillotson, Chair, will post a proposal to the Anti-Spam mailing list regarding methods to improve finding abuse contacts in the RIPE Database. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#anti-spam IPv6 === - The 6BONE phase-out was discussed. The next milestone will be 01/01/2004 when new allocations stop. - Discussion on the separation of the identifier and locater functions of IP addresses in regards to IPv6 multihoming. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ipv6 TECHSEC ======== - Community feedback was requested on the requirements needed to secure large scale IP infrastructure especially around CLI interface requirements. - The RIPE NCC presented a report on DNSSec status, DISI achievements since RIPE 45 and the impact of signing on zone size. - George Jones, Mitre, gave a presentation on operational security requirements including the history and current status of the requirements, related work, next steps and milestones. - Baiba Kaskina, TERENA, gave a presentation on Euro CSIRT developments that included details on the CSIRT Task Force, the countries involved, the projects and deliverables. - NLNetLab presented an update on Fonkey and PKI-related developments in IETF. TechSec Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#techsec EIX == - Support was expressed for aligning and harmonising IPv6 address space policy regarding IXPs with other RIRs and existing IPv4 policies. - Reports were presented by 11 European IXPs in Europe that showed a trend of steady growth, use of GE instead of FE and wide deployment of IPv6. - Discussion of the Inter-Provider Traffic Analyzer that uses past data and statistical calculations to detect anomalies in traffic patterns. - EIX presentations were given on the anycast deployments of the "F" and "K" root servers by ISC and the RIPE NCC. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#eix DN* === - From the merging of the former DNS Working Group and DNR Forum it was concluded that one working group is sufficient to deal with everything related to Domain Names. A new name/charter will be discussed on the mailing list. - Jaap Akkerhuis, DN* Co-Chair, will organise a "DNS Related Issues" document. - Peter Koch, DN* Co-Chair, talked about how firewall vendors could make mistakes handling DNS communication issues. DN* Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#dn RIPE NCC SERVICES ================ - Axel Pawlik noted that the RIPE NCC will present more details in next year's RIPE NCC budget. - There were comments on the current RIPE NCC services, whether they benefit the entire community and whether a 'pay per service' system could be an option. - There was discussion about the need for a more transparent evaluation of RIPE NCC activities and how they benefit the community. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ncc TUTORIALS ========= - The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-46/tutorials/ip-request/ - A full-day tutorial on VoIP and ENUM was presented during the European Operators Forum (EOF). For more information about the EOF at RIPE 46 see: http://www.ripe.net/ripe/meetings/ripe-46/eof.html RIPE MEETING WEBCASTING ======================= - The third phase of RIPE Meeting webcasting trials was held at RIPE 46. Recordings of certain sessions from RIPE 46, including the Plenary, have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/ripe-46/webcast.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== - The RIPE NCC Hostmaster Consultation Centre was open at RIPE 46, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. Later consultation hours, as introduced at RIPE 44, were continued. "MEET & GREET" =============== - The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 46. "Meet & Greet" introduces newcomers to the meetings, to key attendees of the RIPE community and to social events throughout the week. More information can be obtained by contacting the RIPE NCC's Pepa Tejedor Carnicero at . RIPE 46 REFERENCE PAGE ====================== - A complete list of RIPE 46 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-46/index.html RIPE NCC GENERAL MEETING ======================= - The RIPE NCC General Meeting 2003 was held Friday, 5 September 2003, adjacent to the RIPE 46 Meeting, at the Hotel Krasnapolsky in Amsterdam. For the highlights from the RIPE NCC General Meeting 2003, please see: http://www.ripe.net/ripencc/about/gm/gm2003/highlights.html RIPE 47 ====== - RIPE 47 will be held in Amsterdam, the Netherlands, from 26 - 30 January 2004. Information on RIPE 47 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-47/ NEW LOCAL INTERNET REGISTRIES (LlRs) - PLEASE NOTE LIRs who signed up after 1 January 2002 are entitled to two (2) free tickets to attend the next RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact . END From nick at ripe.net Thu Oct 2 16:32:14 2003 From: nick at ripe.net (Nick Hyrka) Date: Thu, 02 Oct 2003 16:32:14 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: References: <20031001173928.27e20e52.olaf@ripe.net> Message-ID: <5.2.1.1.2.20031002163142.04390508@mailhost.ripe.net> Hello Hank. At 20:35 01/10/2003 +0300, Hank Nussbacher wrote: >On Wed, 1 Oct 2003, Olaf M. Kolkman wrote: > > > 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. > >Where is Appendix 1? > > > > > 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. > >Shouldn't this proposal: >http://www.ripe.net/reverse/proposal.html >be linked into the reverse page at: >http://www.ripe.net/reverse/ Thank you for your kind suggestion. We've relocated the page with a new link as a result of your input. Regards, Nick Hyrka Communications Manager RIPE NCC >-Hank From olaf at ripe.net Thu Oct 2 16:52:04 2003 From: olaf at ripe.net (Olaf Kolkman) Date: Thu, 02 Oct 2003 16:52:04 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: Message from Nick Hyrka of "Thu, 02 Oct 2003 16:32:14 +0200." <5.2.1.1.2.20031002163142.04390508@mailhost.ripe.net> Message-ID: <200310021452.h92Eq4JO007986@birch.ripe.net> * >Where is Appendix 1? The appendix and the table were removed because I considered it was to much detail for this generic proposal and planned to publish it, after more detailed analysis, with the the forthcoming consistency/cleanup proposal. I forgot to remove the reference to it and did not catch that mistake in the final reviews. The original table, appendix 1, is included below. Apologies for the confusion. --Olaf Kolkman Appendix 1. Inconsistencies between the Zone files and Whois Database in August 2003 NET TOTAL-DNS TOTAL-DB IN-DNS-NOT-DB IN-DB-NOT-DNS NS-MISMATCH 62/8 11775 12083 341 844 296 80/8 5910 6098 98 412 158 81/8 6560 6213 31 106 71 82/8 376 281 4 4 1 188/8 2 1 1 0 1 193/8 5940 6918 1032 1072 353 194/8 7374 6780 1928 1302 477 195/8 14739 15493 1531 2354 1106 212/8 20734 22353 790 2626 1320 213/8 16281 17236 575 1498 480 217/8 6257 6631 109 741 154 TOTAL-DNS: total unique entries in the zone files TOTAL-DB: total entries in database IN-DNS-NOT-DB: missing entries in database IN-DB-NOT-DNS: missing entries in zone files NS-MISMATCH: entries with conflicting name servers Note that in the above table the difference between TOTAL-DNS and TOTAL-DB does not correlate with IN-DNS-NOT-DB, IN-DB-NOT-DNS and/or NS-MISMATCH. The reason is that DOMAIN object that contain syntax errors have not been taken into account in the calculation of IN-DNS-NOT-DB, IN-DB-NOT-DNS and NS-MISMATCH. Further analysis of the syntax errors will be performed as part of the cleanup process. From dr at cluenet.de Fri Oct 3 04:19:19 2003 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 3 Oct 2003 04:19:19 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031002124307.GP5360@reifa-wave.karrenberg.net>; from daniel.karrenberg@ripe.net on Thu, Oct 02, 2003 at 02:43:07PM +0200 References: <20031002140834.A9640@homebase.cluenet.de> <200310021216.h92CGkq14240@grimsvotn.TechFak.Uni-Bielefeld.DE> <20031002141928.A10229@homebase.cluenet.de> <20031002124307.GP5360@reifa-wave.karrenberg.net> Message-ID: <20031003041919.A20955@homebase.cluenet.de> On Thu, Oct 02, 2003 at 02:43:07PM +0200, Daniel Karrenberg wrote: > On 02.10 14:19, Daniel Roesen wrote: > ^^^^^^^ > > > > You're right of course. No coffee yet. *sigh* > > No coffee -> dormant clue. > > [sorry, could not resist] Hehe, fair 'nuff ;-> Best regards, Daniel (night owl) From bruce.campbell at ripe.net Fri Oct 3 09:54:12 2003 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Fri, 3 Oct 2003 09:54:12 +0200 (CEST) Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031002140834.A9640@homebase.cluenet.de> References: <20031001173928.27e20e52.olaf@ripe.net> <20031002140834.A9640@homebase.cluenet.de> Message-ID: On Thu, 2 Oct 2003, Daniel Roesen wrote: > On Wed, Oct 01, 2003 at 05:39:28PM +0200, Olaf M. Kolkman wrote: > > - Once a delegation at a /16 boundary is made the more specific > > /24 domain objects are ignored. > > Hm. This has to consequences which I can see off-hand: > - higher resolution delays as more indirection is involved In abstract terms, this project merely changes the authoritative data source for the DNS-based data (delegations), moving it from the current zone files, to the RIPE Database. No additional DNS indirection is involved or created by this project. ( Note that the NCC currently secondaries /16-level zones on ns.ripe.net when /16-level delegations are requested, thus cutting out one level of indirection when queries hit ns.ripe.net . No change to this behaviour is introduced by this project ) > And: you're saying that this is part of a filter between the database > and the actual zone file generation. Wouldn't this introduce possible > inconsistencies between DNS data and database data? The end goal is that the authoritative DNS data is taken from the Database, such that barring the lag time (minimal) between a Database update, and publication of the same data in DNS, there are no inconsistencies between the two data sets. Kind regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security From david at iprg.nokia.com Sat Oct 4 01:27:41 2003 From: david at iprg.nokia.com (David Kessens) Date: Fri, 3 Oct 2003 16:27:41 -0700 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031001173928.27e20e52.olaf@ripe.net>; from ext Olaf M. Kolkman on Wed, Oct 01, 2003 at 05:39:28PM +0200 References: <20031001173928.27e20e52.olaf@ripe.net> Message-ID: <20031003162741.A28768@iprg.nokia.com> Olaf, On Wed, Oct 01, 2003 at 05:39:28PM +0200, ext Olaf M. Kolkman wrote: > > - 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. Does this mean that the 'rev-srv:' attribute will be retired too ?!? This proposal also means that one has to submit for example 16 reverse delegation objects to do a reverse delegation of a single /20. I was the one who wrote the first 'reverse delegation checking tool' for the RIPE NCC a long time ago and we used the 'domain:' object approach because that was 'the way it was always done' but it still doesn't make a lot of sense to me. Would it not be more customer friendly to find a way to allow people to request for the reverse delegation of a block of IP addresses, no matter what the size of the block actually is ?!? Unfortunately, reverse delegations are (generally) done on 8 bit boundaries but I don't see much reason why we should expose this kludge to the user (and neither do ISPs who use a good configuration system for their DNS servers). Adding a couple of 'rev-srv:' attributes to one 'inetnum:' object seems so much easier to me. In fact, there is actually very little use for doing the whole thing in the RIPE database in the first place. I haver never found any use at all for looking up one of the in-addr.arpa objects in the database. Maybe we should even think about retiring the 'domain:' objects and 'rev-srv:' attributes altogether and offer a simple secure web or mail user interface for submitting reverse delegations. David K. --- From gert at space.net Sun Oct 5 16:01:14 2003 From: gert at space.net (Gert Doering) Date: Sun, 5 Oct 2003 16:01:14 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031003162741.A28768@iprg.nokia.com>; from david@iprg.nokia.com on Fri, Oct 03, 2003 at 04:27:41PM -0700 References: <20031001173928.27e20e52.olaf@ripe.net> <20031003162741.A28768@iprg.nokia.com> Message-ID: <20031005160114.L67740@Space.Net> Hi, On Fri, Oct 03, 2003 at 04:27:41PM -0700, David Kessens wrote: > In fact, there is actually very little use for doing the whole thing > in the RIPE database in the first place. I haver never found any use > at all for looking up one of the in-addr.arpa objects in the database. > Maybe we should even think about retiring the 'domain:' objects and > 'rev-srv:' attributes altogether and offer a simple secure web or mail > user interface for submitting reverse delegations. While I agree with the first half of your comments (do away with domain: and do it with the inetnum:) I disagree here. Users know how to access and modify the RIPE database - so please don't introduce yet another interface just for the reverse DNS. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56883 (56833) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From olaf at ripe.net Mon Oct 6 15:58:13 2003 From: olaf at ripe.net (Olaf M. Kolkman) Date: Mon, 6 Oct 2003 15:58:13 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031003162741.A28768@iprg.nokia.com> References: <20031001173928.27e20e52.olaf@ripe.net> <20031003162741.A28768@iprg.nokia.com> Message-ID: <20031006155813.0ad8e77c.olaf@ripe.net> David and others, I've put comments in-line. On Fri, 3 Oct 2003 16:27:41 -0700 David Kessens wrote: > > Olaf, > > On Wed, Oct 01, 2003 at 05:39:28PM +0200, ext Olaf M. Kolkman wrote: > > > > - 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. > > Does this mean that the 'rev-srv:' attribute will be retired too ?!? the "rev-srv:" attribute has been retired for the purpose of requesting reverse delegation. E.g see: http://www.ripe.net/ripencc/faq/reverse/qa2.html#14: What are those "rev-srv" lines in an inetnum object for? Previously, delegation requests could be made using either an inetnum object or a domain object. We discovered several problems with this, one being inconsistency of the two possible sources. Requests are now only accepted via domain objects, so you must register your reverse servers only in the domain object. If you're changing a reverse delegation and find rev-srv lines in the corresponding inetnum object in the RIPE DB, you must create a domain object and you should delete the rev-srv lines from the inetnum. (...) > This proposal also means that one has to submit for example 16 reverse > delegation objects to do a reverse delegation of a single /20. To request delegation ranges you can use the "y-x.z.w.in-addr.arpa" notation. This only works for "3rd" octets and there are problems when using this update method in combination with PGP (will be fixed during the migration to the WHOIS interface). Documentation on the range-update feature cannot be found on the web. It used to be part of the documentation, but fell through a crack at some point. We will be reviewing the documentation as part of the project but will fix this omission soon. In the mean time, this is the relevant piece of documentation: http://www.ripe.net/reverse/howtoreverse.html#ranged-domain The range-update is also part of the LIR training curriculum: http://www.ripe.net/training/lir/material/slides/page97.htm (...) > > In fact, there is actually very little use for doing the whole thing > in the RIPE database in the first place. I haver never found any use > at all for looking up one of the in-addr.arpa objects in the database. > Maybe we should even think about retiring the 'domain:' objects and > 'rev-srv:' attributes altogether and offer a simple secure web or mail > user interface for submitting reverse delegations. We need an interface to 'transport' reverse zone information; now only nameserver attributes but in the future also DNSSec key attributes. Our "philosophy" when drawing this proposal is to provide our customers with uniform interfaces to deal with the RIPE NCC. By having one data-store, that comes with authorization mechanisms and a well defined API we are able to develop multiple interfaces to it; currently we have a mail and a network interface to the WHOIS database, web-portal functionality is being extended. Outside of the scope of this project, but this project enabling it, is the idea of a web-interface to reverse delegation management. Which includes easier management for simultaneous updating of "y-x.z.w.in-addr.arpa" objects (e.g. the same contact info, ns, etc.). I hope this addresses you question and comments. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC From katie at ripe.net Mon Oct 6 11:34:40 2003 From: katie at ripe.net (Katie Petrusha) Date: Mon, 6 Oct 2003 11:34:40 +0200 Subject: [ncc-services-wg] Re: [db-wg] Fw: FAILED: In-Reply-To: <3F7FE972.000003.01428@benhadjira.l26037.sfux.com> References: <3F7FE972.000003.01428@benhadjira.l26037.sfux.com> Message-ID: <20031006093440.GC6970@ripe.net> On Sun, Oct 05, 2003 at 10:50:42AM +0100, benhadjira wrote: Dear Mourad, Your update failed because you didn't send any password in your update message. Your maintainer object BM-MNT has CRYPW-PW authentication, therefore the clear text password corresponding to crypt line should be presented when creating/deleting/updating any object protected by this maintainer. Add the line password: your_clear_text_pass to your update message and resend it to auto-dbm at ripe.net. You can also use Web interface for updating the RIPE Database: WebUpdates: https://www.ripe.net/perl/webupdates.pl In the future, please report problems/errors/questions to ripe-dbm at ripe.net. Katie Petrusha RIPE Database Administration. > Dear sir > > We have tried several times to add inetnum to the data-base, but > unfortunetely this is the error message we received every time . > Could you please give us some help & advices on how to do it ? > > Thanking you in advance > > Mourad > Techni-communication > > -------Original Message------- > > From: ripe-dbm at ripe.net > Date: samedi 4 octobre 2003 10:34:28 > To: benhadjira at techni-communication.com > Subject: FAILED: > > > > From: benhadjira at techni-communication.com > > Subject: > > Date: Sat, 04 Oct 2003 05:34:19 -0400 > > Reply-To: benhadjira at techni-communication.com > > Message-ID: <04df532f66b14c6c874ce4e412db3b3d at techni-communication.com> > > > SUMMARY OF UPDATE: > > Number of objects found: 1 > Number of objects processed successfully: 0 > Create: 0 > Modify: 0 > Delete: 0 > No Operation: 0 > Number of objects processed with errors: 1 > Create: 1 > Modify: 0 > Delete: 0 > Syntax Errors: 0 > > > DETAILED EXPLANATION: > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following object(s) were found to have ERRORS: > > > --- > Create FAILED: [inetnum] 217.29.219.0 - 217.29.219.255 > ***Error: Authorisation failed > ***Info: Syntax check passed > > inetnum: 217.29.219.0 - 217.29.219.255 > netname: Techni-communication > descr: Techni-Communication - customer SEI.NET > country: DZ > admin-c: MA1973-ripe > tech-c: BM1974-RIPE > status: LIR-PARTITIONED PA > mnt-by: BM-MNT > mnt-lower: BM-MNT > mnt-routes: TACHYON-EU-MNT > changed: benhadjira at techni-communication.com 20031004 > source: RIPE > > ***Info: Authorisation for parent [inetnum] 217.29.208.0 - 217.29.223.255 > using mnt-lower: > not authenticated by: BM-MNT > > ***Info: Authorisation for [inetnum] 217.29.219.0 - 217.29.219.255 > using mnt-by: > not authenticated by: BM-MNT > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following paragraph(s) do not look like objects > and were NOT PROCESSED: > > -------------------------------------------------------------------- > mail2web.com™ - Check your email from the web at http://mail2web.com. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For assistance or clarification please contact: > RIPE Database Administration > > > . -- Kind regards, Katje From david at iprg.nokia.com Mon Oct 6 21:19:32 2003 From: david at iprg.nokia.com (David Kessens) Date: Mon, 6 Oct 2003 12:19:32 -0700 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031006155813.0ad8e77c.olaf@ripe.net>; from Olaf M. Kolkman on Mon, Oct 06, 2003 at 03:58:13PM +0200 References: <20031001173928.27e20e52.olaf@ripe.net> <20031003162741.A28768@iprg.nokia.com> <20031006155813.0ad8e77c.olaf@ripe.net> Message-ID: <20031006121932.A4658@iprg.nokia.com> Olaf, On Mon, Oct 06, 2003 at 03:58:13PM +0200, Olaf M. Kolkman wrote: > > > > On Wed, Oct 01, 2003 at 05:39:28PM +0200, ext Olaf M. Kolkman wrote: > > > > > > - 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. > > > > Does this mean that the 'rev-srv:' attribute will be retired too ?!? > > the "rev-srv:" attribute has been retired for the purpose of requesting > reverse delegation. E.g see: > http://www.ripe.net/ripencc/faq/reverse/qa2.html#14: > > What are those "rev-srv" lines in an inetnum object for? > > > Previously, delegation requests could be made using either an > inetnum object or a domain object. We discovered several problems > with this, one being inconsistency of the two possible sources. > Requests are now only accepted via domain objects, so you must > register your reverse servers only in the domain object. If you're > changing a reverse delegation and find rev-srv lines in the > corresponding inetnum object in the RIPE DB, you must create a > domain object and you should delete the rev-srv lines from the > inetnum. As you saw from my previous mail, if we decide to go the 'domain:' object way, let's get rid of the 'rev-srv:' attribute at the same time. I would like that to be part of the proposal. This whole 'rev-srv:' versus 'domain:' confusion has already lasted for such a long time that it is time to clear it up. > (...) > > This proposal also means that one has to submit for example 16 reverse > > delegation objects to do a reverse delegation of a single /20. > > To request delegation ranges you can use the "y-x.z.w.in-addr.arpa" > notation. This only works for "3rd" octets and there are problems > when using this update method in combination with PGP (will be fixed > during the migration to the WHOIS interface). > > Documentation on the range-update feature cannot be found on the web. > It used to be part of the documentation, but fell through a crack at > some point. We will be reviewing the documentation as part of the > project but will fix this omission soon. > > In the mean time, this is the relevant piece of documentation: > > http://www.ripe.net/reverse/howtoreverse.html#ranged-domain > > The range-update is also part of the LIR training curriculum: > > http://www.ripe.net/training/lir/material/slides/page97.htm Ok, but as you mentioned this gives problems with PGP. This is in my opinion a serious problem since this is the only real secure way to enter data in the database. Security is even more important if we use the data for actual operational purposes instead of informational purposes in contrast to all other registry data (with the exception of the routing registry part of the database). It is a real change from current procedures to use something from the RIR database for real operational purposes. It is also a departure of our policy of not rewriting users data. I am not sure whether that is a good thing. Rewriting and making a small correction to users input is one thing, expanding from one object to 16 or even more different objects is quite another. Don't be surprised if users are getting confused why they cannot find the range notation objects that they thought they just entered in the database. > > In fact, there is actually very little use for doing the whole thing > > in the RIPE database in the first place. I haver never found any use > > at all for looking up one of the in-addr.arpa objects in the database. > > Maybe we should even think about retiring the 'domain:' objects and > > 'rev-srv:' attributes altogether and offer a simple secure web or mail > > user interface for submitting reverse delegations. > > > We need an interface to 'transport' reverse zone information; now only > nameserver attributes but in the future also DNSSec key > attributes. This is a very good point. However, I am not sure whether it is a good idea to overengineer a solution for a thing that we possibly might be doing in the future. I can probably be convinced if there is actually a concrete project plan that we can discuss for adding DNSsec. > Our "philosophy" when drawing this proposal is to provide > our customers with uniform interfaces to deal with the RIPE NCC. By > having one data-store, that comes with authorization mechanisms and a > well defined API we are able to develop multiple interfaces to it; > currently we have a mail and a network interface to the WHOIS > database, web-portal functionality is being extended. I think myself that using the database is probably the right way to do it but I am not really sure either. I do think that a bit more discussion on this list will help to determine that this is really the case. Doing a reverse delegation is a relatively easy transaction and the proposal that is currently on the table adds a tremendous amount of extra complexity to the database and the request process. I am not convinced that there are no alternate ways to make the life of the users easier (that can or cannot include the database). Doing the reverse delegation over a secure webinterface where one only has to choose for which allocation the reverse delegation has to be changed and entering a couple of servers comes to mind. I am afraid, despite my fondness for the database, that it will only get into the way of people doing their job. I have seen too many companies deciding that they wanted to have a uniform way of dealing with their company systems and they end up with this beautiful all encompassing SAP (or whatever other vendors) system and people have to become an expert in the system before being able to do relatively easy transactions. For example, simply using the 'rev-srv:' attributes and retiring the 'domain:' objects seems a lot easier for the user. Yes, there is the disadvantage of different administative responsibilities inside larger local registries that could make this more difficult in certain cases, but this should balanced against the much greater ease of use. In addition, there are solutions possible that can address this fairly easily like adding a 'mnt-rev-srv:' attribute that allows the 'mntner:' to only change the 'rev-srv:' lines and nothing else. And the good thing is that this is completely optional so it doesn't interfere with people who want to do it the easy way. David K. --- From schuma at gaertner.de Tue Oct 7 03:02:53 2003 From: schuma at gaertner.de (Joerg Schumacher) Date: Tue, 7 Oct 2003 01:02:53 GMT Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> References: <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> Message-ID: In article <20031006121932.A4658 at iprg.nokia.com>, David Kessens wrote: > >On Mon, Oct 06, 2003 at 03:58:13PM +0200, Olaf M. Kolkman wrote: >> [...] >> the "rev-srv:" attribute has been retired for the purpose of requesting >> reverse delegation. E.g see: >> http://www.ripe.net/ripencc/faq/reverse/qa2.html#14: >> [...] > >As you saw from my previous mail, if we decide to go the 'domain:' >object way, let's get rid of the 'rev-srv:' attribute at the same >time. I would like that to be part of the proposal. Seconded. >This whole 'rev-srv:' versus 'domain:' confusion has already lasted >for such a long time that it is time to clear it up. IIRC, Marvin only accepts domain objects for the last couple of years. The FAQ asks kindly to remove the rev-srv lines, but I guess no one really cares. Let's get rid of them in the cleanup process. Regards, Joerg From schuma at gaertner.de Tue Oct 7 04:26:34 2003 From: schuma at gaertner.de (Joerg Schumacher) Date: Tue, 7 Oct 2003 02:26:34 GMT Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> References: <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> Message-ID: In article <20031006121932.A4658 at iprg.nokia.com>, David Kessens wrote: > [...] > For example, simply using the 'rev-srv:' attributes and retiring the > 'domain:' objects seems a lot easier for the user. [...] The RIPE NCC delegates reverse domains on /24 and /16 boundaries only so they don't match inetnum objects very well. The 'rev-srv' might seem to be easier, but thats only true for /16 allocs. rev-srv on e.g. a /29 are meaningless and should go away. Same holds true for a rev-srv on a /24 within a /16. Regards, Joerg From schuma at gaertner.de Tue Oct 7 05:58:32 2003 From: schuma at gaertner.de (Joerg Schumacher) Date: Tue, 7 Oct 2003 03:58:32 GMT Subject: [ncc-services-wg] interfaces to ripe ncc services (was: Reverse DNS Restructuring Project) In-Reply-To: <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> References: <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> Message-ID: In article <20031006121932.A4658 at iprg.nokia.com>, David Kessens wrote: > [...] > I think myself that using the database is probably the right way to do > it but I am not really sure either. I do think that a bit more > discussion on this list will help to determine that this is really the > case. > > Doing a reverse delegation is a relatively easy transaction and the > proposal that is currently on the table adds a tremendous amount of > extra complexity to the database and the request process. I am not > convinced that there are no alternate ways to make the life of the users > easier (that can or cannot include the database). > > Doing the reverse delegation over a secure webinterface where one only > has to choose for which allocation the reverse delegation has to be > changed and entering a couple of servers comes to mind. > > I am afraid, despite my fondness for the database, that it will only > get into the way of people doing their job. I have seen too many > companies deciding that they wanted to have a uniform way of dealing > with their company systems and they end up with this beautiful all > encompassing SAP (or whatever other vendors) system and people have to > become an expert in the system before being able to do relatively easy > transactions. > [...] I think David has a valid point here: We should discuss the differnent possible interfaces to the RIPE NCC services. IMHO we have to camps: 1) the webinterface folks 2) the mailinterface folks I think that RIPE NCC should support both camps. The occasional user of the services will certainly welcome a simple webinterface. The LIR Portal (https://lirportal.ripe.net/) could be extended for this camp. Reverse delegations are certainly an example of only occasionally needed services. The regular user won't be happy with a webinterface, since automation isn't as easy as with the mailinterface. An example for a regular task is the "Provider Aggregatable (PA) Assignment Request Form". While the LIR Portal already reflects the current ripe-283, I don't see a new autohm in ftp://ftp.ripe.net/ripe/tools/ Supporting two different interfaces to the same service doesn't come for free, but I think it's worth the trouble (and money). Regards, Joerg From lists at complx.LF.net Tue Oct 7 06:23:35 2003 From: lists at complx.LF.net (Kurt Jaeger) Date: Tue, 7 Oct 2003 06:23:35 +0200 Subject: [ncc-services-wg] interfaces to ripe ncc services (was: Reverse DNS Restructuring Project) In-Reply-To: References: <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> Message-ID: <20031007042335.GZ5474@complx.LF.net> Hi! > IMHO we have to camps: > > 1) the webinterface folks > 2) the mailinterface folks > > I think that RIPE NCC should support both camps. [...] > Supporting two different interfaces to the same service doesn't come > for free, but I think it's worth the trouble (and money). >From what I learned, supporting two different interfaces allows for very subtle bugs and annoyances, which ultimatly lead to effects like "you can do this only with that interface" or "If you do this with that interface, something different will happen compared to that other interface". Having *one* way, and having this way consistently, is far easier to support. I vote for mail. -- MfG/Best regards, Kurt Jaeger 17 years to go ! LF.net GmbH fon +49 711 90074-23 pi at LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From peter.galbavy at knowtion.net Tue Oct 7 15:01:54 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 7 Oct 2003 14:01:54 +0100 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail Message-ID: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com> 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 From manuel at ripe.net Tue Oct 7 18:09:04 2003 From: manuel at ripe.net (Manuel Valente) Date: Tue, 7 Oct 2003 18:09:04 +0200 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail In-Reply-To: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com> References: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com> Message-ID: <20031007180904.264084b7.manuel@ripe.net> Mr Galbavy, On Tue, 7 Oct 2003 14:01:54 +0100 "Peter Galbavy" wrote: > 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. When we created the LIR Portal, we tried to set up security measures to prevent accounts from being hijacked, which include receiving a fax. If members think that this process is unnecessary or cumbersome, we welcome suggestions for streamlined alternatives that retain a high level of authentication. > 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 ??? You normally don't: when an e-mail is received that contains a valid ticket number, and the ticket already has the regID set, that is enough for the distribution robot. Now, the problem that you spotted comes from the fact that we inadvertently did not set the regID in this batch of tickets. This is why the distribution robot rejected your reply. I apologise to you and to the other members for any delays this may have caused. This problem will not appear again, as we have now set all the regIDs in all the tickets that were created for this particular announcement, and any replies to those tickets should be accepted by the distribution robot. > 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. I agree with you: over-babying of inbound mail to the NCC is a bad thing. We are always interested to receive suggestions from our members on ways to improve our membership services. We can then relay these suggestions to the members for approval. We appreciate your input. Regards. -- Manuel Valente - Software Manager - RIPE NCC From peter.galbavy at knowtion.net Tue Oct 7 18:39:06 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 7 Oct 2003 17:39:06 +0100 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail References: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com> <20031007180904.264084b7.manuel@ripe.net> Message-ID: <029e01c38cf1$869032f0$2f28a8c0@cblan.mblox.com> Manuel Valente wrote: > When we created the LIR Portal, we tried to set up security measures > to prevent accounts from being hijacked, which include receiving a > fax. If members think that this process is unnecessary or cumbersome, > we welcome suggestions for streamlined alternatives that retain a > high level of authentication. To give the history, when my company's fax machines died we never replaced it as 99.9% of our communications was e-mail based. I still see no reason to buy one "just for RIPE". 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. So, in a context, I ask you as a member to remove the pointless requirement of having a fax machine / number and allowing other equially (if not more so) valid ways of authenticating INCLUDING the real-paper postal service. Pointless rules == Cash cow for otherwise redundent staff. rgds, -- Peter From olaf at ripe.net Wed Oct 8 11:50:56 2003 From: olaf at ripe.net (Olaf M. Kolkman) Date: Wed, 8 Oct 2003 11:50:56 +0200 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031006121932.A4658@iprg.nokia.com> References: <20031001173928.27e20e52.olaf@ripe.net> <20031003162741.A28768@iprg.nokia.com> <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> Message-ID: <20031008115056.5f29bb5a.olaf@ripe.net> David and others, David wrote: > > As you saw from my previous mail, if we decide to go the 'domain:' > object way, let's get rid of the 'rev-srv:' attribute at the same > time. I would like that to be part of the proposal. > > This whole 'rev-srv:' versus 'domain:' confusion has already lasted > for such a long time that it is time to clear it up. 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. David wrote: > > Ok, but as you mentioned this gives problems with PGP. This is in my > opinion a serious problem since this is the only real secure way to > enter data in the database. Security is even more important if we use > the data for actual operational purposes instead of informational > purposes in contrast to all other registry data (with the exception of > the routing registry part of the database). It is a real change from > current procedures to use something from the RIR database for real > operational purposes. > I may not have explicitly mentioned this but in the new system PGP will work in combination with the "range" update. (Technical detail, now the authorization checks are done after the objects have been split and individually processed, in the future the authorization check will be done first and then the objects are split to to further checks). Note also that not only PGP will work with the proposed setup but users will be able to use the consistent authorization model of the RIPE DB. As for using WHOIS directly to generate zone information, you hit the nail on the head, this is a real change. However, we currently use the domain objects to maintain reverse delegations. Those domain objects do end up in the database while simultaneously updating zone files. So if everybody would use the proper interface to update domain objects than we would have full consistency. So when implementing the proposal we loose the ambiguity in the update path, we get consistent WHOIS and ZONE data. Besides we gain access, and use of new authorization mechanism that become available to the database (e.g. X509). > It is also a departure of our policy of not rewriting users data. I am > not sure whether that is a good thing. Rewriting and making a small > correction to users input is one thing, expanding from one object to > 16 or even more different objects is quite another. Don't be surprised > if users are getting confused why they cannot find the range notation > objects that they thought they just entered in the database. I am not in the position to judge if this will be a problem. I hope and think the mechanism of the range update is documented well enough that users will know that the range update is "synthesizing multiple updates". Olaf wrote: > > We need an interface to 'transport' reverse zone information; now only > > nameserver attributes but in the future also DNSSec key > > attributes. David replied: > This is a very good point. However, I am not sure whether it is a good > idea to overengineer a solution for a thing that we possibly might be > doing in the future. I can probably be convinced if there is actually > a concrete project plan that we can discuss for adding DNSsec. The proposal as such stands on its own. Ideas on DNSSEC deployment are a motivation to go this way but are not the main driving force behind it. Having said this, here are the requirements for DNSSec key-exchanges. - Initial key exchange needs to happen out of band. - The authorization mechanisms use during the key exchange will need to be as strong as the authorization used for the exchange of nameserver attributes. A less strict requirement: - There is a preference to maintain a database with key information. (A hash over the key ends up in the parent zone, during trouble shooting it may be handy to figure out what the key material was used to generate the hash). All these requirements are fulfilled when we use the domain object to store key information and adding DNSSEC capabilities to our provisioning system will be a matter of weeks, allowing for rollout soon after standards have been completed. Note that we will still be able to deploy DNSSEC with a key-attribute in a domain object and using auto-inaddr/Marvin (Marvin is the robot in the back-end) however with the in-addr robot and the WHOIS database not being tightly integrated we will get more and more inconsistencies. The proposal is to make sure there is one update path for domain objects that leads to consistent zone information; that is independent of deployment of DNSSEC or not. David wrote: > I think myself that using the database is probably the right way to do > it but I am not really sure either. I do think that a bit more > discussion on this list will help to determine that this is really the > case. Reading and open to suggestions see however the next point. > Doing a reverse delegation is a relatively easy transaction and the > proposal that is currently on the table adds a tremendous amount of > extra complexity to the database and the request process. I am not > convinced that there are no alternate ways to make the life of the users > easier (that can or cannot include the database). There might be other mechanisms. But our requirements for the current proposal were minimal changes to the end-user and minimizing the amount of different back-end databases we have to maintain. It is hard to put hard numbers on these things but less complicated systems lead to less costs. > Doing the reverse delegation over a secure web interface where one only > has to choose for which allocation the reverse delegation has to be > changed and entering a couple of servers comes to mind. As said above and in the previous mail, the DB group is developing various interfaces to the WHOIS database. Piggy-backing on those developments that kind of interface becomes real close. > I am afraid, despite my fondness for the database, that it will only > get into the way of people doing their job. I have seen too many > companies deciding that they wanted to have a uniform way of dealing > with their company systems and they end up with this beautiful all > encompassing SAP (or whatever other vendors) system and people have to > become an expert in the system before being able to do relatively easy > transactions. > > For example, simply using the 'rev-srv:' attributes and retiring the > 'domain:' objects seems a lot easier for the user. Yes, there is the > disadvantage of different administative responsibilities inside larger > local registries that could make this more difficult in certain cases, > but this should balanced against the much greater ease of use. In > addition, there are solutions possible that can address this fairly > easily like adding a 'mnt-rev-srv:' attribute that allows the > 'mntner:' to only change the 'rev-srv:' lines and nothing else. And > the good thing is that this is completely optional so it doesn't > interfere with people who want to do it the easy way. It strikes me that this example as remarkable similarity to the current proposal. Both use the DB for storage of reverse information and both use a new attribute to delegate authorization for updating specific information. Most users have been using domain objects for years. I am not sure if deprecating those in favor of reviving "rev-srv:" is something those users are waiting for. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC From manuel at ripe.net Wed Oct 8 12:25:01 2003 From: manuel at ripe.net (Manuel Valente) Date: Wed, 8 Oct 2003 12:25:01 +0200 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail In-Reply-To: <029e01c38cf1$869032f0$2f28a8c0@cblan.mblox.com> References: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com> <20031007180904.264084b7.manuel@ripe.net> <029e01c38cf1$869032f0$2f28a8c0@cblan.mblox.com> Message-ID: <20031008122501.0c99c31c.manuel@ripe.net> Mr Galbavy, On Tue, 7 Oct 2003 17:39:06 +0100 "Peter Galbavy" wrote: > Manuel Valente wrote: > > When we created the LIR Portal, we tried to set up security measures > > to prevent accounts from being hijacked, which include receiving a > > fax. If members think that this process is unnecessary or cumbersome, > > we welcome suggestions for streamlined alternatives that retain a > > high level of authentication. > > To give the history, when my company's fax machines died we never > replaced it as 99.9% of our communications was e-mail based. I still see > no reason to buy one "just for RIPE". 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. > > So, in a context, I ask you as a member to remove the pointless > requirement of having a fax machine / number and allowing other equially > (if not more so) valid ways of authenticating INCLUDING the real-paper > postal service. The whole point of requiring a fax and an email to be sent to the requester of an LIR Portal account was to enable us to have a fully automated procedure for the creation of accounts: the fax and the email are both sent by a robot with no human intervention at all. At the time that we created this procedure, we expected - incorrectly it seems - that all the LIRs would own a fax machine or have a gateway to be able to receive faxes by other means. I take note of your proposal to allow requesters to receive this information by other means than faxes. I think it's valuable because it allows for more flexibility in the service that we provide to the members and, from a technical point of view, would not represent a problem for us to implement. But I would comment that, for instance, using a paper letter would require a staff member at the RIPE NCC to actually print the letter, stuff it in an envelope and send it. I would like the opinion of the other members on the proposal, considering its potential impact on the utilisation of the resources of the RIPE NCC. > Pointless rules == Cash cow for otherwise redundent staff. Regards. -- Manuel Valente - Software Manager - RIPE NCC From peter.galbavy at knowtion.net Wed Oct 8 12:33:04 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 8 Oct 2003 11:33:04 +0100 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail References: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com><20031007180904.264084b7.manuel@ripe.net><029e01c38cf1$869032f0$2f28a8c0@cblan.mblox.com> <20031008122501.0c99c31c.manuel@ripe.net> Message-ID: <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> Manuel Valente wrote: > I take note of your proposal to allow requesters to receive this > information by other means than faxes. I think it's valuable because > it allows for more flexibility in the service that we provide to the > members and, from a technical point of view, would not represent a > problem for us to implement. But I would comment that, for instance, > using a paper letter would require a staff member at the RIPE NCC to > actually print the letter, stuff it in an envelope and send it. Er, perhaps you have got matters confused ? Can you please explain to me who works for who here ? Your objective should *NOT* be to minimise the work for RIPE staff but to provide a service - at economical cost - to the members who pay for it. If you can propose such a fully automated system that no staff are actually required for anything, then well done; I look forward to the membership fee going towards zero. If you are just trying to make life easy for yourselves, I am against this. Again, please remember who works for who. > I would like the opinion of the other members on the proposal, > considering its potential impact on the utilisation of the resources > of the RIPE NCC. Does anyone else care ? Peter From ripe-lists at stop.me.uk Wed Oct 8 12:34:20 2003 From: ripe-lists at stop.me.uk (Denesh Bhabuta) Date: Wed, 08 Oct 2003 11:34:20 +0100 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail In-Reply-To: <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> References: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com> <20031007180904.264084b7.manuel@ripe.net> <029e01c38cf1$869032f0$2f28a8c0@cblan.mblox.com> <20031008122501.0c99c31c.manuel@ripe.net> <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> Message-ID: <348590000.1065609259@dhcppc1> --On Wednesday, October 08, 2003 11:33:04 +0100 Peter Galbavy wrote: >> I would like the opinion of the other members on the proposal, >> considering its potential impact on the utilisation of the resources >> of the RIPE NCC. > Does anyone else care ? I have to say I agree with Peter in this thread. Regards Denesh (uk.aexiomus) From pim at bit.nl Wed Oct 8 12:43:37 2003 From: pim at bit.nl (Pim van Pelt) Date: Wed, 8 Oct 2003 12:43:37 +0200 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail In-Reply-To: <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> References: <20031008122501.0c99c31c.manuel@ripe.net> <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> Message-ID: <20031008104336.GN22479@crow.bit.nl> Hoi, | > I would like the opinion of the other members on the proposal, | > considering its potential impact on the utilisation of the resources | > of the RIPE NCC. | Does anyone else care ? Yes, at least one person in Holland does. With regard to the fax, I think it is wise to have at least some method of proof of human intervention. If you cannot send/receive faxes, I suggest you buy a fax machine in stead of going the route you suggested. With regard to the proposal. I do not think it is nessecary to push manhours against other forms of authentication/signup than those already in place. I find it amazing (and somewhat ironic) that you are suggesting that the folks at NCC should invest time in these types of "nobody wants them anyway" features. Pun intended. -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From woeber at cc.univie.ac.at Wed Oct 8 12:56:56 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 08 Oct 2003 12:56:56 +0200 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail Message-ID: <00A27124.1E5B0EA4.11@cc.univie.ac.at> > ... 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 at 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. From gert at space.net Wed Oct 8 13:10:44 2003 From: gert at space.net (Gert Doering) Date: Wed, 8 Oct 2003 13:10:44 +0200 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail In-Reply-To: <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com>; from peter.galbavy@knowtion.net on Wed, Oct 08, 2003 at 11:33:04AM +0100 References: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com><20031007180904.264084b7.manuel@ripe.net><029e01c38cf1$869032f0$2f28a8c0@cblan.mblox.com> <20031008122501.0c99c31c.manuel@ripe.net> <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> Message-ID: <20031008131044.Y67740@Space.Net> Hi, On Wed, Oct 08, 2003 at 11:33:04AM +0100, Peter Galbavy wrote: > > I would like the opinion of the other members on the proposal, > > considering its potential impact on the utilisation of the resources > > of the RIPE NCC. > Does anyone else care ? Actually, we do, and I agree with Manuel that everything that doesn't require manual interaction at the NCC will help reducing staff costs, and thus reducing fees. So "automated fax" sounds like a useful thing (and it isn't *that* hard, even for a small LIR, to find a fax modem in some closet and hook it up to a unused phone extention for a couple of days). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56883 (56833) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From peter.galbavy at knowtion.net Wed Oct 8 13:19:44 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 8 Oct 2003 12:19:44 +0100 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail References: <20031008122501.0c99c31c.manuel@ripe.net> <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> <20031008104336.GN22479@crow.bit.nl> Message-ID: <017d01c38d8e$14c20d40$2f28a8c0@cblan.mblox.com> Pim van Pelt wrote: > Yes, at least one person in Holland does. With regard to the fax, I > think it is wise to have at least some method of proof of human > intervention. If you cannot send/receive faxes, I suggest you buy > a fax machine in stead of going the route you suggested. Just for this ? No. Apart from sales people asking for fax numbers, we have had no need to replace the broken machine (and cancelled the line) ages ago. > With regard to the proposal. I do not think it is nessecary to push > manhours against other forms of authentication/signup than those > already in place. I find it amazing (and somewhat ironic) that you > are suggesting that the folks at NCC should invest time in these > types of "nobody > wants them anyway" features. No, what I want is there to always be a fallback and never ever a "twisty little maze of passages, all different" when dealing with RIPE. BTW If the fax system is automated, how does it help to verify someones ID ? Why can't a verification "page" be sent with or on the paper invoices for membership ? Peter From peter.galbavy at knowtion.net Wed Oct 8 13:28:45 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 8 Oct 2003 12:28:45 +0100 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail References: <00A27124.1E5B0EA4.11@cc.univie.ac.at> Message-ID: <018001c38d8f$56171960$2f28a8c0@cblan.mblox.com> Wilfried Woeber, UniVie/ACOnet wrote: > Could you give us an example and/or timeframe for that? Most of the '90s from memory. > I am curious when/how/why an "organisation" (RIPE) - which doesn't > have the concept of membership - would request any certificate. Whatever. Peter From peter.galbavy at knowtion.net Wed Oct 8 13:40:08 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 8 Oct 2003 12:40:08 +0100 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail References: <00A27124.1E5B0EA4.11@cc.univie.ac.at> <018001c38d8f$56171960$2f28a8c0@cblan.mblox.com> Message-ID: <018d01c38d90$ed2dbab0$2f28a8c0@cblan.mblox.com> Peter Galbavy wrote: > Wilfried Woeber, UniVie/ACOnet wrote: >> Could you give us an example and/or timeframe for that? > > Most of the '90s from memory. In fact, RIPE-257: -- quote -- The RIPE NCC can only supply services to organisations that operate as a legal entity in the RIPE NCC service region. Therefore, together with the "The Standard RIPE NCC Service Agreement", the RIPE NCC requires you to send a copy of your organisation's registration with the local Chamber of Commerce, or the equivalent. The RIPE NCC will only sign "The Standard RIPE NCC Service Agreement" in the English language. -- end -- The "or equivalent" was only added later. There is still the point that "humans" are "legal entities" in a number of legal territories, including England. There should be no reason that you should be a company to joing RIPE. Peter From djp-ripe-lists at djp.net Wed Oct 8 14:45:30 2003 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Wed, 8 Oct 2003 13:45:30 +0100 (BST) Subject: [ncc-services-wg] ripe rejecting "valid" e-mail In-Reply-To: <348590000.1065609259@dhcppc1> References: <01fa01c38cd3$2ecf9510$2f28a8c0@cblan.mblox.com> <20031007180904.264084b7.manuel@ripe.net> <029e01c38cf1$869032f0$2f28a8c0@cblan.mblox.com> <20031008122501.0c99c31c.manuel@ripe.net> <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> <348590000.1065609259@dhcppc1> Message-ID: I agree with Peter too on this issue. Fax machines may not quite be obsolete but they are definitely on the way out. This is particularly so for ISPs which are more likely to embrace new technology. Fax machines are a liability and an unnecessary expense. Cheers Dave On Wed, 8 Oct 2003, Denesh Bhabuta wrote: ->--On Wednesday, October 08, 2003 11:33:04 +0100 Peter Galbavy -> wrote: ->>> I would like the opinion of the other members on the proposal, ->>> considering its potential impact on the utilisation of the resources ->>> of the RIPE NCC. ->> Does anyone else care ? -> ->I have to say I agree with Peter in this thread. -> ->Regards ->Denesh (uk.aexiomus) -> From contact at ripe.net Wed Oct 8 15:58:22 2003 From: contact at ripe.net (Membership Liason Officer) Date: Wed, 8 Oct 2003 15:58:22 +0200 Subject: [ncc-services-wg] RIPE NCC Regional Meeting, Middle Message-ID: <200310081358.h98DwMrY021723@birch.ripe.net> East, Dubai, 7-9 December 2003 Message-Id: <20031008155822.0e2b8155.contact at 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: 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: . Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC From pieterjan.d.hertog at belgacom.be Wed Oct 8 13:25:59 2003 From: pieterjan.d.hertog at belgacom.be (Pieterjan d'Hertog) Date: Wed, 08 Oct 2003 13:25:59 +0200 Subject: [ncc-services-wg] ripe rejecting "valid" e-mail In-Reply-To: <017d01c38d8e$14c20d40$2f28a8c0@cblan.mblox.com> References: <20031008122501.0c99c31c.manuel@ripe.net> <011e01c38d87$8f8e87d0$2f28a8c0@cblan.mblox.com> <20031008104336.GN22479@crow.bit.nl> Message-ID: <5.2.1.1.2.20031008132504.026dfa58@mail.dhertog.be> At 12:19 8/10/2003 +0100, Peter Galbavy wrote: >Pim van Pelt wrote: > > Yes, at least one person in Holland does. With regard to the fax, I > > think it is wise to have at least some method of proof of human > > intervention. If you cannot send/receive faxes, I suggest you buy > > a fax machine in stead of going the route you suggested. > >Just for this ? No. Apart from sales people asking for fax numbers, we have >had no need to replace the broken machine (and cancelled the line) ages ago. > Peter, You will have to update your website :-) To contact us, please use one of the following: sales enquiries sales at knowledge-matters.co.uk general information info at knowledge-matters.co.uk website issues webmaster at knowledge-matters.co.uk fax +44 845 660 7666 :-)) voice/mobile +44 7710 348988 post Knowledge Matters Limited 22 Chesterfield Road LONDON N3 1PR United Kingdom --- Pieterjan d'Hertog, Expert IT Analyst Belgacom ANS/ROC Internet Expertise Center From bruce.campbell at ripe.net Wed Oct 8 16:41:49 2003 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Wed, 8 Oct 2003 16:41:49 +0200 (CEST) Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031008160109.1260d536.olaf@ripe.net> References: <20031001173928.27e20e52.olaf@ripe.net> <20031003162741.A28768@iprg.nokia.com> <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> <20031008115056.5f29bb5a.olaf@ripe.net> <20031008160109.1260d536.olaf@ripe.net> Message-ID: 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 From david at iprg.nokia.com Wed Oct 8 23:57:11 2003 From: david at iprg.nokia.com (David Kessens) Date: Wed, 8 Oct 2003 14:57:11 -0700 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031008115056.5f29bb5a.olaf@ripe.net>; from Olaf M. Kolkman on Wed, Oct 08, 2003 at 11:50:56AM +0200 References: <20031001173928.27e20e52.olaf@ripe.net> <20031003162741.A28768@iprg.nokia.com> <20031006155813.0ad8e77c.olaf@ripe.net> <20031006121932.A4658@iprg.nokia.com> <20031008115056.5f29bb5a.olaf@ripe.net> Message-ID: <20031008145711.C7178@iprg.nokia.com> Olaf, On Wed, Oct 08, 2003 at 11:50:56AM +0200, Olaf M. Kolkman wrote: > > David wrote: > > > > As you saw from my previous mail, if we decide to go the 'domain:' > > object way, let's get rid of the 'rev-srv:' attribute at the same > > time. I would like that to be part of the proposal. > > > > This whole 'rev-srv:' versus 'domain:' confusion has already lasted > > for such a long time that it is time to clear it up. > > 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. very good. > I may not have explicitly mentioned this but in the new system PGP > will work in combination with the "range" update. (Technical detail, > now the authorization checks are done after the objects have been > split and individually processed, in the future the authorization > check will be done first and then the objects are split to to further > checks). Note also that not only PGP will work with the proposed setup > but users will be able to use the consistent authorization model of > the RIPE DB. That is exactly why I think the RIPE database might be a good place. However, if we use 'rev-srv:' attributes instead of 'domain:' objects, we can still use this model without the need to rewrite users data. > As for using WHOIS directly to generate zone information, you hit the > nail on the head, this is a real change. And an important one. Not all database security mechanisms in use are good enough for this new purpose. They might be good enough for publishing data for informational purposes, they are not good enough to make actual changes to configurations. > However, we currently use the domain objects to maintain reverse > delegations. Those domain objects do end up in the database while > simultaneously updating zone files. So if everybody would use the > proper interface to update domain objects than we would have full > consistency. So when implementing the proposal we loose the > ambiguity in the update path, we get consistent WHOIS and ZONE data. > Besides we gain access, and use of new authorization mechanism that > become available to the database (e.g. X509). Yes, that is certainly useful. However, we would also get full consistency if we got rid of both 'domain:' and 'rev-srv:' attributes and use a simple specialized interface to do reverse delegations. The DNS is already a fully public database. There is no need to keep the data in yet another backend database or publish it in more than one place. I think the focus should be on the people who use the interface: we need to choose the most simple and easy way for the user to get the job done. The goal is not to make a complicated interface and declare victory because we have reached data consistency! > > It is also a departure of our policy of not rewriting users data. I am > > not sure whether that is a good thing. Rewriting and making a small > > correction to users input is one thing, expanding from one object to > > 16 or even more different objects is quite another. Don't be surprised > > if users are getting confused why they cannot find the range notation > > objects that they thought they just entered in the database. > > I am not in the position to judge if this will be a problem. I hope > and think the mechanism of the range update is documented well enough > that users will know that the range update is "synthesizing multiple > updates". Rewriting users data is messy and should be avoided if there is other alternatives available. There is all kind of possible problems that one can come up with and you will find more when you start doing this in practise. To give another example: - Somebody sends in: 3-10.193.in-addr.arpa - Next, requests a change to: 4.193.in-addr.arpa - Next, somebody requests a deletion of: 3-10.193.in-addr.arpa Should the deletion fail since 3-10.193.in-addr.arpa is actually many different objects and one of them is not the same anymore so in fact there is really two sets of different objects ?!? This kind of things can be solved by applying (or implying) more rules and this will result in making life more difficult for the casual database user because one has to go first to a three week training class before one is able to interact properly with the RIPE database. > David wrote: > > I think myself that using the database is probably the right way to do > > it but I am not really sure either. I do think that a bit more > > discussion on this list will help to determine that this is really the > > case. > > Reading and open to suggestions see however the next point. > > > Doing a reverse delegation is a relatively easy transaction and the > > proposal that is currently on the table adds a tremendous amount of > > extra complexity to the database and the request process. I am not > > convinced that there are no alternate ways to make the life of the users > > easier (that can or cannot include the database). > > There might be other mechanisms. But our requirements for the current > proposal were minimal changes to the end-user and minimizing the > amount of different back-end databases we have to maintain. It is hard > to put hard numbers on these things but less complicated systems lead > to less costs. And that is exactly my problem with it. I don't think that the 'minimal changes to the end-user' is the right requirement. The right requirement is to make things as easy as possible for your customers. Doing reverse delagations with 'rev-srv:' attributes seems a lot easier to me (I prefer this option). There is no need to rewrite objects. And one can reverse delegate whole blocks at once by doing a single simple submission without a need to learn any complications like 'range' notations for domain objects. But as an alternative, I think not using the RIPE database at all can possibly be even easier (and there is no need to have multiple backend databases either, the DNS works just fine for that). And there are pretty good arguments for this too: the database allows one to submit objects that are lower in the delegation tree and they will be ignored because there are already delegations in another part of the tree. This points in the direction that neither 'inetnum:' objects or 'domain:' objects are the right datamodel to this. Again, this can solved by adding rules, but it adds complexity and in the mean time, the user will be confused because the user didn't read the 50 page database manual before requesting the reverse delegation. > > For example, simply using the 'rev-srv:' attributes and retiring the > > 'domain:' objects seems a lot easier for the user. Yes, there is the > > disadvantage of different administative responsibilities inside larger > > local registries that could make this more difficult in certain cases, > > but this should balanced against the much greater ease of use. In > > addition, there are solutions possible that can address this fairly > > easily like adding a 'mnt-rev-srv:' attribute that allows the > > 'mntner:' to only change the 'rev-srv:' lines and nothing else. And > > the good thing is that this is completely optional so it doesn't > > interfere with people who want to do it the easy way. > > It strikes me that this example as remarkable similarity to the > current proposal. Both use the DB for storage of reverse information > and both use a new attribute to delegate authorization for updating > specific information. Of course there is a lot of similarity because they are trying to accomplish the same thing. But only one of the proposals is the easiest and least complicated to use. > Most users have been using domain objects for years. I am not sure if > deprecating those in favor of reviving "rev-srv:" is something those > users are waiting for. Yes, but did they have a choice ?!? They had to submit 'domain:' objects to get their reverse delegations done. No wonder they are more up to date (but still far from correct) than the 'rev-srv:' attributes. Again, the requirement is what works easiest for your customer, it is not: 'let's keep doing it the old way because people are used to it'. I think it is time for me now to take a step back and watch what other people like as the best solution. David K. --- From schuma at gaertner.de Thu Oct 9 03:56:29 2003 From: schuma at gaertner.de (Joerg Schumacher) Date: Thu, 9 Oct 2003 01:56:29 GMT Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: <20031008115056.5f29bb5a.olaf@ripe.net> <20031008145711.C7178@iprg.nokia.com> References: <20031008115056.5f29bb5a.olaf@ripe.net> <20031008145711.C7178@iprg.nokia.com> Message-ID: In article <20031008145711.C7178 at iprg.nokia.com>, David Kessens wrote: > [...] > > However, we currently use the domain objects to maintain reverse > > delegations. Those domain objects do end up in the database while > > simultaneously updating zone files. So if everybody would use the > > proper interface to update domain objects than we would have full > > consistency. So when implementing the proposal we loose the > > ambiguity in the update path, we get consistent WHOIS and ZONE data. > > Besides we gain access, and use of new authorization mechanism that > > become available to the database (e.g. X509). > > Yes, that is certainly useful. However, we would also get full > consistency if we got rid of both 'domain:' and 'rev-srv:' attributes > and use a simple specialized interface to do reverse delegations. The > DNS is already a fully public database. There is no need to keep the > data in yet another backend database or publish it in more than one > place. I beg to differ. The redundancy in the database is needed for us operators. If you were right, we could drop all the IRR databases, sice the bgp table is a fully public database. That's fine as long as no errors happen, but error do happen so we need some out-of-band method to know how it should look like and whom to cantact if it doesn't. A quick example: let's assume that the nameservers for iprg.nokia.com and nokia.com are all lame delegations. Who'e the right contact to fix this? Since they are all lame, I can't retrieve the RNAME in the SOA. I guess I could get the RNAME of .com, but contacting nstld at verisign-grs.com would certainly not solve the problem. > I think the focus should be on the people who use the interface: we > need to choose the most simple and easy way for the user to get the > job done. The goal is not to make a complicated interface and declare > victory because we have reached data consistency! It's not getting more complicated. You already have to submit a domain object to get a reverse delegation. In fact it's getting easyer since you don't have to remember that this object has go to auto-inaddr at ripe.net. It's an ripe database object, so auto-dbm at ripe.net seems to be the natural choice. > [...] > To give another example: > > - Somebody sends in: 3-10.193.in-addr.arpa > - Next, requests a change to: 4.193.in-addr.arpa > - Next, somebody requests a deletion of: 3-10.193.in-addr.arpa > > Should the deletion fail since 3-10.193.in-addr.arpa is actually many > different objects and one of them is not the same anymore so in fact > there is really two sets of different objects ?!? Try again, this time with inetnums and rev-srv. What's the meaning of rev-srv on a /20 followed by a more specific /24 followed by the less specific /20? The problem space is exactly the same. Joerg From david at iprg.nokia.com Thu Oct 9 20:43:13 2003 From: david at iprg.nokia.com (David Kessens) Date: Thu, 9 Oct 2003 11:43:13 -0700 Subject: [ncc-services-wg] Reverse DNS Restructuring Project In-Reply-To: ; from Joerg Schumacher on Thu, Oct 09, 2003 at 01:56:29AM +0000 References: <20031008115056.5f29bb5a.olaf@ripe.net> <20031008145711.C7178@iprg.nokia.com> <20031008115056.5f29bb5a.olaf@ripe.net> Message-ID: <20031009114313.A8358@iprg.nokia.com> Joerg, On Thu, Oct 09, 2003 at 01:56:29AM +0000, Joerg Schumacher wrote: > > > > Yes, that is certainly useful. However, we would also get full > > consistency if we got rid of both 'domain:' and 'rev-srv:' attributes > > and use a simple specialized interface to do reverse delegations. The > > DNS is already a fully public database. There is no need to keep the > > data in yet another backend database or publish it in more than one > > place. > > I beg to differ. The redundancy in the database is needed for us > operators. If you were right, we could drop all the IRR databases, > sice the bgp table is a fully public database. I happen to be an operator too :-). I very carefully talked about the reverse delegation 'domain:' and 'rev-srv:' data only. I never said that IRR databases should be dropped. When the DNS is unable to provide you with a contact, the 'inetnum:' objects are still there and it gives you quite a few contacts to talk to in case of problems. If people feel that that is not enough, you could always introduce a 'reverse-contact:' attribute. Note that my preferred solution is to use 'rev-srv:' attributes which actually keeps all the reverse information in the database. I just wanted to point out that there are other alternatives that could also be considered. When changing the systems anyways, it is always a good idea to take a step back and look with an open mind whether the current process actually accomplishes the goal in the most efficient way. Of course we can make incremental improvements but sometimes a lot of the problems with the current process go away by taking a different direction. > That's fine as long as no errors happen, but error do happen so we > need some out-of-band method to know how it should look like and > whom to cantact if it doesn't. > > A quick example: let's assume that the nameservers for iprg.nokia.com > and nokia.com are all lame delegations. Who'e the right contact to > fix this? Since they are all lame, I can't retrieve the RNAME in the > SOA. I guess I could get the RNAME of .com, but contacting > nstld at verisign-grs.com would certainly not solve the problem. This example is not about reverse domains. As said before, there are still plenty of contacts to be found in the 'inetnum:' object in the RIPE database and additional contact information could be added if people wish so. > > I think the focus should be on the people who use the interface: we > > need to choose the most simple and easy way for the user to get the > > job done. The goal is not to make a complicated interface and declare > > victory because we have reached data consistency! > > It's not getting more complicated. You already have to submit a > domain object to get a reverse delegation. In fact it's getting > easyer since you don't have to remember that this object has go to > auto-inaddr at ripe.net. It's an ripe database object, so > auto-dbm at ripe.net seems to be the natural choice. I agree. I think overall it is preferrable to use the 'auto-dbm at ripe.net' interface. But I do think that the process would work a lot better if we used 'rev-srv:' attributes instead of 'domain:' objects. At the same time, I think it is good to mention and study some other alternatives in order to get a better understanding of the problem that needs to be solved. > > Should the deletion fail since 3-10.193.in-addr.arpa is actually many > > different objects and one of them is not the same anymore so in fact > > there is really two sets of different objects ?!? > > Try again, this time with inetnums and rev-srv. What's the meaning of > rev-srv on a /20 followed by a more specific /24 followed by the less > specific /20? The problem space is exactly the same. No, the drawback that I was talking about was an example of how rewriting of user data is eventually going to cause confusion because it is not clear anymore whether the 'range' notation object that the user submitted is the real object or the objects that eventually get written in the database. You talk about another drawback with objects lower in the tree that get ignored and are confusing to the user. I actually already mentioned that drawback in my previous mail and it is indeed the same for 'rev-srv:' or 'domain:' based solutions but non-existant for solutions that don't use the RIPE database. Some more intelligence in the database software could probably help here too. Thanks for your comments - I do think this discussion helps people to better understand the disadvantages and advantages of the different approaches. David K. --- From postmaster at godhead.ru Tue Oct 14 10:07:53 2003 From: postmaster at godhead.ru (postmaster) Date: Tue, 14 Oct 2003 12:07:53 +0400 Subject: [ncc-services-wg] Billing scheme Message-ID: <002f01c3922a$47e6dde0$5802a8c0@cit.co.ru> 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) From jochem at ripe.net Wed Oct 15 10:52:04 2003 From: jochem at ripe.net (Jochem de Ruig) Date: Wed, 15 Oct 2003 10:52:04 +0200 Subject: Fwd: RE: [ncc-services-wg] Billing scheme Message-ID: <5.2.1.1.2.20031015104348.0466ae48@mailhost.ripe.net> Dear all, For all financial issues you can contact billing at 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) From contact at ripe.net Mon Oct 20 17:12:47 2003 From: contact at ripe.net (Membership Liason Officer) Date: Mon, 20 Oct 2003 17:12:47 +0200 Subject: [ncc-services-wg] RIPE NCC Dubai Meeting, Dec. 2003 - Reminder: Hotel Reservations Message-ID: <20031020171247.4dac9312.contact@ripe.net> 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.html 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: . Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC From peter.galbavy at knowtion.net Thu Oct 23 16:05:19 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 23 Oct 2003 15:05:19 +0100 Subject: [ncc-services-wg] Spammers using RIPE DB again ? Message-ID: <011a01c3996e$b19b1990$2f28a8c0@cblan.mblox.com> I got a couple of these today, to hostmaster at knowledge.com and hostmaster at 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: Envelope-to: hostmaster at 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 at 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 at 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 at 488ap9c> From: "Dot EU" Reply-To: "Dot EU" To: hostmaster at 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-- From leo at ripe.net Thu Oct 23 16:20:15 2003 From: leo at ripe.net (leo vegoda) Date: Thu, 23 Oct 2003 09:20:15 -0500 Subject: [ncc-services-wg] Spammers using RIPE DB again ? In-Reply-To: <011a01c3996e$b19b1990$2f28a8c0@cblan.mblox.com> References: <011a01c3996e$b19b1990$2f28a8c0@cblan.mblox.com> Message-ID: Hi Peter, Peter Galbavy wrote: >I got a couple of these today, to hostmaster at knowledge.com and >hostmaster at 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 ? Both addresses appear in your domain registration records for those domains. Regards, -- leo vegoda RIPE NCC Registration Services Manager From peter.galbavy at knowtion.net Thu Oct 23 17:47:43 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 23 Oct 2003 16:47:43 +0100 Subject: [ncc-services-wg] Spammers using RIPE DB again ? References: <011a01c3996e$b19b1990$2f28a8c0@cblan.mblox.com> Message-ID: <017c01c3997c$ffb78ec0$2f28a8c0@cblan.mblox.com> leo vegoda wrote: > Both addresses appear in your domain registration records for those > domains. Good point, I was not actually aware that the knowledge.com domain had it's own domain in it. Too later now. All my domain crap should be knowtion.net only... The main reason I thought RIPE DB was that they appear to be targetting .eu potentials :-( Peter From denesh at cyberstrider.net Thu Oct 23 17:45:31 2003 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Thu, 23 Oct 2003 16:45:31 +0100 Subject: [ncc-services-wg] Spammers using RIPE DB again ? In-Reply-To: <011a01c3996e$b19b1990$2f28a8c0@cblan.mblox.com> References: <011a01c3996e$b19b1990$2f28a8c0@cblan.mblox.com> Message-ID: <130480000.1066923931@dhcppc1> --On Thursday, October 23, 2003 15:05:19 +0100 Peter Galbavy wrote: > I got a couple of these today, to hostmaster at knowledge.com and > hostmaster at 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 ? Cambridgeshire police maybe? He has been arrested a few times in the past few weeks. The guy who runs the domain registering company, given as the link in the body of the message has already been arrested a few times by the police. He is a known spammer (also a known scammer in the words of the police) and various other things. I have been complaining about him to Trading Standards for about 2.5 years now, in conjunction with another guy, whose web site will give you more details - www.ninet.co.uk Generally, the 'from' addresses are not the spammers.. Peter Francis-Mcrae (the spammer) is the one responsible and he is basically using the domain names of those people who have complained against him, or he does not like. Anyway - www.ninet.co.uk will gove you some info.. and just typing in things like 'francis-macrae' into google will brin up loads of information. Regards Denesh > -- > Peter > > > Return-path: > Envelope-to: hostmaster at 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 at 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 at 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 at 488ap9c> > From: "Dot EU" > Reply-To: "Dot EU" > To: hostmaster at 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-- > From kurtis at kurtis.pp.se Thu Oct 23 18:38:32 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 23 Oct 2003 18:38:32 +0200 Subject: [ncc-services-wg] Spammers using RIPE DB again ? In-Reply-To: <011a01c3996e$b19b1990$2f28a8c0@cblan.mblox.com> Message-ID: <56E990BC-0577-11D8-948D-000A9598A184@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, okt 23, 2003, at 16:05 Europe/Stockholm, Peter Galbavy wrote: > I got a couple of these today, to hostmaster at knowledge.com and > hostmaster at 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 ? From dig on your domains : knowledge.com. 4H IN SOA ns-0.registry.knowtion.net. hostmaster.knowtion.net. ( 2001090802 ; serial 1H ; refresh 30M ; retry 1W ; expiry 4H ) ; minimum - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5gECqarNKXTPFCVEQL9AQCgnOKBNqVHJqj+ihzwgX63M1+Vy00AoJ5G R/EpGwLNzKeEzOsuoYvsm4uJ =yTWJ -----END PGP SIGNATURE----- From contact at ripe.net Wed Oct 29 15:37:45 2003 From: contact at ripe.net (Membership Liason Officer) Date: Wed, 29 Oct 2003 15:37:45 +0100 Subject: [ncc-services-wg] RIPE NCC Dubai Meeting, Dec. 2003 - Updated Agenda Message-ID: <20031029153745.488620e0.contact@ripe.net> [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: . 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.html 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: . Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC