January 2004 - dns-wg - mailman.ripe.net

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

Draft Agenda DN*
by Jaap Akkerhuis 15 Jan '04

15 Jan '04

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 $

3 3

Erroneous Domain Cleanup Messages
by Olaf Kolkman 13 Jan '04

13 Jan '04

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

1 0

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

06 Jan '04

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

1 0