From pk at DENIC.DE Mon Oct 4 10:30:53 2010 From: pk at DENIC.DE (Peter Koch) Date: Mon, 4 Oct 2010 10:30:53 +0200 Subject: [dns-wg] 2nd DNS WG slot at RIPE61 rescheduled Message-ID: <20101004083053.GC3597@x27.adm.denic.de> Dear DNS WG, several WG members pointed out the undesirable scheduling conflict between the Anti-Abuse WG and the 2nd DNS WG slot for the Rome meeting. Thanks to the cooperation of other WGs this could be resolved and the overall situation hopefully improved. We have switched places with ENUM, i.e. DNS moved from Thu 1400-1530 to Tue 1600-1800. The full meeting plan is available at Also, please allow me to repeat our call for contributions: If you'd like to present a topic relevant to the DNS (or domain names) in operations, technology, research and/or policy, please contact the WG chairs at . Regards, Peter From rickard.bellgrim at iis.se Mon Oct 4 17:42:00 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 4 Oct 2010 17:42:00 +0200 Subject: [dns-wg] OpenDNSSEC training Message-ID: <36F985DA-83B4-4921-8FBE-C11D5DB986D3@iis.se> Hi OpenDNSSEC have now been deployed at six TLD:s (.dk, .fi, .fr, .nl, .se, and .uk) and ICANN. We are therefore continuing our effort on giving two-day training courses. You can select from two dates 1-2 November and 29-30 November. Please read the attached PDF and get back to me if you are interested. // Rickard Bellgrim -------------- next part -------------- A non-text attachment was scrubbed... Name: opendnssec_training_invitation.pdf Type: application/pdf Size: 78760 bytes Desc: opendnssec_training_invitation.pdf URL: From rickard.bellgrim at iis.se Mon Oct 4 21:41:46 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 4 Oct 2010 21:41:46 +0200 Subject: [dns-wg] OpenDNSSEC training In-Reply-To: <36F985DA-83B4-4921-8FBE-C11D5DB986D3@iis.se> References: <36F985DA-83B4-4921-8FBE-C11D5DB986D3@iis.se> Message-ID: On 4 okt 2010, at 17.42, Rickard Bellgrim wrote: > Hi > > OpenDNSSEC have now been deployed at six TLD:s (.dk, .fi, .fr, .nl, .se, and .uk) and ICANN. We are therefore continuing our effort on giving two-day training courses. You can select from two dates 1-2 November and 29-30 November. Please read the attached PDF and get back to me if you are interested. > > // Rickard Bellgrim > And I forgot this: Preparations: Previous trainings had an extra full day of theory. This is now included and spread out over the two days. However, we do recommend that you watch the recordings of those sessions: http://www.opendnssec.org/documentation/training/ // Rickard From jim at rfc1035.com Tue Oct 5 13:07:41 2010 From: jim at rfc1035.com (Jim Reid) Date: Tue, 5 Oct 2010 12:07:41 +0100 Subject: [dns-wg] another concern over naming Message-ID: <7DF59E01-6119-4E01-BD3A-65C6D221960C@rfc1035.com> Colleagues, I wonder if we've overlooked this rather important concern about the use of hyphens in domain name labels? http://forum.icann.org/lists/name-numbers-and-hyphens-domains/msg00000.html From anandb at ripe.net Tue Oct 5 16:47:02 2010 From: anandb at ripe.net (Anand Buddhdev) Date: Tue, 05 Oct 2010 16:47:02 +0200 Subject: [dns-wg] Decommissioning of the RIPE NCC Reply-size Tester Message-ID: <4CAB3A66.2000905@ripe.net> [Apologies for duplicates] Dear Colleagues, In December 2009, the RIPE NCC made a reply-size tester available to the community. The purpose of this was to allow users to test their networks for path MTU related issues and to help them prepare for the roll-out of a signed root zone. We installed the reply-size server component on a temporary basis at the global instances of K-root to allow testing against an actual root server instance. We collected some statistics and published some interesting research on the RIPE Labs website: http://labs.ripe.net/Members/dfk/content-measuring-dns-transfer-sizes-first-results A signed root zone has been published since 15 July 2010, and we feel that the reply-size tester has served its function. We are therefore going to decommission it on Monday, 11 October 2010. If you wish to continue testing networks for path MTU issues, we recommend that you use the reply-size tester of DNS OARC: https://www.dns-oarc.net/oarc/services/replysizetest Regards, Anand Buddhdev DNS Services Manager, RIPE NCC From bmanning at vacation.karoshi.com Tue Oct 5 13:21:28 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 5 Oct 2010 11:21:28 +0000 Subject: [dns-wg] another concern over naming In-Reply-To: <7DF59E01-6119-4E01-BD3A-65C6D221960C@rfc1035.com> References: <7DF59E01-6119-4E01-BD3A-65C6D221960C@rfc1035.com> Message-ID: <20101005112128.GA7100@vacation.karoshi.com.> On Tue, Oct 05, 2010 at 12:07:41PM +0100, Jim Reid wrote: > Colleagues, I wonder if we've overlooked this rather important concern > about the use of hyphens in domain name labels? > > http://forum.icann.org/lists/name-numbers-and-hyphens-domains/msg00000.html The American Hyphen Society is a community-based, not-for-profit, grass-roots consciousness-raising/education-research alliance that seeks to help effectuate the across-the-board self-empowerment of wide-ranging culture-, nationality-, ethnicity-, creed-, gender-, and sexual-orientation defined identity groups by excising all multiculturally-less-than-sensitive terminology from the English language, and replacing it with counter-hegemonic, cruelty-, gender-, bias-, and, if necessary, content-free speech. The society's motto is "It became necessary to destroy the language in order to save it." Its headquarters are in Wilkes-Barre, Pennsylvania. Seems perfectly alinged to ICANN's mission. --bill From ripe at polnik.de Fri Oct 15 10:18:48 2010 From: ripe at polnik.de (thoma spolnik) Date: Fri, 15 Oct 2010 10:18:48 +0200 Subject: [dns-wg] request about RIPE vs. ISP and RFC 1921, 2.1 Message-ID: <4CB80E68.7080901@polnik.de> Hello, if RIPE assigns an large ip net to an ISP - Does RIPE accept, that this ISP ignores RFC 1921, 2.1 [1] (for commercial interests)? Are commercial interests a valid reason [2] for RIPE, that an ISP does not set (generic) PTR records for an used IP? Does or does not RIPE claim the compliance with (basic) RFCs (like RFC 1921, 2.1 - I think it is a basic, that every IP must have a correct PTR record.) for assigned IP nets? I hope, I found the correct mailing list for my question. If this the wrong list, which should I use for my question? Best regards, thomas polnik. [1] 2.1 Inconsistent, Missing, or Bad Data Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS. Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. [...] [2] RFC 2119 [...] 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. [...] From jim at rfc1035.com Fri Oct 15 12:09:41 2010 From: jim at rfc1035.com (Jim Reid) Date: Fri, 15 Oct 2010 11:09:41 +0100 Subject: [dns-wg] request about RIPE vs. ISP and RFC 1921, 2.1 In-Reply-To: <4CB80E68.7080901@polnik.de> References: <4CB80E68.7080901@polnik.de> Message-ID: <13F23A21-066E-49D3-9F17-FF9641112B8E@rfc1035.com> On 15 Oct 2010, at 09:18, thoma spolnik wrote: > if RIPE assigns an large ip net to an ISP - Does RIPE accept, that > this ISP ignores RFC 1921, 2.1 [1] (for commercial interests)? > Are commercial interests a valid reason [2] for RIPE, that an ISP > does not set (generic) PTR records for an used IP? It's up to the ISP/LIR to decide how to organise the DNS for their reverse zones. Though I'm not aware of any policy which explicitly states that. Perhaps there should be one. Why not present your ideas to this list or even draft a policy proposal? It might be helpful if you said a bit more about the problem(s) which encouraged to to ask these questions. > Does or does not RIPE claim the compliance with (basic) RFCs (like > RFC 1921, 2.1 - I think it is a basic, that every IP must have a > correct PTR record.) for assigned IP nets? To the best of my knowledge, RIPE (and the NCC) have no policy in this area. While I agree wholeheartedly that every IP address should have a corresponding PTR entry, there are a few scenarios where this may not apply. For example the address space could be used on an Intranet and isn't visible or routed on the Internet. So putting PTRs in the public- facing DNS for that bit of in-addr.arpa could well be pointless. In other cases, the ISP/LIR may have the space but haven't yet started issuing it to customers. So if the addresses aren't in use, what's the point of adding PTR records for them? [Does everyone put 16M PTRs into 10.in-addr.arpa on their home net?] PTRs might be missing too while a network is renumbered or reconfigured. Personally speaking, it's a Good Thing some IP addresses don't have reverse DNS working. This is usually a very powerful hint that inbound SMTP is likely to be delivering spam. Note too that RFC1912 is rather old -- the DNS landscape has changed a lot since it was written -- and only an INFORMATIONAL. [BIND4 config file snippets? Eek!] It's not a sacred text. ISTR the IETF once mumbled about updating/replacing RFC1912. Though this might only have happened in my imagination. I'm not sure if it's wise to use this RFC as the foundations of a RIPE policy. However that is something for the WG to decide. > I hope, I found the correct mailing list for my question. You have. PS: Please don't say "IP" when you mean "IP address". From ripe at polnik.de Fri Oct 15 17:23:30 2010 From: ripe at polnik.de (thoma spolnik) Date: Fri, 15 Oct 2010 17:23:30 +0200 Subject: [dns-wg] request about RIPE vs. ISP and RFC 1912, 2.1 [was: request about RIPE vs. ISP and RFC 1921, 2.1] In-Reply-To: <13F23A21-066E-49D3-9F17-FF9641112B8E@rfc1035.com> References: <4CB80E68.7080901@polnik.de> <13F23A21-066E-49D3-9F17-FF9641112B8E@rfc1035.com> Message-ID: <4CB871F2.1@polnik.de> Hello, first: Please excuse, there was transposed digits in my question, I mean RFC 1912. > It might be helpful if you said a bit more about the problem(s) which > encouraged to to ask these questions. I'm a private customer of a not so small DSL Internet Provider in Germany and I use an ADSL2+ internet access product for very small companies. My internet access provider offers an internet access via ADSL with a static IP address. The advertising message, as I signed the agreement with this company, was: "With this internet access you can run your own mail/web servers." ... but without PTR I can not run my own small mail server. Since more than a year I discuss with this company about this topic without any success. The 1st level suppport does not understand, what a PTR is and why I need it (... btw: This company offers customers with this product (like me) an experts hotline ... *no comment*). It was for me impossible to contact a person with expert knowledge behind this 1st level support wall of stupidness. After many, many requests I got answers like this from this company: "If you would pay more per month, you would get a PTR. Your product is for companies with less than 5 members of staff, we don't offer a PTR for this product and we don't offer support for your own mail server. But if you want a PTR, you can order one of our SDSL products." (btw: I never asked for support "how to setup a mail server", because I know enough about this.) You see, there are _only_ commercial interests to avoid a PTR for my static IP address. I checked the IP address range around my own IP address (It is i a x.y.0.0-x.y.89.255 net.). Perhaps 2% of ca. 23.000 IP addresses have a PTR. All internet access products from this company without a static IP address have generic PTR. >> Does or does not RIPE claim the compliance with (basic) RFCs (like RFC >> 1921, 2.1 - I think it is a basic, that every IP must have a correct >> PTR record.) for assigned IP nets? > > To the best of my knowledge, RIPE (and the NCC) have no policy in this > area. It's a pity that RIPE does not expect a good quality of reverse lookups for used public IP addresses. > Note too that RFC1912 is rather old -- the DNS landscape has changed a > lot since it was written -- and only an INFORMATIONAL. [BIND4 config > file snippets? Eek!] It's not a sacred text. ISTR the IETF once mumbled > about updating/replacing RFC1912. Though this might only have happened > in my imagination. I'm not sure if it's wise to use this RFC as the > foundations of a RIPE policy. However that is something for the WG to > decide. Shure, RFCs are not sacred texts, but for system administrators (like me) RFCs are every time a good source to find answers for common questions (i.e. How is the syntax for an email address? How works IMAP, SMTP, DNS,... protocol? W). >> I hope, I found the correct mailing list for my question. > You have. That's fine. So I hope to find an answer. Must an _public_ IP address have a PTR or not? > PS: Please don't say "IP" when you mean "IP address". I thank you for this hint. Please excuse me, my english is really bad :( Best regards, thomas polnik. From Ed.Lewis at neustar.biz Fri Oct 15 17:40:35 2010 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 15 Oct 2010 11:40:35 -0400 Subject: [dns-wg] request about RIPE vs. ISP and RFC 1912, 2.1 [was: request about RIPE vs. ISP and RFC 1921, 2.1] In-Reply-To: <4CB871F2.1@polnik.de> References: <4CB80E68.7080901@polnik.de> <13F23A21-066E-49D3-9F17-FF9641112B8E@rfc1035.com> <4CB871F2.1@polnik.de> Message-ID: At 17:23 +0200 10/15/10, thoma spolnik wrote: >That's fine. So I hope to find an answer. Must an _public_ IP address have >a PTR or not? The short answer is no. To give you an idea of how much debatehas occurred over that question, that question was considered inside the IETF (the de facto Internet engineering standards body) for over 5 years and there was no positive or really definitive outcome. In 2000 this proposal was submitted http://tools.ietf.org/html/draft-senie-inaddr-required-00 and was revised over the period of 5 years to be this proposal (within one of the official working groups) http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07). Still, no RFC emerged from all this (meaning it failed to pass all of the review cycles). You may notice the title changed from : Requiring DNS IN-ADDR Mapping to Encouraging the use of DNS IN-ADDR Mapping and even that wasn't agreed upon. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Ever get the feeling that someday if you google for your own life story, you'll find that someone has already written it and it's on sale at Amazon? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Fri Oct 15 18:11:23 2010 From: jim at rfc1035.com (Jim Reid) Date: Fri, 15 Oct 2010 17:11:23 +0100 Subject: [dns-wg] request about RIPE vs. ISP and RFC 1912 In-Reply-To: <4CB871F2.1@polnik.de> References: <4CB80E68.7080901@polnik.de> <13F23A21-066E-49D3-9F17-FF9641112B8E@rfc1035.com> <4CB871F2.1@polnik.de> Message-ID: <3A278B8A-9D1B-4B77-AFAE-6A0A62F797EE@rfc1035.com> On 15 Oct 2010, at 16:23, thoma spolnik wrote: > first: Please excuse, there was transposed digits in my question, I > mean RFC 1912. Yeah. I think we all realised you had made a typo. :-) > My internet access provider offers an internet access via ADSL with > a static IP address. The advertising message, as I signed the > agreement with this company, was: "With this internet access you can > run your own mail/web servers." ... but without PTR I can not run my > own small mail server. Since more than a year I discuss with this > company about this topic without any success. > The 1st level suppport does not understand, what a PTR is and why I > need it (... btw: This company offers customers with this product > (like me) an experts hotline ... *no comment*). It was for me > impossible to contact a person with expert knowledge behind this 1st > level support wall of stupidness. Right. So why are you continuing to do business with these bozos? Aside from your reverse DNS entries, it's clear their customer service and clue levels leave plenty of scope for improvement. Economic Darwinism should take care of this problem. I don't think RIPE needs to intervene in that natural process. > After many, many requests I got answers like this from this company: > "If you would pay more per month, you would get a PTR. Your product > is for companies with less than 5 members of staff, we don't offer a > PTR for this product and we don't offer support for your own mail > server. But if you want a PTR, you can order one of our SDSL > products." (btw: I never asked for support "how to setup a mail > server", because I know enough about this.) > > You see, there are _only_ commercial interests to avoid a PTR for my > static IP address. I'm not so sure about that. It looks to me that your ISP has realised you consider reverse DNS to be important and have decided this is a business opportunity they want to exploit. :-) Quite a few ISPs charge customers more for static IP addresses. Not because it costs the ISP more. But because their customers value having the same fixed IP address. Your ISP is applying the same thinking. Most ISPs will bundle reverse DNS with their base offering. You've chosen one who doesn't. If you can't convince them to provide the service which meets your requirements, find someone else who does. Easy for me to say... You might also have a claim against them for false advertising or breach of contract if what they're providing doesn't match what was offered. As you already know it will be hard to run your own mail server if it doesn't have a PTR record. > It's a pity that RIPE does not expect a good quality of reverse > lookups for used public IP addresses. That's not what I said Thomas. I'm fairly sure RIPE does expect a good quality from reverse lookups. And many on the people on this list do a lot of work to make sure that happens. Not that I speak for them or RIPE of course... It's just that this quality or expectation is not underpinned by a policy document. If there's a need for that, anyone is welcome to develop a document or suggest a policy. The RIPE policy development process is open to all. So far nobody sees this as a priority or something worth doing. Perhaps your email will prove me wrong. > That's fine. So I hope to find an answer. Must an _public_ IP > address have a PTR or not? The short answer to that is no. There's no mandatory standard or policy on the Internet which says this and no protocol police to enforce it either. We might well be moving to an Internet where working reverse DNS is the exception: think stateless autoconfiguration for IPv6. >> PS: Please don't say "IP" when you mean "IP address". > > I thank you for this hint. Please excuse me, my english is really > bad :( Not at all Thomas. Your English is far, far better than my German. Which says more about me than it does about you. :-) The use of "IP" instead of "IP address" is one of life's little niggles which annoys me. "PIN number" is another. Yes, I need to get out more... From bmanning at vacation.karoshi.com Fri Oct 15 18:32:31 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 15 Oct 2010 16:32:31 +0000 Subject: [dns-wg] request about RIPE vs. ISP and RFC 1912, 2.1 [was: request about RIPE vs. ISP and RFC 1921, 2.1] In-Reply-To: References: <4CB80E68.7080901@polnik.de> <13F23A21-066E-49D3-9F17-FF9641112B8E@rfc1035.com> <4CB871F2.1@polnik.de> Message-ID: <20101015163231.GA27535@vacation.karoshi.com.> On Fri, Oct 15, 2010 at 11:40:35AM -0400, Edward Lewis wrote: > At 17:23 +0200 10/15/10, thoma spolnik wrote: > > >That's fine. So I hope to find an answer. Must an _public_ IP address have > >a PTR or not? > > The short answer is no. > to be fair, an IP address is not required to be the rdata of an A record either. address literals are (and should remain) perfectly fine(*). * some RIPE-DNS WG co-chair not withstanding. -- bill From anandb at ripe.net Mon Oct 25 11:13:28 2010 From: anandb at ripe.net (Anand Buddhdev) Date: Mon, 25 Oct 2010 11:13:28 +0200 Subject: [dns-wg] DNSSEC KSK Roll-over Event for RIPE NCC Zones Message-ID: <4CC54A38.7010401@ripe.net> [Apologies for duplicates] Dear Colleagues, On 21 September, we performed a roll-over of Key Signing Keys (KSKs) of all our signed zones. However, we encountered some issues with the signing infrastructure, and we had to perform a roll-back and delay the key roll-over event. We have resolved the issues with the signing infrastructure, and we will perform a roll-over of KSKs on Wednesday 27 October, and publish new trust anchor files on the RIPE NCC website: More information on DNSSEC keys is available at: https://www.ripe.net/dnssec-keys/index.html Regards, Anand Buddhdev DNS Services Manager, RIPE NCC