Delegation checking policy/procedure at ARIN
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@[192.168.1.100]> Date: Tue, 29 Apr 2003 15:07:00 -0400 To: Jim.Reid@nominum.com, Patrik Faltstrom <paf@cisco.com>, Peter Koch <pk@techfak.uni-bielefeld.de> From: Edward Lewis <edlewis@arin.net> Subject: ripe 45 notes Cc: Edward Lewis <edlewis@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
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)
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 <http://www.cymru.com/DNS/lame.html>). 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, <brad.knowles@skynet.be> "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(+++)
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 <http://www.cymru.com/DNS/lame.html>).
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
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.
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
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
participants (6)
-
Brad Knowles -
Edward Lewis -
JFC (Jefsey) Morfin -
Jim Reid -
Joe Abley -
Patrik Fältström