May 2003 - dns-wg - mailman.ripe.net

Re: [dns-wg] Progress with DNS Quality, Also: Lameness
by Jim Reid 27 May '03

27 May '03

>>>>> "john" == john brown <dns-wg(a)chagres.net> 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. :-)

1 0

Re: [dns-wg] lameness and unreachability
by Jim Reid 25 May '03

25 May '03

>>>>> "Ed" == Edward Lewis <edlewis(a)arin.net> 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.

3 3

Re: [dns-wg] Progress with DNS Quality, Also: Lameness
by Jim Reid 24 May '03

24 May '03

>>>>> "Daniel" == Daniel Karrenberg <daniel.karrenberg(a)ripe.net> 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.

2 1

Re: [dns-wg] lameness and unreachability
by Jim Reid 24 May '03

24 May '03

>>>>> "Ed" == Edward Lewis <edlewis(a)arin.net> 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.

1 0

Progress with DNS Quality, Also: Lameness
by Daniel Karrenberg 22 May '03

22 May '03

[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

4 4

lameness and unreachability
by Edward Lewis 22 May '03

22 May '03

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 <sig-dns.lists.apnic.net> List-Archive: <http://www.apnic.net/mailing-lists/sig-dns/> 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.

4 6

Draft DNS-WG minutes from RIPE 45
by Olaf M. Kolkman 19 May '03

19 May '03

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-zonechec… Tool available at http://zonecheck.nic.fr/v2/ For testing contact <zonecheck(a)nic.fr> 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-… 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 <dnscheck(a)lists.paf.se. Question by Jim Reid: Are the tests cached so one can tell that things are improved. Answer: Tests are not being stored for more than the tests that failed during the latest one. Question Bernard Tuy: is there IPv6 support Answer DNSSEC and IPv6 are on the stack. Question Winkler: How do you check the consistency at the root. What is the authoritative information. The delegation NS set or the TLD NS set. Answer: First the root delegation NS set is requested, it is checked for consistency in the NS RR set in the TLD, then the glue is verified against the addresses in the DNS. Remark by George Michaelson: The trends seem flat. Answer: The data is only been collected for a month. 2nd Remark by George Michaelson: An authoritative NXDOMAIN hurts the end-users most. F.4 Panel Session on Delegation and Lame Server Checking Stephane D'Alu, Ed Lewis & Patrik Faltstrom Andrei Robachevsky and George Michealson Chair explains that this is a mixture of technology and policy and that there may a working item for this working group. Daniel Karrenberg: The quality of the DNS lameness seems to have been constant. The DNS remains working. Do we want to play protocol police? Will there be an impact on the registry operators? Randy Bush: If you delegate zones you are responsible for the technical quality. The availability of tools helps. DNS breakages effect end users e.g. microsofts delegation not observing RFC 2881 recommendations. Let us not wait for fatal breakage. Patrick Faltsrom: Big DNS operators seem to be able to do a better job. This may be due to the availability of better tools. (General availability of tools, also for smaller DNS operators, is good) Mohsen: Lame delegation happens after the delegation. Regular checks are good. Akkerhuis: Most complaints are not about being lame but more that registrants have moved domains and old ISPs have not removed their zones from the old zones. (Karrenberg suggests that with tools that keep history you can actually check this) Karrenberg: It is a good thing that zone administrators checking what happens in their zones but are the mechanism used correct? Reid: How do we do this; which tools do we need, what policy statements. Randy: Since there is no increased error rate. Do not confuse RIPEs job with the job of the ccTLDs. Michaelson: Lameness is not well defined. We probably need a good common understanding. Faltsrom refined that we should be careful to not to have statements about lameness into quality statements. The chair gauged if there is consensus for working on this lameness issues in particular with respect to practices on the reverse tree. Reid, Faltsrom and Michaelson volunteered further discussion on the mailinglist. ----------------------------------------------------------------------- AOB: A patent was granted to Verisign for multiple simultaneous domain name searches. 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. ---------------------------------------------------------------------

1 0

Re: [dns-wg] Delegation checking policy/procedure at ARIN
by Thor Kottelin 15 May '03

15 May '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dns-wg-request(a)ripe.net wrote: > From: "JFC (Jefsey) Morfin" <jefsey(a)jefsey.com> > 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-----

1 0

Re: [dns-wg] Delegation checking policy/procedure at ARIN
by Jim Reid 15 May '03

15 May '03

>>>>> "JFC" == JFC (Jefsey) Morfin <jefsey(a)jefsey.com> 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.

4 4

Delegation checking policy/procedure at ARIN
by Jim Reid 13 May '03

13 May '03

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: <a05111b0ebad47bb890b7(a)[192.168.1.100]> Date: Tue, 29 Apr 2003 15:07:00 -0400 To: Jim.Reid(a)nominum.com, Patrik Faltstrom <paf(a)cisco.com>, Peter Koch <pk(a)techfak.uni-bielefeld.de> From: Edward Lewis <edlewis(a)arin.net> Subject: ripe 45 notes Cc: Edward Lewis <edlewis(a)arin.net> 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

6 6