- dns-wg - mailman.ripe.net

Agenda Items for RIPE48
by Jim Reid 22 Mar '04

22 Mar '04

Contributions and suggestions for the DNS WG Agenda at RIPE48 are now invited. Please let dns-wg-chair(a)ripe.net know if you have a presentation or topic for discussion at the WG. It will help the planning if you do this sooner rather than later. Last time, a couple of interesting items were suggested after the Agenda had been finalised. Sigh. The closing date for input to the Agenda is likely to be around April 16th: two weeks before RIPE48.

1 0

DNS registrant details...
by reaction＠optionalreaction.net 11 Mar '04

11 Mar '04

Hello, This is my first post to this mailing list. When a person or persons register a domain name, a clear distinction should be made to exclusively identify a difference between input of credit card details and input of domain name registrant details. There are some large companies that 'automatically' use the entered credit card details, as the address of the registrant a domain name. This, as is true in my case, depending on the content of the domain names associated website(s), may lead to someone having to physical location because _they were not aware that domain registrant address details had been taken from their credit card details_. Regards, optionalreaction.net (webmaster)

3 2

FYI: Cleanup of domain objects.
by Olaf M. Kolkman 04 Mar '04

04 Mar '04

Dear Colleagues, Excuxes for the duplicate messages. During the third week of March we will perform the cleanup as described in section B of the "Domain Cleanup Proposal"[1]. Users affected by this cleanup were contacted during the first week of January 2004[2]. Once the domain object cleanup has been finished, the RIPE NCC provisioning system will be migrated to generate reverse zones from the whois database. We will proceed with that around the last week of March 2004. This change should be transparent. A small notification will be sent to the dns-wg mailing list. The next step of the RDNS project [3] will be the introduction of the "mnt-domain:" attribute. More information about this introduction will be sent to the ncc-services-wg and dns-wg mailing lists by the end of March 2004. Please reply to me in private or to the <dns-wg(a)ripe.net> mailing list if you have any questions or comments. --Olaf Kolkman New Projects RIPE NCC [1] http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html [2] The set of people contacted was larger than the set of people actually affected by the cleanup see http://www.ripe.net/ripe/mail-archives/db-wg/2004/msg00086.html for details. [3] http://www.ripe.net/reverse/rdns-project/

1 0

Drafts minutes DN* WG, RIPE 47 etc.
by Jaap Akkerhuis 19 Feb '04

19 Feb '04

Gentlefolks, Below you'll find the Draft minutes of our meetings at RIPE-47. They have been reviewed by the chairs already. Please send your comments to the list or directly to the list. Thanks to our scribes, Timur Bakeyev and Arno Meulenkamp (in alphpabetical order of last name) and the webmaster(a)ripe.net whois is Bcc'd on this so he/she can place the minutes on the ripe web site. Note that there is also an action item to work on: Formulate a charter/workingplan for the new combined group. I will try to make a rough proposal, although I wouldn't mind if somebody else would do that instead. I don't know who put the charter up at http://www.ripe.net/ripe/wg/dns/index.html and assume it is only a placeholder for the real one to come. Does anybody has an old version of the charter of as well as the DNR forum and the DNS-wg oldstyle lying around? These might be a good start for a new charter. Anyway, enjoy, jaap ---- DRAFT minutes, cut here ------ RIPE 47 Meeting DNS Working Group and DNR Forum Agenda Date: Tuesday 27 January 2004 Time: 16.00 - 17.30 Location: Grand Ballroom A. Administrative matters: - Scribe: Arno Meulenkamp - Blue sheets - Agenda bashing Jaap: (1) The talk about WSIS will be drop, because it is also on the agenda of the Plenray; will be replaced by a report over the "Last Call Workshop at Ripe NCC" about DNSSEC (2) The talk about the SSAC DNSS document will not be seperate agenda item, but will be covered during the "News from ICANN" item (3) Jakob Schlyter couldn't come. - 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). Not a lot of discussion on the mailing list, so no decision can be made currently, discussion needs to be continued. C. Status reports Centr Report (Kim Davies) [5-10 minutes] Kim Davies presented the report. Daniel Karrenberg: Freedom of information? Kim: Perhaps I should have said data protection laws provreg (Jaap [1 min]) Jaap Akkerhuis: We were waiting on the IANA XML registry. This is just recentky established, the XML RFC is published. So now the rfc-editor can continue dnsext Suzanne Woolf dnsop Suzanne Woolf Suzanne Woolf presented an overview of what happened recently in the WGs enum Patrick Faltstrom Patrick Faltstrom: the RFC has been approved, the RFC editor will look at it, it is in the queue right now Jaap: 3 documents? Patrick Faltstrom: Yes, 3 documents Jim Reid: what's the estimate before the RFC editor will look at it? Patrick Faltstrom: hard to say, we are #5 on the list. Could be up to 3 months from now. sshfp Jakob Schlyter Jakob couldn't make it crisp Lesley/Anthony [By proxy, 5 min, Jaap] They also couldn't make it, but they did send slides, which Jaap presented. ICANN/IANA news [10 min] presented by Doug Barton No slides. DNS Infrastructure Recommendation Of the Security and Stability Advisory Committee. ICANN report, which can be found here: http://icann.org/committees/security/dns-recommendation-01nov03.htm AAAA records in the root, Daniel Karrenberg There was some research to see what happens with more glue in the root, this to accomodate IPv6 addresses in the zone file. There might be a technical problem. Doug: There are concerns over changing the root zone. We're trying to work with all parties involved. Jim Reid: is there look into what might happen when AAAA records are added, because IPv6 traffic might cause other operational things Doug: this is looked at. Iljitsch van Beinum: This is looked at for tld's and root zone? Daniel: yes Daniel: what is the timeline? Doug: the RSAC recommendation (see link) needs to be formally presented to the ICANN board. And it also needs to be published publicly and we need to see what the feedback is. Suzanne Woolf: is the IANA looking at how the technical recommendation would be operationally implemented? Doug: yes, when we present the plan officially, we also want to add a recommendation. D. Registrar/Registry News News from RIPE NCC Update on dnsmon: Going beta [5 min], Daniel Karrenberg It is now Beta, still on development machines, documentation is much improved, soon completely ready. Changes in RDNS [25 min], Olaf Kolkman (or replacement) Olaf presented the project. Andre: does the mnt-domains in inetnum override the mnt-by in the domain object? Olaf: no, it only controls the creation of the object, the mnt-by in the domain object then takes care of protecting the object. Peter Koch: you said this will not save the lameness problem,why not, what are you going to do? Olaf: it is quite different thing, we're not trying to solve too many problems at the same time. We check when delegations are created, that will not change. Lameness might come later. Peter: Old domain objects could be fed through the system, do you have any number of lame delegations or other DNS problems? Olaf: not currently Jim Reid: with regard to lameness, the working group should look at this and maybe make a definition of lameness after which we can map the situation (with the help of the RIPE NCC, perhaps) Jim Reid: as chair: does this working group approve of this project, do we think we need to say something about this (as it is internal housekeeping to some extent)? Jaap Akkerhuis: time flies. Let's postpone the other registry points to the other slots. Date: Thursday 29 January 2004 Time: 09.00 - 12.30 Location: St. Johns II Chair: Jaap Akkerhuis, Jim Reid Scribe: Timur Bakeyev, RIPE NCC Thanks to our scribe. Introduction. Short description of the Tuesday session. Scribe is presented to the public. News from CZ, Ing Tomas Marsalek [15 min] covers: new registry model enum idn file:DNS/cznic.ppt A nice story about cybersquatter who claimed 10.000$ for the domain from one of the bank groups but was sued and charged for half of this sum :> No questions were asked. News from PL, Andrzej Bartosiewicz [20 min] covers: idn monitoring internal systems ISO 9001 certification archiving blessed by Polish Certification Office file:DNS/RIPE47_DNS_PL.ppt Due to the shortage of time the introduction slides were skipped. Andrzej described the process of deployment of IDN for .pl domain. The policy is: First come - first served. In first few days a peak of the interest to the IDN was noticed(1600 registrations), now the average number of new domains registrations is around 20 per week. EPP for ENUM part of the presentation was skipped; it was already presented during the enum BOF. The overview of the process of monitoring DNS servers and services was done by Slawomir Gruca. In the past they had several conflicts, then the customer claimed, that the given domain wasn't accessible at certain date/time. Since then they start to use zone signing service via SigNet.pl as a proof that domain zone did exist in the particular time in this state. Q: In the slides it's mentioned, that the 'crucial domain list' is used to monitor the possible harmful changes to the DNS. Who did compile this list? A: This is the list of the most popular domains, which was provided by the 3-d parity. It's assumed that domains from that list are the best target for frauge. The changes in nameservers layout of these domains are also verified by a human. Q: Do you provide monitoring from the end user point? A: That's in the plans of the company. Q(Bruce): What is actually tracked for the domains from the 'crucial list'? A: List is monitored by script, which checks changes in the name servers structure and delegation information. E. Other news News from ISC, Joao Damas [20 min] covers: Bind road map OARG file:DNS/dns-wg-ripe47.ppt ISC is dead! Long life ISC! ISC had changed their name from Internet Software Consortium to the Internet System Consortium. New incidental respond group is created - Operations, Analysis and Research Center(OARC). http://oarc.isc.org. F-root server in Paris, Moscow, Dubai, Beijing, Taipei, Singapore. New Bind forum(and DHCP in future). Bind will remain free! Two parallel versions were released - Bind 8.4.4 and Bind 9.2.3. Bind8 is in a maintainace phase - only security fixes. Focus is on Bind9 and improving it's performance and support of DNSSEC. Q: It is said, that F-root server in Paris is IPv6 enabled. Is this information publically available and how to get it? A: You need to ask sysadmins of their provider. Q: Is this some kind of a secret then? A: No, it just means that this setup is still considered under trial and still in development. Q: Whom should I contact then? A: Tiscali.fr. Q(humorous): Can you, please, stop releasing Bind8? Version 9 is so cool and existence of the persistently updating Bind8 keeps people from switching to version 9. A: For Bind8 only bug fixes are done. All new features are added to the Bind9. Comment(Daniel): Bind8 is buggy, that's the reason for so often releases. Also, it still outperforms Bind9. Comment(Joao): One nice feature Bind9 has - an automated update of the hints file(with the list of root servers). With the upcoming change of the IP of the B-root server tomorrow(30 Jan 2003) it makes it very neat feature(Bind8 users need eventually to download a new version of hint file by themselves). Q: Regarding IPv6 support. http://www.root-servers.org/ lists the IPv6 addresses of some of the root servers. Would it be possible to ship hints file which will include IPv6 addresses of these servers as well? A: Speaking about web page - it's a good idea. Hints file... Well, we'll see :) Comment: B-root would be available on the old address for quite reasonable amount of time(2 years). Q: For Bind8 users - the change of the B-root IP address isn't an emergency? A: Completely not, but eventually this file should be replaced. DNSSEC workshop, Joao Damas [20 min] file:DNS/lcws.ppt The workshop was done in cooperation with NLnet Labs and RIPE NCC. The goal was to check interoperability of two implementations of the DNSSEC - one is in the beta version of Bind9.4 and another in NSD2.0. The results of workshop did prove, that this two versions can interoperate, but also a lot of updates and remarks were done to the DNSSEC draft and send back to IETF. Q: How long will it take before thre is a standard? A: Workshop helped a lot to spot the issues in the current draft of the standard. It will take a while, before all of them will be fixed in the document. At minimum, 2 more months... F. Tools Fingerprint DNS-servers, Roy Arends [20 min] file:DNS/Fingerprinting DNS.ppt The goal of survey was troubleshooting, statistic information on distribution of different version of DNS software. Different versions of different name servers were run in the test environment to collect an authentic fingerprint of them. Still looking for pre BSD4.3-tahoe bind implementation. Comment(Daniel): We have contacts with people who are still own necessary hardware and software. Still, no available CISCO DNS implementation(?) Olaf's DNS calculator was mentioned as on of the amazing examples of Perl based DNS servers. Survey also helped in spotting bug in the QR bit handling of one of the DNS server implementations, which could lead to the DoS attack. Fixed! Software is available at: http://www.rfc.se/fpdns/ Note from the audience: PowerDNS is mentioned twice on the slide! Q(Jim Reid): What is the distribution of the DNS software according to the survey? A: Out of 50.000 queried servers nearly half do run Bind9, a quarter - Bind8 and most of the rest are Windows DNS. But if to count by number of zones, supported by server, then Bind8 is the winer :() NSD & DNSSEC, NLnetlabs, Erik Rozendaal [5 min] file:DNS/erik-rozendaal.tar.gz Short introduction to NDS - simple, high performing name server for authoritative zones. Q(Joao): What kind of traffic is shown on the graphs? Does it reflect real life scenario, when unreplied(dropped) queries actually create additional queries, coming from the client side, artificially increasing load? A: Have no idea... PowerDNS, Bert Hubert [30 min] file:DNS/powerdns.pdf Written in C++, multithreaded DNS server. Multiple backends. No DJB-isms :)) Had a 0x1FFFFFFF bug in the code :) Q: Is TSIG supported? A: I have it in my plans. G. Experiences DNSSEC in .NL; preliminary results (Miek Gieben, NLnetlabs) [20 min] file:DNS/miek.tgz Q: What does phrase in the slides 'automated key compromise' actually mean :)? A: The zone dropped immediately. IDN Implementations in Europe, Kim Davies [40 minutes] file:DNS/ripe47-dn-idneurope.pdf Q: End user problem: How can I type in Chinese, let's say domain name? A: Have no idea, the main application for IDN is local usage within this language speaking country/community. Q: Any plans for having IDN for TLDs? A: Not yet. Q: What browsers are already support IDN out of the box? A: Two are known at the moment - Mozilla and Opera. H. To merge or not to merge (continued) 5 minutes past the lunch break. Jim shouts: Shall we merge or not? Audience screams: YES! Everyone runs for the lunch :) Action Item: Charter for the new group. $Id: minutes,v 1.2 2004/02/19 20:31:07 jaap Exp jaap $

1 0

Fingerprinting DNS implementations.
by Roy Arends 10 Feb '04

10 Feb '04

Hi, Jakob and I spent the past few weeks hacking up a DNS implementation fingerprint tool (where implementation == anything responding to a query). This mail introduces the methodology of fingerprinting DNS implementations. A nameserver basically responds to a query. Inter-operability is an obvious requirement here, the standard protocol behaviour of different DNS implementations is expected to be the same. Protocol behaviour of a DNS implementation is widely documented in the case of a 'common' query. The DNS protocol is over 20 years old and since its inception, there have been over 40 independant DNS implementations, while some implementations have over 20 versions. The methodology used to identify individual nameserver implementations is based on "borderline" protocol behaviour. The DNS protocol offers a multitude of message bits, response types, opcodes, classes, query types and label types in a fashion that makes some mutually exclusive while some are not used in a query messages at all. Not every implementation offers the full set of features the DNS protocol set currently has. Some implementations offer features outside the protocol set, and there are implementations that do not comform to standards. Also, new features added to - or bugs removed allow for differentiations between versions of an implementation. Methodology We use a serie of "borderline" query-response messages to identify implementations. A serie of query-response messages form a sequence. We call the interpretation of these series to form a conclusion "DNS sequencing". As mentioned, responses to a "borderline" query is used in this method. To be somewhat efficient, a tree can be constructed which consists of queries (nodes) and responses (branches), where the leave nodes identify the implementation. Every path, from the root node (initial query) to a leave node (final query) is essentially a "strain". The strains are used to distinguish between, and as said, ultimatly identify implementations. Parallel to this technique it is possible to identify some brands and their versions by doing a specific query asking for the servers' version. This technique does not satisfy our requirement since this has not been implemented in all brands of nameservers (it is not part of any standard), operators may have obscured the information and there are implementations that try to resolve the query, essentially asking root-servers from a different class for their version. Implementation. Our current software is written as a proof-of-concept. In field tests, false positives were encountered when trying to identify a set of servers residing behind a load-balancing apparatus where the servers itself are of different implementations, or when a specific implementation behaves like a forwarder. We are actively looking for implementations not yet identified by this tool to complement the set of strains. The current set of strains identify the following implementations and their versions: ATLAS BIND 4 BIND 4.8 -- 4.8.3 BIND 4.9.3 -- 4.9.11 BIND 8 BIND 8.1 -- 8.2.1T4B BIND 8.2.1 BIND 8.2.2P3 -- 8.4.1 BIND 8.4.1P1 BIND 9 BIND 9.0.0b5 -- 9.0.1 BIND 9.1.0 -- 9.1.3 BIND 9.2.0a1 -- 9.2.0rc3 BIND 9.2.0rc4 -- 9.2.2P3 BIND 9.2.3rc1 -- 9.4.0a0 eNom DNS Incognito DNS Commander MARADNS Microsoft Windows Server 2003 Server 2000 Server NT4 MyDNS Nominum ANS Nominum CNS NonSequitur DNS NSD Oak DNS Pliant DNS Server Posadis PowerDNS 2.8 -- 2.9.3 2.9.4 -- 2.9.11 QuickDNS Simple DNS plus TinyDNS UltraDNS We are actively looking for volunteers who allow us to identify their running code in some form or configuration of some version of: chives custom-dns dents dnrd dnsmasq gnudip-www ibmdns jeeves lbdns lbnamed ldapdns MacDNS Microsoft Windows Server NT3.51 pdnsd Stanford::DNSserver yaku-ns and/or All other unidentified, unmentioned original code. Thanks, Roy Arends Jakob Schlyter

1 1

6to4 reverse delegation
by Andrei Robachevsky 29 Jan '04

29 Jan '04

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

1 0

Agenda Tuesday
by Jaap Akkerhuis 28 Jan '04

28 Jan '04

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 $

1 0

DNS Related Policy and Procedure Proposals
by Olaf Kolkman 22 Jan '04

22 Jan '04

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

3 2

Consequences of DOMAIN Object Authorisation Changes
by Olaf Kolkman 21 Jan '04

21 Jan '04

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

1 0

"mnt-domains:" Attribute Proposal
by Olaf Kolkman 21 Jan '04

21 Jan '04

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(a)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

1 0