From ripe-dbm at ripe.net Tue Jan 6 15:59:23 2004 From: ripe-dbm at ripe.net (RIPE Database Manager) Date: Tue, 6 Jan 2004 15:59:23 +0100 Subject: [dns-wg] Domail Clean-up Message-ID: <200401061459.i06ExNWI032022@x61.ripe.net> Dear Colleagues, As of 6 January, 2004, messages concerning inconsistencies between "nserver:" attributes in DOMAIN objects and delegation NS RRs in our zone files will be sent out. The messages will be mailed to various contact addresses for the relevant DOMAIN objects. In addition to the description of the inconsistencies, an indication of the 'default actions' will also be provided. We kindly request data be updated so that the inconsistencies are corrected before 1 March, 2004. About two weeks before 1 March, 2004 we will send a second set of warnings for the remaining inconsistencies. By 1 March, 2004 all remaining inconsistencies will be cleaned by the RIPE NCC, using the 'default actions'. If you receive a warning about inconsistencies we recommend that you fix the data yourself. It may be that you receive multiple mails for multiple domains with multiple inconsistencies. If you want to configure a dedicated mail filter the messages will contain the subject header "Subject: Reverse DNS inconsistencies in the RIPE Database" and originate "From: ". If you have further questions please contact . Background The cleanup is part of the effort to streamline reverse DNS operations [1] and make it easier for network range users to manipulate related DOMAIN objects. The goal of the cleanup [2] is to streamline the contents of DOMAIN objects and zone configuration files so that we can create zone files from the Whois Database. An explanation of the various possible inconsistencies can be found at: http://www.ripe.net/reverse/rdns-project/Cleanup.html. ----- [1]: Original proposal http://www.ripe.net/reverse/proposal.html. Discussion on this proposal has taken place on the RIPE NCC Services WG mailing list and was summarized in: http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2003/msg00361.html [2]: Original cleanup proposal http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html. ----- Can Bican Software Engineering Department Olaf Kolkman New Projects Group RIPE NCC From olaf at ripe.net Tue Jan 13 20:00:29 2004 From: olaf at ripe.net (Olaf Kolkman) Date: Tue, 13 Jan 2004 20:00:29 +0100 Subject: [dns-wg] Erroneous Domain Cleanup Messages Message-ID: <200401131900.i0DJ0UMF002034@birch.ripe.net> Dear Colleagues, Apologies for duplicate mails. == Introduction We recently informed the Working Groups about the start of a cleanup of inconsistencies between data in our reverse DNS and data in the Whois Database [1]. Since Wednesday 7 January, 2004 we have been sending out warning messages. Unfortunately a number of messages were sent out in error. == The Problem Due to a bug in the script, messages have been sent to contacts for /24 DOMAIN objects that have a more specific /16 object, stating that there are no matching NS RRs in the zone files and that the DOMAIN object will be deleted. This has been done in error and these DOMAIN objects will remain unaltered. The contacts for these /24 DOMAIN objects will be sent a message shortly confirming that their objects will remain unaltered and that no further action is required on their part. == Background The Whois Database holds informational data for domains in the reverse tree. The database holds information about reverse domains corresponding to /8, /16 and /24 address space. The '/8 domain' zone files at the RIPE NCC only contain NS RRs for the delegation corresponding to the most less specific address block. If there is a /16 DOMAIN object and a number of more specific /24 DOMAIN objects in the database only a delegation will be created corresponding to the /16 DOMAIN object. In other words, if the /16 domain has been delegated one cannot delegate its children any longer. Therefore, the absence of the NS resource records corresponding to the "nserver:" attributes in the /24 DOMAIN objects is not an error. Note: for End Users it is not obvious if an NS RR is in the zone files of the RIPE NCC since ns.ripe.net is a secondary DNS server for the /16 zones. Our apologies for any confusion and extra work this may have caused. For further clarification please do not hesitate to contact . --Olaf Kolkman New Projects RIPE NCC [1]: http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00000.html Further information about the cleanup project can be found at: http://www.ripe.net/reverse/rdns-project/cleanup.html From jaap at sidn.nl Thu Jan 15 11:23:35 2004 From: jaap at sidn.nl (Jaap Akkerhuis) Date: Thu, 15 Jan 2004 11:23:35 +0100 Subject: [dns-wg] Draft Agenda DN* Message-ID: <200401151023.i0FANZrP059577@bartok.sidn.nl> Hi folks, As usual, it took more time then planned to whip up an agenda for the working group. Of course, the real agenda is always decided on at the meeting itself. But find below the current proposal. Note that the slots haven't been allocated yet over the agnda since not all the sizes of the timeslots are known (yet). Please send last minute additions, corrections, etc., to the list or the co-chairs. Have a good preperation for the RIPE meeting (reading the minutes before approving is a Good Thing(tm)) and a save trip to Amsterdam. jaap ---- Agenda: DN* Working Group Times: 27 January 16:00-17:30 29 January 09:00-10:30 29 January 11:00-12:30 [Agenda points not allogate to meeting slots yet] A. Administrative matters: - Scribe - Blue sheets - Agenda bashing - Minutes Ripe 46 (http://www.ripe.net/ripe/wg/dns/r46-minutes.html) B. To merge or not to merge Heads up for discussion at end of Agenda (Chairs). C. Status reports Centr Report (Kim Davies) [5-10 minutes] Centr Report (Kim Davies) [5-10 minutes] DNS in IETF [35 min total] provreg (Jaap [1 min]) dnsop Suzanne Woolf dnsext Suzanne Woolf enum Patrick Faltstrom sshfp Jakob Schlyter crisp Lesley/Anthony [By proxy, 5 min, Jaap or Marcos Sanz] ICANN/IANA news [10 min] AAAA records in the root, Daniel Karrenberg D. Registar/Registry News News from RIPE-NCC, Olaf Kolkman (or replacement) DISI report, securing the reverse tree Changes in RDNS News from CH, Ing Tomas Marsalek [15 min] covers: new registry model enum idn. News from PL, Andrzej Bartosiewicz [20 min] covers: idn monitoring internal systems ISO 9001 certification archiving bleseed by Polish Certification Office E. Oher news News from ISC, Joao Damas [ 20 min] covers: Bind roadmap OARG kitchen sink :-) Everything you always wanted to know about the UN but was too afraid to ask: News from WSIS. Miriam Kuhne [ ?? minutes] DNS Infrastructure Recommendation Of the Security and Stability Advisory Committee [20 min] (Doug Barton, Jaap Akkerhuis) F. Tools NSD & DNSSEC, NLnetlabs, Erik Rozendaal [5 min] Fingerprint DNS-servers, Jakob Schlyter, Roy Arends [20 min] PowerDNS, Bert Hubert, [30 min] G. Experiences DNSSEC in .NL; preliminary results (Miek Gieben, NLnetlabs) [20 min] IDN Implementations in Europe, Kim Davies [40 minutes] H. To merge or not to merge (continued) Discussion about we here we go from here with DN* I. AOB $Id: pagenda,v 1.2 2004/01/15 10:17:23 jaap Exp jaap $ From carsten at ripe.net Thu Jan 15 14:41:15 2004 From: carsten at ripe.net (Carsten Schiefner) Date: Thu, 15 Jan 2004 14:41:15 +0100 Subject: [dns-wg] Draft Agenda DN* In-Reply-To: <200401151023.i0FANZrP059577@bartok.sidn.nl> References: <200401151023.i0FANZrP059577@bartok.sidn.nl> Message-ID: <4006987B.8010107@ripe.net> Jaap, Jaap Akkerhuis wrote: > C. Status reports > > Centr Report (Kim Davies) [5-10 minutes] > > Centr Report (Kim Davies) [5-10 minutes] it's always a pleasure to listen to Kim's presentations but I guess we don't need to have it two times... :-) > D. Registar/Registry News > > [...] > > News from CH, Ing Tomas Marsalek [15 min] > covers: new registry model > enum > idn. This is likely to be news from C_Z!_, the Czech registry; see http://www.ripe.net/perl/whois?searchtext=Tomas+Marsalek Cheers, -C. From jaap at sidn.nl Thu Jan 15 14:52:23 2004 From: jaap at sidn.nl (Jaap Akkerhuis) Date: Thu, 15 Jan 2004 14:52:23 +0100 Subject: [dns-wg] Draft Agenda DN* In-Reply-To: Your message of Thu, 15 Jan 2004 14:41:15 +0100. <4006987B.8010107@ripe.net> Message-ID: <200401151352.i0FDqNrP060378@bartok.sidn.nl> Hi Carsten, > C. Status reports > > Centr Report (Kim Davies) [5-10 minutes] > > Centr Report (Kim Davies) [5-10 minutes] it's always a pleasure to listen to Kim's presentations but I guess we don't need to have it two times... :-) I noticed this two minutes after posting... > News from CH, Ing Tomas Marsalek [15 min] This is likely to be news from C_Z!_, the Czech registry; see http://www.ripe.net/perl/whois?searchtext=Tomas+Marsalek You are so right. Thanks! Folks. keep sending in those correct so I can put out a better, new, improved agenda after the weekend. jaap From sanz at denic.de Thu Jan 15 15:02:19 2004 From: sanz at denic.de (Marcos Sanz/Denic) Date: Thu, 15 Jan 2004 15:02:19 +0100 Subject: [dns-wg] Draft Agenda DN* In-Reply-To: <200401151023.i0FANZrP059577@bartok.sidn.nl> Message-ID: Jaap, > crisp Lesley/Anthony [By proxy, 5 min, Jaap or Marcos Sanz] Unfortunately I won't be able to attend to the RIPE meeting due to time constraints. So you are the only backup proxy :-) Best regards, Marcos From olaf at ripe.net Wed Jan 21 15:57:46 2004 From: olaf at ripe.net (Olaf Kolkman) Date: Wed, 21 Jan 2004 15:57:46 +0100 Subject: [dns-wg] DNS Related Policy and Procedure Proposals Message-ID: <200401211457.i0LEvkAS030175@birch.ripe.net> Dear Colleagues, Apologies for duplicate mails. Shortly after this mail we will be sending two separate mails to the DNS Working Group mailing list. We will also be posting a draft policy document (see below). These mails also have relevance to the RIPE NCC Services and Database Working Groups. The two messages and revised policy document are part of a project started in October 2003 to streamline and simplify the process of requesting and managing reverse DNS delegation for the holders of the address space allocated or assigned by the RIPE NCC. The original proposal can be found at: http://www.ripe.net/reverse/proposal.html The content of the mails are: - A proposal for the introduction of a new "mnt-domains:" attribute in INETNUM objects to authorise the creation of DOMAIN objects. This proposal also suggests making "mnt-by:" a mandatory DOMAIN object attribute. This authorisation mechanism will enable address space users to delegate the responsibility for maintaining reverse address space to third parties in a flexible manner. - An assessment of the consequences of the introduction of the "mnt-domains:" attribute and of the "mnt-by:" attribute being made mandatory. The reverse delegation policy has been revised, relaxing the terms under which reverse delegation will be serviced and providing the framework to implement the authorisation mechanism described above. The draft "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region" can be found at: http://www.ripe.net/ripe/draft-documents/reverse-draft-200401.html We would like to invite your comments on this. Please discuss these proposals on the DNS Working Group mailing list. More information can be found at: http://www.ripe.net/reverse/rdns-project/ -- Olaf Kolkman New Projects Group RIPE NCC From olaf at ripe.net Wed Jan 21 15:59:48 2004 From: olaf at ripe.net (Olaf Kolkman) Date: Wed, 21 Jan 2004 15:59:48 +0100 Subject: [dns-wg] "mnt-domains:" Attribute Proposal Message-ID: <200401211459.i0LExmAS031221@birch.ripe.net> Dear Colleagues, Following the effort to streamline reverse DNS operations [1] and make it easier for the network range users to manipulate related DOMAIN objects. We propose a new attribute, "mnt-domains:" to be added to INETNUM and INET6NUM objects. (See section A of this proposal.) In addition we propose mandatory use of the "mnt-by:" attribute in DOMAIN objects. (See section B of this proposal.) ----- A.1. The "mnt-domains:" attribute The new attribute will be used to authorise modifications to encompassed DOMAIN objects. The "mnt-domains:" attribute has the same syntax as the "mnt-lower:" attribute; the value is the maintainer name. The attribute will be optional and may have multiple values. The new template for an INETNUM object will be as follows: inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The new template for an INET6NUM object will be as follows: inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] A.2. Authorisation rules based on "mnt-domains:" The authorisation rules for creation and deletion of DOMAIN objects will be changed. Maintainers listed in the appropriate "inetnum:" or "inet6num:" attributes will be able to maintain encompassed DOMAIN objects. The authorisation algorithm is documented in the diagrams available at: - http://www.ripe.net/reverse/rdns-project/create.pdf - http://www.ripe.net/reverse/rdns-project/delete.pdf - http://www.ripe.net/reverse/rdns-project/modify.pdf Below is a textual representation of these diagrams. Please note that following the Routing Policy System Security (RPSS) authorisation rules, the authorisation mechanism will fall back to the "mnt-lower:" or "mnt-by:" attributes in the absence of "mnt-domains:" attributes. In the descriptions below "authorisation succeeds" means that the algorithm exits and that the object is created, modified or deleted. "Authorisation fails" means that the algorithm exits. The "closest matching INETNUM object" is either the INETNUM object that exactly matches the address space covered by the domain in the DOMAIN object or, if there is no exact match, the smallest less specific INETNUM object. Creation: 1. If the submitted DOMAIN object does not contain "mnt-by:" the authorisation fails (see section B of this proposal). 2. Find the closest matching INETNUM object (referred to as I). 3. If (I) has "mnt-domains:" and authentication provided matches the authentication provided in "mnt-domains:" in (I), authorisation succeeds. 4. If (I) has "mnt-domains:" and authentication provided does not match the authentication provided in "mnt-domains:" in (I), go to step 8. 5. If (I) has "mnt-lower:" and authentication provided matches the authentication provided in "mnt-lower:" in (I), authorisation succeeds. 6. If (I) has "mnt-lower:" and authentication provided does not match the authentication provided in "mnt-lower:" in (I), go to step 8. 7. If authentication provided matches the authentication provided in "mnt-by:" in (I), authorisation succeeds. 8. Find the DOMAIN object that is one level less specific (referred to as D). If there is no such object authorisation fails. 9. If (D) contains "mnt-lower:" and matches the authentication provided, authorisation succeeds. 10. If (D) contains "mnt-by:" and matches the authentication provided, authorisation succeeds. 11. Authorisation fails. Modification: 1. If the submitted DOMAIN object does not contain "mnt-by:" the authorisation fails (see section B of this proposal). 2. Find the DOMAIN object currently in the database (D) that is to be modified. 3. If (D) does not contain "mnt-by:" (see section B of this proposal) 3.a. If the update is authorised using authentication provided in the "mnt-by:" attribute of the submitted object, the authorisation succeeds. 3.b. Otherwise the update fails. 4. If (D) contains "mnt-by:" and matches the authentication provided, authorisation succeeds. 5. Authorisation fails. Deletion: 1. Find the DOMAIN object (D) that is to be deleted. 2. If (D) contains "mnt-by:" and matches the authentication provided, authorisation succeeds. 3. If (D) does not contain "mnt-by:" the authentication succeeds. (see section B of this proposal). 4. Find the INETNUM object (I) that is the closest match. 5. If (I) contains "mnt-domains:" and matches the authentication provided, authorisation succeeds. 6. If (I) contains "mnt-lower:" and matches the authentication provided, authorisation succeeds. 7. If (I) contains "mnt-by:" and matches the authentication provided, authorisation succeeds. 8. Authorisation fails. A.3. Inverse queries against "mnt-domains:" attributes In addition to the new authorisation algorithm for DOMAIN objects we propose the possibility of searching for INETNUM objects that have the given maintainers in their "mnt-domains:" attributes. The inverse query flag will be '-i md', with the alternative form of '-i mnt-domains', accepting a maintainer name as the lookup key. This will return all objects whose "mnt-domains:" attributes match the query argument. An example INETNUM object with "mnt-domains:" attribute will be as follows: inetnum: 192.168.28.0 - 192.168.28.255 netname: EXAMPLE-BLK descr: An example IPv4 address space country: EU # Country is really world wide admin-c: NONE-RIPE tech-c: NONE-RIPE status: ALLOCATED UNSPECIFIED mnt-by: EXAMPLE-MNT mnt-domains: EXAMPLE2-MNT changed: ripe-dbm at ripe.net 20031121 source: RIPE ----- B. Mandatory use of the "mnt-by:" attribute in DOMAIN objects As part of streamlining the reverse DNS delegations it has become evident that the authorisation mechanism for modifying DOMAIN objects needs to be strengthened. Currently it is possible to have DOMAIN objects without "mnt-by:" attributes. This means that the objects are not protected against unauthorised changes. If the changes are submitted via the proper interface they are reflected in the DNS. A mandatory "mnt-by:" attribute will enforce conscious decisions on who is allowed to maintain a domain, enforce a conscious choice of the authorisation mechanism and will reduce the chances of misconfiguration of the authorisation mechanism. The attribute is only mandatory for DOMAIN objects that are created or modified. DOMAIN objects without "mnt-by:" attributes that currently exist in the Whois Database remain unaltered. The authorisation mechanism will treat DOMAIN objects that do not have a "mnt-by:" attribute as unprotected; anybody will be able to delete or update the object. Note that during an update of an object without a "mnt-by:" attribute, a new "mnt-by" attribute must be added. The only restriction imposed on unprotected objects is that the update needs to be authorised by the maintainer referenced from the newly added "mnt-by:" attribute. For objects that already have a "mnt-by:" attribute the authorisation is based only on the maintainer referenced in the "mnt-by:" attribute of the 'old' object. This is how the authorisation currently works. ----- Closing remarks Timeline: We plan to introduce the changes in the authorisation mechanism only after we have concluded cleanup of inconsistencies [1]. The tentative milestone for the cleanup to be finished is 1 March 2004. The implementation is planned for the beginning of April 2004. Any changes to the authorisation mechanism will be announced at least two weeks in advance. In an accompanying message entitled "Consequences of DOMAIN Object Authorisation Changes" we analyze the possible operational impact of the authorisation mechanism proposed here. [1]: Links to the original proposal and related sub-projects can be found at http://www.ripe.net/reverse/rdns-project/ We look forward to your suggestions and comments. Best Regards, -- Can Bican Software Engineering Department Olaf Kolkman New Projects Group RIPE NCC From olaf at ripe.net Wed Jan 21 16:00:49 2004 From: olaf at ripe.net (Olaf Kolkman) Date: Wed, 21 Jan 2004 16:00:49 +0100 Subject: [dns-wg] Consequences of DOMAIN Object Authorisation Changes Message-ID: <200401211500.i0LF0nAS031823@birch.ripe.net> Dear Colleagues, The RIPE NCC has proposed a number of changes to the authorisation mechanism for the creation of DOMAIN objects. (References to this project and related projects can be found at: http://www.ripe.net/reverse/rdns-project/) One of our requirements in designing the authorisation mechanism is that it is backwards compatible. However, we have identified at least one scenario where this is not the case. In section 1 below we document that scenario, give an estimate of its severity and of the operational impact for Local Internet Registries (LIRs). In section 2 we document the possible operational impact of the introduction of a mandatory "mnt-by:" attribute for DOMAIN objects. In section 3 we document the "mnt-domains:" attribute based authorisation for PI space. Please send any comments on these or other operational impacts of the proposed DOMAIN object authorisation change to the author or the DNS Working Group mailing list. In this text 'INETNUM object' is used to indicate network objects and to represent both IPv4 INETNUM and IPv6 INET6NUM objects. Section 1: Blocking through more specific inetnums In this section DOMAIN objects refer to DOMAIN objects that represent names in the reverse address name space. Currently the authorisation for the creation or deletion of DOMAIN objects is based on the request being filed by an LIR that made an assignment for the relevant address space. Example: An LIR has been allocated a /19, a /22 has been assigned to a customer. Both the /19 and /22 are represented by INETNUM objects in the Whois Database. Currently the LIR can request reverse delegation for the 4 reverse domains that live under the assigned /22. The authorisation is only based on the RegID in the request, and some heuristic checks. Currently the maintainer attributes in both the INETNUM objects are irrelevant in the authorisation. In the new proposal this will change. The authorisation will be based on the "mnt-domains:" attribute in the smallest less specific INETNUM object. If the "mnt-domains:" attribute does not exist, the authorisation will 'cascade' from "mnt-lower:" to the "mnt-by:" attributes. This may lead to the "mnt-by:" attribute on the smallest less specific inetnum preventing an LIR from creating a delegation, which is backwards incompatible. Example: Using the same situation as above. Consider the INETNUM object for a /19 allocation has a "mnt-by:" attribute containing Maintainer A and a "mnt-lower:" attribute containing Maintainer B. There also exists a /22 that is assigned out of the /19. The INETNUM object for that assignment only contains a "mnt-by:" attribute with Maintainer B. The LIR will now only be able to create a DOMAIN object for a /24 space under the /22 if they have access to Maintainer B credentials. We have tried to assess how often an LIR uses different maintainers for the allocations, assignments and related DOMAIN objects. Our estimate (see appendix) is that in 15% of the cases there are differences. Our explanation for a large number of cases where the maintainers differ is that the LIR has delegated the responsibility to maintain address space and relevant reverse space to their customers. In those cases the LIR will not be able to create or delete DOMAIN objects themselves but their customers will be able to. When problems are experienced there is a possible work around. If there is a need for the LIRs to maintain the reverse space for the /22 in the example above, the customer could add a "mnt-domains:" attribute containing both Maintainer A and B. This would, off course, involve customer co-operation. Section 2: Making "mnt-by:" a mandatory attribute in DOMAIN objects This change has been proposed to raise the overall security of the Whois Database. Since the database will be used as an authoritative source for the creation of zone files it is important that users consciously add maintainers to their objects, thereby making the choice about the level of authorisation they want to use to protect their objects. The operational impact of this is that users will have to adapt their processes and/or software to add "mnt-by:" attributes and make sure that, when created or modified, the objects are submitted with the credentials that belong to the maintainer referenced in the "mnt-by:" attribute. Having a proper maintainer with sufficient protection will protect users from "object theft", which would, in the future setup, translate to "DNS delegation theft". Note that people who do not have a "mnt-by:" attribute on their DOMAIN object will be able to change or delete the object. However, when the object is changed a "mnt-by:" attribute will have to be added. Section 3: "mnt-domains:" based authorisation and PI space The logic of the authorisation mechanism means that, in the absence of a "mnt-domains:" attribute, the creation of a delegation is blocked by the "mnt-lower: RIPE-NCC-HM-PI-MNT" attribute. In order to be able to request reverse delegation space without further human intervention, the users of PI space now have to add a "mnt-domains:" attribute to their INETNUM objects. The majority of INETNUM objects that represent PI space assigned after 1997 contain a "mnt-by:" attribute that points to a maintainer associated with the address space user. For users of PI space that do not have such a "mnt-by:" attribute the situation is more problematic. They will have to contact an LIR to request the addition of the "mnt-by:" and "mnt-domains:" attributes. The details of that procedure are out of the scope of this document. Appendix: Estimate of different maintainers The sample scanned was 10% of the size of the total number of objects in the RIPE Database. From the sample we deduce that out of all INETNUM objects ~15% have a "mnt-lower:" attribute that is different to the "mnt-by:" attribute in one of its child INETNUM objects. These objects are maintained by ~8% of the maintainers that currently exist in the RIPE Database. --------------- Olaf Kolkman New Projects Group Can Bican Software Engineering Department RIPE NCC From slz at baycix.de Thu Jan 22 02:47:02 2004 From: slz at baycix.de (Sascha Lenz) Date: Thu, 22 Jan 2004 02:47:02 +0100 Subject: [dns-wg] Re: [ncc-services-wg] DNS Related Policy and Procedure Proposals In-Reply-To: <200401211457.i0LEvkAS030175@birch.ripe.net> References: <200401211457.i0LEvkAS030175@birch.ripe.net> Message-ID: <400F2B96.6040502@baycix.de> Hay, [I didn't remove ncc-services-wg and db-wg lists since it's also a policy and db-issue] Olaf Kolkman wrote: [...] > The reverse delegation policy has been revised, relaxing the terms > under which reverse delegation will be serviced and providing the > framework to implement the authorisation mechanism described > above. > > The draft "Policy for Reverse Address Delegation of IPv4 and IPv6 > Address Space in the RIPE NCC Service Region" can be found at: > > http://www.ripe.net/ripe/draft-documents/reverse-draft-200401.html > > We would like to invite your comments on this. Please discuss these > proposals on the DNS Working Group mailing list. [...] AFAIR there was no objection to this proposal as long as it comes to relaxing the policy itself. I think we could implement the new draft ASAP. It's short and easy and was updated to IPv6 - all we need. The best part in my eyes is, that with the new policy and the new authorisation system (mnt-domains ect.), every address space holder can again request/update their rDNS delegations on their own (given the correct db authorisation) - as long as they know what they do. (At least I think that's intentionally, since all the parts relating to only LIRs can hand in requests have been removed :-) ) And a personal sidenote: I always kinda liked the current policy, allowing reverse delegation on a /24 block only if there's at least one valid assignment in it. Even though one usually shouldn't route a net without a valid assignment, i merged several LIRs throughout the last years, and I _always_ discovered some routed but not assigned networks. In almost all cases it was hard to get the customer to hand in a correct request for nets he's already been using for a while. The best was to tell the customer, they can't get rDNS until they have a valid Assignment and point to the policy - that often helped, unless they didn't care about rDNS at all. Though, this is rather a social problem of unwilling customers and lazy LIRs. So I do support the relaxed policy. Just saying that in my case the current policy rather helped some times than causing problems due to the restrictions. But i see the advantages of the new draft in general. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From uhlar at fantomas.sk Thu Jan 22 12:46:07 2004 From: uhlar at fantomas.sk (Matus UHLAR - fantomas) Date: Thu, 22 Jan 2004 12:46:07 +0100 Subject: [dns-wg] Re: [db-wg] Re: [ncc-services-wg] DNS Related Policy and Procedure Proposals In-Reply-To: <400F2B96.6040502@baycix.de> References: <200401211457.i0LEvkAS030175@birch.ripe.net> <400F2B96.6040502@baycix.de> Message-ID: <20040122114607.GA22240@fantomas.sk> Hello, On 22.01 02:47, Sascha Lenz wrote: > [I didn't remove ncc-services-wg and db-wg lists since it's also a > policy and db-issue] > > Olaf Kolkman wrote: > > [...] > >The reverse delegation policy has been revised, relaxing the terms > >under which reverse delegation will be serviced and providing the > >framework to implement the authorisation mechanism described > >above. > > > >The draft "Policy for Reverse Address Delegation of IPv4 and IPv6 > >Address Space in the RIPE NCC Service Region" can be found at: > > > >http://www.ripe.net/ripe/draft-documents/reverse-draft-200401.html > > > >We would like to invite your comments on this. Please discuss these > >proposals on the DNS Working Group mailing list. > [...] > > AFAIR there was no objection to this proposal as long as it comes to > relaxing the policy itself. > I think we could implement the new draft ASAP. I agree, that should run already ;-) > The best part in my eyes is, that with the new policy and the new > authorisation system (mnt-domains ect.), every address space holder can > again request/update their rDNS delegations on their own (given the > correct db authorisation) - as long as they know what they do. > (At least I think that's intentionally, since all the parts relating to > only LIRs can hand in requests have been removed :-) ) I only have one question - do I need to use mntner object for reverse delegation? If so, couldn't that be just left on persons/roles? So we (DNS team) wouldn't need two objects to delegate DNS for our address space. -- Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I just got lost in thought. It was unfamiliar territory. From jaap at sidn.nl Wed Jan 28 17:32:24 2004 From: jaap at sidn.nl (Jaap Akkerhuis) Date: Wed, 28 Jan 2004 17:32:24 +0100 Subject: [dns-wg] Agenda Tuesday Message-ID: <200401281632.i0SGWOrP045566@bartok.sidn.nl> For all around at the current Ripe meeting. This is the current time plan for the two last slots for the dns-wg meetimng. jaap Second Slot: 29 January 09:00-10:30 News from CZ, Ing Tomas Marsalek [15 min] covers: new registry model enum idn. News from PL, Andrzej Bartosiewicz [20 min] covers: idn monitoring internal systems ISO 9001 certification archiving blessed by Polish Certification Office (www.DNS.pl/ENUM/ripe47_dns_pl.pdf) E. Oher news News from ISC, Joao Damas [ 20 min] covers: Bind roadmap OARC DNS SEC LC Workshop [Joao 10 min] F. Tools Fingerprint DNS-servers, Jakob Schlyter, Roy Arends [20 min] Third Slot: 29 January 11:00-12:30 NSD & DNSSEC, NLnetlabs, Erik Rozendaal [5 min] PowerDNS, Bert Hubert, [30 min] G. Experiences DNSSEC in .NL; preliminary results (Miek Gieben, NLnetlabs) [20 min] IDN Implementations in Europe, Kim Davies [40 minutes] H. To merge or not to merge (continued) Discussion about where we go from here with DN* I. AOB $Id: pagenda,v 1.3 2004/01/19 14:01:43 jaap Exp jaap $ From andrei at ripe.net Thu Jan 29 14:23:43 2004 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 29 Jan 2004 14:23:43 +0100 Subject: [dns-wg] 6to4 reverse delegation Message-ID: <4019095F.2080104@ripe.net> Colleagues, This is just a heads-up that an Internet draft has been published by Geoff Huston (draft-huston-6to4-reverse-dns-00.txt). It describes a pragmatic solution for managing reverse delegation for 6to4 networks (2002::/16). The intent of circulating the proposed methodology for implementation of the service is to ensure that there is some level of peer review in order to provide some additional assurance that there is nothing critical that is missing from the proposed specification. Regards, Andrei Robachevsky RIPE NCC