From paf at cisco.com Mon Sep 1 10:05:03 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 1 Sep 2003 10:05:03 +0200 Subject: [dns-wg] Agenda for RIPE 46 (4th and final version) Message-ID: When discussing the agenda, and order of the items, items related to CENTR and registry/registrar mechanisms are taken care of _FIRST_, on the Tuesday session. The rest on Thursday. I will personally not arrive to Amsterdam until Wed evening, so Peter, Jaap and Jim will take care of the wg until thursday morning. Any suggestions on late changes I because of this redirect at them. regards, paf Agenda at RIPE 46 ----------------- Tuesday 16:00-17:30 ------------------- [0] Charter / Agenda Bashing / Goals etc 0.1 Agenda, welcome etc (15 min) Discussion: Peter Koch, Jim Reid and Jaap Akkerhuis. [2] Reports / status items (same bullets every meeting) 2.5 IDN deployment / experience 2.5.1 Experience in Poland (15 minutes) Andrzej Bartosiewicz 2.7 CENTR Technical committee 2.7.1 Report from .JP (10 min) Yasuhiro Orange Morishita / ???? - JP DNS server update - IDN deployment update - Report from DNSQC-TF (DNS Quality check Task Force) 2.7.2 Report from .PL (10 min) Andrzej Bartosiewicz [3] Special invited (longer) presentation (30 min) 3.1 RIPE NCC DNS Monitoring Daniel Karrenberg Thursday 9:00-10:30 ------------------- [0] Charter / Agenda Bashing / Goals etc (30 min) Leader of the discussion: Patrik Faltstrom Help from co-chairs: Peter Koch, Jim Reid and Jaap Akkerhuis. 0.2 Charter 0.3 What are we doing here anyway? [1] Topics with deliverables (15 min) 1.1 Quality of the DNS Topic-Leader: Unknown 1.1.1 Background, deliverables, participants etc 1.1.1.1 Who will lead this topic? 1.1.1.2 Deliverables 1.2.1 Tools 1.2.1.1 DomainSentinel (15 min) John Brown [2] Reports / status items (same bullets every meeting) 2.1 Monitoring 2.1.1 RIPE NCC DNS Monitoring (5 min) Daniel Karrenberg 2.2 DNS in the IETF 2.2.1 DNSEXT (5 min) Olaf Kolkman 2.2.2 DNSOP (5 min) Lars-Johan Liman 2.2.3 Other wg's which touch DNS 2.2.3.2 SSHFP (5 min) Jakob Schlyter 2.2.3.3 ENUM (5 min) Patrik Faltstrom 2.2.3.4 PROVREG (5 min) Jaap Akkerhuis Thursday 11:00-12:30 -------------------- 2.4 Root servers 2.4.2 B-Root (5 min) Bill Manning 2.4.2 F-Root (5 min) Joao Damas 2.4.3 I-Root (5 min) Lars-Johan Liman 2.6 DNSSEC deployment / experience 2.6.1 DNSSEC status (5 min) Sam Weiler 2.7 Anycast deployment / experience 2.7.1 Dave Knight (5 min) 2.8 DNS Software 2.8.1 Bind (5 min) Joao Damas 2.8.2 OpenReg (5 min) Joao Damas 2.8.3 NSD (5 min) Ted Lindgreen 2.9 IPv6 deployment / experience 2.9.1 Adding IPv6 glue to the root zone (5 min) Ronald van der Pol [4] Temporary items 4.1 Use of DNS for SPAM prevention (15 min + max 10 minutes discussion) Note: This is not to be a spam discussion, but more a heads-up on the various mechanisms which exists and are discussed for example in the anti-spam research group in the IETF. Anne P. Mitchell, Esq. 4.2 The status of the rs.net testbed: (15 min) Bill Manning CN & JP tlds registered punycode entries KeyMgmt issues w/ persistant DNSSEC testbeds Precursors for IPv6 tlds & glue in the root zone 4.3 SYN flood like patterns on nameserver due to firewall issues? Peter Koch From jakob at rfc.se Fri Sep 5 10:12:05 2003 From: jakob at rfc.se (Jakob Schlyter) Date: Fri, 5 Sep 2003 10:12:05 +0200 Subject: [dns-wg] v6 ns/glue naming bcp Message-ID: is there any operational considerations before putting both A and AAAA records on a name used glue? or, should one use separate names for v4 and v6 transport? e.g.: example.com. NS ns1.example.com. NS ns2.example.com. ns1.example.com. A 192.0.2.1 AAAA dead:beef::1 ns2.example.com. A 192.0.2.2 AAAA dead:beef::2 vs example.com. NS ns1.example.com. NS ns1.ipv6.example.com. NS ns2.example.com. NS ns2.ipv6.example.com. ns1.example.com. A 192.0.2.1 ns1.ipv6.example.com. AAAA dead:beef::1 ns2.example.com. A 192.0.2.2 ns2.ipv6.example.com. AAAA dead:beef::2 yours, jakob From paf at cisco.com Fri Sep 5 10:19:22 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri, 5 Sep 2003 10:19:22 +0200 Subject: [dns-wg] Fwd: draft RIPE 46 DN* WG minutes Message-ID: Please have a look at these, and come with comments if you have any. We chairs seems to like the minutes, and we thank the scribes for getting the minutes together so fast. Those of you which had presentations and did NOT use the laptop on the stage, please send the presentations to webmaster at ripe.net, and cc me. paf Begin forwarded message: > From: Ziya Suzen > Date: 4 september 2003 16.26.07 MET > To: Patrik Faltstrom , Peter Koch > , Jaap Akkerhuis , NCC > Webmaster > Cc: Arno Meulenkamp > Subject: RIPE 46 DN* WG minutes > > Dear all, > > Attached are the minutes for Tuesday and Thursday sessions > respectively from RIPE 46 Meeting, Amsterdam, the Netherlands 1 - 5 > September, 2003. > > Working Group: DN* (Domain Names in Everything) > Sessions: > Tuesday, 2 September 2003 Time: 16.00 - 17.30 Location: Grand > Ballroom > (dns-dnr-minutes-1.txt) > > Thursday, 4 September 2003 Time: 09.00 - 12.30 Location: St. Johns II > (dns-dnr-minutes-2.txt) > > After the meeting I did get help from Arno Meulenkamp's (RIPE NCC) > notes as well. Thank you Arno. > > Regards, > > Ziya Suzen > RIPE NCC > > P.S. I am sorry. I couldn't find Jim Reid's email address. Can you > please forward this message to him as well if needed. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dns-dnr-minutes-1.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dns-dnr-minutes-2.txt URL: From paf at cisco.com Fri Sep 5 11:21:20 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri, 5 Sep 2003 11:21:20 +0200 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: References: Message-ID: <4FD9E9AA-DF82-11D7-9CBB-000A959CF516@cisco.com> On 5 sep 2003, at 10.12, Jakob Schlyter wrote: > is there any operational considerations before putting both A and AAAA > records on a name used glue? > or, should one use separate names for v4 and v6 transport? I personally would put A and AAAA for the same name. Otherwise I guess there is a risk the resolver using only IPv4 will query for A RR for ns1.ipv6.example.com, which of course will not exist. A and AAAA should use the same namespace. I think the same is true for any service which uses domain names when addressing services. One use in the example below ns1.example.com as the domain name for the nameserver for example.com, and that is true regardless of what transport you use. Similar rules should be true for HTTP, SMTP etc. paf > e.g.: > > example.com. NS ns1.example.com. > NS ns2.example.com. > ns1.example.com. A 192.0.2.1 > AAAA dead:beef::1 > ns2.example.com. A 192.0.2.2 > AAAA dead:beef::2 > vs > example.com. NS ns1.example.com. > NS ns1.ipv6.example.com. > NS ns2.example.com. > NS ns2.ipv6.example.com. > ns1.example.com. A 192.0.2.1 > ns1.ipv6.example.com. AAAA dead:beef::1 > ns2.example.com. A 192.0.2.2 > ns2.ipv6.example.com. AAAA dead:beef::2 > > > yours, > > jakob > From EUser at t-online.de Fri Sep 5 11:20:00 2003 From: EUser at t-online.de (EUser at t-online.de) Date: 05 Sep 2003 09:20 GMT Subject: [dns-wg] re: IDN Message-ID: <19vCnb-0eJaZE0@fwd07.sul.t-online.com> Moin >>>Internationalized Domain Names are represented by local >>>language characters, available in more than 350 languages, from >>>Korean to Greek, Russian to Chinese "VeriSign" >>The domain names are sent with funny names (IDN) this may >>cause confusion in big companies for examples >>"Rob Blokzijl" >http://www.oojjoo.com/nn/eisvogel.htm is this a multilingual IDN or a definition thing ? (seems to be a Percentage for commissions, discounts, rebates . .) mfg Bernd c/o EUser at t-online.de From paf at paf.se Fri Sep 5 10:21:04 2003 From: paf at paf.se (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri, 5 Sep 2003 10:21:04 +0200 Subject: [dns-wg] Presentations at DNS meeting Message-ID: An update: You can see yourself on http://rosie.ripe.net/ripe/meetings/ripe-46/presentations/ whether your presentations has been taken care of. If they are missing there, please resend. paf From yasuhiro at jprs.co.jp Fri Sep 5 12:47:56 2003 From: yasuhiro at jprs.co.jp (Yasuhiro Orange Morishita / =?iso-2022-jp?B?GyRCPzkyPEJZOSgbKEI=?=) Date: Fri, 05 Sep 2003 19:47:56 +0900 (JST) Subject: [dns-wg] Presentations at DNS meeting In-Reply-To: References: Message-ID: <20030905.194756.127888409.yasuhiro@jprs.co.jp> > An update: You can see yourself on > http://rosie.ripe.net/ripe/meetings/ripe-46/presentations/ whether your > presentations has been taken care of. If they are missing there, please > resend. A correction: In page 8 of my presentation (.JP technical update), I mistaked the former name of B.dns.jp. The correct name is 'dns0.nic.ad.jp', not 'dns-jp.nic.ad.jp'. I resended the updated presentation to webmaster at ripe.net, so I hope that it is updated sooner or later. Regards, -- Yasuhiro 'Orange' Morishita DNS Technical Engineer Research and Development department, Japan Registry Service Co.,Ltd. (JPRS) E-Mail: yasuhiro at jprs.co.jp / orange at jprs.co.jp From yasuhiro at jprs.co.jp Fri Sep 5 13:06:16 2003 From: yasuhiro at jprs.co.jp (Yasuhiro Orange Morishita / =?iso-2022-jp?B?GyRCPzkyPEJZOSgbKEI=?=) Date: Fri, 05 Sep 2003 20:06:16 +0900 (JST) Subject: [dns-wg] Presentations at DNS meeting In-Reply-To: <20030905.194756.127888409.yasuhiro@jprs.co.jp> References: <20030905.194756.127888409.yasuhiro@jprs.co.jp> Message-ID: <20030905.200616.61293885.yasuhiro@jprs.co.jp> > > An update: You can see yourself on > > http://rosie.ripe.net/ripe/meetings/ripe-46/presentations/ whether your > > presentations has been taken care of. If they are missing there, please > > resend. > > A correction: In page 8 of my presentation (.JP technical update), I > mistaked the former name of B.dns.jp. The correct name is > 'dns0.nic.ad.jp', not 'dns-jp.nic.ad.jp'. More correction: these are 'ns0.nic.ad.jp' and 'ns-jp.nic.ad.jp'. So, former name of B.dns.jp is 'ns0.nic.ad.jp'. I'm very sorry for double mistake... -- Orange > I resended the updated presentation to webmaster at ripe.net, so I hope > that it is updated sooner or later. > > Regards, > -- > Yasuhiro 'Orange' Morishita > DNS Technical Engineer > Research and Development department, Japan Registry Service Co.,Ltd. (JPRS) > E-Mail: yasuhiro at jprs.co.jp / orange at jprs.co.jp > From pk at TechFak.Uni-Bielefeld.DE Fri Sep 5 14:55:31 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Fri, 05 Sep 2003 14:55:31 +0200 Subject: [dns-wg] re: IDN In-Reply-To: Your message of "05 Sep 2003 09:20:00 GMT." <19vCnb-0eJaZE0@fwd07.sul.t-online.com> Message-ID: <200309051255.h85CtVl00487@grimsvotn.TechFak.Uni-Bielefeld.DE> Dear Bernd, > >>The domain names are sent with funny names (IDN) this may > >>cause confusion in big companies for examples > >>"Rob Blokzijl" > >http://www.oojjoo.com/nn/eisvogel.htm > is this a multilingual IDN or a definition thing ? I'm not too sure I understand what you're trying to say here, but the picture to be found following the URL is "artwork". Your quote from the meetimng minutes may be misunderstood, since it's out of context here. The "funny characters" were not meant to characterize non-latin scripts or `dingbats', but instead the "real" domain names like "xn--fobar-xcvg". -Peter From pk at TechFak.Uni-Bielefeld.DE Fri Sep 5 18:52:51 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Fri, 05 Sep 2003 18:52:51 +0200 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: Your message of "Fri, 05 Sep 2003 11:21:20 +0200." <4FD9E9AA-DF82-11D7-9CBB-000A959CF516@cisco.com> Message-ID: <200309051652.h85GqqO01937@grimsvotn.TechFak.Uni-Bielefeld.DE> paf wrote: > A and AAAA should use the same namespace. apart from this more general statement, which I agree with, separating namespaces would cost more precious octets in the packet. -Peter From jim at rfc1035.com Fri Sep 5 19:36:20 2003 From: jim at rfc1035.com (Jim Reid) Date: Fri, 05 Sep 2003 18:36:20 +0100 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: Your message of "Fri, 05 Sep 2003 18:52:51 +0200." <200309051652.h85GqqO01937@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <14537.1062783380@gromit.rfc1035.com> >>>>> "Peter" == Peter Koch writes: >> A and AAAA should use the same namespace. Peter> apart from this more general statement, which I agree with, Peter> separating namespaces would cost more precious octets in Peter> the packet. I wonder if saving the odd octet here and there to squeeze stuff into a 512 byte payload is really the best approach. It is wise to apply the constraints of 1980's DNS to the world of IPv6 in the 21st century? This seems to be storing up trouble for the future and could make it awkward to get reasonable amounts of IPv6 glue deployed. How feasible would it be to mandate or recommend that IPv6-aware DNS clients use EDNS0 to get bigger payloads and complete glue RRsets? Could we just say "use EDNS0" and be done with it? From pk at TechFak.Uni-Bielefeld.DE Fri Sep 5 19:49:06 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Fri, 05 Sep 2003 19:49:06 +0200 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: Your message of "Fri, 05 Sep 2003 18:36:20 BST." <14537.1062783380@gromit.rfc1035.com> Message-ID: <200309051749.h85Hn7r02208@grimsvotn.TechFak.Uni-Bielefeld.DE> Jim Reid said: > century? This seems to be storing up trouble for the future and could > make it awkward to get reasonable amounts of IPv6 glue deployed. How > feasible would it be to mandate or recommend that IPv6-aware DNS > clients use EDNS0 to get bigger payloads and complete glue RRsets? that might be useful but will not solve the problem. > Could we just say "use EDNS0" and be done with it? Legacy, i.e. EDNS-unaware, clients will continue to use the 512 byte limit, so the servers - unless they call for more load - should be conservative and the zone administrators should be as well. Related to this, IPv6 already has an impact on server load. On our system we already see large amounts of AAAA and A6 type queries (each roughly 85% of the type A count), so I'd really favor a conservative approach. -Peter From paf at cisco.com Sat Sep 6 10:44:12 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sat, 6 Sep 2003 10:44:12 +0200 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: <200309051749.h85Hn7r02208@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200309051749.h85Hn7r02208@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <4A112CA7-E046-11D7-9CBB-000A959CF516@cisco.com> How many old clients and servers do _NOT_ handle a 1400 byte packet? When was the last time you saw one? (The pix blocks it in some configuration modes I can add before you all say _T_H_E__P_I_X_...) paf On 5 sep 2003, at 19.49, Peter Koch wrote: > Jim Reid said: > >> century? This seems to be storing up trouble for the future and could >> make it awkward to get reasonable amounts of IPv6 glue deployed. How >> feasible would it be to mandate or recommend that IPv6-aware DNS >> clients use EDNS0 to get bigger payloads and complete glue RRsets? > > that might be useful but will not solve the problem. > >> Could we just say "use EDNS0" and be done with it? > > Legacy, i.e. EDNS-unaware, clients will continue to use the 512 byte > limit, > so the servers - unless they call for more load - should be > conservative > and the zone administrators should be as well. > > Related to this, IPv6 already has an impact on server load. On our > system > we already see large amounts of AAAA and A6 type queries (each roughly > 85% > of the type A count), so I'd really favor a conservative approach. > > -Peter > From jim at rfc1035.com Sat Sep 6 11:08:13 2003 From: jim at rfc1035.com (Jim Reid) Date: Sat, 06 Sep 2003 10:08:13 +0100 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: Your message of "Fri, 05 Sep 2003 19:49:06 +0200." <200309051749.h85Hn7r02208@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <16348.1062839293@gromit.rfc1035.com> >>>>> "Peter" == Peter Koch writes: >> Could we just say "use EDNS0" and be done with it? Peter> Legacy, i.e. EDNS-unaware, clients will continue to use the Peter> 512 byte limit, so the servers - unless they call for more Peter> load - should be conservative and the zone administrators Peter> should be as well. Indeed. However I wonder how much legacy IPv6 stuff exists and whether we're allowing that to unduly influence things. Suppose an EDNS0 header bit was set aside for a resolver to say "give me all the AAAA or A6 records you have for this query". And of course, the resolver would provide a buffer large enough to receive the reply. Meanwhile, legacy stuff would continue with 512 byte payloads. It would see the largely IPv4 internet just as they do right now, unless those clients explicitly queried for (say) a AAAA record. There's some hand-waving going on here. An RFC would be needed to document server behaviour along the lines of "don't throw in IPv6 glue unless you *know* the client (a) said they wanted it; (b) provided a buffer big enough for the extra data without causing truncation. I think this should work without breaking anything. New resolvers could use this hypothetical EDNS0 bit if they care about IPv6. Legacy stuff would be unchanged. However legacy IPv6 stuff would be no better off than it is at present. That deployed base might not be large enough to worry about anyway. IMO it won't be big enough to justify protocol tweaks or changes in operational practice. What I'm really saying is fix this for the millions of IPv6 hosts that will be joining the internet and not get too obsessed with backwards compatibility for the probably small installed base of existing IPv6 devices with resolvers that can't or won't be upgraded. Peter> Related to this, IPv6 already has an impact on server Peter> load. On our system we already see large amounts of AAAA Peter> and A6 type queries (each roughly 85% of the type A count), Peter> so I'd really favor a conservative approach. Aha! Interesting numbers. Do you have any idea what it is that's generating these AAAA and A6 queries? 85% of the A query count seems very high. I wonder if there are some idiot clients out there in a tight loop who just keep asking for AAAA or A6 even when they are told there aren't any? Maybe it's something like that which accounts for the high AAAA and A6 query rate you're seeing. From jeroen at unfix.org Sat Sep 6 12:56:52 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 6 Sep 2003 12:56:52 +0200 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: <200309051749.h85Hn7r02208@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <004801c37465$94fec7b0$210d640a@unfix.org> -----BEGIN PGP SIGNED MESSAGE----- Peter Koch wrote: > Related to this, IPv6 already has an impact on server load. > On our system we already see large amounts of AAAA and A6 type queries > (each roughly 85% of the type A count), so I'd really favor a > conservative approach. We could make a rather stupid assumption that 85% of the queriers you see request AAAA and then the A record. Thus that the installed base supporting IPv6 is really growing. Sounds like a good thing. Patrik F?ltstr?m [paf at cisco.com] wrote: > (The pix blocks it in some configuration modes I can add before you all > say _T_H_E__P_I_X_...) Haha, hmm people where indeed complaining about PIX's at RIPE46 :) Btw, when is a PIX going to do IPv6, I once heared "March 2003" but I queried a university where they wanted to do IPv6 but due to policy stuff were not allowed as their PIX didn't filter IPv6 that it still did not support it :( Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP1m9dCmqKFIzPnwjEQIi9ACcCwDWE8q37sVknGKx+HLbploQnw4An2bk V2aGclP12SzfxOA/dJQewPPF =xTjY -----END PGP SIGNATURE----- From jordi.palet at consulintel.es Sat Sep 6 13:21:31 2003 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 6 Sep 2003 13:21:31 +0200 Subject: [dns-wg] v6 ns/glue naming bcp References: <004801c37465$94fec7b0$210d640a@unfix.org> Message-ID: <1c8b01c37469$06951ed0$870a0a0a@consulintel.es> I'm not sure about the actual status, but Cisco demonstrated it at the last US Summit. See http://newsroom.cisco.com/dlls/prod_062403c.html. May be is still not commercial, but sure you can get a release from the Cisco people, just to try ? Regards, Jordi ----- Original Message ----- From: "Jeroen Massar" To: "'Peter Koch'" ; Cc: "'Patrik F?ltstr?m'" Sent: Saturday, September 06, 2003 12:56 PM Subject: RE: [dns-wg] v6 ns/glue naming bcp -----BEGIN PGP SIGNED MESSAGE----- Peter Koch wrote: > Related to this, IPv6 already has an impact on server load. > On our system we already see large amounts of AAAA and A6 type queries > (each roughly 85% of the type A count), so I'd really favor a > conservative approach. We could make a rather stupid assumption that 85% of the queriers you see request AAAA and then the A record. Thus that the installed base supporting IPv6 is really growing. Sounds like a good thing. Patrik F?ltstr?m [paf at cisco.com] wrote: > (The pix blocks it in some configuration modes I can add before you all > say _T_H_E__P_I_X_...) Haha, hmm people where indeed complaining about PIX's at RIPE46 :) Btw, when is a PIX going to do IPv6, I once heared "March 2003" but I queried a university where they wanted to do IPv6 but due to policy stuff were not allowed as their PIX didn't filter IPv6 that it still did not support it :( Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP1m9dCmqKFIzPnwjEQIi9ACcCwDWE8q37sVknGKx+HLbploQnw4An2bk V2aGclP12SzfxOA/dJQewPPF =xTjY -----END PGP SIGNATURE----- ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From paf at cisco.com Sat Sep 6 14:00:37 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sat, 6 Sep 2003 14:00:37 +0200 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: <004801c37465$94fec7b0$210d640a@unfix.org> References: <004801c37465$94fec7b0$210d640a@unfix.org> Message-ID: On 6 sep 2003, at 12.56, Jeroen Massar wrote: >> (The pix blocks it in some configuration modes I can add before you >> all >> say _T_H_E__P_I_X_...) > > Haha, hmm people where indeed complaining about PIX's at RIPE46 :) > Btw, when is a PIX going to do IPv6, I once heared "March 2003" > but I queried a university where they wanted to do IPv6 but due > to policy stuff were not allowed as their PIX didn't filter IPv6 > that it still did not support it :( The pix is like all "firewall software" there to "protect" stupid things behind it. So, to some degree it should only allow the minimal possible things (512 byte DNS packets, no extensions to SMTP etc). But, the problem _I_ see with the pix is that one only have the choice of being so rigid regarding the standards, OR to open the port(s) completely. As you understand, this is something I am trying to change, but it is hard, because firewall people are extremely conservative. paf From pk at TechFak.Uni-Bielefeld.DE Sat Sep 6 16:01:23 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Sat, 06 Sep 2003 16:01:23 +0200 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: Jim Reid's message of "Sat, 06 Sep 2003 10:08:13 BST." <16348.1062839293@gromit.rfc1035.com> Message-ID: <200309061401.h86E1OX03348@grimsvotn.TechFak.Uni-Bielefeld.DE> Jim Reid wrote: > Indeed. However I wonder how much legacy IPv6 stuff exists and whether there's no "legacy IPv6" but a lot of EDNS0-unaware ("legacy") mostly IPv4 based clients, which have to deal with what fits into 512 bytes. > legacy stuff would continue with 512 byte payloads. It would see the > largely IPv4 internet just as they do right now, unless those clients > explicitly queried for (say) a AAAA record. 1886bis, currently in "AUTH48" state, instead modified all additional section processing from "add A" to "add A and AAAA". > compatibility for the probably small installed base of existing IPv6 > devices with resolvers that can't or won't be upgraded. I agree that the currently installed base of IPv6 hosts could be required to change, but I'm not concerned about those anyway. > there aren't any? Maybe it's something like that which accounts for > the high AAAA and A6 query rate you're seeing. Exactly. Most of these queries are for a single nameserver's name, which only has A but no AAAA and even less A6. -Peter From brad.knowles at skynet.be Sun Sep 7 01:58:48 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun, 7 Sep 2003 01:58:48 +0200 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: <004801c37465$94fec7b0$210d640a@unfix.org> References: <004801c37465$94fec7b0$210d640a@unfix.org> Message-ID: At 12:56 PM +0200 2003/09/06, Jeroen Massar wrote: > Haha, hmm people where indeed complaining about PIX's at RIPE46 :) > Btw, when is a PIX going to do IPv6, I once heared "March 2003" > but I queried a university where they wanted to do IPv6 but due > to policy stuff were not allowed as their PIX didn't filter IPv6 > that it still did not support it :( I think there are some changes coming soon. I was contacted by one of the PIX project managers in response to some negative things I had to say about it in the past, and they were offering to let me test the new version. Problem is, I don't really have a network available to me to do that, but they did confirm that there are some changes coming. Now, whether those changes include IPv6, I couldn't say. But I could ask, if anyone is interested. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From bmanning at ISI.EDU Sun Sep 7 14:34:12 2003 From: bmanning at ISI.EDU (Bill Manning) Date: Sun, 7 Sep 2003 05:34:12 -0700 (PDT) Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: <200309061401.h86E1OX03348@grimsvotn.TechFak.Uni-Bielefeld.DE> from Peter Koch at "Sep 6, 3 04:01:23 pm" Message-ID: <200309071234.h87CYCQ27791@boreas.isi.edu> % Jim Reid wrote: % % > Indeed. However I wonder how much legacy IPv6 stuff exists and whether % there's no "legacy IPv6" but a lot of EDNS0-unaware ("legacy") mostly % IPv4 based clients, which have to deal with what fits into 512 bytes. To some degree, the 512 byte limit is part of the DNS protocol. RFC 1034 is reasonably clear on this. % > legacy stuff would continue with 512 byte payloads. It would see the % > largely IPv4 internet just as they do right now, unless those clients % > explicitly queried for (say) a AAAA record. % % 1886bis, currently in "AUTH48" state, instead modified all additional % section processing from "add A" to "add A and AAAA". It would perhaps be useful to review the respsize draft that is circulating in the DNSOPS w/g. And I am informed that the 8.4.1 and the 9.2.3 code attempt to "shuffle" the data in the additional section processing step to first send out glue of the type that the request came in on. e.g. query over v4, get A's first, query over v6, AAAAs first. % > compatibility for the probably small installed base of existing IPv6 % > devices with resolvers that can't or won't be upgraded. % % I agree that the currently installed base of IPv6 hosts could be required % to change, but I'm not concerned about those anyway. pretty much any resolver code shipped since 1998 understands IPv6 rrs. Not sure O'dells law still holds. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From jim at rfc1035.com Mon Sep 8 20:23:55 2003 From: jim at rfc1035.com (Jim Reid) Date: Mon, 08 Sep 2003 19:23:55 +0100 Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: Your message of "Sat, 06 Sep 2003 16:01:23 +0200." <200309061401.h86E1OX03348@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <21003.1063045435@gromit.rfc1035.com> >>>>> "Peter" == Peter Koch writes: Peter> there's no "legacy IPv6" but a lot of EDNS0-unaware Peter> ("legacy") mostly IPv4 based clients, which have to deal Peter> with what fits into 512 bytes. Indeed. This stuff mostly doesn't know or care about IPv6, so let's try to ensure they never see AAAA records or get into problems caused by truncation isses as IPv6 glue comes along. >> legacy stuff would continue with 512 byte payloads. It would >> see the largely IPv4 internet just as they do right now, unless >> those clients explicitly queried for (say) a AAAA record. Peter> 1886bis, currently in "AUTH48" state, instead modified all Peter> additional section processing from "add A" to "add A and Peter> AAAA". I'd not read this draft. It seems to be what I've been suggesting. Thanks for the tip Peter. From jakob at rfc.se Tue Sep 9 00:16:25 2003 From: jakob at rfc.se (Jakob Schlyter) Date: Tue, 9 Sep 2003 00:16:25 +0200 (CEST) Subject: [dns-wg] v6 ns/glue naming bcp In-Reply-To: <4FD9E9AA-DF82-11D7-9CBB-000A959CF516@cisco.com> References: <4FD9E9AA-DF82-11D7-9CBB-000A959CF516@cisco.com> Message-ID: On Fri, 5 Sep 2003, Patrik F?ltstr?m wrote: > I personally would put A and AAAA for the same name. Otherwise I guess > there is a risk the resolver using only IPv4 will query for A RR for > ns1.ipv6.example.com, which of course will not exist. > > A and AAAA should use the same namespace. wasn't there an issue with bind8 marking names, instead of addresses, as bad/stale/unreachable ? so if a host has local v6 connectivity (e.g. link-local) but cannot reach the global v6 Internet, all A/AAAA nameservers would be considered bad since their v6 addresses wouldn't be reachable. I really hope I got this wrong, but I want find out before I put all my NSes on v6 and suddenly find my self unresolvable. jakob From yasuhiro at jprs.co.jp Fri Sep 5 12:31:55 2003 From: yasuhiro at jprs.co.jp (Yasuhiro Orange Morishita / =?iso-2022-jp?B?GyRCPzkyPEJZOSgbKEI=?=) Date: Fri, 05 Sep 2003 19:31:55 +0900 (JST) Subject: [dns-wg] Presentations at DNS meeting In-Reply-To: References: Message-ID: <20030905.193155.110232847.yasuhiro@jprs.co.jp> > An update: You can see yourself on > http://rosie.ripe.net/ripe/meetings/ripe-46/presentations/ whether your > presentations has been taken care of. If they are missing there, please > resend. A correction: In page 8 of my presentation (.JP technical update), I mistaked the former name of B.dns.jp. The correct name is 'dns0.nic.ad.jp', not 'dns-jp.nic.ad.jp'. I resended the updated presentation to webmaster at ripe.net, so I hope that it is updated sooner or later. Regards, -- Yasuhiro 'Orange' Morishita DNS Technical Engineer Research and Development department, Japan Registry Service Co.,Ltd. (JPRS) E-Mail: yasuhiro at jprs.co.jp / orange at jprs.co.jp From aosman at ie-eg.com Sun Sep 7 10:54:55 2003 From: aosman at ie-eg.com (Abdelhamid Osman) Date: Sun, 7 Sep 2003 11:54:55 +0300 Subject: [dns-wg] New DNS server Message-ID: <3F5A1290@webmail> Dear Ripe, We are here in Internet Egypt a LIR to RIPE NCC reg ID : eg.ie . We currently have two DNS servers : brainy1.ie-eg.com and brainy2.ie-eg.com We want to add a new DNS server brainy4.ie-eg.com We want to know if there is any thing that we should do with ripe in order to have this new DNS server registered and be able to add domain names to it ? Please advise us with the necessary procedures that should be taken. Best Regards, Abdelhamid Osman Network Manager Internet Egypt From joao at psg.com Tue Sep 9 12:24:08 2003 From: joao at psg.com (Joao Luis Silva Damas) Date: Tue, 9 Sep 2003 12:24:08 +0200 Subject: [dns-wg] New DNS server In-Reply-To: <3F5A1290@webmail> Message-ID: The RIPE NCC only handles (parts of) the inaddr.arpa tree. You can manage the part of the inaddr.arpa corresponding to the addresses that have been delegated to your LIR using the process described in: * http://www.ripe.net/ripencc/mem-services/registration/reverse/index.html For forward domains, you need to talk to the registrar of those domains. Cheers, Joao Damas ISC On Sunday, September 7, 2003, at 10:54 AM, Abdelhamid Osman wrote: > Dear Ripe, > We are here in Internet Egypt a LIR to RIPE NCC reg ID : eg.ie . > We currently have two DNS servers : brainy1.ie-eg.com and > brainy2.ie-eg.com > We want to add a new DNS server brainy4.ie-eg.com > > We want to know if there is any thing that we should do with ripe in > order to > have this new DNS server registered and be able to add domain names to > it ? > > Please advise us with the necessary procedures that should be taken. > > Best Regards, > > Abdelhamid Osman > Network Manager > Internet Egypt > From randy at psg.com Tue Sep 9 17:39:18 2003 From: randy at psg.com (Randy Bush) Date: Tue, 9 Sep 2003 08:39:18 -0700 Subject: [dns-wg] New DNS server References: <3F5A1290@webmail> Message-ID: > We currently have two DNS servers : brainy1.ie-eg.com and > brainy2.ie-eg.com We want to add a new DNS server > brainy4.ie-eg.com it would be even brainier if you read rfc 2182 section 3, and put at least one server at a tolpologically and geographically diverse location. randy From paf at cisco.com Tue Sep 9 18:51:16 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 9 Sep 2003 09:51:16 -0700 Subject: [dns-wg] Presentations at DNS meeting In-Reply-To: <20030905.193155.110232847.yasuhiro@jprs.co.jp> References: <20030905.193155.110232847.yasuhiro@jprs.co.jp> Message-ID: On 5 sep 2003, at 03.31, Yasuhiro Orange Morishita / ???? wrote: > I resended the updated presentation to webmaster at ripe.net, so I hope > that it is updated sooner or later. Thanks! paf From daniel.karrenberg at ripe.net Wed Sep 10 09:38:55 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Sep 2003 09:38:55 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: <200309100258.h8A2w7JY014039@aunt.gaertner.de> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> Message-ID: <20030910073855.GS490@reifa.karrenberg.net> Joerg, thanks for the encouragement. So far we only monitor domains which we have contacts with and whose administrators have indicated that they are interested in the service. Should the .org folks come forward and indicate interest we will be happy to do that. MfG Daniel On 10.09 04:58, Joerg Schumacher wrote: > Hi! > > Thanks for providing dnsmon. I think it's a useful service. Back on > 18.07.2003 our own monitoring showed some trouble reaching dns.denic.de. > Could be us, could be them. dsnmon gave the answer: it's not only us > having the problem, so it's them. ops at denic.de confimed that the IOS > upgrade on their DECIX routers caused the trouble. > > Mind adding the nameservers for .ORG to the monitoring? I'd be > interested in the effects of the recent change in the root zone. > Having only two nameservers for a tld and both of them in a single AS > makes me kind of nervous. > > Regards, > Joerg > > PS: http://www.pir.org/news/press_releases/pr_articles/2003-09-08-01 > > "[...] announced the implementation of a change that enables .ORG > names to resolve through web browsers worldwide within 5 minutes > [..] This change will enhance the speed of > registration/modification-to-resolution of .ORG names to less > than 5 minutes, from the previous average of 12-24 hours. [...]" > > makes me wonder if they'll also change the ttl of all NS record > in the org-zone to 5 minutes somewhere in the near future. Ouch! > > -- > Gaertner Datensysteme 38114 Braunschweig > Joerg Schumacher Hamburger Str. 273a > Tel: 0531-2335555 Fax: 0531-2335556 > From daniel.karrenberg at ripe.net Wed Sep 10 09:56:51 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Sep 2003 09:56:51 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: <200309100258.h8A2w7JY014039@aunt.gaertner.de> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> Message-ID: <20030910075651.GC486@reifa.karrenberg.net> On 10.09 04:58, Joerg Schumacher wrote: > Hi! > > Thanks for providing dnsmon. I think it's a useful service. Back on > 18.07.2003 our own monitoring showed some trouble reaching dns.denic.de. > Could be us, could be them. dsnmon gave the answer: it's not only us > having the problem, so it's them. ops at denic.de confimed that the IOS > upgrade on their DECIX routers caused the trouble. > > Mind adding the nameservers for .ORG to the monitoring? I'd be > interested in the effects of the recent change in the root zone. > Having only two nameservers for a tld and both of them in a single AS > makes me kind of nervous. > > Regards, > Joerg > > PS: http://www.pir.org/news/press_releases/pr_articles/2003-09-08-01 > > "[...] announced the implementation of a change that enables .ORG > names to resolve through web browsers worldwide within 5 minutes > [..] This change will enhance the speed of > registration/modification-to-resolution of .ORG names to less > than 5 minutes, from the previous average of 12-24 hours. [...]" > > makes me wonder if they'll also change the ttl of all NS record > in the org-zone to 5 minutes somewhere in the near future. Ouch! > > -- > Gaertner Datensysteme 38114 Braunschweig > Joerg Schumacher Hamburger Str. 273a > Tel: 0531-2335555 Fax: 0531-2335556 > From schuma at gaertner.de Wed Sep 10 02:41:05 2003 From: schuma at gaertner.de (Joerg Schumacher) Date: Wed, 10 Sep 2003 02:41:05 +0200 (MET DST) Subject: [dns-wg] New DNS server In-Reply-To: Message-ID: <200309100041.h8A0f5Fk028845@aunt.gaertner.de> >> We currently have two DNS servers : brainy1.ie-eg.com and >> brainy2.ie-eg.com We want to add a new DNS server >> brainy4.ie-eg.com > >it would be even brainier if you read rfc 2182 section 3, and put >at least one server at a tolpologically and geographically diverse >location. A pointer to a best current practice document is always helpful. RFC 2182 is getting old, I guess I'd also recommend that recursion is disabled on the servers. A "dig version.bind txt chaos @brainy1.ie-eg.com" returns 8.2.3-REL-IDNS. If this is an unpatched version you might want to read http://www.isc.org/products/BIND/bind-security.html. I still wonder why so many DNS operators don't pay attention to RFC 2182. Lots of domains have all their nameservers in a single AS. The worst example for what can go wrong I've seen so far was the trouble of web.de (a large freemailer in Germany) back in the last summer: They were multihomed but had both nameservers only connected via AS517. The KPNQwest network went suddenly down and both servers were unreachable. IIRC web.de somehow managed to get an "emergency rebuild" of the .de zone from DENIC. Did they learn something from this sad event? Nope: Both servers are again connected via a single AS. Joerg From schuma at gaertner.de Wed Sep 10 04:58:07 2003 From: schuma at gaertner.de (Joerg Schumacher) Date: Wed, 10 Sep 2003 04:58:07 +0200 (MET DST) Subject: [dns-wg] dnsmon / .org Message-ID: <200309100258.h8A2w7JY014039@aunt.gaertner.de> Hi! Thanks for providing dnsmon. I think it's a useful service. Back on 18.07.2003 our own monitoring showed some trouble reaching dns.denic.de. Could be us, could be them. dsnmon gave the answer: it's not only us having the problem, so it's them. ops at denic.de confimed that the IOS upgrade on their DECIX routers caused the trouble. Mind adding the nameservers for .ORG to the monitoring? I'd be interested in the effects of the recent change in the root zone. Having only two nameservers for a tld and both of them in a single AS makes me kind of nervous. Regards, Joerg PS: http://www.pir.org/news/press_releases/pr_articles/2003-09-08-01 "[...] announced the implementation of a change that enables .ORG names to resolve through web browsers worldwide within 5 minutes [..] This change will enhance the speed of registration/modification-to-resolution of .ORG names to less than 5 minutes, from the previous average of 12-24 hours. [...]" makes me wonder if they'll also change the ttl of all NS record in the org-zone to 5 minutes somewhere in the near future. Ouch! -- Gaertner Datensysteme 38114 Braunschweig Joerg Schumacher Hamburger Str. 273a Tel: 0531-2335555 Fax: 0531-2335556 From daniel.karrenberg at ripe.net Wed Sep 10 11:17:46 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Sep 2003 11:17:46 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: <200309100258.h8A2w7JY014039@aunt.gaertner.de> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> Message-ID: <20030910091746.GA2737@reifa.karrenberg.net> [sorry about the useless re-post to dns-wg, finger trouble ....] On 10.09 04:58, Joerg Schumacher wrote: > ... > Mind adding the nameservers for .ORG to the monitoring? I'd be > interested in the effects of the recent change in the root zone. > Having only two nameservers for a tld and both of them in a single AS > makes me kind of nervous. > ... Weiteres Nachdenken ergab: While we so far have only monitored TLDs with whome we have some contact, we can certainly also monitor any TLD if there is an expressed interest from the RIPE community. Thechnically this is no problem at all. Configuring it takes all of 5 minutes and even the alpha version of the analysis web site on the development server box can easily take the load. However there is a more principle problem and that is why I copied ncc-services: Currently there is a heated debate about (new) NCC services and their cost. One question asked over and over again there is: Why should NCC members pay for this service? For dnsmon my answer is that they are interested in seeing the data, just like Joerg; they are also interested that the data is collected professionally and neutrally, so that they can point all sorts of people to it. Most importantly they can use it to take action if TLD service, a service vital to their business, should not be adawquate. So very generally this data helps to keep the DNS stable in a number of ways; that benefits the whole community in general and the RIPE NCC membership in particular. However, quite obviously, the TLD administrators concerned also benefit from this data. They can use it direcly to monitor their operations. They can also use it in the same way as the NCC membership: they can point third parties to it and say that independent and professional measurements show that they are doing a good job. So why should they not pay a fair share of the cost? So far the TLDs we monitor have agreed informally to do that, once the service becomes fully operational. I have had a number of questions like Joerg's already for all gTLDs besides .MIL. I see little chance that we can get them all to agree to pay a share of the cost. I also see that the overhead of making agreements with some of the organisations involoved can be prohibitive. If there is interest from the RIPE community it is easy to monitor these domains. However it is very difficult to do it for some for free and ask the others to pay. So doing that may lead to a situation where the RIPE NCC membership ends up paying the whole bill. I would actually like that because it makes the measurements even more independent and I would not have to invest time into making agreements with the TLD admins, billing, etc. pp. But is this acceptable to the RIPE NCC memebrship in the long run? Comments please! Daniel From jim at rfc1035.com Wed Sep 10 11:24:29 2003 From: jim at rfc1035.com (Jim Reid) Date: Wed, 10 Sep 2003 10:24:29 +0100 Subject: [dns-wg] dnsmon / .org In-Reply-To: Your message of "Wed, 10 Sep 2003 04:58:07 +0200." <200309100258.h8A2w7JY014039@aunt.gaertner.de> Message-ID: <25221.1063185869@gromit.rfc1035.com> >>>>> "Joerg" == Joerg Schumacher writes: Joerg> Having only two nameservers for a tld and Joerg> both of them in a single AS makes me kind of nervous. Indeed. However, don't assume that the number of NS records for a zone is the same as the number (and physical locations) of its name servers. There's a fair amount of anycasting going on. What is curious is ICANN allowing a TLD to put all its name servers in a single AS. They made the new gTLDs use at least 2. So I would have expected ICANN to apply the same requirement for .org when it was moved from Verisign/NSI. From pk at TechFak.Uni-Bielefeld.DE Wed Sep 10 11:26:39 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 10 Sep 2003 11:26:39 +0200 Subject: [dns-wg] dnsmon / .org In-Reply-To: Your message of "Wed, 10 Sep 2003 04:58:07 +0200." <200309100258.h8A2w7JY014039@aunt.gaertner.de> Message-ID: <200309100926.h8A9QdG13795@grimsvotn.TechFak.Uni-Bielefeld.DE> > Having only two nameservers for a tld and both of them in a single AS > makes me kind of nervous. Just because there are two IP addresses only doesn't necessarily mean there are also only two servers/server instances. > makes me wonder if they'll also change the ttl of all NS record > in the org-zone to 5 minutes somewhere in the near future. Ouch! Well, at least they have to learn the effects of RFC 2308 and their current settings in the ORG SOA RR. -Peter From pk at TechFak.Uni-Bielefeld.DE Wed Sep 10 11:32:37 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 10 Sep 2003 11:32:37 +0200 Subject: [dns-wg] dnsmon / .org In-Reply-To: Your message of "Wed, 10 Sep 2003 10:24:29 BST." <25221.1063185869@gromit.rfc1035.com> Message-ID: <200309100932.h8A9WbS13842@grimsvotn.TechFak.Uni-Bielefeld.DE> Jim Reid said: > allowing a TLD to put all its name servers in a single AS. They made > the new gTLDs use at least 2. So I would have expected ICANN to apply As in "info"? No surprise, both RRSets are identical: info 172800 IN NS tld1.ultradns.net info 172800 IN NS tld2.ultradns.net ORG 172800 IN NS tld1.ultradns.net ORG 172800 IN NS tld2.ultradns.net -Peter From brad.knowles at skynet.be Wed Sep 10 11:35:35 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 10 Sep 2003 11:35:35 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: <20030910091746.GA2737@reifa.karrenberg.net> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> <20030910091746.GA2737@reifa.karrenberg.net> Message-ID: At 11:17 AM +0200 2003/09/10, Daniel Karrenberg wrote: > So doing that may lead to a situation where the > RIPE NCC membership ends up paying the whole bill. I would actually > like that because it makes the measurements even more independent > and I would not have to invest time into making agreements with the > TLD admins, billing, etc. pp. > > But is this acceptable to the RIPE NCC memebrship in the long run? > > Comments please! I'm not a paying member of RIPE NCC, so my views don't count. However, I would like to see this sort of monitoring extended by RIPE NCC to all available TLDs, paid for by RIPE NCC. Indeed, I am moving closer to having my own co-lo, and once I do I plan on setting up my own monitoring tools for all TLDs, for my own purposes. I'll probably extend that to sharing lame delegation data with Rob Thomas, etc.... If you are concerned about the cost, you could place a copyright on the collected data so that re-use for RIPE NCC members does not incur an additional charge, and perhaps allow academic re-use by non-RIPE NCC members to likewise be without fee, but for-profit non-RIPE NCC members would be required to contact you first and arrange to pay a fee if they wanted to reuse the data or the results. At that point, it basically comes down to how much enforcement of the copyright you would want to participate in, and how you could make the fee payment scheme at least cover its own administrative costs. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From daniel.karrenberg at ripe.net Wed Sep 10 11:36:04 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Sep 2003 11:36:04 +0200 Subject: [dns-wg] Re: [ncc-services-wg] Re: dnsmon / .org In-Reply-To: <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> <200309100258.h8A2w7JY014039@aunt.gaertner.de> <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> Message-ID: <20030910093604.GC2737@reifa.karrenberg.net> On 10.09 12:18, Hank Nussbacher wrote: > RIPE NCC should only monitor those ccTLDs that are LIRs or that their LIR > is willing to endorse. -Hank I like the principle. However .... How would this endoresement be determined? Doing it simple-mindedly potentially leads to a *very* long list of domains to monitor, and not only (cc)TLDs. Daniel From daniel.karrenberg at ripe.net Wed Sep 10 11:46:59 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Sep 2003 11:46:59 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> <20030910091746.GA2737@reifa.karrenberg.net> Message-ID: <20030910094658.GD2737@reifa.karrenberg.net> On 10.09 11:35, Brad Knowles wrote: > ... > If you are concerned about the cost, you could place a copyright > on the collected data so that re-use for RIPE NCC members does not > incur an additional charge, and perhaps allow academic re-use by > non-RIPE NCC members to likewise be without fee, but for-profit > non-RIPE NCC members would be required to contact you first and > arrange to pay a fee if they wanted to reuse the data or the results. The whole point is that a detaled analysis of the data published for all to see. I cannot see how to apply copyright in this environment. Daniel From ulrich.kiermayr at univie.ac.at Wed Sep 10 11:48:52 2003 From: ulrich.kiermayr at univie.ac.at (Ulrich Kiermayr) Date: Wed, 10 Sep 2003 11:48:52 +0200 Subject: [dns-wg] Re: [ncc-services-wg] Re: dnsmon / .org In-Reply-To: <20030910093604.GC2737@reifa.karrenberg.net> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> <200309100258.h8A2w7JY014039@aunt.gaertner.de> <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> <20030910093604.GC2737@reifa.karrenberg.net> Message-ID: <3F5EF384.2090807@univie.ac.at> Daniel Karrenberg wrote: > On 10.09 12:18, Hank Nussbacher wrote: > > >>RIPE NCC should only monitor those ccTLDs that are LIRs or that their LIR >>is willing to endorse. -Hank > > > I like the principle. However .... > > How would this endoresement be determined? > > Doing it simple-mindedly potentially leads to a *very* long list of > domains to monitor, and not only (cc)TLDs. my 0.02 EUR: So what about monitoring the (cc)TLDs as a Service paid by the Membership, since these are the most relevant for the stability of the net, and sell it for 2+ Level domains? lG uk -- ------------------------------------------------------------------------ Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network Security Universitaetsstrasse 7, 1010 Wien, Austria ------------------------------------------------------------------------ eMail: ulrich.kiermayr at univie.ac.at Tel: (+43 1) 4277 / 14104 Hotline: security.zid at univie.ac.at Fax: (+43 1) 4277 / 9140 Web: http://www.univie.ac.at/zid/security.html ------------------------------------------------------------------------ GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8 From hank at att.net.il Wed Sep 10 12:18:04 2003 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 10 Sep 2003 12:18:04 +0200 Subject: [dns-wg] Re: [ncc-services-wg] Re: dnsmon / .org In-Reply-To: <20030910091746.GA2737@reifa.karrenberg.net> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> <200309100258.h8A2w7JY014039@aunt.gaertner.de> Message-ID: <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> At 11:17 AM 10-09-03 +0200, Daniel Karrenberg wrote: My view: RIPE NCC should only monitor those ccTLDs that are LIRs or that their LIR is willing to endorse. -Hank >[sorry about the useless re-post to dns-wg, finger trouble ....] > >On 10.09 04:58, Joerg Schumacher wrote: > > ... > > Mind adding the nameservers for .ORG to the monitoring? I'd be > > interested in the effects of the recent change in the root zone. > > Having only two nameservers for a tld and both of them in a single AS > > makes me kind of nervous. > > ... > >Weiteres Nachdenken ergab: > >While we so far have only monitored TLDs with whome we have some contact, >we can certainly also monitor any TLD if there is an expressed interest >from the RIPE community. Thechnically this is no problem at all. >Configuring it takes all of 5 minutes and even the alpha version >of the analysis web site on the development server box can easily take >the load. > >However there is a more principle problem and that is why I copied >ncc-services: > >Currently there is a heated debate about (new) NCC services and their >cost. One question asked over and over again there is: Why should NCC >members pay for this service? For dnsmon my answer is that they are >interested in seeing the data, just like Joerg; they are also interested >that the data is collected professionally and neutrally, so that they >can point all sorts of people to it. Most importantly they can use it >to take action if TLD service, a service vital to their business, should >not be adawquate. So very generally this data helps to keep the DNS >stable in a number of ways; that benefits the whole community in general >and the RIPE NCC membership in particular. > >However, quite obviously, the TLD administrators concerned also benefit >from this data. They can use it direcly to monitor their operations. >They can also use it in the same way as the NCC membership: they can >point third parties to it and say that independent and professional >measurements show that they are doing a good job. So why should they >not pay a fair share of the cost? So far the TLDs we monitor have >agreed informally to do that, once the service becomes fully operational. > >I have had a number of questions like Joerg's already for all gTLDs >besides .MIL. I see little chance that we can get them all to agree to >pay a share of the cost. I also see that the overhead of making >agreements with some of the organisations involoved can be prohibitive. >If there is interest from the RIPE community it is easy to monitor these >domains. However it is very difficult to do it for some for free and >ask the others to pay. So doing that may lead to a situation where the >RIPE NCC membership ends up paying the whole bill. I would actually >like that because it makes the measurements even more independent >and I would not have to invest time into making agreements with the TLD >admins, >billing, etc. pp. > >But is this acceptable to the RIPE NCC memebrship in the long run? > >Comments please! > >Daniel From brad.knowles at skynet.be Wed Sep 10 12:39:10 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 10 Sep 2003 12:39:10 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: <20030910094658.GD2737@reifa.karrenberg.net> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> <20030910091746.GA2737@reifa.karrenberg.net> <20030910094658.GD2737@reifa.karrenberg.net> Message-ID: At 11:46 AM +0200 2003/09/10, Daniel Karrenberg wrote: >> If you are concerned about the cost, you could place a copyright >> on the collected data so that re-use for RIPE NCC members does not >> incur an additional charge, and perhaps allow academic re-use by >> non-RIPE NCC members to likewise be without fee, but for-profit >> non-RIPE NCC members would be required to contact you first and >> arrange to pay a fee if they wanted to reuse the data or the results. > > The whole point is that a detaled analysis of the data published > for all to see. I cannot see how to apply copyright in this environment. You can apply copyright both to the collection of the data, and to the compilation of the data. Telephone companies publish directories with a certain number of known false entries. If another telephone company comes along and wholesale copies the data, they get the false entries along with the good ones. The copyright owner can then look for the known false entries, and if they see them, then they can prove that the other company illegally copied the data. You wouldn't want to publish any known false entries, but you can still claim copyright on the compilation of the data, and the analysis you apply. That is, if you want to. You don't have to. But this would be one potential way to allow people who should have free access to the data to do so, while also requiring that those who can afford it to pay their fare share. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From mike.norris at heanet.ie Wed Sep 10 12:47:42 2003 From: mike.norris at heanet.ie (Mike Norris) Date: Wed, 10 Sep 2003 11:47:42 +0100 Subject: [dns-wg] RE: [ncc-services-wg] Re: dnsmon / .org Message-ID: <1948D86456DFD511883900306E1C5B97608B28@exchange.heanet.ie> > I have had a number of questions like Joerg's already for all gTLDs > besides .MIL. I see little chance that we can get them all to agree to > pay a share of the cost. I also see that the overhead of making > agreements with some of the organisations involoved can be prohibitive. > If there is interest from the RIPE community it is easy to monitor these > domains. However it is very difficult to do it for some for free and > ask the others to pay. So doing that may lead to a situation where the > RIPE NCC membership ends up paying the whole bill. I would actually > like that because it makes the measurements even more independent > and I would not have to invest time into making agreements with the TLD admins, > billing, etc. pp. I agree; if people want accuracy and integrity, the measurements have to be taken independently. Mike Norris -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3099 bytes Desc: not available URL: From jim at rfc1035.com Wed Sep 10 13:01:35 2003 From: jim at rfc1035.com (Jim Reid) Date: Wed, 10 Sep 2003 12:01:35 +0100 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: Your message of "Wed, 10 Sep 2003 11:17:46 +0200." <20030910091746.GA2737@reifa.karrenberg.net> Message-ID: <25372.1063191695@gromit.rfc1035.com> >>>>> "Daniel" == Daniel Karrenberg writes: Daniel> But is this acceptable to the RIPE NCC memebrship in the Daniel> long run? Speaking as a non-member of RIPE NCC, I say no. It's not acceptable. To be honest Daniel, I think your mail indicates the way RIPE NCC seems to have lost sight of its raison d'etre. Why is an RIR -- whose main (only?) job is to hand out IP addresses and AS numbers -- getting into other areas that are clearly outside its core business? ARIN and APNIC are providing that core service to their regions with a fraction of the staff that the NCC has. IMO, there must be complete transparency about non-core activities at the NCC. These things should be seen to be self-funding or else making a profit to reduce the costs of the core services and/or membership fees. If they're not, there will be a suspicion that it's the other way round. ie Income from the NCC's monopoly operations are cross-subsidising these non-core activities. That will eventually come to the attention of the anti-competition people in Brussels. This will be a Very Very Bad Thing since there are voices in governments and the Commission who are looking for a pretext to regulate this uncontrolled "Internet thing". Now I know you'll say that NCC does these other things as "a benefit to the community" and "the membership has approved them". I'm not so sure that either of these things are really true. Has a majority of the *membership* -- not those who turn up for the AGM or take the time to vote -- ever approved the activity plan? Has the activity plan ever said something like "non-core activity X costs Y. If it is dropped, the membership fees can be reduced by Z. Do you want to pay for X?"? Now I don't doubt that these non-core activities are a benefit to the community. But perhaps only in the short-term. If the NCC does these things "for free", it makes it almost impossible for others to enter the market. It also undervalues the service being provided. In the long run, this is very, very bad. Take DNS hosting for instance. RIPE NCC provides free service to any TLD that asks. That's fine for poor countries with weak infrastructure. Nobody should dispute that helping them is a good and noble thing and that NCC should be doing that. But serving anyone else means those TLDs are conditioned into getting something for nothing. They get into a mindset that they shouldn't have to pay for DNS service or arrange proper contracts, set up SLAs, put servers in decent IXPs, etc. In short, they don't need to take their responsibilities seriously. That has to be a Very Bad Thing in the long run. Then there's the issue about having so much important DNS stuff on ns.ripe.net. That's a Very Bad Thing too, though I know you disagree with me on this. Here's another example of how NCC crossed the line IMO. The NCC was involved in the development of NSD. Fair enough, you might think. The gene pool of DNS software is too small. So having another DNS implementation is good, so this was/is a benefit to the community. However one of the NCC's members -- my former employer, Nominum -- was/is selling its own DNS implementation. So Nominum's money in membership fees was and is used to fund the NCC to develop software that competed with and undercut Nominum's product. This cannot be right. [As it turns out Nominum doesn't consider NSD to be a credible competitor or a revenue threat to its software, but that's another story.] There may well be further examples of this sort of thing in the other non-core activities of RIPE NCC. Why would anyone pay for a place on my DNSSEC training course (if I was selling one) when NCC is offering their course for free? I fear that your plans for DNS monitoring will similarly distort the market. Firstly, potential customers -- TLDs, regulators, etc -- will expect to get this type of service for free instead of paying for it as they really should. Secondly, it will prevent commercial operators, some of whom could well be NCC members, from providing this kind of service. Who can compete with free? That brings up the concerns about monopolies and cross-subsidies again. Thirdly, this service could become a bottomless pit for NCC resources. What are the current and projected costs and how are they covered? Fourthly, it's an example of NCC extending itself well beyond its core function. Finally, incrementally adding these sorts of non-core services doesn't just entrench the NCC monopoly: it embraces and extends it. Another point. The internet and telecommunications industry has been suffering in the last few years. Budgets have been cut and companies have downsized or gone bust. At this time NCC should be seen to be tightening its belt, not adding new non-core activities. This rant probably doesn't belong in dns-wg. Followups should go somewhere else: the NCC services list perhaps? From jim at rfc1035.com Wed Sep 10 13:12:52 2003 From: jim at rfc1035.com (Jim Reid) Date: Wed, 10 Sep 2003 12:12:52 +0100 Subject: [dns-wg] dnsmon / .org In-Reply-To: Your message of "Wed, 10 Sep 2003 11:32:37 +0200." <200309100932.h8A9WbS13842@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <25408.1063192372@gromit.rfc1035.com> >>>>> "Peter" == Peter Koch writes: >> allowing a TLD to put all its name servers in a single AS. They >> made the new gTLDs use at least 2. So I would have expected >> ICANN to apply Peter> As in "info"? No surprise, both RRSets are identical: Peter> info 172800 IN NS tld1.ultradns.net Peter> info 172800 IN NS tld2.ultradns.net Oooh! When .info was started, it used Nominum's GNS hosting service (RIP). ICANN made Nominum use 2 AS's for the /24s it had for that anycast DNS service. It's strange they didn't insist on 2 AS's when the zone moved to UltraDNS. Not only that the addresses for tld[12].ultradns.net are in one /20! From randy at psg.com Wed Sep 10 13:56:49 2003 From: randy at psg.com (Randy Bush) Date: Wed, 10 Sep 2003 04:56:49 -0700 Subject: [dns-wg] New DNS server References: <200309100041.h8A0f5Fk028845@aunt.gaertner.de> Message-ID: > A pointer to a best current practice document is always helpful. > RFC 2182 is getting old yep. so am i :-). > I guess I'd also recommend that recursion is disabled on the > servers. this was not appropriate for 2182 because the document was not addressing heavily loaded, root, or other servers where it is clear this is clearly needed. > I still wonder why so many DNS operators don't pay attention to > RFC 2182. because they do not associate that not paying attention to a moldy rfc was the reason microsoft.com was off the air for almost a day? randy From randy at psg.com Wed Sep 10 14:00:27 2003 From: randy at psg.com (Randy Bush) Date: Wed, 10 Sep 2003 05:00:27 -0700 Subject: [dns-wg] Re: [ncc-services-wg] Re: dnsmon / .org References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> Message-ID: > RIPE NCC should only monitor those ccTLDs that are LIRs or that > their LIR is willing to endorse. as a lot of folk, whose primary mission it is, monitor, it is not clear to me why the ncc monitors at all. the philosphy that the ncc should provide all the services that we use devolves into ncc making shoes and shirts for us all too. the net works on de- centralization and distributed cooperation and trust. time and again, centralization has been sub-optimal or failed. randy From clive at demon.net Wed Sep 10 12:05:02 2003 From: clive at demon.net (Clive D.W. Feather) Date: Wed, 10 Sep 2003 11:05:02 +0100 Subject: [ncc-services-wg] Re: [dns-wg] Re: dnsmon / .org In-Reply-To: <20030910094658.GD2737@reifa.karrenberg.net> References: <200309100258.h8A2w7JY014039@aunt.gaertner.de> <20030910091746.GA2737@reifa.karrenberg.net> <20030910094658.GD2737@reifa.karrenberg.net> Message-ID: <20030910100502.GP27212@finch-staff-1.thus.net> Daniel Karrenberg said: > > If you are concerned about the cost, you could place a copyright > > on the collected data so that re-use for RIPE NCC members does not > > incur an additional charge, and perhaps allow academic re-use by > > non-RIPE NCC members to likewise be without fee, but for-profit > > non-RIPE NCC members would be required to contact you first and > > arrange to pay a fee if they wanted to reuse the data or the results. > > The whole point is that a detaled analysis of the data published > for all to see. I cannot see how to apply copyright in this environment. Quite easily. Something like this: This data is the copyright of RIPE NCC. A non-exclusive licence is granted to RIPE NCC members for their internal use. A non-exclusive licence is granted for use by any person for non-commercial purposes. In both cases there is no charge for use of the data but it must not be re-published without separate agreement. This does not prevent publication of any other work done making use of this data but not including it. All other rights are reserved. [IANAL, but I understand the principles involved. A Dutch lawyer can no doubt make it formally correct.] -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From schneider at switch.ch Wed Sep 10 14:43:26 2003 From: schneider at switch.ch (Marcel Schneider) Date: Wed, 10 Sep 2003 14:43:26 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: Message from Daniel Karrenberg of "Wed, 10 Sep 2003 11:17:46 +0200." <20030910091746.GA2737@reifa.karrenberg.net> References: <20030910091746.GA2737@reifa.karrenberg.net> <200309100258.h8A2w7JY014039@aunt.gaertner.de> Message-ID: <6610.1063197806@switch.ch> On Wednesday, 10 Sep 2003, Daniel Karrenberg writes: Daniel > While we so far have only monitored TLDs with whome we have some contact, > we can certainly also monitor any TLD if there is an expressed interest > from the RIPE community. Thechnically this is no problem at all. > Configuring it takes all of 5 minutes and even the alpha version > of the analysis web site on the development server box can easily take > the load. Here the views of a (small) ccTLD (CH): 1. Monitoring TLD name servers from different points on earth in a, let's say 'standardized' way, and publish such data is welcome. The points to clarify here are: standardized and 'such', the later designating a subset of all possible measurements or everything. The standardization aspect is is IMO more interesting: we need an RFC for these measurements. 2. Since this kind of monitoring can be bought from e.g. UltraDNS, it may be wise not enter in any competition, meaning it should have a price tag. 3. If it has aprice tag, people will want to know what to get for the money, meaning an SLA is required. An SLA is a contract with technical, organizational, legal and administrative definitions. 4. It is to be determined if RIPE NCC is the appropriate org to offer such services. Good: neutral, professional, some hard- and software already in place and can be used; bad: not really RIPE's core business, the competition with commercial firms. How about a RIPE-spin-off, Netlabs, etc. ? Summary: desirable service, still much to be defined. Marcel From daniel.karrenberg at ripe.net Wed Sep 10 15:50:01 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Sep 2003 15:50:01 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: <25372.1063191695@gromit.rfc1035.com> References: <20030910091746.GA2737@reifa.karrenberg.net> <25372.1063191695@gromit.rfc1035.com> Message-ID: <20030910135001.GB3556@reifa.karrenberg.net> Jim, [I agree it would be better to have this discussion (again) in ncc-services. I have copied it there and encourage people to reply there only.] I could write a reply rant about the individual points in your rant but the main difference of opinion we have is about the mission of the RIPE NCC. This mission is broader than just being a RIR: "The mission of the RIPE NCC is to perform activities for the benefit of the membership, primarily activities that the members need to organise as a group, although they may be competing with each other in other areas. While an activity may result in services being provided to an individual member, performing the activity as a whole must benefit the RIPE NCC membership as a group. Membership is open to anyone using the RIPE NCC services. The activities and services of the RIPE NCC are defined, performed, discussed and evaluated in an open manner. In all of its activities, the RIPE NCC observes strict neutrality and impartiality in regard to individual members." Monitoring DNS and gathering Internet statistics has always been a part of these activities from the very first activity plan in 1991. See ftp://ftp.ripe.net/ripe/docs/ripe-035.txt Of course the activities themselves come and go and those that stay change shape. However the NCC is, and has always been, more than a place that just registers numbers. Daniel ------ Ah, well I'll rant back just for the heck of it. My main point is above. read on at your own risk. Rant-Warning: Moderate to Severe from Varying Directions On 10.09 12:01, Jim Reid wrote: > > To be honest Daniel, I think your mail indicates the way RIPE NCC > seems to have lost sight of its raison d'etre. Why is an RIR -- whose > main (only?) job is to hand out IP addresses and AS numbers -- getting > into other areas that are clearly outside its core business? See above. The NCC is not getting into them it has been there all the time. It is not the RIPE NCC that is changing but it is *you* proposing a change. > ARIN and > APNIC are providing that core service to their regions with a fraction > of the staff that the NCC has. Fraction yes, but not a very small one and not orders of magnitude. Also it appears to me after a quick glance at the ARIN and APNIC web sites that the RIPE NCC fees are very comparable to the fees of the other RIRs, actually slightly lower in many categories. > IMO, there must be complete transparency about non-core activities at > the NCC. I agree completely. > These things should be seen to be self-funding or else making > a profit to reduce the costs of the core services and/or membership > fees. If they're not, there will be a suspicion that it's the other > way round. ie Income from the NCC's monopoly operations are > cross-subsidising these non-core activities. For maximum independence the membership fees should cover all activities. > Now I know you'll say that NCC does these other things as "a benefit > to the community" and "the membership has approved them". I'm not so > sure that either of these things are really true. Has a majority of > the *membership* -- not those who turn up for the AGM or take the time > to vote -- ever approved the activity plan? I beg to disagree. Opener than RIPE NCC and RIPE is hardly possible. If people choose not to participate there is little one can do. One of my major frustrations, past and present. > Has the activity plan ever > said something like "non-core activity X costs Y. If it is dropped. > the membership fees can be reduced by Z. Do you want to pay for X?"? This is very hard to do since activities are so interdependent. The budget gives a general idea of the relative sizes though. > Take DNS hosting for instance. RIPE NCC provides free service to any > TLD that asks. That's fine for poor countries with weak infrastructure. > Nobody should dispute that helping them is a good and noble thing and > that NCC should be doing that. But serving anyone else means those > TLDs are conditioned into getting something for nothing. They get into > a mindset that they shouldn't have to pay for DNS service or arrange > proper contracts, set up SLAs, put servers in decent IXPs, etc. In > short, they don't need to take their responsibilities seriously. That > has to be a Very Bad Thing in the long run. Then there's the issue > about having so much important DNS stuff on ns.ripe.net. That's a Very > Bad Thing too, though I know you disagree with me on this. I see your point and I actually agree, but you have to put it into historic perspective too. There were no commercial offerings when we started this and none were expected any time soon. This activity has helped DNS stability enormously over a long period. And what about our rescue of ns.eu.net? As a matter of fact most bigger TLDs are no longer using either. So the market works. We are not marketing or improving it. But does that mean we have to shut this down now? When? > Here's another example of how NCC crossed the line IMO. The NCC was > involved in the development of NSD. Fair enough, you might think. The > gene pool of DNS software is too small. So having another DNS > implementation is good, so this was/is a benefit to the community. > However one of the NCC's members -- my former employer, Nominum -- > was/is selling its own DNS implementation. So Nominum's money in > membership fees was and is used to fund the NCC to develop software > that competed with and undercut Nominum's product. This cannot be > right. [As it turns out Nominum doesn't consider NSD to be a credible > competitor or a revenue threat to its software, but that's another > story.] We needed this to responsibly operate k.root-servers.net in the light of extremely serious concerns about server software diversity combined with the requirement for open source. We have helped with the design because that is the best way to get one's requirements met. We have helped with the testing because we had to test thoroughly anyway before using it on K. So the additional effort was not that big and the Internet is now a safer place. And we have done all this *extremely* openly. You could say that I came close to bragging about it ;-). > There may well be further examples of this sort of thing in > the other non-core activities of RIPE NCC. Why would anyone pay for a > place on my DNSSEC training course (if I was selling one) when NCC is > offering their course for free? Who is selling DNSSEC courses? The whole point of DISI is to kick-start deployment of something that makes the Internet infrastructure more secure in the absence of clear economic drivers. We have done this before, remember CIDR? > I fear that your plans for DNS monitoring will similarly distort the > market. Firstly, potential customers -- TLDs, regulators, etc -- will > expect to get this type of service for free instead of paying for it > as they really should. Secondly, it will prevent commercial operators, > some of whom could well be NCC members, from providing this kind of > service. Who can compete with free? Yes, but is there a market? And can this be done independently and neutrally for a fee? Again we needed this for k.root-servers.net operations. > That brings up the concerns about > monopolies and cross-subsidies again. Thirdly, this service could > become a bottomless pit for NCC resources. What are the current and > projected costs and how are they covered? My estimate of the incremental cost of developing it so far are about 1-2 weeks of a network engineer, and 5 weeks of a chief scientist. However it is based on the network of test boxes and on the RIPE NCC web presence. How do you account for that? Difficult. We also needed something like this for operating k.root-servers.net responsibly. One could argue that the incremental cost to that is even less. But again: This helps DNS stability and Internet self-regulation. If there is another viable business model to do this at the required quality and neutrality I am all for it. I just do not see that. > of NCC extending itself well beyond its core function. Finally, > incrementally adding these sorts of non-core services doesn't just > entrench the NCC monopoly: it embraces and extends it. See above. DNS monitoring is an NCC activity since 1991. > Another point. The internet and telecommunications industry has been > suffering in the last few years. Budgets have been cut and companies > have downsized or gone bust. At this time NCC should be seen to be > tightening its belt, not adding new non-core activities. The RIPE NCC is another kettle of fish than a commercial company. You need stability and neutrality and that has its price! What if you lean it until it falls over at the most inconveient time? Talking about fairness: The RIPE NCC does not have stock options either. Yes I have a relatively secure job, but that's because I think the RIPE NCC is important for the Internet in Europe and I chose for it *in good times* when there were *a lot* more interesting offers in terms of remuneration. Daniel From pk at TechFak.Uni-Bielefeld.DE Wed Sep 10 15:53:06 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 10 Sep 2003 15:53:06 +0200 Subject: [dns-wg] dnsmon / .org In-Reply-To: Your message of "Wed, 10 Sep 2003 14:12:10 +0200." <200309101212.h8ACCAHc058376@bartok.sidn.nl> Message-ID: <200309101353.h8ADr6d14572@grimsvotn.TechFak.Uni-Bielefeld.DE> Jaap Akkerhuis said: > Well, at least they have to learn the effects of RFC 2308 and their curre [...] > A lot of people need to do that. We (.nl) ourselve also were guilty. > Something to put on the agenda for the next meeting? yes, definitely. And, although that explicitly does not address TLD zones it's time to update RIPE 203 now. SOA timers are an item for the "DNS quality" work on the "predelegation test basket" as well. -Peter From jaap at sidn.nl Wed Sep 10 14:05:13 2003 From: jaap at sidn.nl (Jaap Akkerhuis) Date: Wed, 10 Sep 2003 14:05:13 +0200 Subject: [dns-wg] dnsmon / .org In-Reply-To: Your message of Wed, 10 Sep 2003 10:24:29 +0100. <25221.1063185869@gromit.rfc1035.com> Message-ID: <200309101205.h8AC5DHc058320@bartok.sidn.nl> Joerg> Having only two nameservers for a tld and Joerg> both of them in a single AS makes me kind of nervous. Indeed. However, don't assume that the number of NS records for a zone is the same as the number (and physical locations) of its name servers. There's a fair amount of anycasting going on. What is curious is ICANN allowing a TLD to put all its name servers in a single AS. They made the new gTLDs use at least 2. So I would have expected ICANN to apply the same requirement for .org when it was moved from Verisign/NSI. Note, org isn't the only gtld announced by a single AS. You wouldn't be suprised to hear that that info as well. The other one has another problem: The tld[12] nameserver don't give authorative answers about nameservers for info. jaap dig @tld1.ultradns.net info ns ; <<>> DiG 9.2.2 <<>> @tld1.ultradns.net info ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38910 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;info. IN NS ;; ANSWER SECTION: info. 86400 IN NS tld2.ultradns.net. info. 86400 IN NS tld1.ultradns.net. ;; ADDITIONAL SECTION: tld2.ultradns.net. 86400 IN A 204.74.113.1 tld1.ultradns.net. 86400 IN A 204.74.112.1 From jaap at sidn.nl Wed Sep 10 14:12:10 2003 From: jaap at sidn.nl (Jaap Akkerhuis) Date: Wed, 10 Sep 2003 14:12:10 +0200 Subject: [dns-wg] dnsmon / .org In-Reply-To: Your message of Wed, 10 Sep 2003 11:26:39 +0200. <200309100926.h8A9QdG13795@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <200309101212.h8ACCAHc058376@bartok.sidn.nl> > makes me wonder if they'll also change the ttl of all NS record > in the org-zone to 5 minutes somewhere in the near future. Ouch! Well, at least they have to learn the effects of RFC 2308 and their current settings in the ORG SOA RR. A lot of people need to do that. We (.nl) ourselve also were guilty. Something to put on the agenda for the next meeting? jaap From hank at att.net.il Wed Sep 10 16:48:51 2003 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 10 Sep 2003 16:48:51 +0200 Subject: [dns-wg] Re: [ncc-services-wg] Re: dnsmon / .org In-Reply-To: <20030910093604.GC2737@reifa.karrenberg.net> References: <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> <200309100258.h8A2w7JY014039@aunt.gaertner.de> <200309100258.h8A2w7JY014039@aunt.gaertner.de> <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> Message-ID: <5.1.0.14.2.20030910164634.00b19830@max.att.net.il> At 11:36 AM 10-09-03 +0200, Daniel Karrenberg wrote: >On 10.09 12:18, Hank Nussbacher wrote: > > > RIPE NCC should only monitor those ccTLDs that are LIRs or that their LIR > > is willing to endorse. -Hank > >I like the principle. However .... > >How would this endoresement be determined? Each LIR would be entitled to one ccTLD to be monitored. Most won't need it. Assuming there are about 50 countries in the RIPE area, and about 3500 LIRs, I am sure that one can find a LIR to support a ccTLD to be monitored. That means that the other countries in ARIN/APNIC/LACLIC would have to fund their own service. -Hank LIR: il.iucc >Doing it simple-mindedly potentially leads to a *very* long list of >domains to monitor, and not only (cc)TLDs. > > >Daniel From daniel.karrenberg at ripe.net Wed Sep 10 16:29:30 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Sep 2003 16:29:30 +0200 Subject: [dns-wg] Re: [ncc-services-wg] Re: dnsmon / .org In-Reply-To: <5.1.0.14.2.20030910164634.00b19830@max.att.net.il> References: <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> <200309100258.h8A2w7JY014039@aunt.gaertner.de> <200309100258.h8A2w7JY014039@aunt.gaertner.de> <5.1.0.14.2.20030910121619.00b2b148@max.att.net.il> <5.1.0.14.2.20030910164634.00b19830@max.att.net.il> Message-ID: <20030910142930.GF3556@reifa.karrenberg.net> On 10.09 16:48, Hank Nussbacher wrote: > At 11:36 AM 10-09-03 +0200, Daniel Karrenberg wrote: > > ... > >How would this endoresement be determined? > > Each LIR would be entitled to one ccTLD to be monitored. Most won't need > it. Assuming there are about 50 countries in the RIPE area, and about 3500 > LIRs, I am sure that one can find a LIR to support a ccTLD to be > monitored. That means that the other countries in ARIN/APNIC/LACLIC would > have to fund their own service. Now this *is* simple-minded: The end-game is that we monitor all TLDs because there are less TLDs than RIPE NCC members and there will be some of them intereste in TLDs outside the RIPE region and many of them will be interested in some gTLDs. Next we will get questions about 2nd level domains. Try again. Hint: One might establish a ranking and set a monitoring capacity. Daniel From johani at autonomica.se Wed Sep 10 17:15:33 2003 From: johani at autonomica.se (Johan Ihren) Date: Wed, 10 Sep 2003 17:15:33 +0200 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: <20030910135001.GB3556@reifa.karrenberg.net> (Daniel Karrenberg's message of "Wed, 10 Sep 2003 15:50:01 +0200") References: <20030910091746.GA2737@reifa.karrenberg.net> <25372.1063191695@gromit.rfc1035.com> <20030910135001.GB3556@reifa.karrenberg.net> Message-ID: Daniel Karrenberg writes: Hi Daniel, >> There may well be further examples of this sort of thing in the >> other non-core activities of RIPE NCC. Why would anyone pay for a >> place on my DNSSEC training course (if I was selling one) when NCC >> is offering their course for free? > > Who is selling DNSSEC courses? The whole point of DISI is to kick-start We do. I.e. not Autonomica, but Lars-Johan Liman, Patrik F?ltstr?m and myself privately teach DNS courses on all levels since years back, including a two day course on DNSSEC. And, yes, we have had students actually cancel their seats at a scheduled course because RIPE NCC staff came to Stockholm and taught DNSSEC for free. While I can personally live with that (at least as long as you don't turn up in Stockholm too often ;-) I do think it is a clear example of the difficulties with your position of being effectively a monopoly that wants to do the right thing for the Internet. Johan PS. With the Autonomica hat on: we also do DNS monitoring, quite similar to dnsmon, and for exactly the same reasons, i.e. to monitor our various DNS services, i.root-servers.net being one of them. To offset our costs for this we are offering this service on some sort of cost recovery basis to interested parties like TLDs. Obviously even a cheap service will never be able to compete with a free one, especially since the hassle of the billing process will make both parties walk away. And, yes, we are RIPE members, so just as in the Nominum case this is our membership fees working against us. In the end this is all about education. Everyone needs to understand that there is a cost associated with providing a service. If the service is offered "for free" that is just a metaphor for "someone else is paying for it". From paf at paf.se Thu Sep 11 04:31:37 2003 From: paf at paf.se (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Wed, 10 Sep 2003 19:31:37 -0700 Subject: [dns-wg] Re: dnsmon / .org In-Reply-To: References: <20030910091746.GA2737@reifa.karrenberg.net> <25372.1063191695@gromit.rfc1035.com> <20030910135001.GB3556@reifa.karrenberg.net> Message-ID: <119EB430-E400-11D7-A062-000A959CF516@paf.se> On 10 sep 2003, at 08.15, Johan Ihren wrote: > I.e. not Autonomica, but Lars-Johan Liman, Patrik F?ltstr?m and myself > privately teach DNS courses on all levels since years back, including > a two day course on DNSSEC. > > And, yes, we have had students actually cancel their seats at a > scheduled course because RIPE NCC staff came to Stockholm and taught > DNSSEC for free. > > While I can personally live with that (at least as long as you don't > turn up in Stockholm too often ;-) I do think it is a clear example of > the difficulties with your position of being effectively a monopoly > that wants to do the right thing for the Internet. FWIW, as Johan explicitly say he _personally_ can live with it, let me also say I find this being ok, even though it feels a bit weird when RIPE NCC is competing on the market with a price we can not beat. So, don't come too often ;-) That said, totally in the world, I think there is not enough people teaching DNS. Or rather, there are enormous number of people which _should_ take a training course. paf From kurtis at kurtis.pp.se Thu Sep 11 14:25:14 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Sep 2003 14:25:14 +0200 Subject: [ncc-services-wg] Re: [dns-wg] Re: dnsmon / .org In-Reply-To: <20030910135001.GB3556@reifa.karrenberg.net> Message-ID: Daniel, >> Another point. The internet and telecommunications industry has been >> suffering in the last few years. Budgets have been cut and companies >> have downsized or gone bust. At this time NCC should be seen to be >> tightening its belt, not adding new non-core activities. > > The RIPE NCC is another kettle of fish than a commercial company. > You need stability and neutrality and that has its price! > What if you lean it until it falls over at the most inconveient time? > There is a big danger in what you say above. Stability yes - but not at any price. The stability is there for the core service of the NCC, to act as a RIR. The rest is benefits that we get on the side. What most people have been asking for is transparency and accountability on why, and to what costs certain projects are done. Saying that this has always been part of the NCCs tasks is not an answer to those questions. Best regards, - kurtis - From hpholen at tiscali.no Fri Sep 12 18:00:56 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 12 Sep 2003 18:00:56 +0200 (CEST) Subject: [dns-wg] Re: [ncc-services-wg] Re: dnsmon / .org In-Reply-To: <20030910093604.GC2737@reifa.karrenberg.net> Message-ID: > On 10.09 12:18, Hank Nussbacher wrote: > > > RIPE NCC should only monitor those ccTLDs that are LIRs or that their LIR > > is willing to endorse. -Hank > > I like the principle. However .... > > How would this endoresement be determined? You offer the service only to members, so if a names server operator wants this service they sign up as a member. You probably should add a new billig category for this. But that should be simple following the last AGM. > Doing it simple-mindedly potentially leads to a *very* long list of > domains to monitor, and not only (cc)TLDs. Doing it this way the list will never be longer than your membership list. -hph From hpholen at tiscali.no Fri Sep 12 18:10:53 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 12 Sep 2003 18:10:53 +0200 (CEST) Subject: [ncc-services-wg] Re: [dns-wg] Re: dnsmon / .org In-Reply-To: Message-ID: > And, yes, we have had students actually cancel their seats at a > scheduled course because RIPE NCC staff came to Stockholm and taught > DNSSEC for free. This is, in mu personal oppinion very unforunate. While I agree bootstraping new fundamental internet infrastrucure services is a good thing (tm), I think it is very unfortunate that the result of RIPE NCC providing such training for free is that comercial enterprises do not develop this area into a sound business. It is clearer to me that the matter of charging for training should be reconcidered. -hph From woeber at cc.univie.ac.at Fri Sep 12 15:31:54 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 12 Sep 2003 15:31:54 +0200 Subject: [dns-wg] Re: dnsmon / .org Message-ID: <00A25CCB.757541F4.30@cc.univie.ac.at> I fail to see an "obvious", structural relationship between a LIR and the parties responsible for the reliable operation of a ccTLD name service? Wilfried. ______________________________________________________________________ >At 11:36 AM 10-09-03 +0200, Daniel Karrenberg wrote: >>On 10.09 12:18, Hank Nussbacher wrote: >> >> > RIPE NCC should only monitor those ccTLDs that are LIRs or that their LIR >> > is willing to endorse. -Hank >> >>I like the principle. However .... >> >>How would this endoresement be determined? > >Each LIR would be entitled to one ccTLD to be monitored. Most won't need >it. Assuming there are about 50 countries in the RIPE area, and about 3500 >LIRs, I am sure that one can find a LIR to support a ccTLD to be >monitored. That means that the other countries in ARIN/APNIC/LACLIC would >have to fund their own service. > >-Hank >LIR: il.iucc From andrei at ripe.net Mon Sep 22 11:34:06 2003 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 22 Sep 2003 11:34:06 +0200 Subject: [dns-wg] Next phase in deploying anycast instances of k.root-servers.net Message-ID: <3F6EC20E.4040906@ripe.net> Dear colleague, After discussions at the last RIPE Meeting, we would like to clarify our current thinking about adding further anycast instances to k.root-servers.net. This message sets out the direction and further details the requirements for hosting such an instance and calls for expressions of interest from the Internet community to support this activity. I look forward to your support. Best regards, Andrei Robachevsky CTO, RIPE NCC General requirements and guidelines for expressions of interest for hosting a mirror instance of k.root-servers.net ============================================================== Introduction ------------ The RIPE NCC operates k.root-servers.net, one of the servers used as a name server for the DNS root zone. In order to further improve the distribution of the service in various Internet regions and its resilience against DDoS attacks the RIPE NCC is deploying mirror instances of the server worldwide as described in the ripe document "Distributing K-Root Service by Anycast Routing of 193.0.14.129" (RIPE 268). The first phase of this project included moving the cold standby instance of the server to service using anycast routing. This phase was completed in July 2003 and k.root-servers.net is currently deployed in two locations (LINX, London and AMS-IX, Amsterdam). The next phase will be mostly focused on the deployment of nodes with limited reachability in the RIPE NCC service region. The main motivation for this phase is: - Improving access to k.root-servers.net for a significant ISP community. - Isolating impact of an "external" DDoS attack. - Localising impact of a "local" DDoS attack. This document sets the direction and further details the requirements for hosting an instance of the k.root-servers.net server so that interested organisations may understand the general intentions and requirements of this phase of the project. Organisations wishing to express their interest in supporting this important activity may do so by following the guidelines below. Physical Sites -------------- Suitable sites for the location of mirror instances of the k.root-servers.net server will in most cases include an Internet exchange (IX) that offers a very high standard of infrastructure and Internet connectivity. The members of the IX should represent a significant ISP community in the region. In terms of physical infrastructure and services, a hosting site must satisfy the general requirements for root server locations, which are described in section 3.1 of RFC2870. Server Hardware --------------- All hardware for the instance of k.root-servers.net will be supplied at the host's expense. In most cases a typical configuration will be assembled by the RIPE NCC and shipped to the hosting site. The hardware will remain the property of the host, but will be operated solely by the RIPE NCC. The host will be asked to provide onsite physical support. However there is no requirement for the host to perform maintenance on the systems themselves, and administrative access will not be available. Connectivity and reachability ----------------------------- Though global reachability is not required for the instance of the k.root-servers.net server, it is critical that access to the server is provided in an open and non-discriminative manner to all members of the IX. However, it is important that global transit is co-ordinated with the RIPE NCC. Requirements for reachability are different for the management network of k.root-servers.net that is used by the RIPE NCC to perform system administration. It is required that connectivity of the management network is global and reliable. Expressions of Interest ----------------------- The RIPE NCC invites expressions of interest from organisations such as Internet Exchanges or other organisations that represent a significant ISP community in the region. Expressions of Interest should include details of the support which is being offered, such as hosting and connectivity. Please provide as much detail as possible, including physical infrastructure details, upstream and peer network connectivity details, and bandwidth availability. Please refer specifically to the provisions of RFC2870 in your response. Please send expressions of interest to: k-anycast at ripe.net If any further information is required, please also use this address. From brad.knowles at skynet.be Tue Sep 23 18:36:53 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue, 23 Sep 2003 18:36:53 +0200 Subject: [dns-wg] Fwd: Re: against broken tld content Message-ID: Folks, I don't know if anyone here has seen this, but Ohta-san submitted this draft to IETF DNSOP a few days ago. Should we start discussing this here? >From: Masataka Ohta >Subject: Re: against broken tld content >To: dnsop at cafax.se >Date: Tue, 23 Sep 2003 02:25:10 +0859 () >Sender: owner-dnsop at cafax.se > >Below is a revised draft ID with the following changes. > >1) "Content" is added to title. > > Distributed Actions Against Broken TLD Content > >2) some text added to "1. Introduction". > >< the problem, this memo describes distriburted actions as a short >< term solution to protect the Internet against broken TLD zone content. >--- >> the problem, this memo describes distributed actions as a short >> term solution to protect the Internet against broken TLD zone content >> and the damage caused by it. > >3) some text added to "3. Actions of ISPs". > >> If such action considerably reduces the number of available TLD servers, >> ISPs may operate their own servers overriding the IP addresses >> of formal TLD servers. >> Such overriding servers should have >> a copy of old zone content known not to be broken. >> Or, if the fix for the zone content is obvious and easy, the >> overriding servers may act as semi transparent proxies to >> formal servers (routing tricks necessary as IP addresses of >> the proxies and the formal servers are identical) modifying only >> the broken part. >> Considering that NAT-based network providers, >> which provide limited service such as web and e-mail with semi >> transparent DNS proxies, are often called ISP, it is fine >> for ISPs to use DNS proxies, especially when it improves web >> and/or e-mail environment of their customers. However, advance negotiation >> should be made, if the override affects other ISPs. > >Any further comment? > > Masataka Ohta > >-- > > > > > > >INTERNET DRAFT M. Ohta >draft-ohta-broken-tld--1.txt Tokyo Institute of Technology > September 2003 > > Distributed Actions Against Broken TLD Content > >Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html The list of Internet-Draft > Shadow Directories can be accessed at http://www.ietf.org/shadow.html > >Abstract > > This memo describes actions against broken content of a primary > server of a TLD. Without waiting for an action of some, if any, > central authority, distributed actions TLD server operators and ISPs > can settle the issue, for a short term. > >1. Introduction > > DNS is a fully distributed database of domain names and their > associated values with loose integrity. > > However, the primary server of a zone is a single point of failure of > the zone to hold the current most copy of the zone and such a failure > at TLD can cause a lot of damage to the Internet. > > As it may take time for a central authority, if any, take care of the > problem, this memo describes distributed actions as a short term > solution to protect the Internet against broken TLD zone content and > the damage caused by it. > > The long term solution is to let the primary server operator fix the > content or to change the primary server operator, which may involve a > > > >M. Ohta Expires on March 22, 2004 [Page 1] > >INTERNET DRAFT Broken TLD June 2003 > > > central authority. > > Similar technique is applicable to root servers with broken contents. > >2. Actions of TLD Server Operators > > A TLD server operator who have found that TLD zone content is broken > should disable zone transfer and use a copy of old zone content known > not to be broken. > > Or, if the fix for the zone content is obvious and easy, the operator > may manually or automatically edit the content of the current most > one without updating SOA serial number. In this case, zone transfer > may not be disabled, though actions of ISPs described in section 3 > may make the transfer from servers of broken content impossible. > >3. Actions of ISPs > > ISPs should disable routes to TLD servers with broken content and/or > filter packets to/from the TLD servers. > > If such action considerably reduces the number of available TLD > servers, ISPs may operate their own servers overriding the IP > addresses of formal TLD servers. Such overriding servers should have > a copy of old zone content known not to be broken. Or, if the fix > for the zone content is obvious and easy, the overriding servers may > act as semi transparent proxies to formal servers (routing tricks > necessary as IP addresses of the proxies and the formal servers are > identical) modifying only the broken part. Considering that NAT- > based network providers, which provide limited service such as web > and e-mail with semi transparent DNS proxies, are often called ISP, > it is fine for ISPs to use DNS proxies, especially when it improves > web and/or e-mail environment of their customers. However, advance > negotiation should be made, if the override affects other ISPs. > > ISPs should periodically check the servers, whether they still > contain broken content or not. > >4. Security Considerations > > As for security, TLD servers should never have broken content. > >5. Author's Address > > Masataka Ohta > Graduate School of Information Science and Engineering > Tokyo Institute of Technology > 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN > > > >M. Ohta Expires on March 22, 2004 [Page 2] > >INTERNET DRAFT Broken TLD June 2003 > > > Phone: +81-3-5734-3299 > Fax: +81-3-5734-3299 > EMail: mohta at necom830.hpcl.titech.ac.jp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >M. Ohta Expires on March 22, 2004 [Page 3] > >#---------------------------------------------------------------------- ># To unsubscribe, send a message to . > -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From jim at rfc1035.com Tue Sep 23 19:21:05 2003 From: jim at rfc1035.com (Jim Reid) Date: Tue, 23 Sep 2003 18:21:05 +0100 Subject: [dns-wg] Fwd: Re: against broken tld content In-Reply-To: Your message of "Tue, 23 Sep 2003 18:36:53 +0200." Message-ID: <13586.1064337665@gromit.rfc1035.com> >>>>> "Brad" == Brad Knowles writes: Brad> Folks, I don't know if anyone here has seen this, but Brad> Ohta-san submitted this draft to IETF DNSOP a few days ago. Brad> Should we start discussing this here? Anyone on this list is welcome to discuss anything that's DNS-related here. However my personal preference would be for discussions about IETF drafts to take place on the relevant IETF mailing lists. That's really where those discussions should go. IMO it would be OK to make an announcement about a draft so that this list's membership could read that draft. And possibly comment on it on the relevant IETF mailing list. That being said, if people want to discuss Ohta's draft here, fine.