From mansaxel at kthnoc.net Sun Apr 1 10:57:56 2007 From: mansaxel at kthnoc.net (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Sun, 01 Apr 2007 10:57:56 +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: <84B151392DB9862455E44C98@rasmus.kthnoc.net> --On l?rdag, l?rdag 31 mar 2007 22.32.46 +0200 Peter Koch wrote: > 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) The worst part here probably is ambiguity. > 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 MAY, yes, but not "will". DNS is probably better maintained (not that it is good, but probably better.) > (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 dig +trace is your friend. > (A3) "rev-srv" attributes could provide additional information in legacy > class B space This is A1 again. I think the objects can be disregarded, if not outright discarded. -- M?ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE INSIDE, I have the same personality disorder as LUCY RICARDO!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From leo.vegoda at icann.org Sun Apr 1 16:37:56 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sun, 1 Apr 2007 15:37:56 +0100 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: <49C71917-E24D-4F74-A19D-315975A97B01@icann.org> On Mar 31, 2007, at 9:32 PM, Peter Koch wrote: [...] > 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". Do you know what percentage of rev-srv records are fully or partially accurate? Regards, -- Leo Vegoda IANA Numbers Liaison From Piotr.Strzyzewski at polsl.pl Sun Apr 1 21:08:31 2007 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Sun, 1 Apr 2007 21:08:31 +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: <20070401190831.GC23318@hydra.ck.polsl.pl> On Sat, Mar 31, 2007 at 10:32:46PM +0200, Peter Koch wrote: Hi, > 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? In my personal opinion it is useless nowadays. I believe it should be removed. Regards, Piotr Strzy?ewski -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From brettcarr at ripe.net Mon Apr 2 09:17:37 2007 From: brettcarr at ripe.net (Brett Carr) Date: Mon, 2 Apr 2007 09:17:37 +0200 Subject: [dns-wg] Maintenance on ns-sec.ripe.net Message-ID: [Apologies for duplicates] Dear Colleagues, On 4 April, 2007, authoritative Reverse DNS Services on ns- sec.ripe.net will be unavailable between 19:00 and 20:00 UTC. During this time we need to carry out maintenance work. 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 Niall.oReilly at ucd.ie Mon Apr 2 11:06:20 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 02 Apr 2007 10:06:20 +0100 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: <3140A986-D4B6-427E-BE26-E949A327C921@ucd.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31 Mar 2007, at 21:32, Peter Koch wrote: > That said, what do you think about deprecating the "rev-srv" > attribute? Deprecate! /Niall -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFGEMeReYfkja6ZXtkRAl8jAJ0TWP6X1UDaoyDMhB5bfnjLi+NUkwCcD5tG eVSX22Sl6T6l2P1+p2wL3zs= =Rw3R -----END PGP SIGNATURE----- From andre.koopal at verizonbusiness.com Mon Apr 2 12:20:29 2007 From: andre.koopal at verizonbusiness.com (Andre Koopal) Date: Mon, 2 Apr 2007 12:20:29 +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: <20070402102028.GG17081@asoserve0.ams.ops.eu.uu.net> On Sat, Mar 31, 2007 at 10:32:46PM +0200, Peter Koch wrote: > Dear colleagues, > > 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? > Deprecate it, perhaps in 2 steps (first make sure it can't be inserted anymore, and updated objects can't have it, remove from old objects later). Regards, Andre Koopal -- Andre Koopal EMEA Server & Service Management - EMEA O&T Verizon Business H.J.E. Wenckebachweg 123 1096 AM Amsterdam Netherlands VNET: 711 6990 tel : +31 (0)20 711 6990 fax : +31 (0)20 711 2519 Verizon Business - global capability. personal accountability. This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated. Verizon Nederland B.V. - H.J.E. Wenckebachweg 123, 1096 AM, Amsterdam, the Netherlands - Commercial Register No. 34199467 From pk at DENIC.DE Mon Apr 2 17:00:08 2007 From: pk at DENIC.DE (Peter Koch) Date: Mon, 2 Apr 2007 17:00:08 +0200 Subject: [dns-wg] use of "rev-srv" attribute in "inetnum" (and "inet6num") objects In-Reply-To: <49C71917-E24D-4F74-A19D-315975A97B01@icann.org> References: <20070331203246.GB970@denics7.denic.de> <49C71917-E24D-4F74-A19D-315975A97B01@icann.org> Message-ID: <20070402150008.GB25028@denics7.denic.de> On Sun, Apr 01, 2007 at 03:37:56PM +0100, Leo Vegoda wrote: > Do you know what percentage of rev-srv records are fully or partially > accurate? I had hoped to be able to avoid this :-) Seriously, that depends on what you consider accurate - or even 'partially accurate'. Is it reality or what the domain: objects say? And is reality what the delegation says or what the authoritative NS RRSet suggests? Just one example: 1000 out of ~ 6000 name servers pointed at by rev-srv attributes didn't even resolve. Whether that's good or bad depends on what the quality of the domain: objects' nserver: attributes looks like. For a match between rev-srv: and nserver: I've tried to get hold of those address ranges greater or equal than /24, postulating /24 or /16 equivalent in-addr.arpa domains where appropriate. The calculation is very rough since /24s may be covered by /16s and sometimes there are domain: objects for both the /16 and (some of) the lower /24s as well (which is confusing in and of itself). With all caveats, out of 38000 candidate domain: objects, only about 50% were actually present. Of those, approximately 2/3 had the same idea of the NS RRSet as the inetnum: object. For those disagreeing, there might be overlaps ("partially accurate") or disjoint sets. -Peter From leo.vegoda at icann.org Mon Apr 2 17:32:16 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 2 Apr 2007 16:32:16 +0100 Subject: [dns-wg] use of "rev-srv" attribute in "inetnum" (and "inet6num") objects In-Reply-To: <20070402150008.GB25028@denics7.denic.de> References: <20070331203246.GB970@denics7.denic.de> <49C71917-E24D-4F74-A19D-315975A97B01@icann.org> <20070402150008.GB25028@denics7.denic.de> Message-ID: <7897A894-7361-4DA8-A543-DFBBECC29F1B@icann.org> On Apr 2, 2007, at 4:00 PM, Peter Koch wrote: > On Sun, Apr 01, 2007 at 03:37:56PM +0100, Leo Vegoda wrote: > >> Do you know what percentage of rev-srv records are fully or partially >> accurate? > > I had hoped to be able to avoid this :-) [analysis snipped] I must admit that I've always thought of rev-srv as misinformation rather than useful information. I think you've demonstrated that it's difficult to use and doesn't reflect reality well. Seeing as a mechanism for auto-populating rev-srv fields with accurate information is likely to open up a new world of pain, deprecating it sounds like a good way of improving the accuracy of DNS data in the RIPE database. Regards, -- Leo Vegoda IANA Numbers Liaison From markguz at ripe.net Tue Apr 3 16:00:22 2007 From: markguz at ripe.net (Mark Guz) Date: Tue, 03 Apr 2007 16:00:22 +0200 Subject: [dns-wg] RIPE NCC Network Maintenance 1700 UTC (1900 CEST) Thurday 5 April 2007 Message-ID: <46125DF6.2000208@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [apologies for duplicates] Dear Colleagues, On Thursday 05/04/2007, between 17:00 and 19:00 (UTC), the RIPE NCC will carry out planned maintenance work on our core network infrastructure. RIPE NCC services will be temporarily unavailable during this period. We apologise for any inconvenience that this may cause. This work is due to the deployment of a new section of dark fibre between two of our PoPs If you have any questions about this, please send an e-mail to: ops at ripe.net Regards Mark Guz Senior Engineer Operations Department RIPE NCC http://www.ripe.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEhqgl42z2L2N9gERAofHAKClFauaor8xhKENLD4dp5PSfN9MFQCfZhCh D1RBdhQbWlox3dtzLzLPvLE= =g9jU -----END PGP SIGNATURE----- From s.steffann at computel.nl Wed Apr 4 23:27:13 2007 From: s.steffann at computel.nl (Sander Steffann) Date: Wed, 4 Apr 2007 23:27:13 +0200 Subject: [dns-wg] use of "rev-srv" attribute in "inetnum" (and "inet6num") objects References: <20070331203246.GB970@denics7.denic.de> <49C71917-E24D-4F74-A19D-315975A97B01@icann.org> <20070402150008.GB25028@denics7.denic.de> <7897A894-7361-4DA8-A543-DFBBECC29F1B@icann.org> Message-ID: <006501c77700$02b57420$b4c8a8c0@sanderthuis> Hi, > I must admit that I've always thought of rev-srv as misinformation rather > than useful information. I think you've demonstrated that it's difficult > to use and doesn't reflect reality well. > > Seeing as a mechanism for auto-populating rev-srv fields with accurate > information is likely to open up a new world of pain, deprecating it > sounds like a good way of improving the accuracy of DNS data in the RIPE > database. Sounds to me like we should get rid of it as soon as possible. I certainly wouldn't miss it. And wrong / conflicting information in the RIPE db should be avoided (where posible). - Sander From zsako at 3c-hungary.hu Thu Apr 5 00:43:39 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 05 Apr 2007 00:43:39 +0200 Subject: [dns-wg] use of "rev-srv" attribute in "inetnum" (and "inet6num") objects References: <20070331203246.GB970@denics7.denic.de> <20070402102028.GG17081@asoserve0.ams.ops.eu.uu.net> Message-ID: <46142A1B.3000507@3c-hungary.hu> Dear all, >>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? > > Deprecate it, perhaps in 2 steps (first make sure it can't be inserted > anymore, and updated objects can't have it, remove from old objects later). Yes, I think this is a wise approach, I support it. Keeping the inetnum in sync with DNS (domain objects) seems to be a hopeless task, if not enforced by the automatic in-addr.arpa zone generation. Having only inetnum defining the reverse zones is not an alternative (due to assignment longer than /24). Hence inetnum/rev-srv is redundant. Peter originally said: >>(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 I do not think this helps. If you cannot guess the domain name (e.g. 0/25.2.0.192.in-addr.arpa), knowing that the zone is on ns.A.domain and some.other.name.server (expample on page 2 of RFC 2317) is of no help in my view. At the same time, you can easily get the domain name with a `host -a 1.0.192.in-addr.arpa` query on a recursive server. Therefore I do not think this is a valid reason for keeping rev-srv. Having outdated/erroneous data in the DB is not desirable at all. In short: I think rev-srv can be deprecated. Best regards, Janos From markguz at ripe.net Thu Apr 5 16:12:31 2007 From: markguz at ripe.net (Mark Guz) Date: Thu, 05 Apr 2007 16:12:31 +0200 Subject: [dns-wg] RIPE NCC Network Maintenance 1700 UTC (1900 CEST) Thurday 5 April 2007 Postponed In-Reply-To: <46125F03.4080103@ripe.net> References: <46125F03.4080103@ripe.net> Message-ID: <461503CF.3040204@ripe.net> Dear Colleagues, Due to the fact that the RIPE NCC will be closed tomorrow and Monday we have decided to postpone this maintenance until next Wednesday (11/04/07 ). Apologies for the inconvenience this may cause. If you have any questions please send them to ops at ripe.net Kind Regards Mark Guz Senior Engineer OPS/IT RIPE NCC Amsterdam From fw at deneb.enyo.de Fri Apr 6 12:28:35 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 06 Apr 2007 12:28:35 +0200 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <20070226095118.479512b5@spx.vb.futz.org> (Robert Story's message of "Mon, 26 Feb 2007 09:51:18 -0500") References: <87d53zwpm4.fsf@mid.deneb.enyo.de> <20070226095118.479512b5@spx.vb.futz.org> Message-ID: <87odm1iyp8.fsf@mid.deneb.enyo.de> * Robert Story: > On Sat, 24 Feb 2007 16:18:43 +0100 Florian wrote: > FW> Unfortunately, the real showstopper I see is that you cannot tell an > FW> attack from an infrastructure change that happened to break DNSSEC. > FW> But we need to provide some kind of fallback in case DNSSEC breaks > FW> because we absolutely must ensure that we match plain DNS in terms of > FW> availability. (And I don't think yet another security indicator > FW> visible to the end user is the answer.) > > Well, you've got yourself painted into a corner here. Probably true. > I don't think you can have a fallback, or you haven't added any > security. I'm concerned that I'm *reducing* security (regarding availability as a part of security). I also don't want to create a situation where organizations fear to DLV-enable their zones because a part of the client population is no longer able to access them. To some extent, this has already happened to AAAA records. Of course, this is motivated more by the categorical imperative, and not by actual market share. But you never know. 8-) > FW> Running name resolution over 443/TCP to some central resolver > FW> infrastructure suddenly seems much more attractive, doesn't it? > > Not particularly. Either way, you've got to get the ISPs to buy into a > new way of thinking about DNS. I think the idea (at least my version of it) is that you use a 443/TCP TLS connection to a resolver to bypass the ISP. The on-the-wire protocol would still be DNS with DNSSEC. The assumption is that the ISP can't do transparent rewriting of TLS connections and will leave the application traffic alone (which is no longer a safe assumption for 53/UDP or 53/TCP -- or 25/TCP for that matter). From jim at rfc1035.com Tue Apr 24 16:04:54 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 24 Apr 2007 15:04:54 +0100 Subject: [dns-wg] Agenda for RIPE54 Message-ID: <6F329005-EC9B-4297-A7C7-27FD208F3E43@rfc1035.com> Here is the agenda for the DNS WG sessions in Tallinn. This will be on the RIPE web site shortly. As always, items may be subject to last minute changes due to external circumstances. # # $Id: dnswgagenda,v 2.2 2007/04/24 14:00:20 jim Exp $ # [1] Administrivia (5 mins) [2] Review of Action Items (15 mins) [3] IETF WG news update (10 mins) Anton Verschuren, SIDN (TBC) [4] NCC Update (10 mins) Brett Carr, RIPE NCC [5] Proposal on rev-srv (10 mins) Peter Koch, DENIC [6] Finding a DNSSEC Trust Anchor (30 mins) Mats Dufberg, TeliaSonera In the absence of a signed root zone, DNS resolving risks of either being isolated (only for the local TLD) or cumbersome and error-prone (through the chasing for the latest key of all signed TLD's). It is in the interest of both ISP's and DNSsec if there would be one safe place with good reputation to get the keys from. We see RIPE NCC to be a good candidate to host such a trust anchor in co-operation with all registries of signed TLD's. Such a trust-anchor should be limited to TLD's and reverse tree. [7] Discussion time for EOF items (10 mins) Lunch Break [8] IDN progress at ICANN (5 mins) Leo Vegoda, ICANN [9] OARC News & DNS DDoS Followup (10 mins) Keith Mitchell, OARC [10] Traffic analysis the .SE way using DNS2DB. (25 mins) Niclas Rosell, NIC-SE DNS2DB is a newly developed tool for analyzing dns-data. It converts raw pcap-files with dns-traffic to Sqlite-databases which then can be used to dig into and analyze the traffic. This presentation will demonstrate this tool and show how it's used in the daily work at the cctld .se. [11] Anycast experiences in Japan (15 mins) Shinta Sato, JPRS In the presentation, the experience of the test run of the new anycast site is shown. Through the presentation, what the actual TLD operators are doing for its measurement is briefly described. [12] AOB/General Discussion (5 mins)