From ncc at ripe.net Thu Sep 1 16:35:24 2005 From: ncc at ripe.net (Paul Rendek) Date: Thu, 01 Sep 2005 16:35:24 +0200 Subject: [dns-wg] RIPE Policy Development Process Message-ID: <5.2.1.1.2.20050901162916.027803b8@mailhost.ripe.net> Dear Colleagues We are pleased to announce that Rob Blokzijl, RIPE Chair, has published a new RIPE Document, "Policy Development Process in RIPE", (ripe-350). This document formally describes the policy development process. The updated process is operational from today, 1 September 2005. A new RIPE web page describes all the active policy proposals and their status. Each proposal has a page showing its history, status and all supporting documentation. This page can be found at: http://www.ripe.net/ripe/policies/proposals/index.html A new mailing list has been created for announcing policy proposals and tracking them through the policy development process. This is not a discussion list; discussions will continue to take place on relevant RIPE Working Group lists and at RIPE Meetings. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce List archives are available at: http://www.ripe.net/ripe/maillists/archives/policy-announce/ Kind regards Paul Rendek Head of Member Services and Communications RIPE NCC From henk at ripe.net Mon Sep 12 09:39:48 2005 From: henk at ripe.net (Henk Uijterwaal) Date: Mon, 12 Sep 2005 09:39:48 +0200 Subject: [dns-wg] DNSSEC deployment on the reverse tree. Message-ID: <6.2.1.2.2.20050912093453.02ced638@localhost> Dear Colleagues, In June, Olaf Kolkman wrote: >The RIPE NCC has been involved with the development of the DNSSEC >protocol. Now that the protocol has become available, we plan to >implement DNSSEC on our domains in the reverse DNS tree. The >deployment of DNSSEC is the second and last phase of the Reverse DNS >restructuring project. [...] >We welcome your feedback on this poposal before 1 August 2005. Please >send your comments to the DNS Working Group Mailing List. The comment period was extended to 1 September and some comments were posted to the list. These have all been incorporated and the new documents are at: >You can find the proposed policy at: > >http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html. > "DNSSEC Key Maintenance Procedure" > >http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html > "Procedure for Requesting DNSSEC Delegations" > >http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html I'm going to suggest to the chairs of the WG to do a last call on these documents and have them published as RIPE documents. Kind regards, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) From jim at rfc1035.com Mon Sep 12 14:11:57 2005 From: jim at rfc1035.com (Jim Reid) Date: Mon, 12 Sep 2005 13:11:57 +0100 Subject: [dns-wg] Last call for DNSSEC policy proposal Message-ID: <884EFFFD-F064-41F7-862E-5F01321DCE99@rfc1035.com> Colleagues, you'll have seen the email from Henk earlier today about the NCC's policy proposal concerning DNSSEC deployment. We're following the new policy development process (PDP) even though this hasn't been formally adopted yet. The discussion phase is now over and Henk has updated the proposal to incorporate the comments that were made. The new documents are at: http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html http://www.ripe.net/rs/reverse/dnssec/key-maintenance- procedure.html http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html The next stage in the new PDP is the Last Call phase. So this message is to announce that the proposal has entered this phase. We now have 4 weeks to decide whether there is consensus for this proposal. Hopefully this decision can be endorsed by the WG Chairs during RIPE51. From jaap at NLnetLabs.nl Tue Sep 13 16:32:35 2005 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 13 Sep 2005 16:32:35 +0200 Subject: [dns-wg] RIPE-51 contributions sought. Message-ID: <200509131432.j8DEWZCj093440@bartok.nlnetlabs.nl> Hi All, It is that time off the year again. Over a month or so you all will be gathering in ``sunny'' Amsterdam for the RIPE-51 meeting. The DNS working group meeting is at Wednesday 16:00-17:00 and Thursday 11:00-12:30, see the meeting plan at the usual place: http://www.ripe.net/ripe/meetings/ripe-51/meeting-plan.html Hereby we are seeking contributions of the agenda. Note that the success of the meeting is as usual depending on you contributions. jaap From jpsp at fccn.pt Tue Sep 20 12:43:09 2005 From: jpsp at fccn.pt (=?ISO-8859-1?Q?Jo=E3o_Pagaime?=) Date: Tue, 20 Sep 2005 11:43:09 +0100 Subject: [dns-wg] NREN swapping secondary name-servers? Message-ID: <432FE7BD.3030301@fccn.pt> Hello all, My name is Jo?o Pagaime and I work for FCCN, the Portuguese NREN that also operates the ccTLD-PT We're about to move "edu.pt" to a standalone DNS zone, and I'm searching for a secondary name server outside AS1930 Is there any NREN interested in swapping seconday name service? We can provide for secondary name service along the lines layed out bellow Our general requirements guidelines for the edu.pt are the following: availability requirements------------------------ It would be nice to have no more than 12 hours down time every 3 months that's 99.4% of availability response time------------------------------------ Less that 140 ms "DNS round-trip-time", measured from the .PT primary name server "DNS round-trip-time" on this context is considered to be the time it takes to answer a DNS query. We use "dig" to get this value estimated zone size------------------------------ about 2MB (measured at the secondary server text file) estimated query load-------------------------------- 20 queries/sec update/transfer strategy----------------------------- AXFR with notifies (no need to actually respond to notify. SOA timers suffice) 3 updates every day zone access policy-------------------------------- restricted Thank you, Jo?o Pagaime From jpsp at fccn.pt Wed Sep 21 11:10:55 2005 From: jpsp at fccn.pt (=?ISO-8859-1?Q?Jo=E3o_Pagaime?=) Date: Wed, 21 Sep 2005 10:10:55 +0100 Subject: [dns-wg] (thanks!) Re: NREN swapping secondary name-servers? In-Reply-To: <432FE7BD.3030301@fccn.pt> References: <432FE7BD.3030301@fccn.pt> Message-ID: <4331239F.2090206@fccn.pt> Hello all, Thanks for the kind offers for secondary name-servers for edu.pt I think we have enough servers, and it will be a healthy DNS zone, with good spread, and IPv6 connectivity Thanks again, best regards, Jo?o Pagaime - FCCN.pt On 20-09-2005 11:43, Jo?o Pagaime wrote: > Hello all, > > My name is Jo?o Pagaime and I work for FCCN, the > Portuguese NREN that also operates the ccTLD-PT > > We're about to move "edu.pt" to a standalone DNS zone, > and I'm searching for a secondary name server outside > AS1930 > > Is there any NREN interested in swapping seconday > name service? We can provide for secondary name service > along the lines layed out bellow > > Our general requirements guidelines for the edu.pt are > the following: > > availability requirements------------------------ > > It would be nice to have no more than 12 hours down > time every 3 months > > that's 99.4% of availability > > response time------------------------------------ > > Less that 140 ms "DNS round-trip-time", measured from the > .PT primary name server > > "DNS round-trip-time" on this context is considered > to be the time it takes to answer a DNS query. > We use "dig" to get this value > > estimated zone size------------------------------ > > about 2MB (measured at the secondary server text file) > > estimated query load-------------------------------- > > 20 queries/sec > > update/transfer strategy----------------------------- > > AXFR with notifies (no need to actually respond > to notify. SOA timers suffice) > > 3 updates every day > > zone access policy-------------------------------- > > restricted > > Thank you, > Jo?o Pagaime > From brettcarr at ripe.net Mon Sep 26 15:57:04 2005 From: brettcarr at ripe.net (Brett Carr) Date: Mon, 26 Sep 2005 15:57:04 +0200 (CEST) Subject: [dns-wg] DNSSEC Signed Zones at the RIPE NCC Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Colleagues, As part of the project to deploy DNSSEC in the RIPE NCC Service region, we have been signing a number of zones over recent weeks. The following zones are currently signed: ripe.net ripencc.com ripencc.net ripencc.org ripe-ncc.com ripe-ncc.net ripe-ncc.org If you want to configure your resolvers to verify these zones using DNSSEC, you can get the key signing keys for these zones from: https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys.txt. For information about how to use the keys, and further details about DNSSEC deployment at the RIPE NCC, see: http://www.ripe.net/projects/disi/keys/. Regards Brett Carr RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFDN/0pP/nJBHjtetsRAg+dAJ0fMl1aZPRr+r2P+SIZJQZVlQC7ogCfXpYK LsbPUyhiOoYPBthLRf7lDoc= =AQQB From jaap at NLnetLabs.nl Tue Sep 27 21:41:01 2005 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 27 Sep 2005 21:41:01 +0200 Subject: [dns-wg] upcoming meeting ripe 51 Message-ID: <200509271941.j8RJf1Uf021460@bartok.nlnetlabs.nl> The minutes of the ripe-51 DNS-WG can found at the usual place: http://ripe.net/ripe/wg/dns/r50-minutes.html The draft agenda follows below. I'll be off ine the week before the RIPE meeting, so please send remarks etc. directly to the list. jaap Agenda Item Time Speaker Title ------------------------------------------------------------------------------------- Wednesday 16:00 -- 17:00 ------------------------------------------------------------------------------------- A 2 min Agenda bashing & Scribe B 10 min Chair Minutes ripe-50; Action points Reports C.1 5 min Olaf Kolkman -- NLnet Labs IETF DNSEXT WG C.2 5 min Marcos Sanz -- DENIC IETF CRISP WG C.3 5 min Scott Hollenbeck -- Verisign EPP: The next steps Proxied by Jaap Talks D 20 min Lorenzo Colitti -- Ripe NCC Effect of anycast on K-root: early results E 10 min Carsten Strotmann -- Men & Mice DNS Guru contest ------------------------------------------------------------------------------------- Thursday 11:00 -- 12:30 ------------------------------------------------------------------------------------- F 10 min Brett Carr -- RIPE NCC DNS restructuring update at RIPE NCC G 15 min Andrei Robachevsky -- Ripe NCC Deprecation of ip6.int H 15 min Johan Ihren -- Autonomica Key rollover Paper & Tools I 15 min Lars-Johan Liman -- Autonomica Ripe NCC secondary service policy J 15 min Jakob Schlyter -- SUNIC DNSSEC in Sweden K 10 min Peter Koch -- Denic Update to RIPE 203 Recommenda- tions for SOA values L 10 min Peter Koch -- Denic ENUM DNS predelegation checks Z 3 min AOB ------------------------------------------------------------------------------------- From rushshe10 at gmail.com Wed Sep 28 07:38:28 2005 From: rushshe10 at gmail.com (Chandrashekhar Kulkarni) Date: Wed, 28 Sep 2005 11:08:28 +0530 Subject: [dns-wg] DNS USer Message-ID: Any one how know about dns with kerberose From jim at rfc1035.com Wed Sep 28 17:19:15 2005 From: jim at rfc1035.com (Jim Reid) Date: Wed, 28 Sep 2005 16:19:15 +0100 Subject: [dns-wg] DNS USer In-Reply-To: References: Message-ID: <865EAA56-D217-497E-AEAD-283A89595ACD@rfc1035.com> On Sep 28, 2005, at 06:38, Chandrashekhar Kulkarni wrote: > Any one how know about dns with kerberose Could you please expand on what you mean by this? Are you asking about using Kerberos to authenticate DNS queries or Dynamic Updates? Or are you asking about using the DNS to store/distribute Kerberos tickets? Or have you something else in mind? To the best of my knowledge the only documented interaction between Kerberos and the DNS is GSS-TISG: Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS. This is documented in RFC3645. GSS-TSIG provides a mechanism for clients and servers to use Kerberos to authenticate DNS transactions. From ops at ripe.net Thu Sep 29 10:30:40 2005 From: ops at ripe.net (RIPE NCC Operations) Date: Thu, 29 Sep 2005 10:30:40 +0200 Subject: [dns-wg] RIPE NCC Service Interruption Message-ID: <200509290830.j8T8UekI004709@birch.ripe.net> [apologies for duplicate mails] Dear Colleagues, >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected disruption to services. Although this may have caused delays to updates to the RIPE Whois Database, these updates have been processed normally. The disruption may have also affected some of these RIPE NCC services: - whois.ripe.net - www.ripe.net - lirportal.ripe.net - ns*.ripe.net - ftp.ripe.net - www.aso.icann.org - www.nro.net - k.root-servers.org (Global node at the AMS-IX) - AS112.ripe.net We apologise for any interruption or delay to services. If you have any questions or concerns regarding this issue, please contact . Regards, RIPE NCC Operations From roy at dnss.ec Thu Sep 29 10:34:59 2005 From: roy at dnss.ec (Roy Arends) Date: Thu, 29 Sep 2005 10:34:59 +0200 (CEST) Subject: [dns-wg] RIPE NCC Service Interruption In-Reply-To: <200509290830.j8T8UekI004709@birch.ripe.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> Message-ID: On Thu, 29 Sep 2005, RIPE NCC Operations wrote: > [apologies for duplicate mails] > > Dear Colleagues, > > From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > disruption to services. Although this may have caused delays to > updates to the RIPE Whois Database, these updates have been processed > normally. > > The disruption may have also affected some of these RIPE NCC services: > > - whois.ripe.net > - www.ripe.net > - lirportal.ripe.net > - ns*.ripe.net > - ftp.ripe.net > - www.aso.icann.org > - www.nro.net > - k.root-servers.org (Global node at the AMS-IX) > - AS112.ripe.net > > We apologise for any interruption or delay to services. If you have > any questions or concerns regarding this issue, please contact > . Just curious, but has the cause of the disruption been determined, and if so, what was it ? Thanks, Roy From roy at dnss.ec Thu Sep 29 10:34:59 2005 From: roy at dnss.ec (Roy Arends) Date: Thu, 29 Sep 2005 10:34:59 +0200 (CEST) Subject: [ripe.net #121131] [dns-wg] RIPE NCC Service Interruption In-Reply-To: <200509290830.j8T8UekI004709@birch.ripe.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> Message-ID: On Thu, 29 Sep 2005, RIPE NCC Operations wrote: > [apologies for duplicate mails] > > Dear Colleagues, > > From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > disruption to services. Although this may have caused delays to > updates to the RIPE Whois Database, these updates have been processed > normally. > > The disruption may have also affected some of these RIPE NCC services: > > - whois.ripe.net > - www.ripe.net > - lirportal.ripe.net > - ns*.ripe.net > - ftp.ripe.net > - www.aso.icann.org > - www.nro.net > - k.root-servers.org (Global node at the AMS-IX) > - AS112.ripe.net > > We apologise for any interruption or delay to services. If you have > any questions or concerns regarding this issue, please contact > . Just curious, but has the cause of the disruption been determined, and if so, what was it ? Thanks, Roy From brettcarr at ripe.net Thu Sep 29 10:56:25 2005 From: brettcarr at ripe.net (Brett Carr) Date: Thu, 29 Sep 2005 10:56:25 +0200 Subject: [ripe.net #121131] [dns-wg] RIPE NCC Service Interruption In-Reply-To: Message-ID: <200509290856.j8T8uPkI013354@birch.ripe.net> > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On > Behalf Of Roy Arends > Sent: 29 September 2005 10:35 > To: RIPE NCC Operations > Cc: dns-wg at ripe.net > Subject: Re: [ripe.net #121131] [dns-wg] RIPE NCC Service > Interruption > > > On Thu, 29 Sep 2005, RIPE NCC Operations wrote: > > > [apologies for duplicate mails] > > > > Dear Colleagues, > > > > From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > > disruption to services. Although this may have caused delays to > > updates to the RIPE Whois Database, these updates have been > processed > > normally. > > > > The disruption may have also affected some of these RIPE > NCC services: > > > > - whois.ripe.net > > - www.ripe.net > > - lirportal.ripe.net > > - ns*.ripe.net > > - ftp.ripe.net > > - www.aso.icann.org > > - www.nro.net > > - k.root-servers.org (Global node at the AMS-IX) > > - AS112.ripe.net > > > > We apologise for any interruption or delay to services. If you have > > any questions or concerns regarding this issue, please contact > > . > > Just curious, but has the cause of the disruption been > determined, and if so, what was it ? > The disruption was caused by a network issue which we are currently investigating. Regards -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 From jim at rfc1035.com Thu Sep 29 12:30:03 2005 From: jim at rfc1035.com (Jim Reid) Date: Thu, 29 Sep 2005 11:30:03 +0100 Subject: [dns-wg] Fwd: [dns-wg-chair] 2005-07 One Week to End of Discussion Period References: <200509290721.j8T7LpkI020316@birch.ripe.net> Message-ID: <3972B95A-D3E9-4C47-8D23-A1369F893079@rfc1035.com> Folks, just a reminder.... If you have any comments on this policy proposal, please submit them in the next couple of days. Begin forwarded message: > From: RIPE NCC Policy Coordinator > Date: September 29, 2005 08:21:51 BDT > To: dns-wg-chair at ripe.net > Cc: Olaf Kolkman > Subject: [dns-wg-chair] 2005-07 One Week to End of Discussion Period > Reply-To: webmaster at ripe.net > > > PDP Number: 2005-07 > Introducing DNSSEC Service to Reverse DNS Trees > > Dear Colleagues > > The "Last Call" period for the new RIPE Document described in proposal > 2005-07 is due to end in one week on 6 October 2005. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2005-7.html > > When the "Last Call" period ends, we will write to you to ask if > consensus has been reached. > > Regards > > Adrian Bedford > RIPE NCC > > > From pherman at cleverbridge.com Fri Sep 30 13:19:41 2005 From: pherman at cleverbridge.com (Paul Herman) Date: Fri, 30 Sep 2005 13:19:41 +0200 Subject: [dns-wg] RIPE's MNAME recommendation Message-ID: <433D1F4D.5070909@cleverbridge.com> Hello dns-wg list! SUMMARY: In short, in a SOA RR of ours we have an MNAME that corresponds to a primary master server which has a private IP address. This is causing problems with many RIPE member registrars. PROBLEM: Using the language described in Section 2.1 of [RFC 1996], we have a primary master DNS server and two slave DNS servers. The primary master has a private [RFC 1918] IP address and the Slaves have public IP address, are named in the NS RRs for the zone and use zone transfer to recieve the zone from the primary master. Furthermore, in accordance with [RFC 1996], [RPC 1035] and [RIPE1] I have named the primary master as the original/primary source of the data for the zone. Here is an example zone file from what I'm talking about: example.com. 3600 SOA dns.private.example.com. hostmaster.example.com. ( 1999022301 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 172800 ) ; minimum ( 2 days) NS slave1.example.com. NS slave2.example.com. slave1 A {public-ip} slave2 A {public-ip} dns.private A 10.11.12.13 So far so good. Our zone appears to be fully RFC compliant. However, the problem arises when I try to transfer, say, the ownership of a ".de" zone using DENIC, because [RIPE1] additionally recommends that this be a valid address of the primary master, "valid" being the key word here. This is a problem, because many RIPE member registrars are indeed enforcing this policy. I gather, however, from more recent messages from Mr. Koch (who authored [RIPE1]), that the "MNAME field need not be part of the NS RRSet and need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this is also neither enforced by IANA nor ICANN. Is it possible that RIPE could consider relaxing this "recommendation" that causes problems for RFC compliant zones? How do you, the DNS community, feel about this? Thank you for your attention in this matter. With kindest regards, Paul Herman Network Architect cleverbrige AG www.cleverbridge.com REFERENCES: ---------- [RFC 1035] Mockapetris,P., "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RFC 1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. "Address Allocation for Private Internets." February 1996 [RFC 1996] Vixie,P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996 [ICANN-FORUM] http://forum.icann.org/lists/iana-del-data-comments/msg00004.html [RIPE1] Koch,P., "Recommendations for DNS SOA Values", ripe-203, http://www.ripe.net/ripe/docs/ripe-203.html , June 1999 From mansaxel at sunet.se Fri Sep 30 13:57:30 2005 From: mansaxel at sunet.se (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Fri, 30 Sep 2005 13:57:30 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <433D1F4D.5070909@cleverbridge.com> References: <433D1F4D.5070909@cleverbridge.com> Message-ID: <02FE5D59D80D795BB551D65C@rasmus.kthnoc.net> --On den 30 september 2005 13.19.41 +0200 Paul Herman wrote: > Hello dns-wg list! > > SUMMARY: > In short, in a SOA RR of ours we have an MNAME that corresponds to a > primary master server which has a private IP address. This is causing > problems with many RIPE member registrars. > Is it possible that RIPE could consider relaxing this "recommendation" > that causes problems for RFC compliant zones? How do you, the DNS > community, feel about this? I think not. The collateral damage of allowing this relaxation when applied to another organisation, where there are slave servers that might not be in the same routing domain[0] as the MNAME box (and thus not able to see the RFC 1918 address, because 1918 says those addresses should stay in one routing domain) would be un-nice. Basically, using RFC 1918 address space for central, critical infrastructure that might get connections from arbitrary places on the net is a bad idea. Allowing it in a policy document is even worse. -- M?ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE [0] Many texts, ripe-192 being one of the more well-written ones, explicitly talk about getting secondaries in Other Places(tm), which means that you probably, as a slave, are not seeing the same 192.168.47.11 as the other servers, if the MNAME resolves to a RFC 1918 address. This also is messy with dynamic updates. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jim at rfc1035.com Fri Sep 30 14:16:17 2005 From: jim at rfc1035.com (Jim Reid) Date: Fri, 30 Sep 2005 13:16:17 +0100 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <433D1F4D.5070909@cleverbridge.com> References: <433D1F4D.5070909@cleverbridge.com> Message-ID: On Sep 30, 2005, at 12:19, Paul Herman wrote: > In a SOA RR of ours we have an MNAME that corresponds to a > primary master server which has a private IP address. This is causing > problems with many RIPE member registrars. > > the problem arises when I try to transfer, say, the ownership of > a ".de" zone using DENIC, because [RIPE1] additionally recommends > that this be a valid address of the primary master, "valid" being the > key word here. This is a problem, because many RIPE member registrars > are indeed enforcing this policy. > > I gather, however, from more recent messages from Mr. Koch (who > authored > [RIPE1]), that the "MNAME field need not be part of the NS RRSet and > need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this > is also neither enforced by IANA nor ICANN. > > Is it possible that RIPE could consider relaxing this "recommendation" > that causes problems for RFC compliant zones? Have you looked at the agenda for the DNS WG at the upcoming RIPE meeting? This includes a discussion on updating RIPE document 203: "Recommendations on SOA values". Perhaps you could make your views known then? Or, if the WG decides to update 203, you could contribute to that effort? Please bear in mind too that 203 was published in 1999 and stealth master servers were not as common then as they are today. I am confused about your reference to "this policy". There is no RIPE- wide policy on SOA values as far as I know. RIPE document 203 is a recommendation, that's all. Of course everyone is free to use 203 (or ignore it) as guidance when forming their own local policies and procedures. So if you are having problems because of such a policy, I think it's best if you raise the issue with those who have applied that policy. Asking the WG to revisit 203 is all very well. In fact it looks as though that's already in hand. But you may still have to persuade the local policy-makers to change things if/when a revised version of 203 is produced. In short, "fixing" 203 could still mean the policies at those registrars would have to be changed. They might not even know or care about the new document. From roy at dnss.ec Fri Sep 30 14:19:09 2005 From: roy at dnss.ec (Roy Arends) Date: Fri, 30 Sep 2005 14:19:09 +0200 (CEST) Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <433D1F4D.5070909@cleverbridge.com> References: <433D1F4D.5070909@cleverbridge.com> Message-ID: On Fri, 30 Sep 2005, Paul Herman wrote: > Hello dns-wg list! > > SUMMARY: > In short, in a SOA RR of ours we have an MNAME that corresponds to a > primary master server which has a private IP address. This is causing > problems with many RIPE member registrars. > > PROBLEM: > Using the language described in Section 2.1 of [RFC 1996], we have a > primary master DNS server and two slave DNS servers. The primary > master has a private [RFC 1918] IP address and the Slaves have public > IP address, are named in the NS RRs for the zone and use zone transfer > to recieve the zone from the primary master. Furthermore, in > accordance with [RFC 1996], [RPC 1035] and [RIPE1] I have named the > primary master as the original/primary source of the data for the > zone. Here is an example zone file from what I'm talking about: > > example.com. 3600 SOA dns.private.example.com. hostmaster.example.com. ( > 1999022301 ; serial YYYYMMDDnn > 86400 ; refresh ( 24 hours) > 7200 ; retry ( 2 hours) > 3600000 ; expire (1000 hours) > 172800 ) ; minimum ( 2 days) > NS slave1.example.com. > NS slave2.example.com. > slave1 A {public-ip} > slave2 A {public-ip} > dns.private A 10.11.12.13 > > So far so good. Our zone appears to be fully RFC compliant. However, > the problem arises when I try to transfer, say, the ownership of > a ".de" zone using DENIC, because [RIPE1] additionally recommends > that this be a valid address of the primary master, "valid" being the > key word here. This is a problem, because many RIPE member registrars > are indeed enforcing this policy. > > I gather, however, from more recent messages from Mr. Koch (who authored > [RIPE1]), that the "MNAME field need not be part of the NS RRSet and > need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this > is also neither enforced by IANA nor ICANN. > > Is it possible that RIPE could consider relaxing this "recommendation" > that causes problems for RFC compliant zones? How do you, the DNS > community, feel about this? > > Thank you for your attention in this matter. What the recommendation [ripe-203] says, is: (1) The DNS specification explicitly states that the primary master server be named here. (2) The value must be determined and used. ad (2) I have no idea what this means. (3) Especially it is a mistake to repeat the zone name here, unless this also leads to a valid address of the primary master. ad (3) The terms 'valid' and 'leads' are subject to broad interpretation. Does 'valid' mean 'reachable', does 'leads' mean 'globally resolvable' ? I think this is trying to reflect rfc2181, section 7.3. But, also this section does not reveal why this is a mistake. IIRC, the MNAME field is used in two parts of the DNS protocol, notify and dynamic update. For notify, the primary master determines the recipients of a notify message by determining the nameservers of the zone (the NS set in the apex) minus the name of the primary master (determined by the mname field). It does not have any impact to have a private space address for a host specified in the MNAME field, since it would not receive a notify message. For dynamic update, the requestor determines the recipient of a dynamic update message by sending it first to address of the host in the MNAME field to avoid unnecessary forwarding in slave servers, and, if that fails, try the other servers. So, if this is a zone that contains addresses of hosts, where the hosts are trying to dynamically update their addresses (or other data), you might see updates directed to the host in the MNAME field. If this, from the dyn.update host view, is not a reachable address, it will try the slave servers. I do not know if there are any other uses of the SOA MNAME field, or what future uses might be. I do not know how 'stuff breaks' by having a private space address for the host listed in the SOA MNAME field. I would, in general, try to avoid leakage of private space addresses in any way, shape or form, since I don't know what other uses of the MNAME are. But, using this recommendation as a policy and bluntly forcing it onto others, without a good explanation of why, is not a good thing. Roy From pk at DENIC.DE Fri Sep 30 15:02:16 2005 From: pk at DENIC.DE (Peter Koch) Date: Fri, 30 Sep 2005 15:02:16 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <433D1F4D.5070909@cleverbridge.com> References: <433D1F4D.5070909@cleverbridge.com> Message-ID: <20050930130216.GJ20853@denics7.denic.de> On Fri, Sep 30, 2005 at 01:19:41PM +0200, Paul Herman wrote: > example.com. 3600 SOA dns.private.example.com. [...] > NS slave1.example.com. > NS slave2.example.com. > slave1 A {public-ip} > slave2 A {public-ip} > dns.private A 10.11.12.13 > > So far so good. Our zone appears to be fully RFC compliant. However, RFC 1918 says that you should not leak "private" IP addresses, including reference to those addresses in DNS RRs (last paragraph in section 3). The A RR at dns.private.example.com and the reference to that name in the SOA RR do not follow this guidance. > the problem arises when I try to transfer, say, the ownership of > a ".de" zone using DENIC, because [RIPE1] additionally recommends > that this be a valid address of the primary master, "valid" being the > key word here. This is a problem, because many RIPE member registrars > are indeed enforcing this policy. I'm not sure I understand the problem here. What do those registrars "enforce" exactly? RIPE 203 addresses the MNAME field because it was (and maybe continues to be) a common mistake to just repeat the zone name in the MNAME field, where that name does not own any A (or maybe AAAA) RR. In retrospect I'd admit that "valid" is an ambiguous term. However, leaking private address space in DNS RRs, especially in situations where it might cause traffic to go to random targets is not a good idea even today IMHO. What error(?) message do those registrars send back? Note, also, that RIPE 203 is not a normative document but a recommendation for a specific type of zone that happens to appear rather often. Without seeing the policy that "enforces" RIPE 203 it is a bit hard to say whether or not that's a good idea. > I gather, however, from more recent messages from Mr. Koch (who authored > [RIPE1]), that the "MNAME field need not be part of the NS RRSet and > need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this There is no inconsistency between my comment in that forum and RIPE 203. Many DNS setups use stealth primaries and even if those accept and respond to NOTIFY and Dynamic Update messages, there's no rule that the system named in the MNAME field respond to DNS queries (unless it is also announced per an NS RR). The IANA procedures draft which this comment addressed could be read in a way that thet system in the MNAME field would also be checked for SOA values and consistency. > Is it possible that RIPE could consider relaxing this "recommendation" > that causes problems for RFC compliant zones? How do you, the DNS > community, feel about this? First of all, RIPE 203 is up for review at the upcoming RIPE meeting, although for a different reason (the "minTTL" field values recommendations are most likely outdated due to the widespread deployment of negative caching). Then there seems to be a mixture of policies and references to normative and non-normative documents. If I understand you correctly some registrar refuses to deal with a zone where the MNAME field refers to a name that owns an A RR carrying an RFC 1918 address. Seems not too unreasonable to me. -Peter From daniel.karrenberg at ripe.net Fri Sep 30 16:47:17 2005 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 30 Sep 2005 16:47:17 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <433D1F4D.5070909@cleverbridge.com> References: <433D1F4D.5070909@cleverbridge.com> Message-ID: <20050930144717.GB479@reifer.karrenberg.net> On 30.09 13:19, Paul Herman wrote: > example.com. 3600 SOA dns.private.example.com. <======== > ... > dns.private A 10.11.12.13 <======= > > So far so good. Our zone appears to be fully RFC compliant. RFC1918: "Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage." Daniel (who iremebers writing the words cited above) From daniel.karrenberg at ripe.net Fri Sep 30 17:24:28 2005 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 30 Sep 2005 17:24:28 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: References: <433D1F4D.5070909@cleverbridge.com> Message-ID: <20050930152428.GG490@reifer.karrenberg.net> All the words were written before hidden masters were necessary or invented. Whether SOAs are used to determine recipients of NOTIFY is a local matter. I do not think there need to be standards or recommendataions about that. So the recommendation should be to put into the MNAME field the domain name of an authoritative name server that allows AXFRs and is the intended target for dynamic updates. The difficult question is what to put there if there is no such server. It is perfectly OK to not use or allow AXFR and not to use dynamic updates. I have no bright ideas here. But what should be recognised is that there may be no such server. Daniel From daniel.karrenberg at ripe.net Fri Sep 30 17:36:40 2005 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 30 Sep 2005 17:36:40 +0200 Subject: [dns-wg] Re: [ncc-services-wg] RIPE NCC Service Interruption In-Reply-To: <200509290830.j8T8UekI004709@birch.ripe.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> Message-ID: <20050930153640.GC479@reifer.karrenberg.net> On 29.09 10:30, RIPE NCC Operations wrote: > [apologies for duplicate mails] > > Dear Colleagues, > > >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > disruption to services. ... > > The disruption may have also affected some of these RIPE NCC services: > ... > - k.root-servers.org (Global node at the AMS-IX) For the record: According to our monitoring this interruption has not at all affected the K root server. In particular our monitoring has detected no interruption in service and no shifting of traffic to other anycast instances of K. Daniel References: http://k.root-servers.org/stats/ams-ix/index.html http://dnsmon.ripe.net/dns-servmon/server/plot?server=k.root-servers.net&type=drops&tstart=1127887200&tstop=1127901599 From daniel.karrenberg at ripe.net Fri Sep 30 17:36:40 2005 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 30 Sep 2005 17:36:40 +0200 Subject: [dns-wg] Re: [ripe.net #121278] [ncc-services-wg] RIPE NCC Service Interruption In-Reply-To: <200509290830.j8T8UekI004709@birch.ripe.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> Message-ID: <20050930153640.GC479@reifer.karrenberg.net> On 29.09 10:30, RIPE NCC Operations wrote: > [apologies for duplicate mails] > > Dear Colleagues, > > >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > disruption to services. ... > > The disruption may have also affected some of these RIPE NCC services: > ... > - k.root-servers.org (Global node at the AMS-IX) For the record: According to our monitoring this interruption has not at all affected the K root server. In particular our monitoring has detected no interruption in service and no shifting of traffic to other anycast instances of K. Daniel References: http://k.root-servers.org/stats/ams-ix/index.html http://dnsmon.ripe.net/dns-servmon/server/plot?server=k.root-servers.net&type=drops&tstart=1127887200&tstop=1127901599 From list-ripe-dns-wg at vicious.dropbear.id.au Fri Sep 30 19:24:33 2005 From: list-ripe-dns-wg at vicious.dropbear.id.au (Bruce Campbell) Date: Fri, 30 Sep 2005 19:24:33 +0200 (CEST) Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <20050930152428.GG490@reifer.karrenberg.net> References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> Message-ID: On Fri, 30 Sep 2005, Daniel Karrenberg wrote: > So the recommendation should be to put into the MNAME field the domain > name of an authoritative name server that allows AXFRs and is the > intended target for dynamic updates. Going back to the original poster's question, Registrars (whether RIPE members or not), imho, should only be checking that the MNAME field is syntactically correct, not whether it represents a reachable host. Of course, there is nothing stopping the Registrant from temporarily changing the MNAME field to point to something 'valid' whilst interacting with the Registrar, and to put it back to their Registrar-invalid version afterwards. Apart from that, RIPE-203 is still good advice. -- Bruce Campbell From brettcarr at ripe.net Fri Sep 30 22:24:21 2005 From: brettcarr at ripe.net (Brett Carr) Date: Fri, 30 Sep 2005 22:24:21 +0200 (CEST) Subject: [dns-wg] Re: [db-wg] Re: [ncc-services-wg] RIPE NCC Service Interruption In-Reply-To: <20050930153640.GC479@reifer.karrenberg.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> <20050930153640.GC479@reifer.karrenberg.net> Message-ID: On Fri, 30 Sep 2005, Daniel Karrenberg wrote: > > > On 29.09 10:30, RIPE NCC Operations wrote: > > [apologies for duplicate mails] > > > > Dear Colleagues, > > > > >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > > disruption to services. ... > > > > The disruption may have also affected some of these RIPE NCC services: > > ... > > - k.root-servers.org (Global node at the AMS-IX) > > For the record: > > According to our monitoring this interruption has not at all affected > the K root server. In particular our monitoring has detected no > interruption in service and no shifting of traffic to other anycast > instances of K. Yes indeed the problem briefly affected the website k.root-servers.org but not the global K-root at amsix as they sit behind different routers. Brett -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL http://www.ripe.net +31 627 546046 GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 From brettcarr at ripe.net Fri Sep 30 22:24:21 2005 From: brettcarr at ripe.net (Brett Carr) Date: Fri, 30 Sep 2005 22:24:21 +0200 (CEST) Subject: [dns-wg] Re: [ripe.net #121288] [db-wg] [ncc-services-wg] RIPE NCC Service Interruption In-Reply-To: <20050930153640.GC479@reifer.karrenberg.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> <20050930153640.GC479@reifer.karrenberg.net> Message-ID: On Fri, 30 Sep 2005, Daniel Karrenberg wrote: > > > On 29.09 10:30, RIPE NCC Operations wrote: > > [apologies for duplicate mails] > > > > Dear Colleagues, > > > > >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > > disruption to services. ... > > > > The disruption may have also affected some of these RIPE NCC services: > > ... > > - k.root-servers.org (Global node at the AMS-IX) > > For the record: > > According to our monitoring this interruption has not at all affected > the K root server. In particular our monitoring has detected no > interruption in service and no shifting of traffic to other anycast > instances of K. Yes indeed the problem briefly affected the website k.root-servers.org but not the global K-root at amsix as they sit behind different routers. Brett -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL http://www.ripe.net +31 627 546046 GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8