From brettcarr at ripe.net Mon Mar 5 11:00:10 2007 From: brettcarr at ripe.net (Brett Carr) Date: Mon, 5 Mar 2007 11:00:10 +0100 Subject: [dns-wg] Maintenance on ns-pri.ripe.net Message-ID: [Apologies for duplicates] Dear Colleagues, On 7 March, 2007, authoritative Reverse DNS Services on ns- pri.ripe.net will be unavailable between 20:00 and 21:00 UTC. During this maintenance window, the server will be upgraded to NSD version 3.0.4. We apologise for any inconvenience this causes. If you have any questions or concerns about this, please e-mail: dns- help at ripe.net -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam From leo.vegoda at icann.org Thu Mar 8 10:10:24 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 8 Mar 2007 10:10:24 +0100 Subject: [dns-wg] ICANN Successfully Conducts Laboratory Tests of Internationalised Domain Names Message-ID: Hi, Anyone interested in the deployment of IDNs might be interested yesterday's announcement of the successful conclusion of laboratory tests of internationalised TLDs in a setting corresponding to the public root. The announcement, details of the test setup and results can be found at: http://www.icann.org/announcements/announcement-4-07mar07.htm Regards, -- Leo Vegoda IANA Numbers Liaison From brettcarr at ripe.net Thu Mar 15 12:11:29 2007 From: brettcarr at ripe.net (Brett Carr) Date: Thu, 15 Mar 2007 12:11:29 +0100 Subject: [dns-wg] Maintenance on ns-tld.ripe.net Message-ID: <3CEEA8B6-A014-446A-86E0-F08B5C671EBE@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, On Wednesday, 21 March 2007, the authoritative DNS Services on the ns-tld.ripe.net server will be unavailable between 20:00 and 21:00 UTC. This will affect all ccTLD nameservers contained within the server including all servers named in the format 'ns-ccTLD.ripe.net'. During this time we will carry out essential maintenance work. We apologise in advance for any inconvenience that this may cause. If you have any questions or concerns about this, send an e-mail to dns-help at ripe.net. Regards, Brett Carr DNS Services Group Manager RIPE NCC From brettcarr at ripe.net Tue Mar 20 10:22:39 2007 From: brettcarr at ripe.net (Brett Carr) Date: Tue, 20 Mar 2007 10:22:39 +0100 Subject: [dns-wg] RIPE NCC KSK Rollover Announcment Message-ID: An embedded and charset-unspecified text was scrubbed... Name: keyrollmsg.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: keyrollmsg.sig Type: application/octet-stream Size: 206 bytes Desc: not available URL: -------------- next part -------------- -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam From jim at rfc1035.com Sat Mar 24 09:57:33 2007 From: jim at rfc1035.com (Jim Reid) Date: Sat, 24 Mar 2007 08:57:33 +0000 Subject: [dns-wg] Agenda Items for RIPE54 Message-ID: <94C13259-C2BD-41FA-B167-764C0CCBF998@rfc1035.com> It's time to invite the WG to make suggestions for agenda items and discussion topics for next month's RIPE meeting. Please let the WG co-chairs know if you have suggestions for the agenda in Tallin. From pk at DENIC.DE Sat Mar 31 22:32:46 2007 From: pk at DENIC.DE (Peter Koch) Date: Sat, 31 Mar 2007 22:32:46 +0200 Subject: [dns-wg] use of "rev-srv" attribute in "inetnum" (and "inet6num") objects Message-ID: <20070331203246.GB970@denics7.denic.de> Dear colleagues, rather recently I was involved in clearing up some old inetnum assignments in the RIPE database. During that archaeologic work a couple of objects with the "rev-srv" attribute were discovered and it turned out that the presence of this attribute not necessarily contributed to an easy solution. The rev-srv attribute was intended to specify the name servers for the "reverse mapping" for a given address range. However, it is just informative in nature. For quite some time now the automatic generation of the IN-ADDR.ARPA zones has been based solely on the "domain" objects (see ). So, it turns out "rev-srv" has some disadvantages: (D1) the "rev-srv" attribute is redundant, because only "domain" objects cause delegations to be present in reverse zone maintained by the NCC (D2) "rev-srv" lacks consistency checks with both the reality and any potential "domain" object; several attributes just contain incorrect information (D3) the "rev-srv" attribute does not really help finding the zone for address ranges smaller than /24 (where delegations are following RFC 2317) On the other hand, it might still have advantages: (A1) where there is a delegation from an NCC maintained zone to an LIR for, say, a /16 address range, the "rev-srv" attribute for enclosed /24s may provide useful additional information (A2) even if the leaf zone name cannot be guessed for RFC 2317 delegations, the "rev-srv" attribute might help in locating the zone containing the CNAME RRs (A3) "rev-srv" attributes could provide additional information in legacy class B space (D1), (D2), and (A1) similarly apply to v6 reverse and inet6num objects. Today, approximately 5% of all "inetnum" objects have at least one "rev-srv" attribute. Of these objects, 17% have been changed in 2007 (which does not imply the rev-srv was changed or checked), and 35% were changed in 2006 or 2007. That means "rev-srv" does not only appear in old objects, but may still be carried as a legacy. The objects with "rev-srv" are maintained by 1300 different maintainers, almost 500 of which own only a single object with "rev-srv". Given the confusion mentioned in the introduction and looking at the pros and cons (where the lists above are not meant to be exhaustive), what is the use of "rev-srv" for a "user" of the object or for its publisher/maintainer? The DB WG chairs' advice was that the purpose and/or future of "rev-srv" should be discussed here first. That said, what do you think about deprecating the "rev-srv" attribute? -Peter (speaking as $self) From slz at baycix.de Sat Mar 31 22:53:10 2007 From: slz at baycix.de (Sascha Lenz) Date: Sat, 31 Mar 2007 22:53:10 +0200 Subject: [dns-wg] use of "rev-srv" attribute in "inetnum" (and "inet6num") objects In-Reply-To: <20070331203246.GB970@denics7.denic.de> References: <20070331203246.GB970@denics7.denic.de> Message-ID: <460ECA36.5030700@baycix.de> Hi, Peter Koch schrieb: [...] > The DB WG chairs' advice was that the purpose and/or future of "rev-srv" > should be discussed here first. That said, what do you think about > deprecating the "rev-srv" attribute? i actually see no real sense in it anymore either, and some people seem to use rev-srv even in NEW objects. So my opinion on this is rather to remove it the sooner the better - as long as it _really_ doesn't serv any purpose anymore. Since i'm not really "interested" in the database that much (i just "use" it - i'm no database person :-), i'm not 100% sure that there is no hidden sense in keeping this attribute. My thoughts on that always was "there surely must be some reason that it is still there". If not, dump it. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================