From paf at cisco.com Sat Oct 1 12:40:09 2005 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sat, 1 Oct 2005 12:40:09 +0200 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: <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> On Sep 30, 2005, at 17:24, Daniel Karrenberg wrote: > 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. As said on this list earlier, the fact is that software deployed do use the MNAME field to try to do dynamic update to and other kind of access. Because of this, for me the MNAME field is in reality a field of data that helps leakage of RFC 1918 addresses if the hostname in MNAME is having such an IP address. This in turn forces to fall under the category of "things that should not have RFC 1918 data". The question is then, as Daniel says, what to put in the MNAME field, as we have conflicting requirements. That it lists the hostname that is the primary master, and that it should not expose RFC 1918 addresses. My suggestion would be to put a domain name there in the domain that hosts the domain, a hostname that can receive the traffic generated by any tool that uses the mname in the SOA for something. Patrik From mansaxel at sunet.se Sat Oct 1 13:49:30 2005 From: mansaxel at sunet.se (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Sat, 01 Oct 2005 13:49:30 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> Message-ID: <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> --On den 1 oktober 2005 12.40.09 +0200 Patrik F?ltstr?m wrote: > My suggestion would be to put a domain name there in the domain that > hosts the domain, a hostname that can receive the traffic generated by > any tool that uses the mname in the SOA for something. In the interest of sanity, I'd suggest adding "should answer queries about said domain with the AA bit set" (in addition to swallowing/properly rejecting/processing updates and allowing/properly refusing zone transfers). That is the The Right Thing to do, IMHO, but it might be hard to get that kind of enforcement into any kind of document short of an ops memo inside one organisation. I for one require it for anything I operate. -- M?ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From president at ukraine.su Mon Oct 3 08:38:13 2005 From: president at ukraine.su (Max Tulyev) Date: Mon, 3 Oct 2005 10:38:13 +0400 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <433D1F4D.5070909@cleverbridge.com> References: <433D1F4D.5070909@cleverbridge.com> Message-ID: <200510031038.13076.president@ukraine.su> Hi! > example.com. 3600 SOA dns.private.example.com. [skip] > dns.private A 10.11.12.13 This is a problem. Why should not use VIEW mechanism in BIND or same in other DNS'es to make your 10.x.x.x visible only for your 10.x.x.x clients? By the way, it makes your network more secure. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From pk at DENIC.DE Mon Oct 3 17:10:53 2005 From: pk at DENIC.DE (Peter Koch) Date: Mon, 3 Oct 2005 17:10:53 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> Message-ID: <20051003151053.GA9389@denics7.denic.de> On Sat, Oct 01, 2005 at 01:49:30PM +0200, M??ns Nilsson wrote: > In the interest of sanity, I'd suggest adding "should answer queries about > said domain with the AA bit set" (in addition to swallowing/properly > rejecting/processing updates and allowing/properly refusing zone > transfers). That is the The Right Thing to do, IMHO, but it might be hard There's no RFC that would support this as far as I can see. At least there's no RFC that suggests that the server named in MNAME act as an additional resource to what is already in the NS RRSet. When RIPE-203 was written, NOTIFY was pretty much in use and that's what the recommendation is mostly based on. At that time some DNS server or admin tool defaulted to the zone name for MNAME and since even NOTIFY doesn't fail if you do not enter the primary master (or the root of the XFR dependency graph, as RFC 1996 puts it), people just accepted that "default" not knowing that it really needed editing. NOTIFY's MNAME use affects the secondaries and the primary master in that it limits the amount of notifications sent and tries to avoid any NOTIFYs going back to the primary master. It may also affect query load when servers do SOA additional section processing (contrary to the words in RFC 1035). At the same time, Dynamic Updates were in far less use, at least far less than today thanks to a prominent OS. Dynamic Update traffic affects more parties and sometimes is so dominant, that the MNAME is used as a dedicated "DunUpd target", e.g. by AS112. Strictly speaking, RFC 2136 only suggests to target MNAME if the name appears in the NS RRSet, but current reality is different. None of the above says or suggests that the server in MNAME be used for DNS queries from random sources or that it should serve the zone via XFR. Then, RIPE-203 explicitly targets "small and stable zones", which are more or less by definition not subject to dynamic updates (if, for a moment, we associate "dynamic updates" with "frequent updates"/DHCP; if DynUpd is used as a provisioning tool by the zone maintainer, it likely can get away even without the SOA info). So, my suggestion is to adjust the MNAME text in a way that keeps the original spirit but explicitly says that the name in MNAME 1) must resolve to an A RR(Set) 2) the address (or, to complicate matters, addresses) must be the public address of the (hidden/stealth) primary master Please remember that RIPE-203 does not try to be an exhaustive (even less so normative) explanation for all the SOA RR's parameters for most any situation. It aims at a rather large subset (maybe in the 70-80%) of zones which can live well with these defaults. -Peter From Francis.Dupont at enst-bretagne.fr Mon Oct 3 18:20:56 2005 From: Francis.Dupont at enst-bretagne.fr (Francis Dupont) Date: Mon, 03 Oct 2005 18:20:56 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: Your message of Mon, 03 Oct 2005 17:10:53 +0200. <20051003151053.GA9389@denics7.denic.de> Message-ID: <200510031620.j93GKuVk040425@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: So, my suggestion is to adjust the MNAME text in a way that keeps the original spirit but explicitly says that the name in MNAME 1) must resolve to an A RR(Set) => A and/or AAAA 2) the address (or, to complicate matters, addresses) must be the public address of the (hidden/stealth) primary master => I support Peter's proposal. Thanks Francis.Dupont at enst-bretagne.fr From ruud at ripe.net Tue Oct 4 08:44:39 2005 From: ruud at ripe.net (Ruud de Kooter) Date: Tue, 04 Oct 2005 08:44:39 +0200 Subject: [dns-wg] RIPE NCC Service Interruption on 29 September Message-ID: <5.2.1.1.2.20051003165533.035b5d78@localhost> Dear Colleagues, As we announced on 29 September, there was an unexpected disruption to our whois and web services between 05:10 and 06:00 UTC. Our investigations have shown that the problem was caused by an increasing traffic load and a growing number of peers on one of our routers. We made some configuration changes to improve load balancing between our border routers. This should prevent any similar problems from occurring in the future. We apologise for any disruption or delay this may have caused. If you have any further questions about this matter, please send an e-mail to . Regards Ruud de Kooter RIPE NCC From mansaxel at sunet.se Tue Oct 4 09:12:40 2005 From: mansaxel at sunet.se (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Tue, 04 Oct 2005 09:12:40 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <20051003151053.GA9389@denics7.denic.de> References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> <20051003151053.GA9389@denics7.denic.de> Message-ID: --On den 3 oktober 2005 17.10.53 +0200 Peter Koch wrote: >> In the interest of sanity, I'd suggest adding "should answer queries >> about said domain with the AA bit set" (in addition to >> swallowing/properly rejecting/processing updates and allowing/properly >> refusing zone transfers). That is the The Right Thing to do, IMHO, > There's no RFC that would support this as far as I can see. At least > there's no RFC that suggests that the server named in MNAME act as an > additional resource to what is already in the NS RRSet. 1035 says: MNAME The of the name server that was the original or primary source of data for this zone. I think this is supportive of the idea that questions about the zone SHOULD be answered, and that AA bit SHOULD be set. > So, my suggestion is to adjust the MNAME text in a way that keeps the > original spirit but explicitly says that the name in MNAME > > 1) must resolve to an A RR(Set) > 2) the address (or, to complicate matters, addresses) must be the public > address of the (hidden/stealth) primary master ...and thus as per above SHOULD do dns? I think there is support in the text for that. > Please remember that RIPE-203 does not try to be an exhaustive (even less > so normative) explanation for all the SOA RR's parameters for most any > situation. It aims at a rather large subset (maybe in the 70-80%) of > zones which can live well with these defaults. Understood. -- M?ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From pherman at cleverbridge.com Tue Oct 4 10:12:05 2005 From: pherman at cleverbridge.com (Paul Herman) Date: Tue, 04 Oct 2005 10:12:05 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <20051003151053.GA9389@denics7.denic.de> References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> <20051003151053.GA9389@denics7.denic.de> Message-ID: <43423955.8030302@cleverbridge.com> [Just replying to some random message in the thread] Excellent discussion, and I'm grateful for everyone's contribution. Two points have essentially been brought up in this thread: 1) private MNAMEs lead to RFC 1918 pollution and 2) RIPE-203 is not policy but just a recommendation. Many people commented that if the MNAME server points to a private RFC 1918 A RR then this contributes exposure of the RFC 1918 address space to the rest of the internet. While this statement is true, it is important to note that RFC 1918 pollution exists IFF the zone exposes RFC 1918 addresses via A, PTR (or AAAA?) RRs and not MNAME entries as some suggested. In fact, it surprised me that RFC 1918 addresses became such an issue in this thread, because MNAME doesn't point to an address, only a machine domain name. I am more concerned with whether MNAMEs should be required to resolve, and not what they should resolve to. ...(Appologies offered for the oversimplified "example.com" zone I presented in my original post. It is not a real zone of ours, and was merely intended to illustrate the structure of the the name server relationships. You can all rest assured that all querries to private RRs are answered only within our private network)... As to RIPE-203 being neither policy nor standard but simply a recommendation, I may have been unlucky but based upon this very MNAME issue I have had one zone flat rejected by two registrars and was told by another after some discussion quite authoritatively that although they would let it slide, DENIC wouldn't allow it and the same would go for any .CH or .AT domain. I'm currently batting 1 for 3 against. It's been my experience that the registrars typically run their web scripts on the zone and if it doesn't pass their test (which include the RIPE-203 recommendations), then your request is rejected. After you call them and finally reach someone who can help you, they point to RIPE-203, end of discussion. I have no problem trying to take this up with individual registrars but it feels like battling windmills. I have a stealth primary master with a private IP, no RFC 1918 address pollution and no dynamic updates configured for this zone at all. What is a sysadmin to do? Looking forward to what fruit the upcoming DNS WG will bear... Regards, Paul Herman Network Architect cleverbrige AG www.cleverbridge.com From dougb at dougbarton.net Tue Oct 4 10:32:12 2005 From: dougb at dougbarton.net (Doug Barton) Date: Tue, 04 Oct 2005 01:32:12 -0700 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <20051003151053.GA9389@denics7.denic.de> References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> <20051003151053.GA9389@denics7.denic.de> Message-ID: <43423E0C.8000209@dougbarton.net> Peter Koch wrote: > So, my suggestion is to adjust the MNAME text in a way that keeps the > original spirit but explicitly says that the name in MNAME > > 1) must resolve to an A RR(Set) > 2) the address (or, to complicate matters, addresses) must be the public > address of the (hidden/stealth) primary master I am curious as to what the purpose of this text would be. If that field is used for either notify or dynamic update (as Roy pointed out earlier in the thread) those are both issues that are relevant only to the operators of the name servers and/or the domain administrators in question. The AXFR issue that Daniel mentioned is also a matter of local policy. In short, without significant good reasons to the contrary (with supporting information and references included in the document), I think if 203 says anything about it at all, it should say only that what goes into that field is a matter of local policy. If the thinking on this topic is being guided by (now stale) RFC statements on this topic, it would probably be useful to consider a document in the IETF process to update this. I would also like to point out that there is an alternative that I haven't seen mentioned to having the MNAME be either a publicly routable or private address. Back when I was managing DNS for a living, I used to create a hostname called hidden-master.example.com, and have that host resolve to 127.0.0.1. That neatly solved many problems, including the overwhelming flood of traffic we were seeing on the (valid) server name that used to be listed in the MNAME field from Windows clients trying to do spurious dynamic updates. I tested this before we deployed it, and it doesn't harm the Windows clients, and it solved our problem. The only time that we had trouble with this was when we would attempt to register country-code domains at certain registries with this configuration. As long as we're talking about updating 203, I'd also like to take this opportunity to point out that the current discussion highlights some of the problems with documents of this type, namely that they are generally out of date within minutes of being published. For example, the recommendation for the MINIMUM field is woefully out of date (as I'm sure is not a surprise to most members of this list). I would also argue that the recommendations for refresh, retry, and expire are only applicable to a fairly narrow part of the bell shaped curve of DNS administration, and should not be adopted blindly without good understanding of both the needs of the domain administrators and how those values interact. I think that a lot of this information was useful at the time it was published, but 6 years is loooong time in net.years. hope this helps, Doug -- If you're never wrong, you're not trying hard enough From pk at DENIC.DE Tue Oct 4 12:09:48 2005 From: pk at DENIC.DE (Peter Koch) Date: Tue, 4 Oct 2005 12:09:48 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> <20051003151053.GA9389@denics7.denic.de> Message-ID: <20051004100948.GC24233@denics7.denic.de> On Tue, Oct 04, 2005 at 09:12:40AM +0200, M??ns Nilsson wrote: > 1035 says: > > MNAME The of the name server that was the > original or primary source of data for this zone. > > I think this is supportive of the idea that questions about the zone SHOULD > be answered, and that AA bit SHOULD be set. "primary" source I'd not read as the "source that's mostly asked", but in the sense the word is used in "primary master". To comply with the above definition, it's sufficient to supply the zone to at least one secondary (ususally by AXFR). So even when 1035 was not explicitly designed to support hidden primaries, it is flexible enough to allow for them. The update to 1035 in RFC 1996 makes this even clearer. -Peter From jim at rfc1035.com Tue Oct 4 12:09:49 2005 From: jim at rfc1035.com (Jim Reid) Date: Tue, 4 Oct 2005 11:09:49 +0100 Subject: Document management & review (was Re: [dns-wg] RIPE's MNAME recommendation) In-Reply-To: <43423E0C.8000209@dougbarton.net> References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> <20051003151053.GA9389@denics7.denic.de> <43423E0C.8000209@dougbarton.net> Message-ID: <9A6D8626-13DC-412A-A9D3-30E767A7A2D6@rfc1035.com> On Oct 4, 2005, at 09:32, Doug Barton wrote: > As long as we're talking about updating 203, I'd also like to take > this > opportunity to point out that the current discussion highlights > some of the > problems with documents of this type, namely that they are > generally out of > date within minutes of being published. Although this is a diversion from the original discussion, I think it's a worthwhile topic for the WG to consider. Maybe the WG could put expiry dates on its documents? ie "This document dies in X years unless it is reviewed and updated if necessary." I'm sure Peter would have made a mental note that 203 would need to be revisited some time after it came out. [Which will explain why it's on the agenda for next week. :-)] Perhaps that could/should be formalised somehow so that some of the WG agenda planning can be done on a longer-term basis? From pk at DENIC.DE Tue Oct 4 12:21:03 2005 From: pk at DENIC.DE (Peter Koch) Date: Tue, 4 Oct 2005 12:21:03 +0200 Subject: [dns-wg] RIPE's MNAME recommendation In-Reply-To: <43423955.8030302@cleverbridge.com> References: <433D1F4D.5070909@cleverbridge.com> <20050930152428.GG490@reifer.karrenberg.net> <37B320C7-DE7D-4B4E-9426-080A40405F35@cisco.com> <5F11415125FBF4B97F3F6945@rasmus.kthnoc.net> <20051003151053.GA9389@denics7.denic.de> <43423955.8030302@cleverbridge.com> Message-ID: <20051004102103.GD24233@denics7.denic.de> On Tue, Oct 04, 2005 at 10:12:05AM +0200, Paul Herman wrote: > issue I have had one zone flat rejected by two registrars and was told > by another after some discussion quite authoritatively that although > they would let it slide, DENIC wouldn't allow it and the same would go > for any .CH or .AT domain. I'm currently batting 1 for 3 against. I'd recommend that for "authoritative" answers on registration policy the registry's documentation be consulted. > It's been my experience that the registrars typically run their web > scripts on the zone and if it doesn't pass their test (which include > the RIPE-203 recommendations), then your request is rejected. After If that were the case it would be ill-advised. RIPE-203 clearly states its target audience *and* intentionally does not offer any intervals but instead recommends fixed values for the various SOA fields. I'm not aware of a registry that would insist on fixed particular numbers here. > you call them and finally reach someone who can help you, they point > to RIPE-203, end of discussion. I have no problem trying to take this > up with individual registrars but it feels like battling windmills. I Let's please keep two issues separate: 1) potential updates to RIPE-203 due to ambuguity or changed premises 2) alleged or evidenced use of RIPE-203 as a basis for policy or policy enforcement You see to have run into a problem with (2), but that does not necessarily call for a change to RIPE-203. > have a stealth primary master with a private IP, no RFC 1918 address > pollution and no dynamic updates configured for this zone at all. What > is a sysadmin to do? Pick one of the announced name servers? -Peter From webmaster at ripe.net Mon Oct 10 11:10:26 2005 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Mon, 10 Oct 2005 11:10:26 +0200 Subject: [dns-wg] New RIPE Document available: RIPE-352 Message-ID: <200510100910.j9A9AQgL016927@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new RIPE Document is available from the RIPE Document store. Ref: ripe-352 Title: Measuring the resource requirements of DNSSEC Author: Olaf Kolkman RIPE NCC / NLnet Labs Date: October 2005 Format: PDF=5367108 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- We measured the effects of deploying DNSSEC on CPU, memory and bandwidth consumption of authoritative name servers. We did this by replaying query traces captured from ns-pri.ripe.net and k.root-servers.net in a controlled lab environment. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/ripe/docs/ripe-352.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf PDF version Kind Regards, RIPE NCC Document Announcement Service From webmaster at ripe.net Thu Oct 13 14:38:56 2005 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Thu, 13 Oct 2005 14:38:56 +0200 Subject: [dns-wg] New Document available: RIPE-359 Message-ID: <200510131238.j9DCcugL017478@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-359 Title: RIPE NCC DNSSEC Policy Author: RIPE NCC Date: October 2005 Format: PDF=58240 TXT=3043 Short content description ------------------------- The RIPE NCC is committed to supporting the deployment of DNS Security Extensions (DNSSEC) [1,2,3]. DNSSEC is a set of security extensions to the DNS that allows validating DNS resolvers to establish 'chains of trust' from known public keys to the data being validated. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL: http://www.ripe.net/docs/ripe-359.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-359.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-359.txt plain text version From jim at rfc1035.com Thu Oct 20 16:09:56 2005 From: jim at rfc1035.com (Jim Reid) Date: Thu, 20 Oct 2005 15:09:56 +0100 Subject: [dns-wg] RIPE51 Minutes Message-ID: <5463114B-F440-4BF5-BB37-3D1241C89B90@rfc1035.com> Colleagues, here are the WG minutes from the sessions at last week's RIPE meeting. These will also be available from the web site in the next day or so. Please send any comments or corrections to the list. Special thanks are due to Adrian Bedford for scribing and promptly producing an excellent set of minutes. This made it very easy for your co-chairs to get the minutes published so quickly and we are grateful to him. Thanks Adrian! RIPE 51 Amsterdam DNS Working Group Session 1 - 12 October 2005 Chaired by Peter Koch Scribe: Adrian Bedford A & B - Administrative Matters: The group approved the minutes from RIPE 50 with no changes: http://www.ripe.net/ripe/wg/dns/r50-minutes.html Updates were provided for the various action points outstanding for the group. http://www.ripe.net/ripe/wg/dns/dns-actions.html 48.1: Peter Koch sent a draft to the working group mailing list before RIPE 50. After detailed feedback from Ed Lewis, the proposal is to be redrafted. Peter hopes to have made progress on this by RIPE 52. Status - Ongoing. 48.2: M?ns Nilsson is negotiating on funding to revise the wording of his proposal. Although this is currently stalled, he hopes to be able to sort this out within the coming two months and provide a rough draft in time for RIPE 52. Status - Ongoing. 48.4: David Malone agreed to continue to provide updates on his work. There has been no draft circulated as yet. Status - Ongoing. 49.1: Peter is stalled on this. A proposal was sent to the NCC Services Working Group Mailing List. Peter encouraged members of the DNS WG to investigate this. Status - Ongoing. 49.2: A small group is working on this, but has not yet got too far. Jim Reid hopes to incorporate changes suggested by Fernando Garcia to a Draft RIPE Document by the end of October. Status - Ongoing. 50.1: This will be covered by a presentation at this session from Lorenzo Collitti. Status - Ongoing. 50.2: This has been completed. Jim explained the background. It appears to have come down to a misunderstanding and subsequent poor communication from the IANA. A problem with zone generation for the root zone when communicated suggested a change in IANA policy. This was in fact not the case. IANA fixed the issue and promised that greater care will be taken with future communication. All letters sent to IANA and their replies are available within the mail archive of this working group. Status - Done. C1. IETF DNS Report ? DNSEXT and DNSOP Olaf Kolkman - NLnetLabs: Olaf gave updates on IETF Working Group documents for both DNEXT and DNSOP. http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- ietf-dns-report.pdf C2. IETF CRISP WG Marcos Sanz - DENIC Marcos provided an update from an IETF meeting that recently took place in Paris, looking at different documents related to the deployment of CRISP. There were no slides. AREG - The Address Registry profile for IRIS reached Version 12 and Last Call was over at the end of September. Some IESG comments will lead to a further edit and a new version will soon be available. This is close to becoming an RFC. DCHK - This is a paper dealing with a lightweight version of IRIS running on top of LWZ (A UDP transport for IRIS). Documents are advancing. XPC - There are no BEEP large-scale deployments, this meets a need for an alternative, simpler transport for IRIS. It is based on TCP with a small binary header. RREG - Routing Registry profile for IRIS. This is an individual draft and not a working group draft. It provides information about prefixes, Autonomous Systems and contacts. The purpose of the document remains unclear; maybe a mirroring mechanism is what Internet routing registries actually need. Discussion goes on, whether to adopt it into the CRISP working group. Additionally, the .br TLD registry announced their DCHK and LWZ implementations. Shane Kerr commented that those interested in the RIPE NCC deployment of IRIS should attend the Database Working Group session on Friday morning. C3. EPP ? The Next Step Jaap Akkerhuis ? on behalf of Scott Hollenbeck - Verisign Jaap outlined work by Scott to improve the quality of papers and move them to draft status, using the ietf-provreg at cafex.se mailing list. He emphasized that Scott welcomes all comments, questions and feedback from the group. http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-epp-rfc.pdf Peter Koch announced that Policy Proposal 007 (DNSSEC) had now completed its run through the formal Policy Proposal Process and the chairs of the DNS WG had decided that there had been no formal objections. They declared consensus had been reached. http://www.ripe.net/ripe/policies/proposals/2005-7.html Peter asked if the group found updates from IETF useful. He requested feedback on this after the session. Peter also let the group know that the co-chairs welcomed any suggestions of things that the group would like to see discussed or presented at future RIPE Meetings. D: Effect of anycast on K-root: early results Lorenzo Colitti ? RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- anycast_k-root.pdf After the presentation, Ladislav Vobr asked about whether anycast technology had been tested before being put into production on K- root. There was interest in how testing had been done and what convinced those behind the project that it was suitable? Daniel Karrenberg, who was involved in the development, explained that the main goal was resilience. The motivation was to increase the protection against Distributed Denial of Service (DDoS) attacks. Prior to deployment, the setup underwent testing. A discussion followed about the merits of anycast and DNS over TCP, with questions asked about whether UDP would be a more appropriate protocol to investigate persistent switching and packet fragmentation. As chair of this session, Peter Koch stated that he felt that it had been discussed at length in the past and added this should be taken up out of this session, as time was limited. The previous discussion is available in the mailing list archive. It was suggested that the RIPE NCC might consider a presentation on how anycasting is working out at RIPE 52. Jim Reid picked up on the scientific paper that Lorenzo mentioned. He asked if this might be published as a RIPE Document. Lorenzo did not see any reason why it could not be. E: DNS Guru Contest Carsten Strotmann -- Men & Mice http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dnsguru-quiz.pdf Carsten encouraged everyone to log on, take the DNS Guru test, and provide feedback. Olaf Kolkman asked about prizes for those taking part. Session 2 - 13 October 2005 Chaired by Jim Reid Scribe: Adrian Bedford Carsten Strotmann announced that there was a prize for those who took part in the DNS Guru Test. He explained that there are polo shirts available to the ten people who score highest. F: DNS Restructuring Update at the RIPE NCC Brett Carr ? RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-restructure.pdf Mohsen Souissi of AFNIC commented that while deploying DNSSEC, one of his servers had encountered problems. It caused some fragmentation for IPv6 when using Fedora with a Symmetrical Multi-Processor front end. AFNIC had found a workaround by switching to mono-processor that worked fine. He is still awaiting feedback on a final solution from Fedora core developers. G: Deprecation of ip6.int Andrei Robachevsky ? RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- deprecation-ip6.int.pdf Peter Koch asked, how the date would be set and when the RIPE NCC would publicly announce it. Andrei replied that the RIRs had met to discuss this. The probable date they had settled on would be 1 June 2006. The date was set to be sufficiently far enough in the future to allow any discussion to follow the Policy Development Process (PDP). There will be no formal announcement until this date is certain. Andrei asked the group how the RIPE NCC should proceed with this. He suggested three possible courses of action: 1. Just go ahead and present this as an operational issue 2. Enter the PDP system with the suggestion 3. Wait and see Lars-Johan Liman suggested that the RIPE NCC favour the first option, this received support from those in the room and is now an action on the RIPE NCC. H: Key Rollover Paper and Tools Johan Ihren ? Autonomica http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- cadr-dnssec.pdf Johan stressed that the presentation he was giving was based on his own private work with Bill Manning and was not representative of the views of Autonomica. The presentation was followed by a live demonstration of the tool. Mohsen Souissi asked how a network operator could be sure that data was correctly configured. He wondered if Johan planned to add additional features to the software to carry out further authentication checks. Johan explained that this would come down to the policy set by each registry. Each would still need to decide on appropriate policies or safeguards before accepting any changes, regardless of how they were submitted. I: RIPE NCC Secondary Service Policy Lars-Johan Liman ? Autonomica http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-nodns.pdf Lars-Johan raised the issue of the future of the RIPE NCC Secondary DNS Service. Axel Pawlik asked why this was being discussed within the DNS Working Group and not within NCC Services. The reply was that an agreement was made at RIPE 50 to first float the idea in this group and discuss it before taking any concrete suggestions to the other group. Axel agreed that the proposal made by Lars-Johan made good sense. The RIPE NCC has a basic principle that it would never compete in any area where its members are offering services. Lars-Johan commented that keeping track of this must be difficult as the business plans and strategies of its members are constantly changing. Axel reiterated that he felt in this case, the situation was quite clear. Rob Blokzijl had three remarks to make. He felt that Lars-Johan had stated that the RIPE NCC should focus purely on IP Address administration and little else. He disagreed with this, adding that this was not why the RIPE NCC was created. It was set up as a permanent secretariat to RIPE with a mandate to do coordination activities for the Internet. He added that he fully agreed that the RIPE NCC should not offer a service that a member was also offering. He then wished to clarify the history behind the offering of this service. It was most likely an activity started when there were different circumstances and was valid at a time when there was no DNS industry. He personally felt that if the membership agrees that the RIPE NCC should revisit this activity, he would offer support. He warned that he felt a gradual phase out was preferable to a sudden stop. Some African ccTLDs might find it hard to move to a fully commercial service. They may need to continue using the RIPE NCC service for some time to come. In principal, Rob feels that the NCC should go through all of the ?non paying customers? for the service and see how they could rationalise the list. Daniel Karrenberg wished to explain why the RIPE NCC took over ns.eu.net. Whilst he fully agreed with the reasoning behind the proposal, he wanted to clarify some points made in the presentation. The RIPE NCC did not take on ns.eu.net as an ?act of charity?. At the time when the system was in financial trouble, there was panic, both operationally and politically. There was much talk about greater regulatory powers being given to governments and the RIPE NCC acted to protect the stability of the Internet. Everyone agreed that it was a good thing for the RIPE NCC to do at the time. If ns.eu.net had collapsed, we would see a very different registration and regulatory environment to the one we have now. He felt that the three options offered at the end of Lars-Johan?s proposal needed modification. The options to do nothing or impose a fee and launch this as a RIPE NCC service, were both impractical and not worth pursuing. He favoured the idea of the RIPE NCC withdrawing from its ccTLD Secondary DNS Service, though agreed with earlier speakers that initially this could not be done entirely. He stated that we live in a world where stability and security of the DNS remains a political issue. He suggested we needed a fourth proposal. The community needed to ask the RIPE NCC to look at the obvious beneficiaries who are well able to procure the service commercially and politely ask them to leave. He did not feel that it would be wise to set any actual rules about who can stay and who should leave at this stage. He felt to do this would hamper the work of emerging ccTLDs, who may wish to stay with the RIPE NCC for a while. Daniel was recently in Africa and made the point that the service offering currently still delivered good PR and political benefits. Lars-Johan accepted the points made, but warned against starting to expect any commercial service to be out of the reach financially of emerging ccTLDs. A pricing structure would have to take account of different customer needs. He felt it should not always be seen as a bad thing to force everyone into the same business model. It could work out. Daniel Karrenberg felt that ?could? was not good enough here. DNS is seen by the world as the holy grail of communication and the RIPE NCC must avoid making any unpredictable moves. He advised that any changes would need careful consideration. Carsten Schiefner commented that if the RIPE NCC stopped serving secondary servers for ccTLDs, the ccTLDs would most likely then organise something amongst themselves. It would not follow that they would all want to start paying for a service and the problem as such would not go away. Jaap Akkerhuis wished to comment on why ns.eu.net ended up at the RIPE NCC. He recalled that at the time, it was down to a toss of the coin whether the service ended up with the RIPE NCC or SIDN. He added that he agreed with what was being suggested. He also observed that the larger ccTLD registries do indeed tend to arrange things amongst themselves. Jaap pointed out that, although he cannot speak for SIDN anymore, it always had been SIDN policy to help a limited number of ccTLD nameservers (up to around 20). As far as he knows, they still have room to do so. Antoin Verschuren of SIDN confirmed this to be the case. Joao Damas stated that he did not feel that the market would simply go away by the RIPE NCC making changes. He thought it would be wrong to get rid of a competent player in the field. As a DNS user, his primary concern remained stability. He feared that if the service was no longer offered free of charge, some operators might be tempted to look for the cheapest possible solution, which may not always be an optimal one. Lars-Johan understood Joao?s concerns. He felt that the only way towards a stable system in the end would be if economical drivers converged with the needs of the community. It was, he said, important that money be funnelled in the right way. Rob Blokzijl agreed with Lars-Johan. To reach stability, he felt a sudden switch off was not the answer. He agreed with many of the other points made by speakers. He did not think that the RIPE NCC taking any action would resolve what is essentially a business problem for Lars-Johan overnight. He cautioned against any sudden moves in the current climate. Politicians could see this as rocking the boat; there remains a level of ignorance about how the Internet works. It could lead some to point fingers at the RIPE NCC for ?selling off? a community service. Lars-Johan again agreed. His intent was not to stop this tomorrow. He wanted to ask if this was something that should now be considered. He agreed that simply stopping this cold was not the answer; he welcomed discussion for what was likely to be a ?long term? solution. Jim Reid rounded up the discussion. He pointed out that stability of the DNS system was vital, but added that we needed to be aware of the political dimensions pointed out by Daniel. On the other hand, this could be seen as the RIPE NCC potentially competing with its member?s interests. He put it to the room and nobody felt it a bad idea to work further on this. Daniel Karrenberg felt that the next step would be for Lars-Johan to put together a proposal to take into the NCC Services Working Group. J: DNSSEC in Sweden Jakob Schlyter ? SUNIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dnssec-se.pdf There were no questions. K: Update to RIPE 203 ? Recommendations for SOA Values Peter Koch ? DENIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-ripe203.pdf Olaf Kolkman asked whether Peter thought it might be an idea to put fixed values or ranges with reasons as to why anyone might choose to sit on the higher or lower end. Peter Koch felt fixed values would avoid problems with poorly aligned intervals. Gerhard Winkler felt that the group should discuss MNAME in more detail. He thought it would be useful for people to see which secondary or slave loaded from which master. Maybe different MNAME fields for different masters would make sense. Peter felt this discussion would fit better on the IETF namedroppers mailing list: http://ops.ietf.org/lists/namedroppers/ The protocol does specifically state that there should be one unique Master Name server. The document is aimed at a very particular set of zones, it does not try to give a general condition or case for the MNAME field. It is constrained to smaller, stable zones. If Gerhard had proof that these zones tended to be loaded from different databases or sources, Peter would welcome any new text. He added that it was important to take into account if this would be relevant to the target audience of the document. Talking about ripe-203, Gerhard commented that a disclaimer might help in case anyone was using the document as an authoritative source of information. Peter Koch replied that he doubted anyone should use ripe-203 as a policy document, since the subject matter had a specific focus but was not ?set in stone?. It should not be regarded as general technical advice. He wanted to see more discussion on the wording of the document through the mailing list and see the issue of MNAME taken to the namedroppers list. Mohsen Souissi said that having read the discussion on the mailing list, felt the document should state whether having an MNAME within a zone with an RFC1918 name was good or bad practice. He noticed that recent discussion through the DNS Working Group mailing list discouraged it. Peter Koch asked Mohsen to provide some specific text. There was nobody who disagreed with the need to update the document. L: ENUM DNS Predelegation Checks Peter Koch ? DENIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-enum-predelegation.pdf Peter explained that have been a very small number of lame or stale delegations. This appears to be largely due to human error. Along with Carsten Schiefner (co-chair of the ENUM Working Group), Peter proposed that the predelegation checks currently applied to reverse mappings by the RIPE NCC before entering a delegation into the respective IN-ADDR.ARPA zone, be applied automatically to e164.arpa delegations. The proposal was universally accepted and Carsten will now draft some text and submit it to the RIPE PDP system. Andrei Robachevsky stated he felt that inconsistencies might have come about when further changes were applied to delegations. The child zone may not be aware that it needs to change something within the parent zone. It would also be worth looking at processes in place to avoid problems in the future. Carsten replied that it might be preferable if the RIPE NCC could perform ongoing checks. This should cover both the parent zone and child zones, either by using their own or third party tools such as Zonecheck. Andrei agreed that there were several ways to do this and that there were ways in which the quality of checks could be improved. Carsten emphasized that e164.arpa downwards delegation is important and there should be some mechanism in place to provide an early heads up if there could be an issue with a zone. Andrei agreed. Niall O?Reilly wished to add his support for the suggestions made by Andrei about periodic checking. Jim Reid asked if it was a good idea to also look into signing the e164.arpa delegations. AOB Carsten Strotmann told the group that over the past three weeks, he had received several customer enquiries about the Open Root Server Network System (ORNS). He wondered if anyone had opinions about whether customers should use it or not. The issue seems to have arisen from an article in CircleID by Paul Vixie where he states he favours ORNS over the IANA root network: http://www.circleid.com/article/1219_0_1_0_C/ Joao Damas of ISC stated that Paul was speaking in his own private capacity. His request to run one of ORSN servers has nothing to do with either ISC or the operation of the F-root server. Lars-Johan Liman, speaking as a maintainer of I-root, pointed out that there is an RFC (2826) maintained by the IAB on this subject. The RFC clearly states the need for a single root. It should leave nobody in doubt that it is a good thing. The single root is currently maintained by the IANA and he feels this works well. Daniel Karrenberg supported the comments made by Lars-Johan. He suggested that if a customer asks for this service, it would be wise to ask why. Do they want a root server that almost everyone uses or one that is used by just a few? Peter Koch pointed to another CircleID piece by Milton Mueller: http://www.circleid.com/article/1227_0_1_0_C/ The article tries to make the case for ORSN being simply an alternative root. ORSN claims that it is identical to the current root, up until the point where it decides to stop being identical. This is, he feels, a precise definition of an alternative root. Claiming it is a copy of the ICANN route is just incorrect. It could also have strange consequences for DNSSEC. Daniel Karrenberg concluded the discussion by stating that a choice has to be made about whom you trust to provide information and quality of service. From pk at DENIC.DE Fri Oct 21 15:25:23 2005 From: pk at DENIC.DE (Peter Koch) Date: Fri, 21 Oct 2005 15:25:23 +0200 Subject: [dns-wg] Updated list of Action Items Message-ID: <20051021132523.GC5961@denics7.denic.de> Dear WG, please find the list of DNS WG action items at http://www.ripe.net/ripe/wg/dns/dns-actions.html As a result of the meeting during RIPE 51, we (your co-chairs) have closed "50.1" on the NCC to produce statistics on K-root as well as "50.2" on Jim to communicate with IANA to resolve the "multiple names" per name server problem. There are now five new action items and also five ongoing. While traditionally new items originate from face to face meetings, major parts of work can and should be done on this mailing list. -Peter From pk at DENIC.DE Fri Oct 28 10:40:28 2005 From: pk at DENIC.DE (Peter Koch) Date: Fri, 28 Oct 2005 10:40:28 +0200 Subject: [dns-wg] RIPE51 Minutes In-Reply-To: <5463114B-F440-4BF5-BB37-3D1241C89B90@rfc1035.com> References: <5463114B-F440-4BF5-BB37-3D1241C89B90@rfc1035.com> Message-ID: <20051028084028.GD10604@denics7.denic.de> Folks, On Thu, Oct 20, 2005 at 03:09:56PM +0100, Jim Reid wrote: > Colleagues, here are the WG minutes from the sessions at last week's > RIPE meeting. These will also be available from the web site in the > next day or so. Please send any comments or corrections to the list. this initiates a four week last call ending November, 27th, 23:59 UTC. After that date we'll consider the minutes "final". -Peter