From training at ripe.net Thu May 1 16:09:35 2003 From: training at ripe.net (RIPE NCC Training) Date: Thu, 01 May 2003 16:09:35 +0200 Subject: [dns-wg] Announcement RIPE NCC DNSSec Training Courses Message-ID: <200305011409.h41E9ZSs028155@birch.ripe.net> ------- Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the DNSSec Training Course. The main objective of the DNSSec Training Course is to provide LIRs with sufficient background to be able to deploy DNSSec in their own organisation as soon as the protocol is standardised. This course also explains the specific procedures set up by the RIPE NCC to to secure the in-addr.arpa zone. The Domain Name System (DNS) is one of the main parts of the Internet infrastructure. At the moment DNS lacks a mechanism to establish the authenticity and integrity of the data it provides. DNSSec is a set of extensions to provide this end-to-end authenticity and integrity. It is currently being developed within the IETF dnsnext Working Group. The protocol is about to be finalised and the code implementing the protocol is available in alpha releases. The DNSSec course consists of two parts: an "Introduction to DNSSec" and a real life demonstration. The "Introduction to DNSSEC" will cover: - DNS security threats - DNSSec security mechanisms - DNSSec server protection - DNSSec data protection - Delegation issues - Key management issues - Current developments Examples are based on the BIND name server. Please note that DNSSec is an advanced course. It will: - NOT teach the basics of DNS. - NOT describe how to receive Internet resources from the RIPE NCC not describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network & system operators, engineers, etc. This course is not intended for administrative or management staff (e.g. Hostmasters). It is assumed that all attendees are familiar with common DNS terminology, have a practical knowledge in operating DNS servers and are interested in learning the concepts and mechanisms that DNSSec offers. The DNSSec course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the DNSSec Training Course can be found at: http://www.ripe.net/training/dnssec/ REGISTRATION: You can register for a course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to In order to register for a DNSSec Training Course you must be an employee of an LIR and either : - be an LIR contact - be confirmed by an LIR contact. LIR contacts are those employees of an LIR who are registered with the RIPE NCC as authoritative contact persons. It is expected that most of those interested in the DNSSec Training Course will not be an authorative contact persons for their LIR, and therefore will be refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to . Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team COURSE DATES AND VENUES +++++++++++++++++++++++ Date: Friday 4 July 2003 Time: 0900 - 1700 Location: Glasgow,Scotland AND: Date: Friday 18 July 2003 Time: 0900 - 1700 Location: Vienna, Austria AND: Date: Friday 19 September 2003 Time: 0900 - 1700 Location: Amsterdam, The Netherlands REGISTRATION FORM +++++++++++++++++ %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END From Jim.Reid at nominum.com Mon May 5 16:42:11 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Mon, 05 May 2003 07:42:11 -0700 Subject: [dns-wg] Delegation checking policy/procedure at ARIN Message-ID: <84722.1052145731@shell.nominum.com> Ed Lewis will be giving a presentation at the WG next week on ARIN's proposals for checking DNS delegations. I've passed a copy of his slides to RIPE NCC for their comments. [This could well turn out to be a subject that RIRs might want to co-ordinate or establish a commpn policy.] The slides probably won't be on the RIPE web site until after WG, so apologies that the detail isn't available yet. Ed's kindly provided the following shopping list of stuff that ARIN are considering. These issues -- and others! -- are likely to crop up if/when a similar policy is adopted by RIPE NCC. I've forwarded Ed's summary to the list so that we can think about this and perhaps have a discussion on the mailing list before the WG meets. Hopefully this could bring some focus to the panel session that's been arranged for the WG next week. ------- Forwarded Message Message-Id: Date: Tue, 29 Apr 2003 15:07:00 -0400 To: Jim.Reid at nominum.com, Patrik Faltstrom , Peter Koch From: Edward Lewis Subject: ripe 45 notes Cc: Edward Lewis ARIN's membership has adopted a policy (found at the following URL: http://www.arin.net/policy/2002_1.html). The policy omits many engineering details, as these are being uncovered we are noting them. This presentation is a discussion of issues identified to date. Note that this is an engineering discussion, not a report on progress nor a statement on findings. Most of the presentation consists of a laundry list of issues. Here is a synopsis of the issues: 0) What is the purpose? 1) Data is stored in different formats - registration database is not a mirror of the DNS. People will have different perspectives - other than DNS. 2) When is a good time to report problems? How can this be done (wrt time ordering) in a clear manner? 3) Data in DB changes over time, even in result of testing reports 4) Incremental nature of tool development 5) Staff impacts, how this will impact those who answer the email and phones 6) Kinds of (and importance of) statistics 7) Firmness of testing, how rigorous? 8) Correlating data in the DB, specifically ASN's and prefixes with the context being RIR specific here - -- - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." ------- End of Forwarded Message From jabley at isc.org Mon May 5 16:57:59 2003 From: jabley at isc.org (Joe Abley) Date: Mon, 5 May 2003 10:57:59 -0400 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: <84722.1052145731@shell.nominum.com> Message-ID: On Monday, May 5, 2003, at 10:42 Canada/Eastern, Jim Reid wrote: > Ed Lewis will be giving a presentation at the WG next week on ARIN's > proposals for checking DNS delegations. I've passed a copy of his > slides to RIPE NCC for their comments. [This could well turn out to be > a subject that RIRs might want to co-ordinate or establish a commpn > policy.] The slides probably won't be on the RIPE web site until after > WG, so apologies that the detail isn't available yet. APNIC are also considering a similar policy; we are currently soliciting feedback on some of these issues on APNIC's sig-dns mailing list, following George Michaelson's draft policy paper which was presented in Taipei: http://www.apnic.net/meetings/15/sigs/dns/docs/dns-pres-ggm-sweep-lame- dns.ppt http://www.apnic.net/meetings/15/sigs/dns/docs/dns-doc-ggm-lame-dns1.doc There are some differences between this proposal (above) and the work that Ed has been doing. I think there is interest at APNIC in converging on a single RIR-wide policy, or at least on a set of RIR policies which are mutually compatible, which is why I thought I'd mention that this is an active topic for us. Joe (apnic sig-dns chair hat) From brad.knowles at skynet.be Mon May 5 21:55:49 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Mon, 5 May 2003 21:55:49 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: <84722.1052145731@shell.nominum.com> References: <84722.1052145731@shell.nominum.com> Message-ID: At 7:42 AM -0700 2003/05/05, Jim Reid wrote: > Ed Lewis will be giving a presentation at the WG next week on ARIN's > proposals for checking DNS delegations. I've passed a copy of his > slides to RIPE NCC for their comments. [This could well turn out to be > a subject that RIRs might want to co-ordinate or establish a commpn > policy.] The slides probably won't be on the RIPE web site until after > WG, so apologies that the detail isn't available yet. Interesting. As you may remember, the issue of lame delegations is something that I have been concerned about for some time, since taking over responsibility for the lamers.sh script from Bryan Beecher. I have been a little lax with regards to this program over the last few years, but within the last few months I've been thinking that it would be good to get back to work on it, and take it to the next logical level. Specifically, I was thinking about a distributed collection script and a centralized checking facility, where results could be posted to the appropriate mailing lists and newsgroups, in much the same way as the reports made by Rob Thomas to the NANOG mailing list (especially his "lame delegation" report at ). Perhaps this is something that could be done in conjunction with the RIRs? Could we all pool our resources? Perhaps we can talk to Rob as well? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From Jim.Reid at nominum.com Tue May 6 14:15:15 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Tue, 06 May 2003 05:15:15 -0700 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: Message from Brad Knowles of "Mon, 05 May 2003 21:55:49 +0200." Message-ID: <11894.1052223315@shell.nominum.com> >>>>> "Brad" == Brad Knowles writes: >> Ed Lewis will be giving a presentation at the WG next week on >> ARIN's proposals for checking DNS delegations. I've passed a >> copy of his slides to RIPE NCC for their comments. [This could >> well turn out to be a subject that RIRs might want to >> co-ordinate or establish a commpn policy.] The slides probably >> won't be on the RIPE web site until after WG, so apologies that >> the detail isn't available yet. Brad> Specifically, I was thinking about a distributed Brad> collection script and a centralized checking facility, where Brad> results could be posted to the appropriate mailing lists and Brad> newsgroups, in much the same way as the reports made by Rob Brad> Thomas to the NANOG mailing list (especially his "lame Brad> delegation" report at ). I encourage you (and others) to expand on these thoughts on the list. Or if you'd prefer, bring this to the WG at a future RIPE meeting. Brad> Perhaps this is something that could be done in Brad> conjunction with the RIRs? Could we all pool our resources? Brad> Perhaps we can talk to Rob as well? These are all good ideas. In fact the RIRs are mumbling about having a common policy on this. We should know more after Ed's presentation and the panel session in Barcelona next week. My hope is there will be enough commitment for the subject to become a work item for the WG. This subject is going to become more important and there's a gap here that will need to be filled, possibly soon. IMO the WG is an ideal forum for the discussion to take place because of the combination of operational, policy and standards issues that are involved. From bmanning at ISI.EDU Tue May 6 14:37:19 2003 From: bmanning at ISI.EDU (Bill Manning) Date: Tue, 6 May 2003 05:37:19 -0700 (PDT) Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: <11894.1052223315@shell.nominum.com> from Jim Reid at "May 6, 3 05:15:15 am" Message-ID: <200305061237.h46CbJM01808@boreas.isi.edu> although it has a slightly different purpose/view, the audits that I've been running since 1997 do collect "lameness" information that we don't use. there are a number of distributed collectors out there and a centralized analysis pod. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From daniel.karrenberg at ripe.net Tue May 13 06:56:48 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 13 May 2003 06:56:48 +0200 Subject: [dns-wg] Signing the Root Zone to be discussed in TechSec WG @ Barcelona Message-ID: <20030513045648.GA4800@reifa.local.> Point C on the agenda below might be interesting for people on this list. Daniel ----- Forwarded message from Daniel Karrenberg ----- Date: Tue, 13 May 2003 06:50:16 +0200 From: Daniel Karrenberg To: techsec-wg at ripe.net Cc: meeting at ripe.net, webmaster at ripe.net, Lars-Johan Liman , Yuri Demchenko , "Olaf M. Kolkman" Subject: Agenda TechSec-wg Barcelona TechSec-ers, Over the last few weeks there have been additional agenda points suggested. Because of other obligations I am a bit late with updating the agenda. My sincere apologies. Here is my suggestion so far. There should be time for more, so if you have relevant material, just be there and we will bash the agenda. (for Ted) Daniel ----- A. Administrative Matters - scribe - list of participants - agenda - minutes B. Disi report, Olaf Kolkman - 15 minutes Report on the status of the DISI project and the state of DNSSEC in the IETF. C. Signing the Root Zone, Johan Ihren (via Lars-Johan Liman) - 40 minutes Presentation on draft-ietf-dnsop-interim-signed-root-01.txt and draft-ihren-dnsext-threshold-validation-00.txt. Also some discussion whether the RIPE NCC should spend time on this. See also message <3EA54B21.3070307 at ripe.net> from Andrei Robachevsky on the dns-wg and local-ir mailing lists. D. Fonkey project update: target applications, Yuri Demchenko - 15 minutes. Short information about the status of the project and description of target applications, including extended PGP keyserver, attributes/privilege server, location server. E. Overview of Related Activities Elsewhere, Yuri Demchenko - 20 minutes Information about activities and projects among CSIRT community (IETF INCH WG and IODEF development, CERT/CC and TF-CSIRT projects, usage of IRT object in RIPE NCC Database by CSIRT community). Short overview of PKI/AA activities and exploring interest of WG in providing more information about PKI/AA developments (in context of supporting PKI based RIPE NCC Improved Secure Communication System), including training courses. F. Any Other Business ----- End forwarded message ----- From paf at cisco.com Tue May 13 12:00:09 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 13 May 2003 12:00:09 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: Message-ID: On m?ndag, maj 5, 2003, at 21:55 Europe/Stockholm, Brad Knowles wrote: > Specifically, I was thinking about a distributed collection script > and a centralized checking facility, where results could be posted to > the appropriate mailing lists and newsgroups, in much the same way as > the reports made by Rob Thomas to the NANOG mailing list (especially > his "lame delegation" report at ). At the meeting in Barcelona I will describe my findings with my tool (http://dnscheck.paf.se/) which uses the dns verification script which runs on http://paf.se/domain/. You can also download the script (perl) and use yourself, under a BSD like license. I am sorry for being so late with the statistics collections I am now finally ready with, after working on this for 4 years or so... Anyway, the meta-questions I have found need some sort of answers are: - What is a proper set of requirements a registry set on operations of a child zone? (One can argue the registry should not care, BUT, in reality they do. The answer can be "do not care", but then it should be said very loud.) - What is a proper set of requirements one can set on a DNS operator, i.e. one which run DNS for a zone, a hosting service? Yes, they can differ, and should differ as for example tld for "se" should have different requirements than the local butcher shop (maybe). I at least see this list of "proper dns" is different from the _requirements_ a registry set. - Is the requirements different between in-addr.arpa delegations from the normal {cc,g}TLD delegations? If so, why? Note, I am really trying hard to only talk about technical things. No policy issues. Yes, a policy is that some technical hoops need to be passed, but, the technical requirements themselves is what I want to discuss. More at the DNS meeting. paf From edlewis at arin.net Tue May 13 13:23:53 2003 From: edlewis at arin.net (Edward Lewis) Date: Tue, 13 May 2003 13:23:53 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: References: Message-ID: Speaking strictly as an engineer and not as font of policy At 12:00 +0200 5/13/03, Patrik F?ltstr?m wrote: > - What is a proper set of requirements a registry set on operations > of a child zone? (One can argue the registry should not care, BUT, > in reality they do. The answer can be "do not care", but then it > should be said very loud.) I've started to answer this three ways already. I'm a bit reticent to speak freely as a member of ARIN staff - any policy statements should come through official channels if we want to get into specifics. That being said, the answer to this is quite policy specific. There is an element of technical data to the answer though, perhaps significant but not substantial. The DNS protocol is defined to be quite robust in the face of misconfiguations (lameness is an exception). With that in mind, there's little technical justification to place a lot of overhead in 'policing' configurations. I'll repeat this - this does not limit what a registry may choose to do, but it limits our ability to point to a section of a standard and say "see, this is why we enforce a certain behavior." > - Is the requirements different between in-addr.arpa delegations from > the normal {cc,g}TLD delegations? If so, why? The answer to this is buried in the debate over whether the reverse map "MUST" be supported. This debate is happening (dormantly for now) in the IETF DNSOP WG. I think the answer is yes - based on the observation that no one is debating whether the forward map is needed. ;) I can't offer a pat answer to "why?" (but where there's smoke there's either a fire or a troll). ;/ -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. From paf at cisco.com Tue May 13 17:42:44 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 13 May 2003 17:42:44 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: Message-ID: <89FEEC2F-8559-11D7-BFE6-000A959CF516@cisco.com> On tisdag, maj 13, 2003, at 13:23 Europe/Stockholm, Edward Lewis wrote: > Speaking strictly as an engineer and not as font of policy That is what I take for granted _anyone_ do on this list (unless very explicitly stated otherwise). > At 12:00 +0200 5/13/03, Patrik F?ltstr?m wrote: >> - What is a proper set of requirements a registry set on operations >> of a child zone? (One can argue the registry should not care, BUT, >> in reality they do. The answer can be "do not care", but then it >> should be said very loud.) > > That being said, the answer to this is quite policy specific. There > is an element of technical data to the answer though, perhaps > significant but not substantial. > > The DNS protocol is defined to be quite robust in the face of > misconfiguations (lameness is an exception). With that in mind, > there's little technical justification to place a lot of overhead in > 'policing' configurations. I'll repeat this - this does not limit > what a registry may choose to do, but it limits our ability to point > to a section of a standard and say "see, this is why we enforce a > certain behavior." Correct. The robustness is also not a degradation nowadays (Rickards talk during EOF showed that resolvers are pretty robust), but a step function. As long as one of the NS is not lame, you will get 100% clean "service" from the set of NS which together is the delegation. But, when the last non-lame server turns lame, the successrate turns to 0%. Because of this, the tests I do which show "errors" is listing possibly the wrong thing. With a similar reasoning you see most registries which require (all) NS responding is doing a questionable thing. The "DNS" will work. A different way of stating this is that a domain might have a too low number of NS records if less that 2 NS _respond_. This way, if the number of responding NS is as low as 1, then there is a big risk the service the delegation define will not work. >> - Is the requirements different between in-addr.arpa delegations >> from >> the normal {cc,g}TLD delegations? If so, why? > > The answer to this is buried in the debate over whether the reverse > map "MUST" be supported. This debate is happening (dormantly for > now) in the IETF DNSOP WG. I think the answer is yes - based on the > observation that no one is debating whether the forward map is > needed. ;) I can't offer a pat answer to "why?" (but where there's > smoke there's either a fire or a troll). ;/ My personal view is that _if_ the IETF DNSOP WG is coming to the conclusion that there should be delegations there, the requirements and view on "what is good and what is bad" should be the same. DNS is DNS is DNS. paf From jefsey at jefsey.com Tue May 13 18:57:25 2003 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Tue, 13 May 2003 18:57:25 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: <89FEEC2F-8559-11D7-BFE6-000A959CF516@cisco.com> References: Message-ID: <5.2.0.9.0.20030513182018.042de250@mail.jefsey.com> At 17:42 13/05/03, Patrik F?ltstr?m wrote: >>The answer to this is buried in the debate over whether the reverse >>map "MUST" be supported. This debate is happening (dormantly for >>now) in the IETF DNSOP WG. I think the answer is yes - based on the >>observation that no one is debating whether the forward map is >>needed. ;) I can't offer a pat answer to "why?" (but where there's >>smoke there's either a fire or a troll). ;/ > >My personal view is that _if_ the IETF DNSOP WG is coming to the >conclusion that there should be delegations there, the requirements and >view on "what is good and what is bad" should be the same. > >DNS is DNS is DNS. May I comment - may be wrongly as a "user". Reading this usual formula you use a question comes to me: which "DNS' do you refer to each time? The DNS definition is: it is three (actually four) different things (STD013): 1. the domain namespace the resource records 2. the name servers 3. the resolvers I am wrong in feeling that actually what you also talk about is also a fith thing: a query protocol ("will I get the response I ask for?"). IMHO this might have an impact on the way one conceives, explains, tests the obligations of the participants? As a DNS non-geek, I must say I am happy when it works. The same as when IE delivers me the nice HTML page I want and that Netscape does not delivers. However I am fully consious I am wrong, and that this may dagerous ("when the last NS turns lame" as you say). What I want to say is that if the DNS - seen as a protocol by the user is resillient - it is also a danger. Without being imposed rules, I am sure users would be happy to be _told? about their risks, mistakes etc. and way to improve their set-up. When I cannot register a ".fr" or a ".tp" name because of the retsrictions imposed by their NICs I am upset. I would prefer - and I would be gratefull - if they told me what is wrong I could correct when I want, but securing the DN in the meanwhile? As does ".ws" if I am correct (you can force the registration). Example: when the nameserver is on the same machine as the site, I never understood why I would need two name servers. Either the machine is in operation or not. Why could I not have only one nameserver in that case? Had to use two IP addresses on the same machine, with two names for the same nameserver once to get a ".tp" name validated. I would be really interested if Patrick's work permitted that: to tell me what may be wrong in my files and to teach me to correcty right them? jfc From Jim.Reid at nominum.com Wed May 14 16:25:30 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Wed, 14 May 2003 07:25:30 -0700 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: Message from "JFC (Jefsey) Morfin" of "Tue, 13 May 2003 18:57:25 +0200." <5.2.0.9.0.20030513182018.042de250@mail.jefsey.com> Message-ID: <25746.1052922330@shell.nominum.com> >>>>> "JFC" == JFC (Jefsey) Morfin writes: JFC> When I cannot register a ".fr" or a ".tp" name because of the JFC> retsrictions imposed by their NICs I am upset. I would prefer JFC> - and I would be gratefull - if they told me what is wrong I JFC> could correct when I want, but securing the DN in the JFC> meanwhile? This is really something to discuss with the registry concerned. There should be some forum where its customers -- or stakeholders -- can influence policy. However registries don't usually run DNS consultancy businesses, so there will be limits on what they can and cannot do. It's hard to see where chatty help messages for the DNS-clueless would stop and DNS consulting starts: how much help and advice is "enough"? And how much of that consultancy can a registry afford to do when it's only getting a few bucks for the registration? JFC> Example: when the nameserver is on the same machine as the JFC> site, I never understood why I would need two name servers. Read section 3.3 of RFC2182. In fact, read the whole RFC. JFC> I would be really interested if Patrick's work permitted JFC> that: to tell me what may be wrong in my files and to teach JFC> me to correcty right them? Well, someone from AFNIC will be talking about their new delegation checking tools and processes at the WG tomorrow. The presentation should be on the RIPE web site by early next week at the latest. I'm hoping the WG will use tomorrow's session on delegation checking to work on this topic: perhaps produce a BCP or something like that. If this gets under way, it would be useful to get contributions on things like the nature of error messages and so on. From Mohsen.Souissi at nic.fr Wed May 14 16:56:29 2003 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Wed, 14 May 2003 16:56:29 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: <25746.1052922330@shell.nominum.com>; from Jim.Reid@nominum.com on Wed, May 14, 2003 at 07:25:30AM -0700 References: <25746.1052922330@shell.nominum.com> Message-ID: <20030514165629.B20662@kerkenna.nic.fr> On 14 May, Jim Reid wrote: | >>>>> "JFC" == JFC (Jefsey) Morfin writes: | | JFC> When I cannot register a ".fr" or a ".tp" name because of the | JFC> retsrictions imposed by their NICs I am upset. I would prefer | JFC> - and I would be gratefull - if they told me what is wrong I | JFC> could correct when I want, but securing the DN in the | JFC> meanwhile? | | This is really something to discuss with the registry concerned. There | should be some forum where its customers -- or stakeholders -- can | influence policy. However registries don't usually run DNS consultancy | businesses, so there will be limits on what they can and cannot do. | It's hard to see where chatty help messages for the DNS-clueless would | stop and DNS consulting starts: how much help and advice is "enough"? | And how much of that consultancy can a registry afford to do when it's | only getting a few bucks for the registration? ==> The registry concerned for instance does provide a public tool that gives information _verbose enough_ to understand what is being tested and what is going wrong if DNS configuration is deemed bad (according to DNS RFCs, BCP documents and the registry's policy). As Jim said it below, the new version of the same tool will be presented at the DNS-wg session and everybody can try (http://zonecheck.afnic.fr/v2/) and give us (zonecheck at afnic.fr) feedback whether something is missing or not clear enough. | | JFC> Example: when the nameserver is on the same machine as the | JFC> site, I never understood why I would need two name servers. | | Read section 3.3 of RFC2182. In fact, read the whole RFC. | | JFC> I would be really interested if Patrick's work permitted | JFC> that: to tell me what may be wrong in my files and to teach | JFC> me to correcty right them? | | Well, someone from AFNIC will be talking about their new delegation | checking tools and processes at the WG tomorrow. The presentation | should be on the RIPE web site by early next week at the latest. | | I'm hoping the WG will use tomorrow's session on delegation checking | to work on this topic: perhaps produce a BCP or something like that. If | this gets under way, it would be useful to get contributions on things | like the nature of error messages and so on. ==> Hope so. Mohsen. From jefsey at jefsey.com Wed May 14 19:24:44 2003 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Wed, 14 May 2003 19:24:44 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: <25746.1052922330@shell.nominum.com> References: <5.2.0.9.0.20030513182018.042de250@mail.jefsey.com> Message-ID: <5.2.0.9.0.20030514190419.02c10a90@mail.jefsey.com> Dear Jim and Mohsen, On 16:25 14/05/03, Jim Reid said: > >>>>> "JFC" == JFC (Jefsey) Morfin writes: > > JFC> When I cannot register a ".fr" or a ".tp" name because of the > JFC> retsrictions imposed by their NICs I am upset. I would prefer > JFC> - and I would be gratefull - if they told me what is wrong I > JFC> could correct when I want, but securing the DN in the > JFC> meanwhile? > >This is really something to discuss with the registry concerned. We are just talking of restrictions imposed by registry BPs. BPs should say that restrictions are to be documented both in plain text and decribing case per case the tested reasons of a denial so one can document when the testing is wrong. BPs should also say that the intended registration should be valid when the denial of registration is due to its wrong analysis of the registrant configuration. There is no reason why the first come first served rule would defeated by an error of the Registry. BPs could say that the registry should provide its proposed DNS configuration, so the Registrant could implement it to get registered. > JFC> Example: when the nameserver is on the same machine as the > JFC> site, I never understood why I would need two name servers. > >Read section 3.3 of RFC2182. In fact, read the whole RFC. This is exactly the section I find inadequate to the case. We all know that. The problem is that some Regustries want to enforce it without discrimination. If the secondary is on the same machine - as I documented - or on the next one or at the other end of the world. It will _not_ improve the average response time to get the information, and will only disseminate a _wrong_ information when the master and the host on the same machine are down. Registry BP should force Registries to accept such registration under the responsiblity of the Registrant as does ".ws". We are talking about BPs you are going to discuss. Good BPs should not lead registrants to trick the Registry: it should consider all the cases and best support the Registrant in every case IMHO. > JFC> I would be really interested if Patrick's work permitted > JFC> that: to tell me what may be wrong in my files and to teach > JFC> me to correcty right them? > >Well, someone from AFNIC will be talking about their new delegation >checking tools and processes at the WG tomorrow. The presentation >should be on the RIPE web site by early next week at the latest. > >I'm hoping the WG will use tomorrow's session on delegation checking >to work on this topic: perhaps produce a BCP or something like that. If >this gets under way, it would be useful to get contributions on things >like the nature of error messages and so on. Certainly ready to help there. Will you address IDNA? jfc http://eurolinc.org From thor at anta.net Thu May 15 11:36:12 2003 From: thor at anta.net (Thor Kottelin) Date: Thu, 15 May 2003 12:36:12 +0300 Subject: [dns-wg] Delegation checking policy/procedure at ARIN References: <20030514100002.17825.39448.Mailman@postboy.ripe.net> Message-ID: <3EC35F8C.1E2CA217@anta.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dns-wg-request at ripe.net wrote: > From: "JFC (Jefsey) Morfin" > when the nameserver is on the same machine as > the site, I never understood why I would need two name servers. > Either the machine is in operation or not. Why could I not > have only one nameserver in that case? As a practical example, someone might need to look up the mail address in your SOA record while "the machine" is down. More generally speaking, domains are administrative entities; using second level domains to name individual boxes is not good namespace administration. Thor - -- http://thorweb.anta.net/ PGP public key available "Women should always wear tight clothes, and men should carry powerful handguns." - Calvin (by Bill Watterson) -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPsNfh+lROe8ye3NFEQLKDQCfdulKFvL1NJ5MdfIARNl9ER1aE4EAoJKV QNm51VjqQB09CyOLkKCHKtiB =8AQi -----END PGP SIGNATURE----- From jefsey at jefsey.com Thu May 15 10:40:37 2003 From: jefsey at jefsey.com (JFC (Jefsey) Morfin) Date: Thu, 15 May 2003 10:40:37 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: <20030515073427.GA28694@nic.fr> References: <5.2.0.9.0.20030514190419.02c10a90@mail.jefsey.com> <5.2.0.9.0.20030513182018.042de250@mail.jefsey.com> <5.2.0.9.0.20030514190419.02c10a90@mail.jefsey.com> Message-ID: <5.2.0.9.0.20030515103239.038239f0@mail.jefsey.com> Dear Stephane, thank you for your remarks. I must say that I did not validate many ".fr" due to the AFNIC resales organization, naming structure and my own users orientations, so my experience with your (our fr) program is limited (and no-experience since IDNA). But we are talking about BPs and my point is certainly that the Registry community should take advantage from AFNIC's efforts (may be smoothing some rigidities - but maybe this has been done?). I want to incitate this experience to be used when considerng BPs. There is no reason when something good is made by some not to tell it. My other point is that such proposed BPs draft should be reveiwable by the @large community(ies). Thank you. jfc At 09:34 15/05/03, Stephane Bortzmeyer wrote: >On Wed, May 14, 2003 at 07:24:44PM +0200, > JFC (Jefsey) Morfin wrote > a message of 64 lines which said: > > > BPs should say that restrictions are to be documented both > > in plain text and decribing case per case the tested reasons > > of a denial so one can document when the testing is wrong. > >They are. Any one can see it by itself at http://zonecheck.nic.fr/v2/. > > > BPs should also say that the intended registration should > > be valid when the denial of registration is due to its wrong > > analysis of the registrant configuration. There is no reason > > why the first come first served rule would defeated by an > > error of the Registry. > >It is not (the ticket is not closed immediately when there is a >configuration error). > > > BPs could say that the registry should provide its proposed > > DNS configuration, so the Registrant could implement it to > > get registered. > >For which software? BIND8, BIND9, nsd, PowerDNS? > > > Will you address IDNA? > >Yes. > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.478 / Virus Database: 275 - Release Date: 06/05/03 From bortzmeyer at gitoyen.net Thu May 15 09:34:27 2003 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Thu, 15 May 2003 09:34:27 +0200 Subject: [dns-wg] Delegation checking policy/procedure at ARIN In-Reply-To: <5.2.0.9.0.20030514190419.02c10a90@mail.jefsey.com> References: <5.2.0.9.0.20030513182018.042de250@mail.jefsey.com> <5.2.0.9.0.20030514190419.02c10a90@mail.jefsey.com> Message-ID: <20030515073427.GA28694@nic.fr> On Wed, May 14, 2003 at 07:24:44PM +0200, JFC (Jefsey) Morfin wrote a message of 64 lines which said: > BPs should say that restrictions are to be documented both > in plain text and decribing case per case the tested reasons > of a denial so one can document when the testing is wrong. They are. Any one can see it by itself at http://zonecheck.nic.fr/v2/. > BPs should also say that the intended registration should > be valid when the denial of registration is due to its wrong > analysis of the registrant configuration. There is no reason > why the first come first served rule would defeated by an > error of the Registry. It is not (the ticket is not closed immediately when there is a configuration error). > BPs could say that the registry should provide its proposed > DNS configuration, so the Registrant could implement it to > get registered. For which software? BIND8, BIND9, nsd, PowerDNS? > Will you address IDNA? Yes. From olaf at ripe.net Mon May 19 10:14:57 2003 From: olaf at ripe.net (Olaf M. Kolkman) Date: Mon, 19 May 2003 10:14:57 +0200 Subject: [dns-wg] Draft DNS-WG minutes from RIPE 45 Message-ID: <20030519101457.4e356923.olaf@ripe.net> Draft DNS-WG minutes from RIPE 45 May 15, 2003 9:00-12:30 Chair: Jim Reid Scribe: Olaf M. Kolkman ------------------------------------------------------------------------ Agenda A. Administrivia: * Minutes of Last Meeting * Matters arising B. IETF Report & News Lars-Johan Liman, Autonomica C. BIND News Joao Damas, ISC D. Invited talk: Mitigating Junk DNS Traffic, How the AS112 Project Can Help. John Brown, Chagres Technologies (cancelled) E. Invited Talk: DNS RTT Measurements: ccTLDs compared with roots/gTLDs Nevil Brownlee, CAIDA F. Delegation and Lame Server Checking ZoneCheck: DNS zone checking tool Stephane D'Alu, AFNIC Fixing Lameness - A Registry Perspective Ed Lewis, ARIN New Tools for Lameness and Delegation Checking Patrik Faltstrom, Cisco Systems Panel Session on Delegation and Lame Server Checking Stephane D'Alu, Ed Lewis & Patrik Faltstrom G. AOB --------------------------------------------------------------------------- A. Administrativia Slightly modified above. - The chair expanded on the fact that the working-group is intended to do some work and that the delegation check panel discussion may end up as a work item for this group; a policy document. - Minutes where approved. - Issues arising: + Andrei Robachevsky on delegation from 2002.ip6.arpa: 2002 space and reverse delegation. Delegation does not scale, it is mapped to /32 in IPv4 space. The issue is currently discussed in the IAB where the decision about delegation to the RIRs is made. After a positive decision a proposal will come to the RIRs and the community will need to work on the policies. Next step in this process in is a meeting between RIR and IAB in Vienna. Remark: Currently only 3 delegations requests. Chair: After gauging consensus: Due to little interest working on a policy is not to become a WG item just yet. + DNS WG and DNR Forum overlap Rob Blokzijl: Its becoming more and more complicated to explain the differences between the DNS-WG and DNR Forum. It is difficult to find out for participants to go where and for the chairs to find out where a presentation belongs. Confusion is the result. The proposal is to combine the meetings of the two groups and allocate 3-4 slots and have the combined meeting chaired by the DNS-WG and DNR-Forum chairs. As a next step the groups may be merged. Comments are: - Let's get on with technical work. - Giving the efficiency combining meetings are good. - There are advantages scheduling DNR issues early in the week, close to the CENTR technical meeting. - There are worries about the amount of time allocated to the combined groups. Rob Blokzijl answered that the amount of slots is allocated by the amount of agenda items, early agendas will help a proper slot allocation. ------------------------------------------------------------------------ B. IETF Report & News Lars-Johan Liman, Autonomica Slides available at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe-45-dns-ietf.pdf Lars-Johan gave an update IETF developments. In the DNSEXT working group: - the details of "Jakob's bug", a DNSSEC related development - IPv6 support in the root. - LLMNR (Link Local Multicast Name Resolution); a protocol for resolving names when there are no external DNS servers. - Clarification of the wildcard processing; few implementations do it correct. - 6DNAR IPv6 Domain Name Auto Registration. - DNSSEC docs, these are under rewrite; some details need to be decided on. - DS draft changes In DNSOP - New chairs Rob Austein and Dave Meyer. - 6to4 delegations; does not follow allocation tree. - .local zones problems: Queries that are supposed to remained in a limited 'scope' leak out. There are a number of solutions. - Response sizes of delegation records. The size of an answer is a function of the query name; how to make sure one receives glue [Quote of the day: "This one is quicker and bigger than your pointer"] ----------------------------------------------------------------------- C. BIND News Joao Damas, ISC Slides available at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-bind.pdf Joao described developments: - BIND8 8.4.0 (in RC1): has IPv6 transport and bug fixes. 8.3.5 same as 8.4.0 without IPv6 - BIND9 9.3.0 no release date defined 9.2.2 DNSSEC _not_ defined at compile time. 9.2.3 bug fix release - BIND developments GSS-TSIG to be incorporated in 9.3 and performance increase. - BIND Forum The forum is a source of funding for BIND development and support. Members have CVS access to bind9 code. Increase of membership is needed to achieve stability. - OpenReg: reference implementation of an EPP based registry system. - F-ROOT: Anycasting on a large number of local nodes. Joao concluded with expressing gratitude for RIPE NCCs contribution to the BIND forum. ----------------------------------------------------------------------- D. Invited talk: Mitigating Junk DNS Traffic, How the AS112 Project Can Help John Brown, Chagres Technologies Cancelled due to illness. ----------------------------------------------------------------------- E. Invited Talk: DNS RTT Measurements: ccTLDs compared with roots/gTLDs Nevil Brownlee, CAIDA Slides available at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-nevil.pdf Nevil does passive measurements of DNS traffic and presented a talk similar to the EOF presentation on Monday though tailored towards ccTLDs. He stressed that this is on-going work and that he is interested in feedback on what aspects are interesting for ccTLDs to measure. Nevil went into the details of measurements made in the first week of May and demonstrated how certain effects in his plots can be explained by congestion close to the probe or the server, daily load effects, route changes, &c, &c. He demonstrated some of the differences in the measurements of Root/gTLD and ccTLDs. One remarkable observation is that the Suriname (SR) TLD seems to be a very popular TLD among the measurement sites. Comments on SR being 'that popular' + Liman notes that this may be a bug. + Faltsrom did some tests: SR seems to have a lame delegation to one of the servers that returns a SERVFAIL for some queries. This may cause an increase of traffic. Nevil further showed slides with details about a number of ccTLDs and explained the congestion patterns. More NeTraMet meter sites for DNS monitoring ar needed. following the "Setting up a NeTraMet meter" on http://www.caida.org/~nevil Chair's Question: Could you give recommendations, using this data, to ccTLD operators. Answer: willing to collaborate if there is interest. Chair's Question2: Maybe looking at the semantic content can be useful for understanding what is going on. Answer: There are limitations, line rates only allow to look at the first cell currently. With new interface cards looking at DNS content might become possible. ----------------------------------------------------------------------- F. Delegation and Lame Server Checking F.1 ZoneCheck: DNS zone checking tool Stephane D'Alu, AFNIC Slides available at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-zonecheck.pdf Tool available at http://zonecheck.nic.fr/v2/ For testing contact Stephane presented the 2nd version of ZoneCheck. Highlights: + Checks on: o DNS RRs: SOA, NS, A, AAAA, MX, o Consistency: SOA serials and content o Flags: recursion and authority. + Modular build so other checks can be build in. (RFC compliant checking tool) + monitoring: http://tac.eureg.org/mon/ + Strengths of the tool Answer to a question about languages: Both French and English are available. Faltsrom: Test on open relay reports false positive Answer bug. F.2 Fixing Lameness - A Registry Perspective Ed Lewis, ARIN Presentation at http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-testing-lameness/ Ed presents the impact on the ARIN engineering department for doing lameness tests. The goal is to give references to those engineers who want to do lameness tests too. This work is based on a policy described in http://www.arin.net/policy/2002_1.html He discussed a number of issues that one has to consider: o why do you want to do lameness tests (save the net or save the DNS). o How do you store your registry data against you want to check (how do you perform the mapping). o When and how do you contact a registrant. o Taking into account the change in the db based on your feedback. o Staging your test (in line with your testing policy): o Training your first line support staff o What kind of statistics do you keep and present o What is best practice and what is "allowed" practice; how far do you go into improving data. o How do you share information with other registries. Comments by George Michealson: There is an emerging policy in the APNIC DNS-SIG. There are questions like what are definitions of lameness and what are the procedures to be followed. He welcomes feedback. George comments on the differences in his personal opinion on some of the choices made by ARIN and his own ideas on lameness: e.g. a 60 days timeout should be considered consistently lame. Jim Reid asked what kind of response you get from customers. Ed answers that the responses were positive and reactive. F.3 New Tools for Lameness and Delegation Checking Patrik Faltstrom, Cisco Systems Slides available at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-check/ Patrik presented 'dnscheck' (http://dnscheck.paf.se). He gave a life demonstration. The tool reports errors where an error is defined as not getting relevant data back. i.e. if only one of the nameservers does not return a proper answer. The tool concentrates on 'parent-child' relation ships. The .SE zone returns 22% errors. 41% lame, 14% missing A, 14% TCP, 6% non-functioning email in SOA, 5% illegal CNAME in MX, 4% has less than 2 NS RRs. Only a small fraction of the zones have combined errors. Patrick poses questions; how come? what are the requirement, what are the recommendations? Is this a WG issue? Tool at http://dnscheck.paf.se discussions on On the APNIC mailing list (sig-dns) a discussion has been begun to try and define the problem needing to be solved (assuming there is one). I'm not sure that the discussion should be mirrored here, but I wanted to call attention to those interested. List info - List-Id: APNIC SIG on DNS issues List-Archive: Before spouting too much on my own here, what is the topic that needs to be discussed(on this mailing list)? ...what RIPE defines (or should define) as a problem delegation? ...a means to measure the health of the DNS delegations? ...how ccTLDs go about testing delegations? ...what responsibility a registry has in publicizing their test criteria? I know that some of the above are topics that are not what is desired, but I'm just trying to throw out some suggestions. The reason I am doing this is that there has been a recent spurt in DNS health mailing lists and it would be good if we could consolidate discussions so as not to cross-post, repost, etc. Also, the topics above have either recently appeared or were mentioned at the recent meeting. BTW - I am not saying that RIPE has a lame delegation problem. Stats I've seen are that "bad delegations" are much more rare in the RIPE region than in the ARIN region. There are possibly clear reasons for this - in the ARIN region, delegations are "cut" in the DNS without any pre-testing of servers. Also, ARIN has a lot of delegations that predate ARIN's establishment. Also - I'm shying away from using "lame delegations" based on how it is defined in the RFCs. The suggested name I threw onto the APNIC list is "unreachable zones." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. From brad.knowles at skynet.be Thu May 22 00:40:07 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu, 22 May 2003 00:40:07 +0200 Subject: [dns-wg] lameness and unreachability In-Reply-To: References: Message-ID: At 9:39 AM -0400 2003/05/21, Edward Lewis wrote: > Before spouting too much on my own here, what is the topic that needs > to be discussed(on this mailing list)? > > ...what RIPE defines (or should define) as a problem delegation? This is a good question. IMO, as far as RIPE is concerned (in and of itself), lame delegations (or "unreachable zones") have only to do with delegations within the appropriate reverse DNS space. The forward delegations are handled separately via the ccTLDs, over which RIPE has no control. This isn't to say that the RIPE DNS WG couldn't help define some terms for this issue and suggest some ideas that appear to be workable (based on experience from ARIN, APNIC, etc...), but it doesn't seem to directly impact on RIPE itself. > ...a means to measure the health of the DNS delegations? I think we can be much more objective on this issue. We can categorize the various ways in which servers may have operational problems and be "unreachable", and using that data we can come to some determination about whether or not the entire zone is unreachable. I think that this could be a good discussion to have, or at least to monitor the appropriate part of the APNIC discussion. > ...how ccTLDs go about testing delegations? I think we could talk about how the RIPE NCC does this for the appropriate reverse DNS space, and give some suggestions on how this could be done for the forward delegation space. However, that would need input and coordination from the RIPE NCC, and we'd need a lot of input & feedback from the various ccTLD operators. > ...what responsibility a registry has in publicizing their test criteria? See above. > Also - I'm shying away from using "lame delegations" based on how it > is defined in the RFCs. The suggested name I threw onto the APNIC > list is "unreachable zones." I think that is a good term. It covers more than just the specific issue of whether or not a server is "lame" for a particular zone, etc.... I believe that we should expand this to include "unreachable servers", and give some further thought as to the various different failure modes and what they might mean. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From daniel.karrenberg at ripe.net Thu May 22 10:02:20 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 22 May 2003 10:02:20 +0200 Subject: [dns-wg] Progress with DNS Quality, Also: Lameness Message-ID: <20030522080220.GB2283@reifa-wave.karrenberg.net> [For those who were at the last meeting: This is a hopefully more coherent version of what I was trying to say to the lameness panel. Maybe I was too shocked by almost killing two laptoys ...] We have had DNS "protocol police" efforts for much more than 10 years now, yet the proportion of misconfigured DNS servers and zones is rising by all policing standards. Yet the DNS keeps working for the parts that really matter. Yet the clueful people who care configure DNS correctly. Yet the others often do not. Nothing changes really despite a lot of effort put in and a lot of improvement in the (self)policing tools. Also the resources for policing are always lacking. As Ed Lewis has pointed out yet again, it is not about finding the problems but about reaching the people who can fix the problems, educate them and make them care. The amount of those resources is always underestimated by us engineers, even those who have (had to) organise such resources. So here is my proposal: Sell the police reports as a premium service! How about your friendly RIR providing an extra service of checking your reverse DNS tree for a small additional fee that covers the people resources needed to get the reports to you and follow up on them. This would serve several purposes: - It would pay for the extra resources needed. - It would make people care for the information and make it more likely they acted on it; after all they paid for it. - It would clearly establish if people cared enough about their DNS quality to do something about it. Daniel From Jim.Reid at nominum.com Thu May 22 11:04:35 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Thu, 22 May 2003 02:04:35 -0700 Subject: [dns-wg] Progress with DNS Quality, Also: Lameness In-Reply-To: Message from Daniel Karrenberg of "Thu, 22 May 2003 10:02:20 +0200." <20030522080220.GB2283@reifa-wave.karrenberg.net> Message-ID: <17819.1053594275@shell.nominum.com> >>>>> "Daniel" == Daniel Karrenberg writes: Daniel> How about your friendly RIR providing an extra service of Daniel> checking your reverse DNS tree for a small additional fee Daniel> that covers the people resources needed to get the reports Daniel> to you and follow up on them. I agree that someone could/should offer a service selling police reports. And related stuff such as audits and logs: "Yes, your name servers were working just fine between 14:40 and 16:00 on June 1st 2002". However I am very uncomfortable with an RIR providing this kind of service, even though they're more likely to be respected as protocol police. There are a number of reasons for this. First of all I'm not sure if services like this fall within the remit of what an RIR is supposed to do. Secondly an RIR is a monopoly and should be *very* careful about extending into new service areas. The likes of the EU anti-competition folks could get very excited about that. Thirdly, this the kind of service that could be offered by others: ISPs, registrars, DNS consulting companies and so on. Many of them will already be paying fees to the RIR. An RIR shouldn't be competing with its customers -- why bite the hand that feeds it? -- or distorting the market. Fourthly, if an RIR diversifies into offering these peripheral services, there is a danger that it will lose sight of its core registry function. I do like the idea of RIRs having top-up charging for additional services. This is a good way to make those services self-financing and be seen to not be a drain on the RIR's core funding. And if that keeps the annual fees down, even better. However this is a discussion that should be going on somewhere else: the new NCC services WG perhaps? Finding out who'd be willing to pay for lameness checks would be worthwhile. However I suspect it won't tell us anything we don't already know. Clueful people might pay. But in general they don't have lame servers. The clueless won't pay because they don't know or care about lameness. They'll be the ones that have the lame delegations. The challenge will always be how to reach out to these people. There's an education problem here. I think the WG could come up with a definition of lameness and a business justification why it's a bad thing. It would be great if registrars & registries could pick this up, point their customers at checking tools and persuade them to regularly use those tools. This is do-able IMO. From paf at cisco.com Thu May 22 11:09:14 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Thu, 22 May 2003 11:09:14 +0200 Subject: [dns-wg] Progress with DNS Quality, Also: Lameness In-Reply-To: <20030522080220.GB2283@reifa-wave.karrenberg.net> Message-ID: <0EEB870F-8C35-11D7-8624-000A959CF516@cisco.com> On torsdag, maj 22, 2003, at 10:02 Europe/Stockholm, Daniel Karrenberg wrote: > Nothing changes really despite a lot of effort put in and > a lot of improvement in the (self)policing tools. To be honest, the result I have shows for .SE: - Overall "errors" is 22.5% - Errors "large" DNS operators have is approximately 1% - "Large" DNS operators are asking me many questions because they think 1% is too bad (they have pushed it down from 1.1% to 0.6% So, my conclusion is that one can not look at the overall average because I don't think that matters so much. Many domains being lame and bad (in the forward zones) might be domain names only "registered" by people wanting the domain name, but they are not "in use". For in-addr.arpa, I don't know if one can draw the same or similar conclusions. It might be more the ISP interest of running in-addr.arpa in the first place which matters. paf From brad.knowles at skynet.be Thu May 22 16:18:53 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu, 22 May 2003 16:18:53 +0200 Subject: [dns-wg] Progress with DNS Quality, Also: Lameness In-Reply-To: <20030522080220.GB2283@reifa-wave.karrenberg.net> References: <20030522080220.GB2283@reifa-wave.karrenberg.net> Message-ID: At 10:02 AM +0200 2003/05/22, Daniel Karrenberg wrote: > So here is my proposal: > > Sell the police reports as a premium service! IMO, the problem is that the people who really need the service (those with unreachable servers and unreachable zones) are most likely the people who won't know that the premium service exists, or that they need it. Moreover, even if they know about it, they probably won't pay for it. I would be inclined to turn this around. Make the service an integral part of the array of services that are provided, and put into the contract that if certain circumstances occur, you can be charged extra as a result of your negligence. You could even have the zone taken away from you, if things got really bad. The only people who "pay" are those who are causing problems. The only issue I see here is making this kind of policy change effective retroactively, and getting all the various registrars of ccTLDs (and presumably the registrars of gTLDs) to go along. No one who needs the medicine will want the carrot that will provide it, or will know that they should want it. But they will all want to avoid the stick. At the very least, a more coordinated and public "name and shame" campaign might possibly do some good. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From joao at psg.com Thu May 22 16:59:23 2003 From: joao at psg.com (Joao Luis Silva Damas) Date: Thu, 22 May 2003 16:59:23 +0200 Subject: [dns-wg] Progress with DNS Quality, Also: Lameness In-Reply-To: References: <20030522080220.GB2283@reifa-wave.karrenberg.net> Message-ID: At 16:18 +0200 22/5/03, Brad Knowles wrote: >At 10:02 AM +0200 2003/05/22, Daniel Karrenberg wrote: > >> So here is my proposal: >> >> Sell the police reports as a premium service! > > IMO, the problem is that the people who really need the >service (those with unreachable servers and unreachable zones) are >most likely the people who won't know that the premium service >exists, or that they need it. Moreover, even if they know about it, >they probably won't pay for it. > > I would be inclined to turn this around. Make the service an >integral part of the array of services that are provided, and put >into the contract that if certain circumstances occur, you can be >charged extra as a result of your negligence. You could even have >the zone taken away from you, if things got really bad. The only >people who "pay" are those who are causing problems. While this seems a fine idea from a geeky point of view, who exactly is going to give the authority to the RIR to carry out such a task? And how is the RIR going to enforce this sort of "traffic violations"? ... > > At the very least, a more coordinated and public "name and >shame" campaign might possibly do some good. Be careful with "name and shame" policies. People might start asking why an organisation they are giving money to (particularly if they have only one choice for that organisation) would go about "naming and shaming" them. Informational statistical reports are one thing. Targetting and enforcement are a very different game, one that most organisations would onyl swallow, and with difficullty, if it is presented as a "click here and you will correct the wrong stuff" type of project, that is: help rather than punish. Joao From edlewis at arin.net Thu May 22 17:49:25 2003 From: edlewis at arin.net (Edward Lewis) Date: Thu, 22 May 2003 11:49:25 -0400 Subject: [dns-wg] lameness and unreachability In-Reply-To: <20030522153751.GW17732@nic.fr> References: <20030522153751.GW17732@nic.fr> Message-ID: For educational purposes, I'd like to ask about some of the errors/warnings as listed. I'll try to stay away from tool-specific suggestions, as this isn't the list for your tool. At 17:37 +0200 5/22/03, Stephane D'Alu wrote: >Here is the list of tests available in the ZoneCheck v2 tool, >with the severity (Fatal/Warning) that are used in the configuration >file to check domain in .fr before accepting the delegation. > >Severity Test >Fatal/warning >F dash ('-') at start or beginning of domain name According to 1035, that is legal. Or do you mean a - at the beginning of a hostname? >F illegal symbols in domain name (RFC1034) I don't think there are any - in a 'domain' name. Yes, in a host name. >W ICMP answer I don't know that this is a concern of DNS - what the other protocols can or can't do. >W nameserver addresses are all on the same subnet (RFC2182) The problem with this test is the rise of anycast. It's harder to determine remotely if servers are all on the same subnet. >W delegated domain is not an openrelay >W domain of the hostmaster email is not an openrelay That's beyond DNS. A real concern, but if I just want to test DNS, then I don't want to do those tests. >W SOA 'minimum' less than 3 hours >W SOA 'refresh' at least 6 hours >W SOA 'retry' at least 1 hour I would think that these are policy dependent - sometimes shortened numbers are a good thing - if you are willing to pay the performance price. >W serial number of the form YYYYMMDDnn (RFC1912) With the advent of dynamic update, the last is no longer recommended. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. From pk at TechFak.Uni-Bielefeld.DE Thu May 22 18:27:06 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 22 May 2003 18:27:06 +0200 Subject: [dns-wg] lameness and unreachability In-Reply-To: Your message of "Thu, 22 May 2003 11:49:25 EDT." Message-ID: <200305221627.h4MGR6E19695@grimsvotn.TechFak.Uni-Bielefeld.DE> Ed Lewis wrote: > >W SOA 'minimum' less than 3 hours > >W SOA 'refresh' at least 6 hours > >W SOA 'retry' at least 1 hour > > I would think that these are policy dependent - sometimes shortened > numbers are a good thing - if you are willing to pay the performance > price. "you" is us in certain cases. As discussed in RIPE 203 the refresh and retry values affect the zone server operators. It's useful to check relative consistency, i.e. retry >W serial number of the form YYYYMMDDnn (RFC1912) I did not yet see the original message, but I guess there's a "not" missing here. > With the advent of dynamic update, the last is no longer recommended. Well, I'd rephrase that to "there are more cases where this recommendation is inappropriate". Still the vast majority of zones is small and stable, so it's unlikely Dynamic Update will be used there. However, that recommendation has another drawback. I've seen many cases where after initial setup (probably done by an external consultant) subsequent SOA serial changes were left to the GUI interface/server maintenance tool, which just increases the value by '1'. That means you see the common format, you think it encodes the date of the last change and you're fooled. -Peter From Stephane.DAlu at nic.fr Thu May 22 19:02:51 2003 From: Stephane.DAlu at nic.fr (Stephane D'Alu) Date: Thu, 22 May 2003 19:02:51 +0200 Subject: [dns-wg] lameness and unreachability In-Reply-To: References: <20030522153751.GW17732@nic.fr> Message-ID: <20030522170251.GA17732@nic.fr> On Thu, May 22, 2003 at 11:49:25AM -0400, Edward Lewis wrote: > For educational purposes, I'd like to ask about some of the > errors/warnings as listed. I'll try to stay away from tool-specific > suggestions, as this isn't the list for your tool. > > At 17:37 +0200 5/22/03, Stephane D'Alu wrote: > >Here is the list of tests available in the ZoneCheck v2 tool, > >with the severity (Fatal/Warning) that are used in the configuration > >file to check domain in .fr before accepting the delegation. > > > >Severity Test > >Fatal/warning > >F dash ('-') at start or beginning of domain name > > According to 1035, that is legal. Or do you mean a - at the > beginning of a hostname? In fact the test check for a '-' at the beginning or at the end of a label as suggested in the grammar of 1035. > > >F illegal symbols in domain name (RFC1034) > > I don't think there are any - in a 'domain' name. Yes, in a host name. Test that all characters are in the set [a-z0-9\-] > > >W ICMP answer > > I don't know that this is a concern of DNS - what the other protocols > can or can't do. Agree, this is not directly DNS related (so it is only a warning), but it could sometimes give you a hit on what is wrong. > > >W nameserver addresses are all on the same subnet (RFC2182) > > The problem with this test is the rise of anycast. It's harder to > determine remotely if servers are all on the same subnet. > I don't think there are many anycast server for now, but the heuristic used to determine the subnet make it already a policy issue :( And I fear that the rise of anycast server will make it really difficult to check the consistency of the different server for a zone. > >W delegated domain is not an openrelay > >W domain of the hostmaster email is not an openrelay > > That's beyond DNS. A real concern, but if I just want to test DNS, > then I don't want to do those tests. That was the point of having a list with different degree of 'completeness', you consider (with a RIR point of view) that a minimal set of test is enough to check the 'reachability of a zone', we consider (with a ccTLD point of view) that these tests should be part of a 'good configuration', but I'm sure that different RIR or ccTLD could have intermediate preferences. We could provide different list of test, where the degree of completeness increase. > > >W SOA 'minimum' less than 3 hours > >W SOA 'refresh' at least 6 hours > >W SOA 'retry' at least 1 hour > > I would think that these are policy dependent - sometimes shortened > numbers are a good thing - if you are willing to pay the performance > price. > These tests are only marked as 'Warning', due to the fact that if you really know what you are doing you could want to go beyond the recommanded values. I would like to say that having some tests with a warning severity, make them serve the purpose of a reminder, and that doesn't hurt as people knowing what they are doing will just considered it as a warning other will be gratefull for the hint. > >W serial number of the form YYYYMMDDnn (RFC1912) > > With the advent of dynamic update, the last is no longer recommended. I'll see if there is a way to make an improved test on the serial number (or retire the test otherwise) Sincerly, -- Stephane D'Alu -- AFNIC http://zonecheck.nic.fr/v2/ Check your domain name From edlewis at arin.net Thu May 22 19:20:34 2003 From: edlewis at arin.net (Edward Lewis) Date: Thu, 22 May 2003 13:20:34 -0400 Subject: [dns-wg] lameness and unreachability In-Reply-To: <20030522170251.GA17732@nic.fr> References: <20030522153751.GW17732@nic.fr> <20030522170251.GA17732@nic.fr> Message-ID: At 19:02 +0200 5/22/03, Stephane D'Alu wrote: >In fact the test check for a '-' at the beginning or at the end of >a label as suggested in the grammar of 1035. That section of 1035 is a source of great confusion. Note that the text preceding the parsing rules says: "The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET)." It doesn't say that the syntax rules are mandatory. In fact, elsewhere: # Because these files are text files several special encodings are # necessary to allow arbitrary data to be loaded. In particular: # # \X where X is any character other than a digit (0-9), is # used to quote that character so that its special meaning # does not apply. For example, "\." can be used to place # a dot character in a label. # # \DDD where each D is a digit is the octet corresponding to # the decimal number described by DDD. The resulting # octet is assumed to be text and is not checked for # special meaning. So, arbitrary octet values are allowed, but isn't 8-bit clean because of the upper==lower case rules. >I don't think there are many anycast server for now, >but the heuristic used to determine the subnet make it already >a policy issue :( > >And I fear that the rise of anycast server will make it really >difficult to check the consistency of the different server for a zone. I've already been slapped by our beloved WG chair (Jim) for the same comment when I accused him of placing both name servers for an ENUM experiment on one LAN. He muttered 'they're anycasted...' >We could provide different list of test, where the degree of completeness >increase. At least a flag to trim back the tests... >These tests are only marked as 'Warning', due to the fact that >if you really know what you are doing you could want to go beyond the >recommanded values. Peter mentioned that there is a RIPE document behind this. I wasn't aware of that. (As an aside, there was a short post meeting discussion about where would we publish operations documents - as in within what venue?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. From brad.knowles at skynet.be Thu May 22 20:34:13 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu, 22 May 2003 20:34:13 +0200 Subject: [dns-wg] Progress with DNS Quality, Also: Lameness In-Reply-To: References: <20030522080220.GB2283@reifa-wave.karrenberg.net> Message-ID: At 4:59 PM +0200 2003/05/22, Joao Luis Silva Damas wrote: >> At the very least, a more coordinated and public "name and shame" >> campaign might possibly do some good. > > Be careful with "name and shame" policies. People might start asking > why an organisation they are giving money to (particularly if they > have only one choice for that organisation) would go about "naming > and shaming" them. Sorry, when I said "name and shame", I meant from the perspective of an independent third party. Something along these lines is already done today, but I believe that these efforts could be increased and improved on. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From Stephane.DAlu at nic.fr Thu May 22 17:37:51 2003 From: Stephane.DAlu at nic.fr (Stephane D'Alu) Date: Thu, 22 May 2003 17:37:51 +0200 Subject: [dns-wg] lameness and unreachability In-Reply-To: References: Message-ID: <20030522153751.GW17732@nic.fr> On Wed, May 21, 2003 at 09:39:54AM -0400, Edward Lewis wrote: > On the APNIC mailing list (sig-dns) a discussion has been begun to > try and define the problem needing to be solved (assuming there is > one). I'm not sure that the discussion should be mirrored here, but > I wanted to call attention to those interested. > > List info - > List-Id: APNIC SIG on DNS issues > List-Archive: > > Before spouting too much on my own here, what is the topic that needs > to be discussed(on this mailing list)? > > ...what RIPE defines (or should define) as a problem delegation? > ...a means to measure the health of the DNS delegations? > ...how ccTLDs go about testing delegations? > ...what responsibility a registry has in publicizing their test criteria? > Here is the list of tests available in the ZoneCheck v2 tool, with the severity (Fatal/Warning) that are used in the configuration file to check domain in .fr before accepting the delegation. Severity Test Fatal/warning zone transfer possible zone transfer contains data zone transfer contains valid labels F check if server is really recursive F double dash in domain name (pre-IDN) F dash ('-') at start or beginning of domain name F illegal symbols in domain name (RFC1034) F correctness of given nameserver list F given primary nameserver is primary W ICMP answer W nameserver addresses are all on the same subnet (RFC2182) W address shouldn't be part of a bogon prefix F identical addresses F address in a private network (RFC1918) W nameserver's addresses on same subnet (RFC2182) W loopback delegation (RFC1537) F loopback is resolvable (RFC1537) F hostmaster email address is valid F hostmaster MX is not an alias (RFC974) W delegated domain is not an openrelay W domain of the hostmaster email is not an openrelay F 'postmaster' email address is valid (RFC1123) F MX record present (RFC1912) F MX authoritative answer F MX is not an alias (RFC1912) F MX can be resolved absence of wildcard MX F MX syntax is valid for an hostname F coherence between MX and ANY records F NS record present F NS authoritative answer F NS is not an alias (RFC1912) F NS can be resolved W Nameserver IP reverse F NS name has a valid domain/hostname syntax F coherence between NS and ANY records F one nameserver for the domain (RFC2182) F root servers list present W root servers addresses identical to ICANN (RFC2870) F root servers list identical to ICANN (RFC2870) F at least two nameservers for the domain (RFC2182) F SOA record present F SOA authoritative answer F coherence of master with primary nameserver F coherence of serial number with primary nameserver F illegal characters in SOA contact name (RFC1034) F missused '@' characters in SOA contact name (RFC1034) F SOA 'expire' at least 7 days (RFC1912) F SOA 'expire' at least 7 times 'refresh' W fully qualified master nameserver in SOA F illegal characters in SOA master nameserver W SOA 'minimum' less than 3 hours F SOA master is not an alias (RFC1912) W SOA 'refresh' at least 6 hours W SOA 'retry' at least 1 hour F SOA 'retry' lower than 'refresh' (RFC1912) W serial number of the form YYYYMMDDnn (RFC1912) F coherence between SOA and ANY records F TCP connectivity (RFC1035) F UDP connectivity (RFC1035) Now if we could create such kind of list, to check the "good health" of a domain and have people using it as a reference (ie: RIR, TLD, and implemented in the various zone checking tools), it would be a major step forward. Several list should be created as you don't perform the same check for arpa, tld and other domains. Also you certainly want to have some control on the level of checking that should be performed from an "authoritative answer for SOA and NS records" to a full checking including tests of mail delivery for hostmaster, postmaster, ... This could lead to the creation of sublists. Perhaps in a first time could we try to agree on a minimal list of items to check for a domain. -- Stephane D'Alu -- AFNIC http://zonecheck.nic.fr/v2/ The zone checking tool From Jim.Reid at nominum.com Sat May 24 12:25:11 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Sat, 24 May 2003 03:25:11 -0700 Subject: [dns-wg] lameness and unreachability In-Reply-To: Message from Edward Lewis of "Thu, 22 May 2003 11:49:25 EDT." Message-ID: <92262.1053771911@shell.nominum.com> >>>>> "Ed" == Edward Lewis writes: >> W ICMP answer Ed> I don't know that this is a concern of DNS - what the other Ed> protocols can or can't do. Indeed. In fact checking for ICMP responses may give false positives. It's likely some good name servers will be behind firewalls or routers that don't allow ICMP through. >> W nameserver addresses are all on the same subnet (RFC2182) Ed> The problem with this test is the rise of anycast. It's Ed> harder to determine remotely if servers are all on the same Ed> subnet. True, but it's easy to accommodate the relatively small number of anycast servers and operators. >> W delegated domain is not an openrelay >> W domain of the hostmaster email is not an openrelay Ed> That's beyond DNS. A real concern, but if I just want to test Ed> DNS, then I don't want to do those tests. I agree. Checking and suppressing open relays is a Noble Thing. But it's orthogonal to whether some domain has been set up correctly on decent DNS infrastructure. From Jim.Reid at nominum.com Sat May 24 12:30:18 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Sat, 24 May 2003 03:30:18 -0700 Subject: [dns-wg] lameness and unreachability In-Reply-To: Message from Edward Lewis of "Thu, 22 May 2003 13:20:34 EDT." Message-ID: <92387.1053772218@shell.nominum.com> >>>>> "Ed" == Edward Lewis writes: Ed> Peter mentioned that there is a RIPE document behind this. I Ed> wasn't aware of that. (As an aside, there was a short post Ed> meeting discussion about where would we publish operations Ed> documents - as in within what venue?) The same place as all other RIPE documents? Or am I missing something? To my mind, the DNS WG should produce this document and publish it in the usual way. Though if somewhere like NANOG or IETF would be more appropriate, that's fine by me. From paf at cisco.com Sat May 24 17:52:36 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sat, 24 May 2003 17:52:36 +0200 Subject: [dns-wg] lameness and unreachability In-Reply-To: <92262.1053771911@shell.nominum.com> Message-ID: On l?rdag, maj 24, 2003, at 12:25 Europe/Stockholm, Jim Reid wrote: >>> W domain of the hostmaster email is not an openrelay > > Ed> That's beyond DNS. A real concern, but if I just want to test > Ed> DNS, then I don't want to do those tests. > > I agree. Checking and suppressing open relays is a Noble Thing. But > it's orthogonal to whether some domain has been set up correctly on > decent DNS infrastructure. What I do is to check that the email address "works": - Look up all MX for the domain in SOA email (or all A for SOA email) - Look up all A records for each MX - Look up all IP addresses for each A - Try to connect to port 25 for every A (every A must respond, but only one IP address per A) - Try EHLO and email address -> Warning if this doesn't work, fall back to HELO - Send empty envelope from address -> Warning if this doesn't wor, fall back to use some email address (the one in the settings) - Send rcpt to: email address in SOA -> ERROR if this is not resulting in a 2xx response I personally find this being part of "correct DNS configuration", i.e. I only see "ERRORS" being needed to be fixed. paf From brad.knowles at skynet.be Sat May 24 22:21:25 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat, 24 May 2003 22:21:25 +0200 Subject: [dns-wg] lameness and unreachability In-Reply-To: References: Message-ID: At 5:52 PM +0200 2003/05/24, Patrik F?ltstr?m wrote: > - Look up all A records for each MX > - Look up all IP addresses for each A > - Try to connect to port 25 for every A (every A must respond, but only > one IP address per A) A records *are* IP addresses. Do you mean reverse lookups? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From dns-wg at chagres.net Sun May 25 01:51:35 2003 From: dns-wg at chagres.net (john brown) Date: Sat, 24 May 2003 17:51:35 -0600 Subject: [dns-wg] Progress with DNS Quality, Also: Lameness In-Reply-To: <17819.1053594275@shell.nominum.com> Message-ID: <000501c3224f$68ef4d60$f9ecdfd8@laptoy> We have been developing such a tool. Currently it has about 40 million zones loaded in a SQL database. We have been trying to get ccTLD operators to let us slave or FTP their zones as well. Some let us, many others dont. Access to the tool is based on setting up an account. If you are interested send email to data AT chagres DOT net with your UID, IP addr, Company Affiliation, Statement that you will NOT use for SPAM or HACKING. We will send your password and URL back to you. Today the tool lets you type in ripe.net it returns the list of NS's that end with ripe.net and a count of the zones in the DB for each NS. You can then get a list of zones, or do a LAME check. You can also create a list thats the DIFF between two different NS"s. Say you have NS1.EXAMPLE.COM and NS2.EXAMPLE.COM NS1 has 300 zones and NS2 has 281 zones. You know that they should be the same. You can diff the NS1 and NS2 lists to see whats missing. cheers john brown chagres technologies, inc > -----Original Message----- > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On > Behalf Of Jim Reid > Sent: Thursday, May 22, 2003 3:05 AM > To: RIPE DNS Working Group > Subject: Re: [dns-wg] Progress with DNS Quality, Also: Lameness > > > >>>>> "Daniel" == Daniel Karrenberg > writes: > > Daniel> How about your friendly RIR providing an extra service of > Daniel> checking your reverse DNS tree for a small additional fee > Daniel> that covers the people resources needed to get the reports > Daniel> to you and follow up on them. > > I agree that someone could/should offer a service selling > police reports. And related stuff such as audits and logs: > "Yes, your name servers were working just fine between 14:40 > and 16:00 on June 1st 2002". However I am very uncomfortable > with an RIR providing this kind of service, even though > they're more likely to be respected as protocol police. > > There are a number of reasons for this. First of all I'm not > sure if services like this fall within the remit of what an > RIR is supposed to do. Secondly an RIR is a monopoly and > should be *very* careful about extending into new service > areas. The likes of the EU anti-competition folks could get > very excited about that. Thirdly, this the kind of service > that could be offered by others: ISPs, registrars, DNS > consulting companies and so on. Many of them will already be > paying fees to the RIR. An RIR shouldn't be competing with > its customers -- why bite the hand that feeds it? -- or > distorting the market. Fourthly, if an RIR diversifies into > offering these peripheral services, there is a danger that it > will lose sight of its core registry function. > > I do like the idea of RIRs having top-up charging for > additional services. This is a good way to make those > services self-financing and be seen to not be a drain on the > RIR's core funding. And if that keeps the annual fees down, > even better. However this is a discussion that should be > going on somewhere else: the new NCC services WG perhaps? > > Finding out who'd be willing to pay for lameness checks would > be worthwhile. However I suspect it won't tell us anything we > don't already know. Clueful people might pay. But in general > they don't have lame servers. The clueless won't pay because > they don't know or care about lameness. They'll be the ones > that have the lame delegations. The challenge will always be > how to reach out to these people. > > There's an education problem here. I think the WG could come > up with a definition of lameness and a business justification > why it's a bad thing. It would be great if registrars & > registries could pick this up, point their customers at > checking tools and persuade them to regularly use those > tools. This is do-able IMO. > From paf at cisco.com Sun May 25 07:56:25 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sun, 25 May 2003 07:56:25 +0200 Subject: [dns-wg] lameness and unreachability In-Reply-To: Message-ID: <9E63CDD0-8E75-11D7-9094-000A959CF516@cisco.com> On l?rdag, maj 24, 2003, at 22:21 Europe/Stockholm, Brad Knowles wrote: > At 5:52 PM +0200 2003/05/24, Patrik F?ltstr?m wrote: > >> - Look up all A records for each MX >> - Look up all IP addresses for each A >> - Try to connect to port 25 for every A (every A must respond, but >> only >> one IP address per A) > > A records *are* IP addresses. Do you mean reverse lookups? Grrr....it was very much evening when I wrote it. The above doesn't make sense. What I do is: (1) Query for all MX records, and get back domain names (2) Query for all A records for every domain name (3) Try to connect to port 25 for every domain name one have I.e. "look up all A records for each MX" means "gather all domain names from all MX records". Yes, I know it didn't make any sense. Sorry. The code is available at http://dnscheck.paf.se/ paf From Jim.Reid at nominum.com Tue May 27 10:07:46 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Tue, 27 May 2003 01:07:46 -0700 Subject: [dns-wg] Progress with DNS Quality, Also: Lameness In-Reply-To: Message from "john brown" of "Sat, 24 May 2003 17:51:35 MDT." <000501c3224f$68ef4d60$f9ecdfd8@laptoy> Message-ID: <53838.1054022866@shell.nominum.com> >>>>> "john" == john brown writes: john> We have been developing such a tool. Currently it has about john> 40 million zones loaded in a SQL database. john> Today the tool lets you type in ripe.net john> it returns the list of NS's that end with ripe.net and a john> count of the zones in the DB for each NS. john> You can then get a list of zones, or do a LAME check. john> You can also create a list thats the DIFF between two john> different NS"s. This sounds like ideal material for a presentation at RIPE46. :-)