From owner-dnsop@cafax.se Tue Apr 1 00:20:02 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12295 for ; Tue, 1 Apr 2003 00:20:01 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h314t9RN015789 for ; Tue, 1 Apr 2003 06:55:09 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h314t9iF015788 for dnsop-outgoing; Tue, 1 Apr 2003 06:55:09 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h314t8RN015783 for ; Tue, 1 Apr 2003 06:55:08 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8178318DF for ; Mon, 31 Mar 2003 23:55:07 -0500 (EST) Date: Mon, 31 Mar 2003 23:55:07 -0500 From: Rob Austein To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: References: <20030401004624.CAF93198D@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030401045507.8178318DF@thrintun.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk At Mon, 31 Mar 2003 21:03:46 -0500 (EST), Dean Anderson wrote: > > Sorry. It seemed to me that Ray misunderstood the point of this draft. > Clearly, correcting the draft to state ARIN's present policy that in-addr > is not required, is not what the authors intend. Obviously, it contradicts > the title. > > I don't seen an ad hominem in the statement you quote. Loaded terminology (eg, "dictate") while speculating presumptively about the motives and intentions of the draft's author. See message dated 27 Mar 2003 18:40:05 (terms like "culprit", "mislead", and so forth while talking about another person posting to the same message thread) for a more obvious example. > I presume I am allowed to disagree with others. Especially, since I > am not alone in the position. Yes, you're allowed to disagree. What you're not allowed to do is to post essentially the same comment over and over again, or attack the people proposing an idea that you happen to disagree with. > Further, it seems to be an attempt to renew a debate that we've been > having for 10 days. You should chastise the author who brought up > this old topic, not the person who is pointing out that it is an old > topic. Yes, the fact that you seem to be construing this as a continuation of the last ten days worth of in-addr discussion is part of the reason that I asked you to cease and desist. Several people (including both WG co-chairs) asked the draft's author to bring the draft back from oblivion for discussion. Part of the point of the draft is to say that applications that break without the reverse tree should be fixed. > However, if it were a new issue, I should be allowed to state my > disagreements to it, and to help clarify its meaning and implications. As I said in my previous note: if you have something genuinely new to say, go ahead, but please don't repeat the same "we should just get rid of the reverse tree" comment you've been making for the last week and a half, and please let other people have their say without stomping all over them the way that you and Brad did to each other the last time around. > Do we make judgements now without debating the issues? Or am I only > allowed to comment on one topic? No, and no, but please let other people have their say too, without chasing folks away from the list. I'm not that fond of the "debate" model for WG operations, it's much too prone to nonterminating loops in which each participant feels that he must have the last word. What seems to work better is to write a draft, give everybody a chance to state his or her view of whether the draft is on the right track and how it might be improved (preferably based on experience with running code), then see whether there's rough consensus on what to do next with the draft. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 1 07:29:49 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07808 for ; Tue, 1 Apr 2003 07:29:46 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31C1HRN019455 for ; Tue, 1 Apr 2003 14:01:17 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31C1HgD019454 for dnsop-outgoing; Tue, 1 Apr 2003 14:01:17 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31C1FRN019449 for ; Tue, 1 Apr 2003 14:01:16 +0200 (MEST) Received: from ano2 ([192.136.136.29]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id HAA05921; Tue, 1 Apr 2003 07:00:39 -0500 (EST) From: "Ray Plzak" To: "'Dean Anderson'" Cc: Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Date: Tue, 1 Apr 2003 07:00:36 -0500 Message-ID: <000c01c2f846$4fc40200$1d8888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit The way to change policy in the ARIN region is to use the policy process. Please see http://www.arin.net/policy/index.html An RFC will not change a policy in the ARIN region. Ray > -----Original Message----- > From: Dean Anderson [mailto:dean@av8.com] > Sent: Monday, March 31, 2003 4:48 PM > To: Ray Plzak > Cc: dnsop@cafax.se > Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > The goal of this draft is to dictate a change in policy at > ARIN and other > registry's. The authors know about that in-addr is not > required. They are > trying to change that. > > --Dean > > On Mon, 31 Mar 2003, Ray Plzak wrote: > > > > > In paragraph 2 the following is stated: > > > > "ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger > > allocations. For smaller allocations, ARIN can provide > IN-ADDR for /24 > > and shorter prefixes." > > > > The ARIN policy statement is: > > > > "All ISPs receiving a /16 or larger block of space (>= 256 > /24s) from > > ARIN will be responsible for maintaining all IN-ADDR.ARPA > domain records > > for their respective customers. For blocks smaller than > /16, ARIN can > > maintain IN-ADDRs through the use of the SWIP template for > reassignments > > of /24 and shorter prefixes." > > > > > > The policy does not require in-addr service. What it means > is that if > > in-addr service is desired then the responsibility for > allocations of > > /16 or shorter prefixes is that of the ISP receiving the > allocation. If > > the prefix is longer than a /16 and shorter than a /24, > then ARIN will > > provide the service if desired. > > > > Ray > > > > > #------------------------------------------------------------- > --------- > > # To unsubscribe, send a message to . > > > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 1 10:09:57 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17545 for ; Tue, 1 Apr 2003 10:09:56 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31Eg5RN021159 for ; Tue, 1 Apr 2003 16:42:05 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31Eg551021158 for dnsop-outgoing; Tue, 1 Apr 2003 16:42:05 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31Eg3RN021153 for ; Tue, 1 Apr 2003 16:42:04 +0200 (MEST) Received: from [192.149.252.108] ([192.136.136.39]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA19729; Tue, 1 Apr 2003 09:41:58 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030331132915.GA2912@atoom.net> References: <20030331132915.GA2912@atoom.net> Date: Tue, 1 Apr 2003 09:41:55 -0500 To: Miek Gieben From: Edward Lewis Subject: Re: preconfigured keys or ds's Cc: dnsop Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk I really think this is an implementation-by-implementation decision. At best, an information RFC describing your experiences in developing running code. At 15:29 +0200 3/31/03, Miek Gieben wrote: >Hello, > >I would like to see the following documented, but I don't know for sure >if it is a dnssec or dnsop issue: > >The preconfigured keys for resolvers are large and are hard to compare >and read (by humans). DS records on the other hand are much smaller >and easier to handle. I think it would be better to preconfigure >DS records in stead of zone keys for resolvers. This is also how >my perl resolver works. > >Where to put this? In the dnssec drafts or in a seperate dnsop BCP? > >grtz Miek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 1 10:50:48 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22812 for ; Tue, 1 Apr 2003 10:50:46 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31FOtRN021638 for ; Tue, 1 Apr 2003 17:24:55 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31FOtEi021637 for dnsop-outgoing; Tue, 1 Apr 2003 17:24:55 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31FOrRN021632 for ; Tue, 1 Apr 2003 17:24:54 +0200 (MEST) Received: from [192.149.252.108] ([192.136.136.39]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA26761; Tue, 1 Apr 2003 10:24:46 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030321011040.762E12329@thangorodrim.hactrn.net> References: <20030321000814.9709B236B@thangorodrim.hactrn.net> <200303210100.h2L10312030304@birch.ripe.net> <20030321011040.762E12329@thangorodrim.hactrn.net> Date: Tue, 1 Apr 2003 10:24:44 -0500 To: Rob Austein From: Edward Lewis Subject: Re: secondary behavior with DNSSEC Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk This just occurred to me when writing something about lame server checking (don't ask): DNSSEC issues ought to be relegated to the resolvers (recursive servers) and be removed from authoritative servers. Ergo, I would not bother to try to tie the expiration of signatures to the SOA knobs - especially given the difference in 1) the nature of the times (relative, absolute) and 2) the need (or non-need) to synchronize clocks. I.e., the secondary should continue to issue expired signatures as per the rules of the SOA knobs until the master is changed. Perhaps, though, it would be good to suggest SOA knobs that are compatible with signature validity spans and vice versa. However, interleaving the two uses of time is something I'd refrain from. At 17:10 -0800 3/20/03, Rob Austein wrote: >At Fri, 21 Mar 2003 02:00:03 +0100, Olaf Kolkman wrote: >> >> Is it way out of line to have the zone expire if one of the SIGs over >> the SOA expires? >> >> Seems like a reasonable thing to do. > >Bit of a layering violation, isn't it? I'd prefer just to advise the >zone admin as best we can on how to set the knobs we already have. >#---------------------------------------------------------------------- ># To unsubscribe, send a message to . -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 1 12:00:26 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29361 for ; Tue, 1 Apr 2003 12:00:25 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31Gd6RN022647 for ; Tue, 1 Apr 2003 18:39:06 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31Gd6Li022646 for dnsop-outgoing; Tue, 1 Apr 2003 18:39:06 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31Gd5RN022641 for ; Tue, 1 Apr 2003 18:39:05 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 190Omu-000Cyy-00; Tue, 01 Apr 2003 08:39:04 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 190Omr-0004qK-00; Tue, 01 Apr 2003 08:39:01 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 1 Apr 2003 08:39:00 -0800 To: Dean Anderson Cc: dnsop@cafax.se Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt References: <000c01c2f846$4fc40200$1d8888c0@arin.net> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > The goal of this draft is to dictate a change in policy at ARIN > and other registry's. cool! i did not realize rfcs had such power. i will now write some rfcs to o end world hunger, o end all war, and o let everyone eat cake ! randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 1 12:13:25 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00590 for ; Tue, 1 Apr 2003 12:13:25 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31GspRN022813 for ; Tue, 1 Apr 2003 18:54:51 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31Gspcw022812 for dnsop-outgoing; Tue, 1 Apr 2003 18:54:51 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31GsnRN022805 for ; Tue, 1 Apr 2003 18:54:50 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CCC9E198D for ; Tue, 1 Apr 2003 11:54:48 -0500 (EST) Date: Tue, 01 Apr 2003 11:54:48 -0500 From: Rob Austein To: dnsop@cafax.se Subject: Re: secondary behavior with DNSSEC In-Reply-To: References: <20030321000814.9709B236B@thangorodrim.hactrn.net> <200303210100.h2L10312030304@birch.ripe.net> <20030321011040.762E12329@thangorodrim.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030401165448.CCC9E198D@thrintun.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk At Tue, 1 Apr 2003 10:24:44 -0500, Edward Lewis wrote: > > This just occurred to me when writing something about lame server > checking (don't ask): > > DNSSEC issues ought to be relegated to the resolvers (recursive > servers) Verifiers, but otherwise, yes, that's what I meant > and be removed from authoritative servers. Ergo, I would > not bother to try to tie the expiration of signatures to the SOA > knobs - especially given the difference in 1) the nature of the times > (relative, absolute) and 2) the need (or non-need) to synchronize > clocks. > > I.e., the secondary should continue to issue expired signatures as > per the rules of the SOA knobs until the master is changed. Perhaps, > though, it would be good to suggest SOA knobs that are compatible > with signature validity spans and vice versa. However, interleaving > the two uses of time is something I'd refrain from. s/SOA knobs/values for the SOA knobs/, but otherwise yes, that's what I meant. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 1 13:19:18 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06162 for ; Tue, 1 Apr 2003 13:19:17 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31HvxRN023523 for ; Tue, 1 Apr 2003 19:57:59 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31Hvx4D023522 for dnsop-outgoing; Tue, 1 Apr 2003 19:57:59 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31HvvRN023517 for ; Tue, 1 Apr 2003 19:57:57 +0200 (MEST) Received: from [192.149.252.108] ([192.136.136.52]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA24456; Tue, 1 Apr 2003 12:57:56 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030401165448.CCC9E198D@thrintun.hactrn.net> References: <20030321000814.9709B236B@thangorodrim.hactrn.net> <200303210100.h2L10312030304@birch.ripe.net> <20030321011040.762E12329@thangorodrim.hactrn.net> <20030401165448.CCC9E198D@thrintun.hactrn.net> Date: Tue, 1 Apr 2003 12:57:53 -0500 To: Rob Austein From: Edward Lewis Subject: Re: secondary behavior with DNSSEC Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk Sorry - ahh, didn't see that (as in 'what you meant') before. My mind was off in another dark corner of the DNS problem space at the time and didn't interpret you previous message just right. At 11:54 -0500 4/1/03, Rob Austein wrote: > >Verifiers, but otherwise, yes, that's what I meant > >s/SOA knobs/values for the SOA knobs/, but otherwise yes, that's what >I meant. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 1 16:52:13 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17058 for ; Tue, 1 Apr 2003 16:52:11 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31LTuRN025799 for ; Tue, 1 Apr 2003 23:29:56 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31LTu7I025798 for dnsop-outgoing; Tue, 1 Apr 2003 23:29:56 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31LTsRN025793 for ; Tue, 1 Apr 2003 23:29:55 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA03443; Tue, 1 Apr 2003 16:20:54 -0500 Date: Tue, 1 Apr 2003 16:22:52 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Ray Plzak cc: dnsop@cafax.se Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <000c01c2f846$4fc40200$1d8888c0@arin.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk I agree. What happens in the case where an RFC contradicts the policy of a registry? --Dean On Tue, 1 Apr 2003, Ray Plzak wrote: > The way to change policy in the ARIN region is to use the policy > process. Please see > > http://www.arin.net/policy/index.html > > An RFC will not change a policy in the ARIN region. > > Ray > > > -----Original Message----- > > From: Dean Anderson [mailto:dean@av8.com] > > Sent: Monday, March 31, 2003 4:48 PM > > To: Ray Plzak > > Cc: dnsop@cafax.se > > Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > > > > The goal of this draft is to dictate a change in policy at > > ARIN and other > > registry's. The authors know about that in-addr is not > > required. They are > > trying to change that. > > > > --Dean > > > > On Mon, 31 Mar 2003, Ray Plzak wrote: > > > > > > > > In paragraph 2 the following is stated: > > > > > > "ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger > > > allocations. For smaller allocations, ARIN can provide > > IN-ADDR for /24 > > > and shorter prefixes." > > > > > > The ARIN policy statement is: > > > > > > "All ISPs receiving a /16 or larger block of space (>= 256 > > /24s) from > > > ARIN will be responsible for maintaining all IN-ADDR.ARPA > > domain records > > > for their respective customers. For blocks smaller than > > /16, ARIN can > > > maintain IN-ADDRs through the use of the SWIP template for > > reassignments > > > of /24 and shorter prefixes." > > > > > > > > > The policy does not require in-addr service. What it means > > is that if > > > in-addr service is desired then the responsibility for > > allocations of > > > /16 or shorter prefixes is that of the ISP receiving the > > allocation. If > > > the prefix is longer than a /16 and shorter than a /24, > > then ARIN will > > > provide the service if desired. > > > > > > Ray > > > > > > > > #------------------------------------------------------------- > > --------- > > > # To unsubscribe, send a message to . > > > > > > > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 1 19:22:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23016 for ; Tue, 1 Apr 2003 19:22:11 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31NwIRN026979 for ; Wed, 2 Apr 2003 01:58:18 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h31NwIRA026978 for dnsop-outgoing; Wed, 2 Apr 2003 01:58:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31NwGRN026973 for ; Wed, 2 Apr 2003 01:58:17 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA02346; Tue, 1 Apr 2003 18:53:41 -0500 Date: Tue, 1 Apr 2003 18:55:49 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Rob Austein cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030401045507.8178318DF@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk > > I don't seen an ad hominem in the statement you quote. > > Loaded terminology (eg, "dictate") while speculating presumptively > about the motives and intentions of the draft's author. It's hardly "presumtive speculation". It's in the title. Whether RFC's dictate the policies of registries could be an open question, I think. The RFC's that established the current policy predate the current registries. This draft modifies the RFC's that were the basis for the current policies. Clearly, it is the intent of the authors to change this policy, as well as the behavior of implementors, and the policies of the registries. The question of changing this policy, which is now embedded in the policies of multiple organizations, each with their own procedures, is a valid question for this draft. If RFC's can't change these policies, then this Draft (and the proposal for removing Reverse DNS) is beyond the authority of this working group, and perhaps beyond the authority of the IETF. (Though I think, at least with respect to IPV6, it isn't.) If it is beyond the authority of the working group, it is a mute question. > See message dated 27 Mar 2003 18:40:05 (terms like "culprit", "mislead", > and so forth while talking about another person posting to the same > message thread) for a more obvious example. As co-chair, you should know the question "Is reverse optional?", is answerable by reference to RFCs, and it not vague. The question "Is anything broken without reverse?" is also answerable by reference to RFCs, because it follows from the fact that reverse is optional. These are questions of fact, not opinion. From the message you refer to: Dean Anderson writes: That would be fine, except that some people like Vixie and others tend to write software that puts reverse map entries in log files. Then consultants go in and try to figure out who rooted a server, and find bogus reverse entries, and no IP addresses. The culprit gets away because someone told people (or implemented it directly) that they can use reverse as a way to determine the relationship between the network operator and the host operator. They also mislead people about the use of reverse, so that your assertion (according to them, anyway) that "no one is forcing [me] to populate reverse maps" is false. Vixie again repeats the assertion that not having reverse is a sign something is broken, in his last email on the subject. This is a true statement. Paul Vixie and Rob Austein (Rob has made the same claims in the past), have asserted that something is broken if reverse doesn't work. Paul recently posted a message dated 27 Mar 2003 18:28:52 +0000 to DNSOP stating this misinformation again. Rob Austein posted to this same effect 1 Oct 1986 (yes, a long time ago). Both yourself and Paul Vixie are senior enough to know that in fact Reverse DNS is optional, and that (also in fact) nothing is broken (according to RFC) if reverse doesn't work. If you state as fact something that is false, you are misleading people. It is misleading, even if you think it is true, but it is not. My use of the word "misleading" is accurate. Furthermore, stating as fact something that you know or can be expected to know is false, is "intentionally misleading". I did not use the phrase "intentionally misleading", in order to soften the effect. However, this phrase is clearly also accurate and applicable in this case. Vixie's recent claim is "intentionally misleading". Not only did I avoid exaggerated "loaded terms", I have softened the terms I am using. The word "culprit" above refers to someone who has committed some abuse where logs are used to identify the abuser. It is an appropriate use of the term. Perhaps you have misread the paragraph. Also, "loaded terms" may be exaggerations, but they are not "ad hominems". You are misusing the term, if that's your objection to my message. I think I've shown that I have not exaggerated anything. > > I presume I am allowed to disagree with others. Especially, since I > > am not alone in the position. > > Yes, you're allowed to disagree. What you're not allowed to do is to > post essentially the same comment over and over again, or attack the > people proposing an idea that you happen to disagree with. Good. I have done neither of these things. Perhaps you could chastise those that have: Randy Bush, and Brad Knowles, in just the last few days. > > Further, it seems to be an attempt to renew a debate that we've been > > having for 10 days. You should chastise the author who brought up > > this old topic, not the person who is pointing out that it is an old > > topic. > > Yes, the fact that you seem to be construing this as a continuation of > the last ten days worth of in-addr discussion is part of the reason > that I asked you to cease and desist. Several people (including both > WG co-chairs) asked the draft's author to bring the draft back from > oblivion for discussion. Part of the point of the draft is to say > that applications that break without the reverse tree should be fixed. The previous discussion has been about discontinuing reverse. It has been argued and that nothing breaks without reverse, and that there are alternatives for the convenience functions. You (as co-chair) privately asked that this topic stop. Subsequently asking the for the revival of this draft "from oblivion" is troubling. And you asked my to stop pointing out the flaws in this draft, which are unique to the draft. The draft is, at best, a new angle to an old discussion. That is an inappropriate use of your authority to bias the discussion. Apparently, there is no point in discussing this draft. It sounds like the co-chairs have already approved it, despite many senior persons arguing convincingly for the removal of Reverse. Where is the consensus? Indeed, I seem to be justified in my construing it as part of the old topic: George Michelson writes: Wed, 19 Mar 2003 10:48:00 +1000 ok. so you mean "any thread with draft-ietf-dnsop-inaddr-required-00.txt" I'd say its hung jury. Time for a re-trial. I count a number of people for discontinuing Reverse, and making substantial technical contributions: George Michelson Kevin Darcy Shan Kerr JINMEI Tatuya I think others can be convinced with a demonstration of traceroute that doesn't use reverse, but uses ICMP node identification or other alternatives. There are more people on Namedroppers, which has also discussed removing Reverse. Articulate arguments have been made, making the case that Reverse should be removed from IPV6. Many of the technical arguments presented haven't been addressed by the proponents of reverse. There is much work to do in IPV6 before Reverse can really be used, and technical obstacles to overcome. There are substantial, credible problems for IPV6 that have been ignored by the proponents, and apparently, the co-chairs. Not only do applications have to be fixed, protocols have to be fixed, to keep reverse in IPV6. It seems easier to fix the few applications like traceroute, to use alternatives, than to make the changes for IPV6. > > However, if it were a new issue, I should be allowed to state my > > disagreements to it, and to help clarify its meaning and implications. > > As I said in my previous note: if you have something genuinely new to > say, go ahead, but please don't repeat the same "we should just get > rid of the reverse tree" comment you've been making for the last week > and a half, and please let other people have their say without > stomping all over them the way that you and Brad did to each other the > last time around. I have not made any repeating comments. People have raised a number of unique objections to the removal of Reverse. I have pointed out flaws in each of those objections. In other cases, people have posted questions about our asserted harms and other claims, and our position has been clarified. However, certain other people (for example, Brad Knowles) have made repeatedly the same post. For example, Randy Bush has made several comments that have no technical merit whatsoever. In fact, he has not made any technical contribution to the discussion whatsoever. All of his posts on the topic have been totally inappropriate ad hominems, sometimes containing foul language. The term 'Ad hominem" means an attack on the person, as opposed to the arguments made by the person. I have been subjected to ad hominem attacks by Randy Bush, and by Brad Knowles. By contrast, I have not made any personal attacks, except to complain about their ad hominem attacks. Pointing out the flaw in a argument is an attack on an idea, not an "ad hominem". Attacking an idea is not a personal attack. This is an example of an Ad hominem: Brad Knowles writes: Mon, 24 Mar 2003 23:02:34 +0100 Tell me something. How many decades have you been doing DNS? How many decades have you been doing e-mail? Of those decades, how much of that work has been at the highest volume sites in the world, where millions and billions of spams are dealt with on a daily basis? Unless you have more experience doing the DNS than anyone in the world, and more experience doing e-mail and dealing with spam than anyone else in the world, and you can call on this experience in making proclamations about the kind of spam that other people might possibly be seeing and how the DNS might or might not be involved, you really don't have a leg to stand on. Personally, since your first name isn't Paul, or Eric, or some of the various other names I am familiar with, I don't think there's much chance of this. This is another example of an ad hominem: Randy Bush writes: Mon, 24 Mar 2003 17:47:41 -0800 i will send you each a bona fide "You Are Right" certificate if you will both shut the hell up. you are one message from my .procmailrc. dean is a long-time entry. randy This is another example of an ad hominem: Randy Bush writes: Tue, 1 Apr 2003 08:39:00 -0800 cool! i did not realize rfcs had such power. i will now write some rfcs to o end world hunger, o end all war, and o let everyone eat cake ! randy They are ad hominems because they attack me personally. They have nothing to do with any of the arguments I have made. They offer no counter-examples, or otherwise refute anything I said. They are attacks on my person: to ridicule me, or suggest I don't have enough experience to be able to read RFC's or analyze problems. They don't point out any flaws in facts or analysis I present. Instead, they try to point out personal flaws. > > Do we make judgements now without debating the issues? Or am I only > > allowed to comment on one topic? > > No, and no, but please let other people have their say too, without > chasing folks away from the list. I have not chased anyone away. I have not ridiculed anyone, or told anyone they shouldn't post. You seem to be chasing me away, or at least telling me and others that we shouldn't point out the flaws in proposals promoting reverse, and changing current policy on reverse that dates back to 1986. And also that we should ignore the problems presented by Reverse to IPV6. Ignoring these problems threaten IPV6 deployment. > I'm not that fond of the "debate" model for WG operations, it's much > too prone to nonterminating loops in which each participant feels that > he must have the last word. Having the last word isn't debate. But not having debate, as you propose, is worse. Only biased proposals are discussed by their proponents. Everyone who disagrees has been told to "shut up". This is not productive. > What seems to work better is to write a draft, give everybody a chance > to state his or her view of whether the draft is on the right track and > how it might be improved (preferably based on experience with running > code), then see whether there's rough consensus on what to do next with > the draft. That is a debate. To make progress, it is important the chairs organize the debate so that facts are presented, and decisions are made logically, rather than in reference to personalities. Otherwise the organization just stamps the positions of the chair. This eventually leads to a lack of participation, and to poor decision-making. As the chair, you have responsibilities to make the decisions of the organization robust. Failing these responsibilities sabotages the goals of the working group. Instead of using your authority to bias discussion around proposals you personally support, you should chastise those making ad hominem attacks, or otherwise unprofessional posts, to keep discussion on a professional level, and work to clarify arguments and objections, so that rational decisions can be made. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 06:57:29 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05708 for ; Wed, 2 Apr 2003 06:57:28 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32BcWRN002581 for ; Wed, 2 Apr 2003 13:38:32 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h32BcWVi002580 for dnsop-outgoing; Wed, 2 Apr 2003 13:38:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32BcVRN002575 for ; Wed, 2 Apr 2003 13:38:31 +0200 (MEST) Received: from ano2 ([192.136.136.29]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id GAA23690 for ; Wed, 2 Apr 2003 06:38:28 -0500 (EST) From: "Ray Plzak" To: Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Date: Wed, 2 Apr 2003 06:38:25 -0500 Message-ID: <001101c2f90c$5f62a7e0$1d8888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Then the authors of the RFC or some other interested party should make a policy proposal following the policy process. This was done previously with regard to IPv6 end sites [RFC 3177 "IAB/IESG Recommendations on IPv6 Address Allocations to Sites"]. Ray > -----Original Message----- > From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se] On > Behalf Of Dean Anderson > Sent: Tuesday, April 01, 2003 4:23 PM > To: Ray Plzak > Cc: dnsop@cafax.se > Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > I agree. What happens in the case where an RFC contradicts > the policy of > a registry? > > --Dean > > On Tue, 1 Apr 2003, Ray Plzak wrote: > > > The way to change policy in the ARIN region is to use the policy > > process. Please see > > > > http://www.arin.net/policy/index.html > > > > An RFC will not change a policy in the ARIN region. > > > > Ray > > > > > -----Original Message----- > > > From: Dean Anderson [mailto:dean@av8.com] > > > Sent: Monday, March 31, 2003 4:48 PM > > > To: Ray Plzak > > > Cc: dnsop@cafax.se > > > Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > > > > > > > The goal of this draft is to dictate a change in policy at > > > ARIN and other > > > registry's. The authors know about that in-addr is not > > > required. They are > > > trying to change that. > > > > > > --Dean > > > > > > On Mon, 31 Mar 2003, Ray Plzak wrote: > > > > > > > > > > > In paragraph 2 the following is stated: > > > > > > > > "ARIN's policy requires ISPs to maintain IN-ADDR for > /16 or larger > > > > allocations. For smaller allocations, ARIN can provide > > > IN-ADDR for /24 > > > > and shorter prefixes." > > > > > > > > The ARIN policy statement is: > > > > > > > > "All ISPs receiving a /16 or larger block of space (>= 256 > > > /24s) from > > > > ARIN will be responsible for maintaining all IN-ADDR.ARPA > > > domain records > > > > for their respective customers. For blocks smaller than > > > /16, ARIN can > > > > maintain IN-ADDRs through the use of the SWIP template for > > > reassignments > > > > of /24 and shorter prefixes." > > > > > > > > > > > > The policy does not require in-addr service. What it means > > > is that if > > > > in-addr service is desired then the responsibility for > > > allocations of > > > > /16 or shorter prefixes is that of the ISP receiving the > > > allocation. If > > > > the prefix is longer than a /16 and shorter than a /24, > > > then ARIN will > > > > provide the service if desired. > > > > > > > > Ray > > > > > > > > > > > #------------------------------------------------------------- > > > --------- > > > > # To unsubscribe, send a message to . > > > > > > > > > > > > > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 11:37:21 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16758 for ; Wed, 2 Apr 2003 11:37:21 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32GDBRN005591 for ; Wed, 2 Apr 2003 18:13:11 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h32GDBJU005590 for dnsop-outgoing; Wed, 2 Apr 2003 18:13:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32GD7RN005582 for ; Wed, 2 Apr 2003 18:13:10 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id LAA19654 for ; Wed, 2 Apr 2003 11:09:32 -0500 Date: Wed, 2 Apr 2003 11:11:40 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: dnsop@cafax.se Subject: A historical perspective on draft-ietf-dnsop-inaddr-required-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk Here is a message from Rob Austein to the TCP-IP mailing list from 1986, which puts a historical perspective on things. Rob is responding to a message from gds@spam.istc.sri.com. Given this was in 1986, the spam.itsc.sri.com hostname was well ahead of its time. Rob knew then that "the silly net" wouldn't have reverse working all the time, but thought this was broken. Apparently, he was under the impression then that reverse was not optional, but could be "broken". More significantly (in retrospect), Rob advocates that one shouldn't put numeric addresses in Received headers. Of course, Rob wasn't the only person with this viewpoint. It is unfair to place this solely on Rob's shoulders. Although not clear from this message, he is accompanied in this viewpoint by many then, and who still share this view today. To the later chagrin of so many people, Rob's viewpoint was implemented in Sendmail. It is unfortunate because we later learned by hard experience that if one used a machine without Reverse, or if reverse were configured to return misleading results, then one could send completely anonymous and untraceable email through a mail relay. It had nothing to do with the openness of the relay, though that was the early "fix". Of course, even "closed" relays could be abused, and it would be impossible to identify the user of the relay. The anonymous spam relay exploit was the result of misplaced trust placed in reverse, and the fact that an IP address wasn't put in the Received: header. It had nothing to do with the openness of the relay. Some say this ability to anonymously abuse relays caused spam. Eventually, this behavior was changed in Sendmail and other MTA's in the early '90s. Since then, it has been impossible to send anonymous email through an open or closed relay. This fact has not stopped people from promoting myths about open relays, however. It is really historically interesting that 17 years later, after so many obvious faults, failures, exploits, and even spam caused by misplaced trust in reverse DNS, that the same people are still promoting the same ideas. It is a historical irony that some of the most vocal and ardent proponents of Reverse DNS want to use it to prevent spam. --Dean Message from Rob Austein (SRA@XX.LCS.MIT.EDU) Wed, 1 Oct 1986 16:00 EDT ============== Date: Tuesday, 30 September 1986 13:29-EDT From: The lost Bostonian To: header-people@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa If it is true that all IP implementations enable a server program to determine the IP address of its peer, then the HELO command, and its response could be eliminated, which would save us a few bytes. You are assuming that it is always possible to translate addresses to names and vice versa. Unfortunately, there are some people out in the world running domain nameservers who are totally clueless about what they are doing, and there are others who have the misfortune to be stuck behind a losing gateway or otherwise be unreachable much of the time. Do you really want to make it impossible to receive mail from some host because a third party is broken? Or have to put numeric addresses into the Recieved headers? The answer is to fix the silly net, not throw away features to save two IP packets. --Rob ==================== #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 17:56:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13741 for ; Wed, 2 Apr 2003 17:56:38 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32MWFRN010864 for ; Thu, 3 Apr 2003 00:32:15 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32MWF6E010863 for dnsop-outgoing; Thu, 3 Apr 2003 00:32:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32MWDRN010858 for ; Thu, 3 Apr 2003 00:32:14 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5111218E1 for ; Wed, 2 Apr 2003 17:32:12 -0500 (EST) Date: Wed, 02 Apr 2003 17:32:12 -0500 From: Rob Austein To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <200303311144.GAA02561@ietf.org> References: <200303311144.GAA02561@ietf.org> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=X-UNKNOWN Message-Id: <20030402223212.5111218E1@thrintun.hactrn.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h32MWERN010859 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit So far we've heard from: - Ray, who pointed out some RIR-related (specifically, ARIN-related) text that needs some work; - Måns, who liked the draft and suggested adding text discussing IPv6; - Dean, who says that we should not be working on this draft. Does anybody -else- have comments on this draft? In particular: does anybody who has not yet spoken on this have an opinion on whether the WG should be working on this? Note to anyone who has not figured this out yet: the title of the draft is old, does not match the content of the draft as it evolved, and most likely would be changed before publication to match the current content of the draft. Please READ THE DRAFT rather than jumping to conclusions about what it says based on the title. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 18:20:10 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15271 for ; Wed, 2 Apr 2003 18:20:08 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32MttRN011165 for ; Thu, 3 Apr 2003 00:55:55 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32MtsK3011164 for dnsop-outgoing; Thu, 3 Apr 2003 00:55:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32MtrRN011157 for ; Thu, 3 Apr 2003 00:55:53 +0200 (MEST) Received: from ano2 ([192.136.136.117]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA13346; Wed, 2 Apr 2003 17:55:52 -0500 (EST) From: "Ray Plzak" To: "'Rob Austein'" , Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Date: Wed, 2 Apr 2003 17:55:49 -0500 Message-ID: <001401c2f96b$01b15150$758888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <20030402223212.5111218E1@thrintun.hactrn.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h32MtsRN011160 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit If the purpose of this draft is to propose policy, then it should not be an item for the WG, but should be put into the RIR policy process. If the purpose of the draft is to define real technical reasons why in-addr are required then the work should proceed and be judged on that merit. Ray > -----Original Message----- > From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se] On > Behalf Of Rob Austein > Sent: Wednesday, April 02, 2003 5:32 PM > To: dnsop@cafax.se > Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > So far we've heard from: > > - Ray, who pointed out some RIR-related (specifically, ARIN-related) > text that needs some work; > > - Måns, who liked the draft and suggested adding text discussing IPv6; > > - Dean, who says that we should not be working on this draft. > > Does anybody -else- have comments on this draft? In particular: does > anybody who has not yet spoken on this have an opinion on whether the > WG should be working on this? > > Note to anyone who has not figured this out yet: the title of the > draft is old, does not match the content of the draft as it evolved, > and most likely would be changed before publication to match the > current content of the draft. Please READ THE DRAFT rather than > jumping to conclusions about what it says based on the title. > > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 18:58:04 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17614 for ; Wed, 2 Apr 2003 18:58:03 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32NaXRN011804 for ; Thu, 3 Apr 2003 01:36:33 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h32NaXCZ011799 for dnsop-outgoing; Thu, 3 Apr 2003 01:36:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32NaVRN011781 for ; Thu, 3 Apr 2003 01:36:31 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.12) id 190rmM-0004eY-00; Wed, 02 Apr 2003 15:36:26 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Apr 2003 15:36:25 -0800 To: Ray Plzak Cc: dnsop@cafax.se Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt References: <20030402223212.5111218E1@thrintun.hactrn.net> <001401c2f96b$01b15150$758888c0@arin.net> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > If the purpose of this draft is to propose policy, then it should not be > an item for the WG, but should be put into the RIR policy process. the document seems to suggest policy for both isps and for rirs. do the rirs see themselves as the venue to set *isps'* policies? maybe we can learn to share the blame . randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 19:02:00 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18040 for ; Wed, 2 Apr 2003 19:01:59 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32NhcRN011943 for ; Thu, 3 Apr 2003 01:43:38 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h32Nhce9011942 for dnsop-outgoing; Thu, 3 Apr 2003 01:43:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32NhbRN011937 for ; Thu, 3 Apr 2003 01:43:37 +0200 (MEST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.7/8.11.7) with ESMTP id h32NhZo03913 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 2 Apr 2003 18:43:36 -0500 Message-Id: <5.2.0.9.2.20030402183738.01bbe988@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 02 Apr 2003 18:43:07 -0500 To: From: Daniel Senie Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <001401c2f96b$01b15150$758888c0@arin.net> References: <20030402223212.5111218E1@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h32NhbRN011938 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit At 05:55 PM 4/2/2003, Ray Plzak wrote: >If the purpose of this draft is to propose policy, then it should not be >an item for the WG, but should be put into the RIR policy process. That is not the purpose. I would be happy to separately work with the RIRs on policy proposals. > If >the purpose of the draft is to define real technical reasons why in-addr >are required then the work should proceed and be judged on that merit. It is the purpose of this draft to define the reasons to promote the use of INADDR, and to also discourage usage that can be harmful and which provides false security (please note that most or all of the text regarding NOT using INADDR came from contributions from the DNSOP WG at or shortly after the Pittsburgh IETF, and were not in the original document). As Rob mentioned the tone and direction of this document has changed from the original I-D which I wrote some years back. The changes were largely brought about by input from the WG in the past. Echoing Rob, I encourage folks to read beyond the title line and evaluate the content. I am planning to replace "Require" with "Encourage" in the title of the document in the next revision, though the file naming will likely continue to have the word "required" in it. > > -----Original Message----- > > From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se] On > > Behalf Of Rob Austein > > Sent: Wednesday, April 02, 2003 5:32 PM > > To: dnsop@cafax.se > > Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > > > > So far we've heard from: > > > > - Ray, who pointed out some RIR-related (specifically, ARIN-related) > > text that needs some work; > > > > - Måns, who liked the draft and suggested adding text discussing IPv6; > > > > - Dean, who says that we should not be working on this draft. > > > > Does anybody -else- have comments on this draft? In particular: does > > anybody who has not yet spoken on this have an opinion on whether the > > WG should be working on this? > > > > Note to anyone who has not figured this out yet: the title of the > > draft is old, does not match the content of the draft as it evolved, > > and most likely would be changed before publication to match the > > current content of the draft. Please READ THE DRAFT rather than > > jumping to conclusions about what it says based on the title. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 19:26:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18654 for ; Wed, 2 Apr 2003 19:26:38 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33083RN012281 for ; Thu, 3 Apr 2003 02:08:03 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h33083Tc012280 for dnsop-outgoing; Thu, 3 Apr 2003 02:08:03 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33081RN012275 for ; Thu, 3 Apr 2003 02:08:02 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA08297; Wed, 2 Apr 2003 18:57:58 -0500 Date: Wed, 2 Apr 2003 19:00:07 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Rob Austein cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030402223212.5111218E1@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.cafax.se id h33082RN012276 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit I have specific comments: According to RFC 2026, "Best Current Practices" are meant to express community consensus on operational aspects. This draft modifies RFC 1034, and RFC 1035, and it changes the requirements for nameserver software. Also, a Best Current Practice RFC shouldn't affect how software applications are written, only how they are operated. Therefore this draft isn't suitable for the abbreviated BCP process. Section 1 Paragraph 1 This section is clearly wrong. It says "This practice, while documented, has never been documented as a requirement placed upon those who control address blocks". This is false. It suggests an omission, where there is no omission. It has been documented as being optional in various RFCs and in the policies of address registries. Section 2 Should either be amended to remove specific reference to ARIN, or be complete with respect to all registries. Section 3 This entire section should be deleted: It is flatly incorrect in some places: "To ensure validity of claimed names, some applications will look up IN-ADDR records..." and goes on to describe the forward-reverse-foward procedure. One cannot ensure validity of names through this procedure, and so this is a false premise. RFC's should not promote clearly false claims. There rest of this section just documents examples where this false premise has been used. That some persons accept these false premises does not make the premise true. These practices are not followed by the vast majority of servers of any type, nor by the vast majority of operators of servers, though there are isolated contrary examples. Section 4 The first paragraph is good. (Basically, this paragraph just repeats my criticism of section 3.) However, including such statements does not negate or remove the false premises that are contained elsewhere in the document. The second paragraph is erroneous. There are valid reasons where it is appropriate or convenient for PTR records which are not the canonical name. For example, this contradicts RFC 2317, which puts CNAMES in PTR records. The third paragraph should be deleted. It violates the security policies of many organizations to identify the broadcast addresses of their networks. Such addresses could be identifed by the lack of IN-ADDR. Further, many organizations find it completely unacceptable that anyone should be auditing its compliance with this RFC, or attempting to determine its internal structure. Such activity is a violation of federal criminal statutes, and should not be encouraged by the IETF. As was already pointed out, paragraph 4 should be removed. Each registry has its own policy process. Paragraph 5 should be removed, as it contradicts common practice at many ISPs which implement automated reverse/forward trees of the form generally like 'h----.somedomain', where the trees are not actually stored, but are simply made up on the fly in response to queries. This places limitations on nameserver implementations, and modifies RFC 1035. Section 5 Encouraging the use of IN-ADDR has demonstrably negative effects on security. Several examples have been given where root and user access has been granted, untraceable email has been granted, and logs have been made useless. On Wed, 2 Apr 2003, Rob Austein wrote: > So far we've heard from: > > - Ray, who pointed out some RIR-related (specifically, ARIN-related) > text that needs some work; > > - Måns, who liked the draft and suggested adding text discussing IPv6; > > - Dean, who says that we should not be working on this draft. > > Does anybody -else- have comments on this draft? In particular: does > anybody who has not yet spoken on this have an opinion on whether the > WG should be working on this? > > Note to anyone who has not figured this out yet: the title of the > draft is old, does not match the content of the draft as it evolved, > and most likely would be changed before publication to match the > current content of the draft. Please READ THE DRAFT rather than > jumping to conclusions about what it says based on the title. > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 21:20:43 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21428 for ; Wed, 2 Apr 2003 21:20:41 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h331qhRN014303 for ; Thu, 3 Apr 2003 03:52:43 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h331qh4b014302 for dnsop-outgoing; Thu, 3 Apr 2003 03:52:43 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h331qfRN014297 for ; Thu, 3 Apr 2003 03:52:42 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h331qSo1055847; Wed, 2 Apr 2003 20:52:39 -0500 (EST) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <20030402223212.5111218E1@thrintun.hactrn.net> References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> Date: Thu, 3 Apr 2003 03:52:43 +0200 To: Rob Austein From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 5:32 PM -0500 2003/04/02, Rob Austein wrote: > Does anybody -else- have comments on this draft? In particular: does > anybody who has not yet spoken on this have an opinion on whether the > WG should be working on this? I can make some comments on the draft regarding what I believe to be typos and incorrect grammar. Is that what you're looking for, or do you want more substantive discussion? > Note to anyone who has not figured this out yet: the title of the > draft is old, does not match the content of the draft as it evolved, > and most likely would be changed before publication to match the > current content of the draft. Please READ THE DRAFT rather than > jumping to conclusions about what it says based on the title. Well, I would have thought that my views on this subject were pretty well known. I guess my question has to be -- what is the real purpose of this draft? Is the purpose to identify the current actual policies (once corrected) of the RIRs and mention the issues that have been raised here, perhaps to bring them to a wider audience? If so, then I think this draft is definitely something we should be working on, but we should make an effort to pull out some of the more emotionally charged language that has been used in the past, and to make it relatively neutral and simply state the facts. We then collect the feedback, and see if we can get some consensus that would allow us to lay out a BCP. If the purpose is to propose policy changes, then I'm not sure that this is the right group to handle this topic. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 22:33:11 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23073 for ; Wed, 2 Apr 2003 22:33:10 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h333BYRN015078 for ; Thu, 3 Apr 2003 05:11:34 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h333BYPW015077 for dnsop-outgoing; Thu, 3 Apr 2003 05:11:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h333BXRN015072 for ; Thu, 3 Apr 2003 05:11:33 +0200 (MEST) Received: from ano2 ([192.136.136.119]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA06647 for ; Wed, 2 Apr 2003 22:11:25 -0500 (EST) From: "Ray Plzak" To: Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Date: Wed, 2 Apr 2003 22:11:23 -0500 Message-ID: <000d01c2f98e$b8ef54c0$778888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Policies are applied to the ISPs to whom the address space is allocated or assigned by the RIR. If an upstream further assigns to a downstream, they generally apply the policy of the RIR to that space as in the end it will affect the relationship of the upstream to the RIR when requesting additional space. An example would be the reporting of utilization. In some cases there are policies that affect operations, such as those pertaining to multihoming which are also generally passed down by the upstream. On the other hand there is no policy in regards to setting filters with regard to the space allocated as this is the purview of the operator as it is independent of the amount of space that has been allocated by an RIR to an ISP and pertains to routing which is not the purview of the RIR. Hope this helps. Ray > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, April 02, 2003 6:36 PM > To: Ray Plzak > Cc: dnsop@cafax.se > Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > > If the purpose of this draft is to propose policy, then it > should not be > > an item for the WG, but should be put into the RIR policy process. > > the document seems to suggest policy for both isps and for > rirs. do the > rirs see themselves as the venue to set *isps'* policies? > maybe we can > learn to share the blame . > > randy > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 2 22:34:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23105 for ; Wed, 2 Apr 2003 22:34:24 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h333ETRN015117 for ; Thu, 3 Apr 2003 05:14:29 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h333ETeW015116 for dnsop-outgoing; Thu, 3 Apr 2003 05:14:29 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h333ENRN015111 for ; Thu, 3 Apr 2003 05:14:23 +0200 (MEST) Received: from ano2 ([192.136.136.119]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA06720 for ; Wed, 2 Apr 2003 22:14:21 -0500 (EST) From: "Ray Plzak" To: Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Date: Wed, 2 Apr 2003 22:14:20 -0500 Message-ID: <000e01c2f98f$1f201130$778888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.2.0.9.2.20030402183738.01bbe988@mail.amaranth.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h333ESRN015112 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Daniel, The ARIN Advisory Council and the ARIN staff will be glad to work with you to facilitate your activity in the policy process. Please contact me off list if you wish to pursue a policy proposal. Ray > -----Original Message----- > From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se] On > Behalf Of Daniel Senie > Sent: Wednesday, April 02, 2003 6:43 PM > To: dnsop@cafax.se > Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > At 05:55 PM 4/2/2003, Ray Plzak wrote: > >If the purpose of this draft is to propose policy, then it > should not be > >an item for the WG, but should be put into the RIR policy process. > > That is not the purpose. I would be happy to separately work > with the RIRs > on policy proposals. > > > If > >the purpose of the draft is to define real technical reasons > why in-addr > >are required then the work should proceed and be judged on > that merit. > > It is the purpose of this draft to define the reasons to > promote the use of > INADDR, and to also discourage usage that can be harmful and > which provides > false security (please note that most or all of the text > regarding NOT > using INADDR came from contributions from the DNSOP WG at or > shortly after > the Pittsburgh IETF, and were not in the original document). > > As Rob mentioned the tone and direction of this document has > changed from > the original I-D which I wrote some years back. The changes > were largely > brought about by input from the WG in the past. Echoing Rob, > I encourage > folks to read beyond the title line and evaluate the content. > I am planning > to replace "Require" with "Encourage" in the title of the > document in the > next revision, though the file naming will likely continue to > have the word > "required" in it. > > > > > -----Original Message----- > > > From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se] On > > > Behalf Of Rob Austein > > > Sent: Wednesday, April 02, 2003 5:32 PM > > > To: dnsop@cafax.se > > > Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt > > > > > > > > > So far we've heard from: > > > > > > - Ray, who pointed out some RIR-related (specifically, > ARIN-related) > > > text that needs some work; > > > > > > - Måns, who liked the draft and suggested adding text > discussing IPv6; > > > > > > - Dean, who says that we should not be working on this draft. > > > > > > Does anybody -else- have comments on this draft? In > particular: does > > > anybody who has not yet spoken on this have an opinion on > whether the > > > WG should be working on this? > > > > > > Note to anyone who has not figured this out yet: the title of the > > > draft is old, does not match the content of the draft as > it evolved, > > > and most likely would be changed before publication to match the > > > current content of the draft. Please READ THE DRAFT rather than > > > jumping to conclusions about what it says based on the title. > > > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 03:05:16 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09694 for ; Thu, 3 Apr 2003 03:05:15 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h337jfRN017329 for ; Thu, 3 Apr 2003 09:45:41 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h337jfXF017328 for dnsop-outgoing; Thu, 3 Apr 2003 09:45:41 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from momotombo.TechFak.Uni-Bielefeld.DE (momotombo.TechFak.Uni-Bielefeld.DE [129.70.136.107]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h337jeRN017323 for ; Thu, 3 Apr 2003 09:45:40 +0200 (MEST) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id h337je509191 for ; Thu, 3 Apr 2003 09:45:40 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id h337jdO08280 for ; Thu, 3 Apr 2003 09:45:39 +0200 (MEST) Message-Id: <200304030745.h337jdO08280@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-reply-to: Your message of "Wed, 02 Apr 2003 17:32:12 CDT." <20030402223212.5111218E1@thrintun.hactrn.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Thu, 03 Apr 2003 09:45:39 +0200 From: Peter Koch Sender: owner-dnsop@cafax.se Precedence: bulk > Does anybody -else- have comments on this draft? In particular: does > anybody who has not yet spoken on this have an opinion on whether the > WG should be working on this? With the promised changes in wording and trying to avoid the ``policy'' debate I am in favor of re-opening this issue and again accept this draft as a work item for the WG. Despite its potential abuses (we don't ban http, do we?) I believe reverse mapping is a valuable resource. In addition, since we're unlikely to succeed in changing the installed base, the factors DNS server load and latency, as mentioned in the draft, suggest to "do something" about it. Anyone operating a nameserver covering a larger amount of /16s down to the leaves should have a look at their query statistics. Reverse mapping for IPv6 should be dealt with in a seperate document. -Peter #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 08:47:22 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19667 for ; Thu, 3 Apr 2003 08:47:22 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33DOsRN020299 for ; Thu, 3 Apr 2003 15:24:54 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33DOsQp020298 for dnsop-outgoing; Thu, 3 Apr 2003 15:24:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h33DOsRN020293 for ; Thu, 3 Apr 2003 15:24:54 +0200 (MEST) Received: (qmail 52155 invoked by uid 1013); 3 Apr 2003 13:24:53 -0000 Date: Thu, 3 Apr 2003 15:24:53 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030403152453.C48824@Space.Net> References: <20030402223212.5111218E1@thrintun.hactrn.net> <200304030745.h337jdO08280@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200304030745.h337jdO08280@grimsvotn.TechFak.Uni-Bielefeld.DE>; from pk@TechFak.Uni-Bielefeld.DE on Thu, Apr 03, 2003 at 09:45:39AM +0200 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk On Thu, Apr 03, 2003 at 09:45:39AM +0200, Peter Koch wrote: > With the promised changes in wording and trying to avoid the ``policy'' > debate I am in favor of re-opening this issue and again accept this > draft as a work item for the WG. I second that. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 08:47:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19668 for ; Thu, 3 Apr 2003 08:47:22 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33DLtRN020272 for ; Thu, 3 Apr 2003 15:21:55 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h33DLtOv020271 for dnsop-outgoing; Thu, 3 Apr 2003 15:21:55 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h33DLsRN020266 for ; Thu, 3 Apr 2003 15:21:55 +0200 (MEST) Received: (qmail 52054 invoked by uid 1013); 3 Apr 2003 13:21:54 -0000 Date: Thu, 3 Apr 2003 15:21:54 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: RR DNS and spam Message-ID: <20030403152154.B48824@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk Over in the IRTF ASRG group I made a proposal to get rid of all the spam that comes via abused (proxies etc.) workstations. My idea was to "mark" hosts in RR DNS zones als being a mailserver by (e.g.) adding a TXT record like 8.0.30.195.in-addr.arpa IN PTR mail.space.net. IN TXT "mailto:abuse@space.net" That way the maintainers of the RR zone could authorize IPs to be valid mailservers and receiving mailservers would only accept mails from sending IPs that have the RR TXT record. It would be easily implemented, existing DNSBL code could be used by using "in-addr.arpa" as a base and inverting the meaning of "there is a TXT record". A non existant TXT record in RR DNS could be "overridden" by - a proper authentification (e.g. SMTP AUTH) so roaming users would bot be locked out. - local configuration that lets smarthosts accept emails from "well known" hosts without making that hosts sending mailservers to the public. The TXT record could carry a contact address (mailto, http) for abuse. And now my question to this audience :-) With all the recent discussions about the in-addr.arpa zone and reverse IPv6 resolution, would such a proposal be accepted by the DNS operators? Would they be willing to "change mind" and take more care of reverse zones? \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 13:02:08 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04504 for ; Thu, 3 Apr 2003 13:02:06 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33HYeRN023452 for ; Thu, 3 Apr 2003 19:34:40 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33HYe1u023451 for dnsop-outgoing; Thu, 3 Apr 2003 19:34:40 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33HYcRN023446 for ; Thu, 3 Apr 2003 19:34:39 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h33HUYY29587; Thu, 3 Apr 2003 20:30:35 +0300 Date: Thu, 3 Apr 2003 20:30:34 +0300 (EEST) From: Pekka Savola To: Rob Austein cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030402223212.5111218E1@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8BIT On Wed, 2 Apr 2003, Rob Austein wrote: > So far we've heard from: > > - Ray, who pointed out some RIR-related (specifically, ARIN-related) > text that needs some work; > > - Måns, who liked the draft and suggested adding text discussing IPv6; > > - Dean, who says that we should not be working on this draft. > > Does anybody -else- have comments on this draft? In particular: does > anybody who has not yet spoken on this have an opinion on whether the > WG should be working on this? Yes, I believe this is quite useful. I also belive in-addr are useful, even though sometimes used improperly. The delegation chain should be provided alongside with address allocations [this may fall upon the RIR policies]. Whether the endsites fill those is their policy, and this draft should try to list the tradeoffs for such decisions. > Note to anyone who has not figured this out yet: the title of the > draft is old, does not match the content of the draft as it evolved, > and most likely would be changed before publication to match the > current content of the draft. Please READ THE DRAFT rather than > jumping to conclusions about what it says based on the title. There are some remnants still, e.g. in the introduction, btw. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 13:16:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05170 for ; Thu, 3 Apr 2003 13:16:53 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33HwRRN023750 for ; Thu, 3 Apr 2003 19:58:28 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33HwRId023749 for dnsop-outgoing; Thu, 3 Apr 2003 19:58:27 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33HwQRN023744 for ; Thu, 3 Apr 2003 19:58:26 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA24058; Thu, 3 Apr 2003 12:54:05 -0500 Date: Thu, 3 Apr 2003 12:56:15 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Daniel Senie cc: dnsop@cafax.se Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <5.2.0.9.2.20030402183738.01bbe988@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Wed, 2 Apr 2003, Daniel Senie wrote: > It is the purpose of this draft to define the reasons to promote the use of > INADDR, and to also discourage usage that can be harmful and which provides > false security (please note that most or all of the text regarding NOT > using INADDR came from contributions from the DNSOP WG at or shortly after > the Pittsburgh IETF, and were not in the original document). Then it should include a statement to the effect of: ------------ IN-ADDR should not be used for any logging, auditing, identification, authentication, or authorization purpose. Its sole purpose is for the convenience of such applications as traceroute. Application developers should be aware that IN-ADDR may not be available in IPV6, and IPV6 applications should be prepared to use ICMP node identification or other alternatives. ------------ #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 13:18:43 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05294 for ; Thu, 3 Apr 2003 13:18:43 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33HrKRN023661 for ; Thu, 3 Apr 2003 19:53:20 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33HrK6R023660 for dnsop-outgoing; Thu, 3 Apr 2003 19:53:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33HrIRN023655 for ; Thu, 3 Apr 2003 19:53:18 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA11591; Thu, 3 Apr 2003 12:45:16 -0500 Date: Thu, 3 Apr 2003 12:47:26 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Markus Stumpf cc: dnsop@cafax.se Subject: Re: RR DNS and spam In-Reply-To: <20030403152154.B48824@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk There have been several proposals along this line (notably, DNS Whitelists). These have tended to fail for the same reasons as blacklists: Administrative variation, revenge use, and other reasons. Some people will undoubtably pick it up. Not everyone will. So it won't be much use. Further, spammers are authorized to use their ISP's mail relays. Most spam comes directly. KLEZ virus infections, which are responsible for increasing amounts of spam, use the infected users mail relay. Spam is a problem of authorized, but inappropriate behavior. People keep trying to find ways to identify spam using an authorization process. All spammers are authorized users of some ISP. They remain authorized users until their ISP cancels their account. There is no way for outsiders to obtain control over who is authorized by another ISP. Any such controls are themselves subject to abuse. --Dean On Thu, 3 Apr 2003, Markus Stumpf wrote: > Over in the IRTF ASRG group I made a proposal to get rid of all the > spam that comes via abused (proxies etc.) workstations. > > My idea was to "mark" hosts in RR DNS zones als being a mailserver by > (e.g.) adding a TXT record like > > 8.0.30.195.in-addr.arpa IN PTR mail.space.net. > IN TXT "mailto:abuse@space.net" > > That way the maintainers of the RR zone could authorize IPs to be valid > mailservers and receiving mailservers would only accept mails from > sending IPs that have the RR TXT record. > It would be easily implemented, existing DNSBL code could be used by using > "in-addr.arpa" as a base and inverting the meaning of "there is a TXT > record". > A non existant TXT record in RR DNS could be "overridden" by > - a proper authentification (e.g. SMTP AUTH) so roaming users would bot > be locked out. > - local configuration that lets smarthosts accept emails from "well > known" hosts without making that hosts sending mailservers to the public. > The TXT record could carry a contact address (mailto, http) for abuse. > > And now my question to this audience :-) > With all the recent discussions about the in-addr.arpa zone and reverse > IPv6 resolution, would such a proposal be accepted by the DNS operators? > Would they be willing to "change mind" and take more care of reverse zones? > > \Maex > > -- > SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 > Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 > "The security, stability and reliability of a computer system is reciprocally > proportional to the amount of vacuity between the ears of the admin" > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 14:15:10 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07638 for ; Thu, 3 Apr 2003 14:15:09 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33IoVRN024426 for ; Thu, 3 Apr 2003 20:50:31 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33IoUpJ024425 for dnsop-outgoing; Thu, 3 Apr 2003 20:50:30 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h33IoTRN024420 for ; Thu, 3 Apr 2003 20:50:29 +0200 (MEST) Received: (qmail 80572 invoked by uid 1013); 3 Apr 2003 18:50:29 -0000 Date: Thu, 3 Apr 2003 20:50:29 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: Re: RR DNS and spam Message-ID: <20030403205029.K48824@Space.Net> References: <20030403152154.B48824@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dean@av8.com on Thu, Apr 03, 2003 at 12:47:26PM -0500 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk On Thu, Apr 03, 2003 at 12:47:26PM -0500, Dean Anderson wrote: > Some people will undoubtably pick it up. That was my question: with all the "we don't want to manage RR zones" how many will pick it up, which would cause them to do at least some administration of the RR zones. > Not everyone will. So it won't be much use. That depends on how many "not everyone" is. If 80% percent use it and you can send mail only to 20% of the Internet if you don't use it, the 20% will change rather fast. It's called group pressure. > Further, spammers are authorized to use their ISP's mail > relays. Most spam comes directly. KLEZ virus infections, which are > responsible for increasing amounts of spam, use the infected users mail > relay. Maybe my English is way too bad ... but what is so hard to understand in the wording "I want to get rid of all those millions of hosts that nobody (even not the owner) wants to be a publicly acting mailserver, but which are abused as mailservers because of e.g. bad maintenance or virus infection or cracking". I don't care about spam from official ISP smarthosts NOW, neither do I care NOW about spam from hosts having that TXT record set. These admins will be lart'd later. I want a way to express "this IP SHOULD act as a mailserver sending to the public" or "this IP SHOULD NOT act as a mailserver sending to the public". Does anyone responsible for unknown:61.254.148.198 HELO compuserve.com unknown:61.254.148.198 rejected: to badhelohost want 61.254.148.198 to act as a mailserver sending to the public? Or how about pcp042221pcs.unl.edu:129.93.209.153 rbl-allowed: <19hsbJack74620mndjoew@nycmail.com> to pcp042221pcs.unl.edu:129.93.209.153 rbl-allowed: <19hsbJack74620mndjoew@nycmail.com> to dhcp024-209-033-173.neo.rr.com:24.209.33.173 HELO earthling.net dhcp024-209-033-173.neo.rr.com:24.209.33.173 rejected: to mail.harborside.com:12.45.56.18 rejected: to badrcptto I don't know. But with a mechanism like a TXT record for 198.148.254.61.in-addr.arpa. 153.209.93.129.in-addr.arpa. 173.33.209.23.in-addr.arpa. 18.56.45.12.in-addr.arpa. identifying that host as "is chosen to be a mailserver" we would know. And I really would like it if spammers have to change and can't abuse "taken" hosts in the wild any longer and have to use their ISPs mailserver, because they have to go through a bottle neck and if the ISP doesn't take approriate actions it's easy to put a cork in the neck and that's it. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 14:51:09 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08977 for ; Thu, 3 Apr 2003 14:51:07 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33JSERN024891 for ; Thu, 3 Apr 2003 21:28:14 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33JSEJS024890 for dnsop-outgoing; Thu, 3 Apr 2003 21:28:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h33JSDRN024885 for ; Thu, 3 Apr 2003 21:28:13 +0200 (MEST) Received: (qmail 83091 invoked by uid 1013); 3 Apr 2003 19:28:13 -0000 Date: Thu, 3 Apr 2003 21:28:13 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030403212813.M48824@Space.Net> References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030402223212.5111218E1@thrintun.hactrn.net>; from sra+dnsop@hactrn.net on Wed, Apr 02, 2003 at 05:32:12PM -0500 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk On Wed, Apr 02, 2003 at 05:32:12PM -0500, Rob Austein wrote: > Does anybody -else- have comments on this draft? In particular: does > anybody who has not yet spoken on this have an opinion on whether the > WG should be working on this? What I am missing is some kind of requirement of usefulness of the IN-ADDR data. We have Internet providers and other users to whom a block of addresses are delegated SHOULD provide for lookup of host names from IP addresses. Do PTR records within the following list qualify for the above statement, i.e. do they qualify as "host names"? (I picked those examples from a scrolling maillog file, so the listed hosts are picked at random and not for the purpose to offend anyone) unknown.level3.net 64.157.143.50 67.106.228.14.ptr.us.xo.net 67.106.228.14 200-170-198-6.core01.spo.ifx.net.br 200.170.198.6 0x50a2eb04.unknown.tele.dk 80.162.235.4 If these are considered to be valid "host names" it would IMHO be nice if the, obviously generated, names mapping the IP address would also carry some CIDR information. A naming scheme like in RFC 2317 could be used: Suppose you have two /25 for two different customers (no delegation) 10.0.1.0/25 10.0.1.128/25 then the scheme could be (as with the above used hosts) 10.0.1.0/25.0.rev.example.net. 10.0.1.0/25.1.rev.example.net. 10.0.1.0/25.2.rev.example.net. [ ... ] 10.0.1.0/25.127.rev.example.net. 10.0.1.128/25.128.rev.example.net. 10.0.1.128/25.129.rev.example.net. [ ... ] 10.0.1.128/25.255.rev.example.net. This would help especially in cases where no assignment information beyond /16 is available from the RIR databases to block out abusive hosts/nets without risking collateral damage. IMHO recommending this would be nice, but maybe this is beyond the objective of that draft. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 15:12:27 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10756 for ; Thu, 3 Apr 2003 15:12:25 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33JmFRN025195 for ; Thu, 3 Apr 2003 21:48:15 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33JmF1i025194 for dnsop-outgoing; Thu, 3 Apr 2003 21:48:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33JmDRN025189 for ; Thu, 3 Apr 2003 21:48:14 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id OAA17308; Thu, 3 Apr 2003 14:41:27 -0500 Date: Thu, 3 Apr 2003 14:43:27 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Markus Stumpf cc: dnsop@cafax.se Subject: Re: RR DNS and spam In-Reply-To: <20030403205029.K48824@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Thu, 3 Apr 2003, Markus Stumpf wrote: > That depends on how many "not everyone" is. If 80% percent use it > and you can send mail only to 20% of the Internet if you don't use > it, the 20% will change rather fast. It's called group pressure. "group pressure" will alter the spammers, too. The rest of the "group" gets tired of jumping through stupid hoops that are provably, and theoretically pointless from the start. Your assumption is that spam can only come from not-real-mailservers. This is a false assumption. Even so, much real mail also comes from such "not-real-mailservers". SMTP is a client-server protocol, not a server-server protocol. Your proposal is just a way to use DNS to make SMTP server-server. > Maybe my English is way too bad ... but what is so hard to understand > in the wording "I want to get rid of all those millions of hosts that > nobody (even not the owner) wants to be a publicly acting mailserver, > but which are abused as mailservers because of e.g. bad maintenance > or virus infection or cracking". Your English was fine. The problem is your assumptions about SMTP make this a useless goal. > I don't care about spam from official ISP smarthosts NOW, neither do I > care NOW about spam from hosts having that TXT record set. These admins > will be lart'd later. The LART may go the other way. I'm sure Rob Austein didn't expect to be LARTed for advocating not putting numeric IP addresses in Recieved: headers. Of course, he's tried to deflect the LART by saying there wasn't anything wrong with IN-ADDR, but that one shouldn't use open relays. Obviously, history shows he was wrong. History eventually corrects such errors. Most of the anti-spammers trying to use DNS to block spam don't understand the SMTP protocol and in particular what entities put headers in email messages. On more than one occasion, seemingly technically experienced people have failed to understand that the spammer can't modify a header put in the message after they give it to a mail relay. > And I really would like it if spammers have to change and can't abuse > "taken" hosts in the wild any longer and have to use their ISPs > mailserver, because they have to go through a bottle neck and if the > ISP doesn't take approriate actions it's easy to put a cork in the neck > and that's it. Yes, it would be nice if spammers would just raise their hand and identify themselves. It would be nicer if spammers would just obey the rules. Of course, this is a naive expectation. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 20:08:18 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21815 for ; Thu, 3 Apr 2003 20:08:17 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h340fERN028363 for ; Fri, 4 Apr 2003 02:41:14 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h340fELR028362 for dnsop-outgoing; Fri, 4 Apr 2003 02:41:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h340f0RN028354 for ; Fri, 4 Apr 2003 02:41:11 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h340eKoF053885; Thu, 3 Apr 2003 19:40:47 -0500 (EST) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Fri, 4 Apr 2003 01:33:10 +0200 To: Dean Anderson From: Brad Knowles Subject: Re: RR DNS and spam Cc: Markus Stumpf , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 2:43 PM -0500 2003/04/03, Dean Anderson wrote: > SMTP is a client-server protocol, not a > server-server protocol. Your proposal is just a way to use DNS to make > SMTP server-server. This is a demonstrably false statement. The updated RFCs for Internet e-mail explicitly state that SMTP is a server-to-server protocol. If you want client-to-server, this would be the Mail Server Protocol (MSP). Right now, MSP looks a hell of a lot like SMTP, but they will diverge in the future. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 21:16:10 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22913 for ; Thu, 3 Apr 2003 21:16:10 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h341nERN029709 for ; Fri, 4 Apr 2003 03:49:14 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h341nEJI029708 for dnsop-outgoing; Fri, 4 Apr 2003 03:49:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h341n3RN029703 for ; Fri, 4 Apr 2003 03:49:13 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h341m1nv057279; Thu, 3 Apr 2003 20:48:02 -0500 (EST) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Fri, 4 Apr 2003 03:48:25 +0200 To: Brad Knowles From: Brad Knowles Subject: Re: RR DNS and spam Cc: Dean Anderson , Markus Stumpf , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 1:33 AM +0200 2003/04/04, Brad Knowles wrote: > This is a demonstrably false statement. The updated RFCs for > Internet e-mail explicitly state that SMTP is a server-to-server > protocol. If you want client-to-server, this would be the Mail > Server Protocol (MSP). Right now, MSP looks a hell of a lot like > SMTP, but they will diverge in the future. Sorry, I meant Message Submission Protocol. My bad. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 3 23:59:05 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25585 for ; Thu, 3 Apr 2003 23:59:05 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h344aaRN001027 for ; Fri, 4 Apr 2003 06:36:36 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h344aa5l001026 for dnsop-outgoing; Fri, 4 Apr 2003 06:36:36 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h344aYRN001021 for ; Fri, 4 Apr 2003 06:36:34 +0200 (MEST) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fea7:b6e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 137F015210; Fri, 4 Apr 2003 13:37:00 +0900 (JST) Date: Fri, 04 Apr 2003 13:36:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Rob Austein Cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030402223212.5111218E1@thrintun.hactrn.net> References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 83 Sender: owner-dnsop@cafax.se Precedence: bulk >>>>> On Wed, 02 Apr 2003 17:32:12 -0500, >>>>> Rob Austein said: > So far we've heard from: > - Ray, who pointed out some RIR-related (specifically, ARIN-related) > text that needs some work; > - Mxxs, who liked the draft and suggested adding text discussing IPv6; ('xx' seemed to be non-ascii characters) > - Dean, who says that we should not be working on this draft. > Does anybody -else- have comments on this draft? In particular: does > anybody who has not yet spoken on this have an opinion on whether the > WG should be working on this? Though I've mentioned this draft in a separate thread, I think I can present my opinion since I'm not listed above. I believe the wg should work on this, and I basically support the intention of the draft. The draft, however, will need several clarifications. As already pointed out, the title (and the filename) does not reflect the content well and will thus need to be revised. Abstract and introduction may also need a revise from this point of view. Secondly, if I don't misunderstand the intention, the draft says two things: 1. we need to try to build correct reverse mapping as much as possible. 2. applications should not rely on reverse mapping for several purposes as they currently do. The discouraged purposes include: - rejecting ftp/telnet connections just due to the lack of reverse mapping or failure of reverse-forward-reverse match. - filtering rule in TCP wrappers due to the lack of reverse mapping - regarding e-mail messages as spam if the sender address does not have a reverse mapping I don't much care about bullet 1, but I think bullet 2 needs some clarification. First, I'd like to confirm if my understanding above is correct. The draft basically just says: Applications SHOULD NOT rely on IN-ADDR for proper operation. But it is not very clear what the "proper operation" means. I picked up the examples of the discouraged usage from Section 3 based on my understanding of the draft. If I read it correctly, however, then I'd wonder why people who seemed to want rely on such a usage (e.g. rejecting ftp connections) are supporting the draft. Also, I'm not sure if all the examples in Section 3 are discouraged based on the intention of the draft, which include: - (to try) logging the result of reverse lookup of a web client in a web server - reverse lookup in traceroute Finally, Section 4 needs to be clearer. The draft says The use of IN-ADDR, sometimes in conjunction with a lookup of the name resulting from the PTR record provides no real security, ... ^^^^^^^^^^^^^^^^ but, as already pointed out in this list, "security" is a broad term. I believe the draft should be clear on what kind of "security" it is talking about. In summary, I'd like the draft - to clarify the first paragraph of Section 4, and - to add a concrete list of discouraged usage in Section 4 JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 03:55:31 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11516 for ; Fri, 4 Apr 2003 03:55:30 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h348WCRN002603 for ; Fri, 4 Apr 2003 10:32:12 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h348WCTq002602 for dnsop-outgoing; Fri, 4 Apr 2003 10:32:12 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h348WARN002597 for ; Fri, 4 Apr 2003 10:32:11 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h348W7nv090540; Fri, 4 Apr 2003 03:32:08 -0500 (EST) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> Date: Fri, 4 Apr 2003 09:57:49 +0200 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: Rob Austein , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 1:36 PM +0900 2003/04/04, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >> - Mxxs, who liked the draft and suggested adding text discussing IPv6; > > ('xx' seemed to be non-ascii characters) I believe it was "Mans", where the "a" character had a circle above it. I'm not sure what this character is called. > First, I'd like to confirm if my understanding above is correct. The > draft basically just says: > > Applications SHOULD NOT rely on IN-ADDR for proper operation. Correct. > But it is not very clear what the "proper operation" means. "Proper operation" should also include any security-related functions. > I picked > up the examples of the discouraged usage from Section 3 based on my > understanding of the draft. If I read it correctly, however, then I'd > wonder why people who seemed to want rely on such a usage > (e.g. rejecting ftp connections) are supporting the draft. It's a matter of what is done by the programmer (assuming some sort of "proper operation" based on rDNS), versus what may be done by the administrator/operator (choosing to configure their machines in a particular way so as to require correct rDNS before they allow you to proceed). We want to discourage programmers from depending on something like this, while allowing owners/operators/administrators to choose to configure their machines in whatever way they feel is appropriate. This also means that software & OS vendors should not install their software in such a fashion that it depends on rDNS for "proper operation", as a default. Most users will simply take whatever default they are given, without understanding the underlying assumptions that might not be appropriate for their situation. So, if someone wants to configure their machine to require correct rDNS before they will allow you to proceed, they should be able to do that. However, they shouldn't be forced to do that by the programmers who wrote the software, nor should the software be configured so as to do that by default. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 06:46:57 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15993 for ; Fri, 4 Apr 2003 06:46:56 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34BHfRN003833 for ; Fri, 4 Apr 2003 13:17:41 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34BHfQl003832 for dnsop-outgoing; Fri, 4 Apr 2003 13:17:41 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from bardisk.pilsnet.sunet.se (bardisk.pilsnet.sunet.se [192.36.125.26]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34BHeRN003827 for ; Fri, 4 Apr 2003 13:17:40 +0200 (MEST) Received: from bardisk.pilsnet.sunet.se (localhost [127.0.0.1]) by bardisk.pilsnet.sunet.se (8.12.8/8.12.5) with ESMTP id h34BHUGh087374; Fri, 4 Apr 2003 13:17:32 +0200 (CEST) Received: (from mansaxel@localhost) by bardisk.pilsnet.sunet.se (8.12.8/8.12.3/Submit) id h34BHRWu087373; Fri, 4 Apr 2003 13:17:27 +0200 (CEST) Date: Fri, 4 Apr 2003 13:17:23 +0200 From: Mans Nilsson To: Markus Stumpf Cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030404111723.GB87120@sunet.se> References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> <20030403212813.M48824@Space.Net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline In-Reply-To: <20030403212813.M48824@Space.Net> User-Agent: Mutt/1.4.1i X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-synced-from: Pilsnet Sender: owner-dnsop@cafax.se Precedence: bulk --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Date: Thu, = Apr 03, 2003 at 09:28:13PM +0200 Quoting Markus Stumpf (maex-lists-dns-ietf= -dnsop@Space.Net): > What I am missing is some kind of requirement of usefulness of the > IN-ADDR data. We have > Internet providers and other users to whom a block of addresses are > delegated SHOULD provide for lookup of host names from IP addresses. >=20 > Do PTR records within the following list qualify for the above statement, > i.e. do they qualify as "host names"? > (I picked those examples from a scrolling maillog file, so the listed hos= ts > are picked at random and not for the purpose to offend anyone) >=20 > unknown.level3.net 64.157.143.50 > 67.106.228.14.ptr.us.xo.net 67.106.228.14 > 200-170-198-6.core01.spo.ifx.net.br 200.170.198.6 > 0x50a2eb04.unknown.tele.dk 80.162.235.4 They do convey something -- the operator has taken care of them, perhaps only by $GENERATE, but still, and it has not been delegated further, for whatever reason. I find this partially useful in assessment och "credibility". That it is served is essentially the most important part, (because of problems associated with unreachable servers et al.) but there is also value in these autgenerated labels. =20 > If these are considered to be valid "host names" it would IMHO be nice > if the, obviously generated, names mapping the IP address would also > carry some CIDR information. A naming scheme like in RFC 2317 could be > used: =20 > This would help especially in cases where no assignment information > beyond /16 is available from the RIR databases to block out abusive > hosts/nets without risking collateral damage. >=20 > IMHO recommending this would be nice, but maybe this is beyond the > objective of that draft. Agree.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE The PILLSBURY DOUGHBOY is CRYING for an END to BURT REYNOLDS movies!! --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+jWnD02/pMZDM1cURAnhhAJ9DaNUCPeydVb3mXdMc4s5m2leg5QCbBxne 4QTxO1yIYtB9MWBinODo5I8= =yJvg -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 10:12:37 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25476 for ; Fri, 4 Apr 2003 10:12:35 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34EjKRN006008 for ; Fri, 4 Apr 2003 16:45:20 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34EjKnV006007 for dnsop-outgoing; Fri, 4 Apr 2003 16:45:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34EjIRN006002 for ; Fri, 4 Apr 2003 16:45:19 +0200 (MEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h34EjDMn1270094; Fri, 4 Apr 2003 16:45:13 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id ABE54110F0; Fri, 4 Apr 2003 16:45:17 +0200 (CEST) Date: Fri, 4 Apr 2003 16:45:17 +0200 From: Stephane Bortzmeyer To: Markus Stumpf Cc: dnsop@cafax.se Subject: Re: RR DNS and spam Message-ID: <20030404144517.GA21718@nic.fr> References: <20030403152154.B48824@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030403152154.B48824@Space.Net> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ Sender: owner-dnsop@cafax.se Precedence: bulk On Thu, Apr 03, 2003 at 03:21:54PM +0200, Markus Stumpf wrote a message of 36 lines which said: > 8.0.30.195.in-addr.arpa IN PTR mail.space.net. > IN TXT "mailto:abuse@space.net" > > That way the maintainers of the RR zone could authorize IPs to be valid > mailservers and receiving mailservers would only accept mails from > sending IPs that have the RR TXT record. I would refuse *any* proposal relying on in-addr.arpa records. Why? Because in many countries (typically all of Africa, except may be RSA), even the ISP have no delegation of the in-addr.arpa space. There are many reasons for that: laziness of the upstream ISP is the most common. But there is also the technical difficulty of delegating in-addr.arpa when the typical allocation is much more specific than a /24. (RFC 2317 is not widely used.) Look at ANRT (Morocco) for instance: they use 194.204.241.128/26 (the object is properly registered in the RIPE database), are fed by the ISP "ONPT" and look at the delegation of the in-addr.arpa... Or look at the Pasteur Institute in Senegal. The IP addresse is 213.154.75.74 (in RIPEland again), The upstream is Sonatel and look at the delegation of the in-addr.arpa... #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 10:57:48 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27452 for ; Fri, 4 Apr 2003 10:57:47 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34FdIRN006671 for ; Fri, 4 Apr 2003 17:39:18 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34FdIHr006670 for dnsop-outgoing; Fri, 4 Apr 2003 17:39:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34FdGRN006665 for ; Fri, 4 Apr 2003 17:39:17 +0200 (MEST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h34FYnO8032875; Fri, 4 Apr 2003 10:34:49 -0500 (EST) Message-Id: <200304041534.h34FYnO8032875@nic-naa.net> To: Stephane Bortzmeyer cc: Markus Stumpf , dnsop@cafax.se, brunner@nic-naa.net Subject: Re: RR DNS and spam In-Reply-To: Your message of "Fri, 04 Apr 2003 16:45:17 +0200." <20030404144517.GA21718@nic.fr> Date: Fri, 04 Apr 2003 10:34:49 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-dnsop@cafax.se Precedence: bulk Good point. Important one too. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 13:54:38 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02607 for ; Fri, 4 Apr 2003 13:54:35 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34IOJRN008586 for ; Fri, 4 Apr 2003 20:24:19 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34IOI4W008585 for dnsop-outgoing; Fri, 4 Apr 2003 20:24:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34IOGRN008580 for ; Fri, 4 Apr 2003 20:24:17 +0200 (MEST) Received: from [192.149.252.108] ([192.136.136.31]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA28626; Fri, 4 Apr 2003 13:22:55 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030402223212.5111218E1@thrintun.hactrn.net> References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> Date: Fri, 4 Apr 2003 13:21:57 -0500 To: Rob Austein From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 17:32 -0500 4/2/03, Rob Austein wrote: >Does anybody -else- have comments on this draft? In particular: does >anybody who has not yet spoken on this have an opinion on whether the >WG should be working on this? On whether the group should spend time on this, my answer is ... it depends. If the document is intended to document the current environment surrounding the .arpa and/or more specifically, .in-addr.arpa, it will be useful. Documenting the current state of affairs, the policies of the IRR's regarding delegations, and making informed statements on the relationship of the .(in-addr.)arpa and the application layer is a good thing. Perhaps by clearly identifying the issues, the contents of .(in-addr.)arpa and the use thereof, will be cleaned up. If, on the other hand, the document is going to try and specify policies for the use of the space, it will have a tough time proceeding. I am not referring to an impact on IRR policy (as an employee of one, I have no say in that regard), but rather the general issue of the IETF having no enforcement arm. E.g., let's assume that there's a "People with computers MUST populate the reverse tree" and I don't. Who's going to come after me? How is my failure to meet that MUST going to impact the rest of the network (where's the interoperability)? I'd recommend only working on the document if the tone is of a report on the current state of affairs and not that of a mission statement to fix the ills of a broken reverse map. The former is useful and closure can be reached, the latter a rat hole without bottom. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 14:57:42 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04890 for ; Fri, 4 Apr 2003 14:57:40 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34JYkRN009466 for ; Fri, 4 Apr 2003 21:34:46 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34JYkpm009465 for dnsop-outgoing; Fri, 4 Apr 2003 21:34:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h34JYjRN009460 for ; Fri, 4 Apr 2003 21:34:45 +0200 (MEST) Received: (qmail 98610 invoked by uid 1013); 4 Apr 2003 19:34:44 -0000 Date: Fri, 4 Apr 2003 21:34:44 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030404213444.D48824@Space.Net> References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from edlewis@arin.net on Fri, Apr 04, 2003 at 01:21:57PM -0500 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk On Fri, Apr 04, 2003 at 01:21:57PM -0500, Edward Lewis wrote: > E.g., let's assume that there's a "People with computers MUST > populate the reverse tree" and I don't. Who's going to come after > me? How is my failure to meet that MUST going to impact the rest of > the network (where's the interoperability)? Maybe after a while it will be hurting you more than the rest of the net. Not so many years ago a lot of public information servers (e.g. FTP, gopher, http) sent you away if your RR didn't work. Some even had paranoid settings enabled to that forward and reverse had to match. With the rapid growth of the net these policies were removed more and more because the RR zones were more and more broken. Bill Manning did nice reports and I think we're by far on the "broken side" already. If due to the draft/rfc people will start populating and repairing the reverse tree those policies may come back and people not caring about the reverse tree may lock themselves out. It's often that a recommendation that has kinda official character can change a lot, because people have something to point at while arguing with other people. Off Topic: We had a lot of problems with mailservers and discussions with admins in the past because of "stray newlines". RFC 821 was a bit unclear about that. Now we have RFC 2821 and it /explicitly/ states that stray newlines are not allowed. Now, if an admin complains that he cannot send mail, I point at the document and they go away and install their patches/updates. Problem solved :-) \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 16:08:01 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08228 for ; Fri, 4 Apr 2003 16:08:00 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34KjuRN010361 for ; Fri, 4 Apr 2003 22:45:56 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34Kju66010360 for dnsop-outgoing; Fri, 4 Apr 2003 22:45:56 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34KjsRN010355 for ; Fri, 4 Apr 2003 22:45:55 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA21119; Fri, 4 Apr 2003 15:41:00 -0500 Date: Fri, 4 Apr 2003 15:41:00 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Brad Knowles cc: Markus Stumpf , Subject: Re: RR DNS and spam In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk What RFC's would that be? --Dean On Fri, 4 Apr 2003, Brad Knowles wrote: > At 2:43 PM -0500 2003/04/03, Dean Anderson wrote: > > > SMTP is a client-server protocol, not a > > server-server protocol. Your proposal is just a way to use DNS to make > > SMTP server-server. > > This is a demonstrably false statement. The updated RFCs for > Internet e-mail explicitly state that SMTP is a server-to-server > protocol. If you want client-to-server, this would be the Mail > Server Protocol (MSP). Right now, MSP looks a hell of a lot like > SMTP, but they will diverge in the future. > > -- > 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(+++) > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 16:23:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08583 for ; Fri, 4 Apr 2003 16:23:51 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34L5oRN010572 for ; Fri, 4 Apr 2003 23:05:50 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34L5ovB010571 for dnsop-outgoing; Fri, 4 Apr 2003 23:05:50 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34L5mRN010564 for ; Fri, 4 Apr 2003 23:05:49 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA11794; Fri, 4 Apr 2003 16:01:36 -0500 Date: Fri, 4 Apr 2003 16:01:37 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Markus Stumpf cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030404213444.D48824@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Fri, 4 Apr 2003, Markus Stumpf wrote: > On Fri, Apr 04, 2003 at 01:21:57PM -0500, Edward Lewis wrote: > > E.g., let's assume that there's a "People with computers MUST > > populate the reverse tree" and I don't. Who's going to come after > > me? How is my failure to meet that MUST going to impact the rest of > > the network (where's the interoperability)? > > Maybe after a while it will be hurting you more than the rest of the > net. Not so many years ago a lot of public information servers (e.g. > FTP, gopher, http) sent you away if your RR didn't work. Some even had > paranoid settings enabled to that forward and reverse had to match. I have yet to see this capability in most FTP, gopher, or http server software. Without the capability, it can't even be configured. While the capability could exist in some software somewhere, I have yet to experience or get a complaint of an FTP, gopher, or http server refusing connection for this reason. The only service that I have ever seen use this to refuse connections was SMTP, and there are very few doing that. Most didn't do it for long. I think what has happened is that there is a small contingent pushing for reverse, and there is a much larger contingent that doesn't do reverse, perhaps just to spite the smaller group, or perhaps because it is inconvenient, or in other cases (I have some) where multihomed mailservers have different forward and reverse names, so the while there are in-addr records, they don't match as the small contingent thinks they ought. Of course, the records still serve a convenience function for my purposes. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 16:27:09 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08664 for ; Fri, 4 Apr 2003 16:27:08 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34LAqRN010646 for ; Fri, 4 Apr 2003 23:10:52 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34LAqCh010645 for dnsop-outgoing; Fri, 4 Apr 2003 23:10:52 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34LAnRN010640 for ; Fri, 4 Apr 2003 23:10:50 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA19453; Fri, 4 Apr 2003 16:06:43 -0500 Date: Fri, 4 Apr 2003 16:06:44 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Brad Knowles cc: Markus Stumpf , Subject: Re: RR DNS and spam In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk Ah, you mean RFC 2476. 2476 is a _proposed_ standard. Since it hasn't moved since 1998, I think it is a _dead_ proposed standard. It is just another in a list of gratuitous changes that are shown by experience to be a waste of time and effort, as their proponents tilt at windmills trying to invent a protocol which can't be subjected to abuse and will prevent human behavior. So, I guess a statement has been demonstrated to be false, but it wasn't mine. --Dean On Fri, 4 Apr 2003, Brad Knowles wrote: > At 1:33 AM +0200 2003/04/04, Brad Knowles wrote: > > > This is a demonstrably false statement. The updated RFCs for > > Internet e-mail explicitly state that SMTP is a server-to-server > > protocol. If you want client-to-server, this would be the Mail > > Server Protocol (MSP). Right now, MSP looks a hell of a lot like > > SMTP, but they will diverge in the future. > > Sorry, I meant Message Submission Protocol. My bad. > > -- > 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(+++) > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 16:42:26 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09155 for ; Fri, 4 Apr 2003 16:42:25 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34LNjRN010790 for ; Fri, 4 Apr 2003 23:23:45 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34LNjn8010789 for dnsop-outgoing; Fri, 4 Apr 2003 23:23:45 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h34LNhRN010781 for ; Fri, 4 Apr 2003 23:23:43 +0200 (MEST) Received: (qmail 4801 invoked by uid 1013); 4 Apr 2003 21:23:43 -0000 Date: Fri, 4 Apr 2003 23:23:43 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: Re: RR DNS and spam Message-ID: <20030404232343.E48824@Space.Net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dean@av8.com on Fri, Apr 04, 2003 at 04:06:44PM -0500 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk On Fri, Apr 04, 2003 at 04:06:44PM -0500, Dean Anderson wrote: > Ah, you mean RFC 2476. 2476 is a _proposed_ standard. Since it hasn't > moved since 1998, I think it is a _dead_ proposed standard. It is just > another in a list of gratuitous changes that are shown by experience to be > a waste of time and effort, as their proponents tilt at windmills trying > to invent a protocol which can't be subjected to abuse and will prevent > human behavior. Yeah, just like POP (3) which was invented in Oktober 1984 and was "dead" for 10 years until "suddenly" with the rush of dialin users it became a desperately needed protocol to access mailboxes. Or like FSP which's principle was reinvented by P2P. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 17:14:40 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10267 for ; Fri, 4 Apr 2003 17:14:39 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34Lu2RN011130 for ; Fri, 4 Apr 2003 23:56:02 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h34Lu2T1011129 for dnsop-outgoing; Fri, 4 Apr 2003 23:56:02 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34Lu1RN011124 for ; Fri, 4 Apr 2003 23:56:01 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA23844; Fri, 4 Apr 2003 16:50:56 -0500 Date: Fri, 4 Apr 2003 16:50:57 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Rob Austein , Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk I think you are misunderstanding the draft. > I believe the wg should work on this, and I basically support the > intention of the draft. I think it could be turned into a useful report on how to use in-addr, and how not to use it. It will take some editing, though. > The draft, however, will need several clarifications. > > As already pointed out, the title (and the filename) does not reflect > the content well and will thus need to be revised. Abstract and > introduction may also need a revise from this point of view. > > Secondly, if I don't misunderstand the intention, the draft says two > things: > > 1. we need to try to build correct reverse mapping as much as > possible. This sounds benign, and even laudable on the surface. However, as you point out, the definition of "correct" is vague. The people who want to use reverse as tool to identify spammers, and drop connections have a particular notion of what "correct" is. That notion requires a "1-to-1 and onto mapping" between forward and reverse. In other words, "correct" means that every domain name must map to an IP address. The PTR record for that IP must map back to that domain name. This is exceedingly simplistic view of the network. For example: (This is a made up example, but we do use this method) custrelay1.av8.net has several IP addresses 130.105.0.1, 130.105.0.2). This is so that one IP address can be used for outbound connections, and the second can be used for inbound connections. Only customers are given the forward name. This reduces spam attempts. However, it you look up the name, custrelay1.av8.net, you will find only one ip address: 1.0.105.130.in-addr.arpa. 1H IN PTR relay1.av8.net. 2.0.105.130.in-addr.arpa. 1H IN PTR relay2.av8.net. custrelay1.av8.net. 1H IN A 130.105.0.2 relay1.av8.net. 1H IN A 127.0.0.1 relay2.av8.net. 1H IN A 127.0.0.1 Outbound connections using 130.105.0.1 don't "match". Spammers or abusers harvesting headers from mail messages won't get a mail relay. Incoming connections to 130.105.0.1 get a lot of OOB data and automatic blacklisting, because no one should be connecting on this address. And if the abusers get wise, we can change things around a bit, using the other address for inbound, etc. It doesn't affect my customers in the least. They aren't even aware of a changes. Some people assert this is somehow incorrect usage. However, it is correct, and becoming more and more common. Its tremendously effective at stopping relay abuse, and for detecting and blocking relay scanners. (though it is odd that the people most upset by this are the relay blacklists) > 2. applications should not rely on reverse mapping for several > purposes as they currently do. The discouraged purposes include: > - rejecting ftp/telnet connections just due to the lack of reverse > mapping or failure of reverse-forward-reverse match. > - filtering rule in TCP wrappers due to the lack of reverse mapping > - regarding e-mail messages as spam if the sender address does not > have a reverse mapping This is where you misunderstand. Although it seems contradictory to some of the other language in the draft, the proponents don't think these are inappropriate uses. The idea is to make everyone else change their usage of reverse so that these kinds of uses won't deny large numbers regular, ordinary users, as is the case now. > I don't much care about bullet 1, but I think bullet 2 needs some > clarification. > > First, I'd like to confirm if my understanding above is correct. The > draft basically just says: > > Applications SHOULD NOT rely on IN-ADDR for proper operation. > > But it is not very clear what the "proper operation" means. I picked > up the examples of the discouraged usage from Section 3 based on my > understanding of the draft. If I read it correctly, however, then I'd > wonder why people who seemed to want rely on such a usage > (e.g. rejecting ftp connections) are supporting the draft. > > Also, I'm not sure if all the examples in Section 3 are discouraged > based on the intention of the draft, which include: > > - (to try) logging the result of reverse lookup of a web client in a > web server > - reverse lookup in traceroute > > Finally, Section 4 needs to be clearer. The draft says > > The use > of IN-ADDR, sometimes in conjunction with a lookup of the name > resulting from the PTR record provides no real security, ... > ^^^^^^^^^^^^^^^^ > > but, as already pointed out in this list, "security" is a broad term. > I believe the draft should be clear on what kind of "security" it is > talking about. This is a concession to the people like me who have pointed out that there is no security whatsoever. It does not matter how broadly one defines security, there is no implication that a matching forward and reverse response indicate some kind of trust relationship between anyone, anywhere. > > In summary, I'd like the draft > > - to clarify the first paragraph of Section 4, and > - to add a concrete list of discouraged usage in Section 4 I think if the draft were changed so that the uses listed in section 3 were really discouraged, then the proponents would find it "turned on its head" so to speak. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 17:14:43 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10282 for ; Fri, 4 Apr 2003 17:14:41 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34LwMRN011178 for ; Fri, 4 Apr 2003 23:58:22 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h34LwL9r011177 for dnsop-outgoing; Fri, 4 Apr 2003 23:58:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h34LwLRN011172 for ; Fri, 4 Apr 2003 23:58:21 +0200 (MEST) Received: (qmail 6818 invoked by uid 1013); 4 Apr 2003 21:58:21 -0000 Date: Fri, 4 Apr 2003 23:58:21 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030404235821.F48824@Space.Net> References: <20030404213444.D48824@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dean@av8.com on Fri, Apr 04, 2003 at 04:01:37PM -0500 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk On Fri, Apr 04, 2003 at 04:01:37PM -0500, Dean Anderson wrote: > I have yet to see this capability in most FTP, gopher, or http server > software. Without the capability, it can't even be configured. While the > capability could exist in some software somewhere, I have yet to Then you should probably go and RTFM. tcpd(8) tcp/ip daemon wrapper program. tcpserver http://cr.yp.to/ucspi-tcp/tcpserver.html are starting points. google will also be of help. > I think what has happened is that there is a small contingent pushing for I did maintain big servers at the time it happend. And nearly none of the "big" FTP servers at that time like wuarchive.wustl.edu ftp.funet.fi prep.ai.mit.edu gatekeeper.dec.com [ ... ] had let you in without proper RR DNS. But with the dotcom rush it became lame to add RR DNS and the server admins stopped using > inconvenient, or in other cases (I have some) where multihomed mailservers > have different forward and reverse names, so the while there are in-addr > records, they don't match as the small contingent thinks they ought. Of And there is no reason for it as DNS also has provisions for that case: $ dig -x 195.30.254.85 But this discussion is getting offtopic for this group. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 17:27:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10516 for ; Fri, 4 Apr 2003 17:27:22 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34M5tRN011310 for ; Sat, 5 Apr 2003 00:05:55 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34M5tuP011309 for dnsop-outgoing; Sat, 5 Apr 2003 00:05:55 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34M5sRN011297 for ; Sat, 5 Apr 2003 00:05:54 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA31775; Fri, 4 Apr 2003 17:02:23 -0500 Date: Fri, 4 Apr 2003 17:02:24 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Markus Stumpf cc: dnsop@cafax.se Subject: Re: RR DNS and spam In-Reply-To: <20030404232343.E48824@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk Just like that. POP finally found a use, though. Historical note, I don't think it was dialin that got POP going, it was client server computing and PC's that made POP attractive. I remember trying to get users with unix workstations to use POP. We had to use a program called snarfmail. Snarfmail was a pop client that put mail in /usr/spool/mail, as though it had been received by sendmail, where Unix mail and mh could pick it up. --Dean On Fri, 4 Apr 2003, Markus Stumpf wrote: > On Fri, Apr 04, 2003 at 04:06:44PM -0500, Dean Anderson wrote: > > Ah, you mean RFC 2476. 2476 is a _proposed_ standard. Since it hasn't > > moved since 1998, I think it is a _dead_ proposed standard. It is just > > another in a list of gratuitous changes that are shown by experience to be > > a waste of time and effort, as their proponents tilt at windmills trying > > to invent a protocol which can't be subjected to abuse and will prevent > > human behavior. > > Yeah, just like POP (3) which was invented in Oktober 1984 and was > "dead" for 10 years until "suddenly" with the rush of dialin users > it became a desperately needed protocol to access mailboxes. > > Or like FSP which's principle was reinvented by P2P. > > \Maex > > -- > SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 > Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 > "The security, stability and reliability of a computer system is reciprocally > proportional to the amount of vacuity between the ears of the admin" > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 20:27:28 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15675 for ; Fri, 4 Apr 2003 20:27:28 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3514cRN012912 for ; Sat, 5 Apr 2003 03:04:38 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3514ctw012911 for dnsop-outgoing; Sat, 5 Apr 2003 03:04:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3514aRN012906 for ; Sat, 5 Apr 2003 03:04:37 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3514IBJ057601; Fri, 4 Apr 2003 20:04:34 -0500 (EST) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <20030404235821.F48824@Space.Net> References: <20030404213444.D48824@Space.Net> <20030404235821.F48824@Space.Net> Date: Sat, 5 Apr 2003 03:03:01 +0200 To: Markus Stumpf From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 11:58 PM +0200 2003/04/04, Markus Stumpf wrote: > Then you should probably go and RTFM. > tcpd(8) tcp/ip daemon wrapper program. As in TCP-Wrappers, by Wietse Venema? I'll agree to that. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 22:14:49 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16966 for ; Fri, 4 Apr 2003 22:14:48 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h352twRN014584 for ; Sat, 5 Apr 2003 04:55:58 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h352twBU014583 for dnsop-outgoing; Sat, 5 Apr 2003 04:55:58 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h352tuRN014578 for ; Sat, 5 Apr 2003 04:55:56 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id VAA27637; Fri, 4 Apr 2003 21:46:09 -0500 Date: Fri, 4 Apr 2003 21:46:10 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Brad Knowles cc: Markus Stumpf , Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk TCP wrappers only works on services that run out of inetd. Most large sites doen't run FTP, gopher, or HTTP out of inetd. And of course, this doesn't work on Windows or VMS, or MVS. As someone already posted, most sites don't drop connections for this reason anymore. --Dean On Sat, 5 Apr 2003, Brad Knowles wrote: > At 11:58 PM +0200 2003/04/04, Markus Stumpf wrote: > > > Then you should probably go and RTFM. > > tcpd(8) tcp/ip daemon wrapper program. > > As in TCP-Wrappers, by Wietse Venema? I'll agree to that. > > -- > 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(+++) > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 22:34:16 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17412 for ; Fri, 4 Apr 2003 22:34:15 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h353FIRN014694 for ; Sat, 5 Apr 2003 05:15:18 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h353FIcP014693 for dnsop-outgoing; Sat, 5 Apr 2003 05:15:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h353FHRN014688 for ; Sat, 5 Apr 2003 05:15:17 +0200 (MEST) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20030405031508053002mn6ne>; Sat, 5 Apr 2003 03:15:08 +0000 Date: Fri, 4 Apr 2003 19:15:06 -0800 (PST) From: Doug Barton To: Dean Anderson cc: Brad Knowles , Markus Stumpf , dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: Message-ID: <20030404191337.S10499@12-234-22-23.pyvrag.nggov.pbz> References: Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Fri, 4 Apr 2003, Dean Anderson wrote: > TCP wrappers only works on services that run out of inetd. Most large > sites doen't run FTP, gopher, or HTTP out of inetd. This is not correct. You can link with the tcp wrappers library for just about any network service. Most of the FreeBSD network services are configured this way, for example. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 23:32:35 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17962 for ; Fri, 4 Apr 2003 23:32:33 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h354B2RN015031 for ; Sat, 5 Apr 2003 06:11:02 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h354B2DL015030 for dnsop-outgoing; Sat, 5 Apr 2003 06:11:02 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h354B1RN015025 for ; Sat, 5 Apr 2003 06:11:01 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id XAA05847; Fri, 4 Apr 2003 23:09:01 -0500 Date: Fri, 4 Apr 2003 23:09:02 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Doug Barton cc: Brad Knowles , Markus Stumpf , Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030404191337.S10499@12-234-22-23.pyvrag.nggov.pbz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk I think you are confusing tcp-wrappers with socks. No doubt that socks-like library could be made from tcp-wrappers, but I don't think there has been. Its kind of a mute point though, since as has been pointed out, no one uses this functionality, and large sites don't run these servers out of inetd. Could such services be built? Sure. Are they built? No. From the tcp-wrappers readme: === There are two ways to use the wrapper programs: 1) The easy way: move network daemons to some other directory and fill the resulting holes with copies of the wrapper programs. This approach involves no changes to system configuration files, so there is very little risk of breaking things. 2) The advanced way: leave the network daemons alone and modify the inetd configuration file. For example, an entry such as: tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot === --Dean On Fri, 4 Apr 2003, Doug Barton wrote: > On Fri, 4 Apr 2003, Dean Anderson wrote: > > > TCP wrappers only works on services that run out of inetd. Most large > > sites doen't run FTP, gopher, or HTTP out of inetd. > > This is not correct. You can link with the tcp wrappers library for just > about any network service. Most of the FreeBSD network services are > configured this way, for example. > > Doug > > -- > > If it's moving, encrypt it. If it's not moving, encrypt > it till it moves, then encrypt it some more. > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 4 23:51:40 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18359 for ; Fri, 4 Apr 2003 23:51:39 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h354UpRN015102 for ; Sat, 5 Apr 2003 06:30:51 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h354UpmG015101 for dnsop-outgoing; Sat, 5 Apr 2003 06:30:51 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h354UnRN015096 for ; Sat, 5 Apr 2003 06:30:50 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id XAA03952; Fri, 4 Apr 2003 23:29:52 -0500 Date: Fri, 4 Apr 2003 23:29:54 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Markus Stumpf cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030404235821.F48824@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk > > > inconvenient, or in other cases (I have some) where multihomed mailservers > > have different forward and reverse names, so the while there are in-addr > > records, they don't match as the small contingent thinks they ought. Of > > And there is no reason for it as DNS also has provisions for that case: > $ dig -x 195.30.254.85 This returns a long list of PTR records, indicating which customers are on this host. That is clearly undesirable for my case--I don't want to give out that information. So there is a good reason for it in my example. And frankly, your competitors will no doubt find the list of your customers useful. Perhaps you want to rethink that long PTR list. And at some point, it will be too big for a UDP reply. I hadn't even thought about that until I looked at your big list. Then what? There is really a lot wrong with such a proposal than first catches the eye. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Apr 5 01:32:42 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19778 for ; Sat, 5 Apr 2003 01:32:41 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3568ZRN015615 for ; Sat, 5 Apr 2003 08:08:35 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3568ZE4015614 for dnsop-outgoing; Sat, 5 Apr 2003 08:08:35 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3568XRN015609 for ; Sat, 5 Apr 2003 08:08:34 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3567h516225; Sat, 5 Apr 2003 09:07:43 +0300 Date: Sat, 5 Apr 2003 09:07:42 +0300 (EEST) From: Pekka Savola To: Dean Anderson cc: Doug Barton , Brad Knowles , Markus Stumpf , Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk Use the source Luke! Do not have blind belief in readme's. I've every confidence that Doug knows how services are in FreeBSD -- you might want to have a look at http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html -- and as it happens, I happen to use tcp-wrappers a lot with non-inetd programs also, and a *LOT* of others do so as well. Just to mention a very common one, OpenSSH. On Fri, 4 Apr 2003, Dean Anderson wrote: > I think you are confusing tcp-wrappers with socks. No doubt that > socks-like library could be made from tcp-wrappers, but I don't think > there has been. Its kind of a mute point though, since as has been pointed > out, no one uses this functionality, and large sites don't run these > servers out of inetd. > > Could such services be built? Sure. > > Are they built? No. > > >From the tcp-wrappers readme: > === > There are two ways to use the wrapper programs: > > 1) The easy way: move network daemons to some other directory and fill > the resulting holes with copies of the wrapper programs. This > approach involves no changes to system configuration files, so there > is very little risk of breaking things. > > 2) The advanced way: leave the network daemons alone and modify the > inetd configuration file. For example, an entry such as: > > tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot > === > > > --Dean > > On Fri, 4 Apr 2003, Doug Barton wrote: > > > On Fri, 4 Apr 2003, Dean Anderson wrote: > > > > > TCP wrappers only works on services that run out of inetd. Most large > > > sites doen't run FTP, gopher, or HTTP out of inetd. > > > > This is not correct. You can link with the tcp wrappers library for just > > about any network service. Most of the FreeBSD network services are > > configured this way, for example. > > > > Doug > > > > -- > > > > If it's moving, encrypt it. If it's not moving, encrypt > > it till it moves, then encrypt it some more. > > > > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Apr 5 13:37:38 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11823 for ; Sat, 5 Apr 2003 13:37:38 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h35ICJRN019684 for ; Sat, 5 Apr 2003 20:12:19 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h35ICJ8s019683 for dnsop-outgoing; Sat, 5 Apr 2003 20:12:19 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h35ICHRN019678 for ; Sat, 5 Apr 2003 20:12:18 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h35IBuBH032870; Sat, 5 Apr 2003 13:12:01 -0500 (EST) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Sat, 5 Apr 2003 19:54:41 +0200 To: Dean Anderson From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: Brad Knowles , Markus Stumpf , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 9:46 PM -0500 2003/04/04, Dean Anderson wrote: > TCP wrappers only works on services that run out of inetd. Most large > sites doen't run FTP, gopher, or HTTP out of inetd. Or any program that is linked with the TCP-Wrappers library, and most programs these days at least allow for that possibility. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From T.UPcPpNv@wslogic.com Sun Apr 6 15:33:24 2003 Received: from ool-182f2310.dyn.optonline.net (ool-182f2310.dyn.optonline.net [24.47.35.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04647 for ; Sun, 6 Apr 2003 15:33:24 -0400 (EDT) Date: Sun, 6 Apr 2003 15:33:24 -0400 (EDT) X-Rim: 8bLnYtB4rJsX1kudOmsze1v--1301082209 Received: from 235.113.177.47 (HELO joedog.org) (235.113.177.47) by bearmeadow.com with ESMTP id for ; Wed, 5 Mar 2003 02:03:11 -0600 X-Mailer: Internet Mail Service (5.5.2655.55) Message-Id: <7.8.8.149715127.UQFhu0dh@diversityuintl.com> To: "dnsop-archive@lists.ietf.org" From: "Vinnie Deveaux" Subject: dnsop-archive@lists.ietf.org Get laid tonight. Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="==11cDfjPsPlRX" --==11cDfjPsPlRX Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 Cgo8aHRtbD4KPGhlYWQ+PC9oZWFkPgo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIj4KPGJyPgo8 Y2VudGVyPgo8IS0tMTE4Nzg0NDQ3MC0tPjwhLS1LWHRla1pPUDJ1c3owNnloNkVxdGItLT4K PGNlbnRlcj48YSBocmVmPSJodHRwOi8vYWR1bHR3ZWJwYXNzaG9zdGluZy5vcmcveHh4ZGF0 ZSI+PGltZyBib3JkZXI9MCBhbHQ9IiIgc3JjPSJodHRwOi8veHh4ZGlyZWN0c2V4Lm5ldC94 eHhkYXRlL2dkMS5naWYiPjwvYT48L2NlbnRlcj4KPCEtLTI4NDM4NzQwMS0tPjwhLS1lZWc2 QWxYSXN6RVktLT4KPC9ib2R5PjwvaHRtbD4KCg== --==11cDfjPsPlRX-- From owner-dnsop@cafax.se Mon Apr 7 14:38:27 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00315 for ; Mon, 7 Apr 2003 14:38:25 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37IBORN010369 for ; Mon, 7 Apr 2003 20:11:24 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h37IBOnl010368 for dnsop-outgoing; Mon, 7 Apr 2003 20:11:24 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h37IBMRN010363 for ; Mon, 7 Apr 2003 20:11:22 +0200 (MEST) Received: (qmail 60092 invoked by uid 1013); 7 Apr 2003 18:11:22 -0000 Date: Mon, 7 Apr 2003 20:11:22 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030407201122.J8692@Space.Net> References: <20030404235821.F48824@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dean@av8.com on Fri, Apr 04, 2003 at 11:29:54PM -0500 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk On Fri, Apr 04, 2003 at 11:29:54PM -0500, Dean Anderson wrote: > this host. That is clearly undesirable for my case--I don't want to give > out that information. So there is a good reason for it in my example. You mean security by obscurity? There is a much easier way to find out all the domains hosted by us than to ask for the PTR records of each and every IP of e.g. our /16. > And frankly, your competitors will no doubt find the list of your > customers useful. So what? We don't fear competitors. Most customers that went away came back, without us having to do something. Quality sells. > Perhaps you want to rethink that long PTR list. And at > some point, it will be too big for a UDP reply. I hadn't even thought > about that until I looked at your big list. Then what? Then we don't add other names. But this was an example that there is no problem adding more than one PTR record, because you stated in a previous post: *> or in other cases (I have some) where multihomed mailservers *> have different forward and reverse names, so the while there are in-addr *> records, they don't match as the small contingent thinks they ought. There is no reason why there shouldn't be more than one PTR records if it would be crucial. > There is really a lot wrong with such a proposal than first catches the > eye. The only valid reason against this proposal I have seen upto now was from Stephane. It shows operational problems that the legit "owners" of the IP block would be unable to solve. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 14:47:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00575 for ; Mon, 7 Apr 2003 14:47:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37IKhRN010463 for ; Mon, 7 Apr 2003 20:20:43 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h37IKh2u010462 for dnsop-outgoing; Mon, 7 Apr 2003 20:20:43 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mclmx.mail.saic.com (mclmx.mail.saic.com [149.8.64.10]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37IKfRN010457 for ; Mon, 7 Apr 2003 20:20:41 +0200 (MEST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for dnsop@cafax.se; Mon, 7 Apr 2003 14:18:59 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003040714201315300 ; Mon, 07 Apr 2003 14:20:13 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <2AXF4Z2M>; Mon, 7 Apr 2003 14:19:49 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104B1B@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Dean Anderson'" , Daniel Senie Cc: dnsop@cafax.se Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Date: Mon, 7 Apr 2003 14:20:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-dnsop@cafax.se Precedence: bulk I know that this draft has been discussed a lot already and that Dean has strongly held convictions, but I can't just let some of Dean's statements go by without comment. Daniel wrote: > > It is the purpose of this draft to define the reasons to > > promote the use of INADDR, and to also discourage usage > > that can be harmful and which provides false security [...] This is a reasonable and proper thing to do in this draft. Yes, there was a period where some sites attempted to do website access control by forward-->reverse-->forward DNS lookups. That didn't last long, but it's appropriate to document the reasons why such things are Bad Ideas. Dean replied: > Then it should include a statement to the effect of: > > ------------ > IN-ADDR should not be used for any logging, auditing, identification, > authentication, or authorization purpose. Its sole purpose is for > the convenience of such applications as traceroute. No, no, no, no, no. Your statement above is not accurate. I agree that is rarely useful to log IN-ADDR information by itself without the IP address--in fact, it's a Bad Idea and the IETF almost certainly should clearly recommend against logging of IN-ADDR without the associated IP. However, it *can* be useful to record both the IP address and corresponding PTR lookup information, where such information is available. The PTR information can't always be relied upon by itself, but since it can change over time it does represent information that is either logged or lost. Is it your assertion that the PTR information, if logged along with the IP address, can *never* be relied upon in any way by a competent administrator or investigator? More importantly: It is *entirely* proper for a large ISP (or in fact any company) to populate the reverse lookup tree with information such as xx.129.203.24.in-addr.arpa PTR \ modemcable0xx.129-203-24.que.mc.videotron.ca [0] and it is *entirely* appropriate for me to be able to choose to use that information as one factor in deciding how to handle incoming connection attempts from that IP address. It's appropriate today in both the "IPv4-only" world and in the IPv4/IPv6 world. Yes, it's difficult to ensure that that information is 100% accurate, even if it's accurate it's not always useful, and it will be more difficult to ensure it's accurate when the number of supported IP addresses grows by $BIGNUM. The fact that reverse lookup information can be difficult to maintain and use effectively does not mean that its continued use constitutes a hazard to users such that it should never be used within applications. It's entirely possible that someone out there will choose to run their own mailserver at home, on an IP address with reverse info such as that above (or no reverse lookup info, or...). That's their choice, and I have no problem with it--but someone in such a situation should realize that there *is* a reasonable probability that their outgoing connections may be denied at other sites. This isn't a problem specific to unsolicited e-mail, it's a general issue. Connectivity to an ISP does not (and never will) constitute some guarantee that everyone else out there is obliged to receive all the packets that one might choose to send. Given that DNS reverse lookup *does* provide a useful function, and there is no other solution (including the ICMP techniques that Dean apparently favors) that provides information which is equivalent and can be used/controlled/managed/distributed in ways as effective as DNS, I strongly object to Dean's continued attempts to use this draft to de-specify DNS reverse lookup. Does the draft need updates and modifications? Yes, from my reading--am I correct in thinking that an updated version is already in work, and/or would now be an appropriate time to Send Text? [0] Yes, I pulled this IP out of a log of spam rejects. -- Rip Loomis Senior Systems Security Engineer SAIC Enterprise Security Solutions Group www.saic.com/securebiz Center for Information Security Technology www.cist-east.saic.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 15:03:11 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00996 for ; Mon, 7 Apr 2003 15:03:10 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37IecRN010678 for ; Mon, 7 Apr 2003 20:40:38 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h37Iecu1010677 for dnsop-outgoing; Mon, 7 Apr 2003 20:40:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37IeZRN010672 for ; Mon, 7 Apr 2003 20:40:36 +0200 (MEST) Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA03370 for ; Mon, 7 Apr 2003 12:40:35 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HCZ00ENEL7MTO@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Mon, 07 Apr 2003 12:40:35 -0600 (MDT) Received: from sun.com (dsl093-078-011.sfo2.dsl.speakeasy.net [66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HCZ00M98L7LSD@mail.sun.net> for dnsop@cafax.se; Mon, 07 Apr 2003 12:40:34 -0600 (MDT) Date: Mon, 07 Apr 2003 11:41:59 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-reply-to: <20030402223212.5111218E1@thrintun.hactrn.net> To: Rob Austein Cc: dnsop@cafax.se Message-id: <9D8681EA-6928-11D7-9601-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h37IebRN010673 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit On Wednesday, April 2, 2003, at 02:32 PM, Rob Austein wrote: > So far we've heard from: > > - Ray, who pointed out some RIR-related (specifically, ARIN-related) > text that needs some work; > > - Måns, who liked the draft and suggested adding text discussing IPv6; > > - Dean, who says that we should not be working on this draft. > > Does anybody -else- have comments on this draft? In particular: does > anybody who has not yet spoken on this have an opinion on whether the > WG should be working on this? Catching up on e-mail in this wg... I just read the draft, here are my comments: 1- This document should talk about IPv6 and suggest practices that are viable in both world, v4 & v6 . Sentences like: "Only IP addresses not presently in use within a block, or that are not valid for use (zeros or ones broadcast addresses) are permitted to have no mapping." have a big impact on IPv6, as the address space is so large! See draft-dnsop-ipv6-dns-issues-02.txt On the same line, the document should mention ip6.arpa as long as in-addr.arpa. 2- The rationale why the reverse tree has to be populated is weak: - checking reverse mapping is far from a good security mechanism - doing log analysis on PTR records is not very good, better alternative exists - export control based on PTR is, hum, questionable. 3- Several people have made the case that apps who rely on the existence of PTR are broken and should be fixed. Although I have some sympathy for this argument, I consider it a long term goal. In the meantime, there is an operation issue when the reverse tree is not populated correctly, and I understand it would be good to RECOMMEND to populate it. 4- Not populating the reverse tree has different effects, depending which part is not populated and who suffer the consequences. e.g: - Mail relays with no PTR exposed themselves to big problems - In Enterprise environment, some weak internal access control based on PTR is often deployed, failure to deploy PTR internally leads to IT problems - Home ISPs who fail to pre-populate the reverse for their customer could face high volume call on their help desk when customers can not access some FTP site that still do PTR enforcement. - When PTR are not populated correctly for web proxies (and transparent proxies) Web server log analyst could arrive to bogus conclusion. What is the point to discuss 5% vs 7% TLD access when 30% or more of the queries do not resolve? It is unclear to me what the current draft is trying to optimize, who gets the benefits and who bares the cost. So I would like to see this draft take another approach at the problem, and issue more targeted recommendations with a softer language (RECOMMEND vs SHOULD) - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 16:54:09 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05732 for ; Mon, 7 Apr 2003 16:54:08 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37KRdRN011935 for ; Mon, 7 Apr 2003 22:27:39 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h37KRdqt011934 for dnsop-outgoing; Mon, 7 Apr 2003 22:27:39 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37KRbRN011922 for ; Mon, 7 Apr 2003 22:27:37 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA31917; Mon, 7 Apr 2003 16:24:25 -0400 Date: Mon, 7 Apr 2003 16:24:29 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Loomis, Rip" cc: Daniel Senie , Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104B1B@US-Columbia-CIST.mail.saic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 7 Apr 2003, Loomis, Rip wrote: > I know that this draft has been discussed a lot already > and that Dean has strongly held convictions, but I can't > just let some of Dean's statements go by without comment. My views are neither "convictions", nor "strongly held". They just happen to be logically correct. The "strongly held convictions" are those that refuse to accept logical arguments and the consequences of deduction. > Dean replied: > > Then it should include a statement to the effect of: > > > > ------------ > > IN-ADDR should not be used for any logging, auditing, identification, > > authentication, or authorization purpose. Its sole purpose is for > > the convenience of such applications as traceroute. > > No, no, no, no, no. Your statement above is not accurate. > I agree that is rarely useful to log IN-ADDR information by itself > without the IP address--in fact, it's a Bad Idea and the IETF almost Actually, it is still quite common to find logs without IP addresses. There are still a number of unix implementations that have syslog's and wtmp's that don't have anything but the in-addr response (and only 64 bytes of that). For example, Linux stores the in-addr for IPv4, and the IP address for IPv6. However, I am not saying it is inappropriate to store in-addr as secondary information. I am saying it is inappropriate to use in-addr as the primary information. Those are different things. Far too many people hold mis-conceptions about the proper use of in-addr: > certainly should clearly recommend against logging of IN-ADDR without > the associated IP. However, it *can* be useful to record both the > IP address and corresponding PTR lookup information, where > such information is available. The PTR information can't always be > relied upon by itself, but since it can change over time it does You seem to miss the point: PTR information can _never_ be relied by itself. There is no case where it can be relied on. It is silly to keep repeating this point. > represent information that is either logged or lost. > Is it your assertion that the PTR information, if logged along with the > IP address, can *never* be relied upon in any way by a competent > administrator or investigator? Yes. Only the IP address can be relied on. If you have the IP address, you don't need the IN-ADDR. If you don't have the IP address, the IN-ADDR can't be trusted. Without the IP address, you have nothing. > More importantly: > It is *entirely* proper for a large ISP (or in fact any company) > to populate the reverse lookup tree with information such as > > xx.129.203.24.in-addr.arpa PTR \ > modemcable0xx.129-203-24.que.mc.videotron.ca [0] > > and it is *entirely* appropriate for me to be able to choose to > use that information as one factor in deciding how to handle > incoming connection attempts from that IP address. It is _entirely_ up to the ISP to decide whether or not to do that. If they don't do that, then that case is _also_ entirely proper. _YOU_ can do whatever you want to. Just don't expect the rest of use to change our IN-ADDR zones to suit your misguided and illogical convictions. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 17:12:20 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06123 for ; Mon, 7 Apr 2003 17:12:19 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37KZwRN012004 for ; Mon, 7 Apr 2003 22:35:58 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h37KZwOM012003 for dnsop-outgoing; Mon, 7 Apr 2003 22:35:58 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37KZuRN011998 for ; Mon, 7 Apr 2003 22:35:57 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA07326; Mon, 7 Apr 2003 16:30:00 -0400 Date: Mon, 7 Apr 2003 16:30:05 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Markus Stumpf cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030407201122.J8692@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 7 Apr 2003, Markus Stumpf wrote: > On Fri, Apr 04, 2003 at 11:29:54PM -0500, Dean Anderson wrote: > > this host. That is clearly undesirable for my case--I don't want to give > > out that information. So there is a good reason for it in my example. > > You mean security by obscurity? No, security by password. The forward domain name is a password for our customers. Of course, all security is through obsurity of the key. > There is a much easier way to find out all the domains hosted by us than > to ask for the PTR records of each and every IP of e.g. our /16. Really? What is it? > > And frankly, your competitors will no doubt find the list of your > > customers useful. > > So what? We don't fear competitors. Most customers that went away came > back, without us having to do something. Quality sells. So, you expect everyone to give out their customer lists? Not every ISP shares your hubris. > > Perhaps you want to rethink that long PTR list. And at > > some point, it will be too big for a UDP reply. I hadn't even thought > > about that until I looked at your big list. Then what? > > Then we don't add other names. If you don't add them, then their reverse is broken, according to this proposal. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 18:35:55 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09426 for ; Mon, 7 Apr 2003 18:35:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37MEARN013318 for ; Tue, 8 Apr 2003 00:14:10 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h37MEAY1013317 for dnsop-outgoing; Tue, 8 Apr 2003 00:14:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37ME9RN013312 for ; Tue, 8 Apr 2003 00:14:09 +0200 (MEST) Received: from daimlerchrysler.com (bgp01019620bgs.sanarb01.mi.comcast.net [68.40.66.101]) by mtaout08.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCZ007A5V03YZ@mtaout08.icomcast.net> for dnsop@cafax.se; Mon, 07 Apr 2003 18:12:07 -0400 (EDT) Date: Mon, 07 Apr 2003 18:13:35 -0400 From: Kevin Darcy Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-reply-to: <9D8681EA-6928-11D7-9601-00039376A6AA@sun.com> To: dnsop@cafax.se Message-id: <3E91F80F.2090409@daimlerchrysler.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312 References: <9D8681EA-6928-11D7-9601-00039376A6AA@sun.com> Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT Alain Durand wrote: > 3- Several people have made the case that apps who rely on the > existence of PTR > are broken and should be fixed. Although I have some sympathy for > this argument, I consider it a long term goal. In the meantime, > there > is an operation issue when the reverse tree is not populated > correctly, > and I understand it would be good to RECOMMEND to populate it. So, if I interpret you correctly, you want to pay lip service to fixing broken apps (that have broken for years) while at the same time removing a significant incentive for those apps to get fixed. "Long-term" == "never", in many contexts, and this is one of them IMO. - Kevin #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 20:44:31 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12430 for ; Mon, 7 Apr 2003 20:44:30 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h380NiRN014186 for ; Tue, 8 Apr 2003 02:23:44 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h380NiAH014185 for dnsop-outgoing; Tue, 8 Apr 2003 02:23:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h380NgRN014180 for ; Tue, 8 Apr 2003 02:23:43 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h380NK2A054871; Mon, 7 Apr 2003 20:23:41 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <3E91F80F.2090409@daimlerchrysler.com> References: <9D8681EA-6928-11D7-9601-00039376A6AA@sun.com> <3E91F80F.2090409@daimlerchrysler.com> Date: Tue, 8 Apr 2003 02:13:45 +0200 To: Kevin Darcy From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 6:13 PM -0400 2003/04/07, Kevin Darcy wrote: > So, if I interpret you correctly, you want to pay lip service to > fixing broken apps (that have broken for years) while at the same > time removing a significant incentive for those apps to get fixed. So, if I understand you correctly, we should jump right to breaking all applications without any intermediate step where we suggest that people stop depending on certain behaviour by default. Ready, fire, aim! -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 21:30:23 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12431 for ; Mon, 7 Apr 2003 20:44:30 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h380O9RN014194 for ; Tue, 8 Apr 2003 02:24:09 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h380O9im014193 for dnsop-outgoing; Tue, 8 Apr 2003 02:24:09 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h380O8RN014188 for ; Tue, 8 Apr 2003 02:24:08 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h380NK28054871; Mon, 7 Apr 2003 20:23:37 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Tue, 8 Apr 2003 02:10:13 +0200 To: Dean Anderson From: Brad Knowles Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: "Loomis, Rip" , Daniel Senie , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 4:24 PM -0400 2003/04/07, Dean Anderson wrote: > My views are neither "convictions", nor "strongly held". They just happen > to be logically correct. The "strongly held convictions" are those that > refuse to accept logical arguments and the consequences of deduction. Methinks thou doth protest too much. Despite all your claims to the contrary, claiming that "strongly held convictions" are actually fact is merely proof of the depth to which you hold these convictions -- in your world, it appears that they are actually fact. However, in the real world.... > Actually, it is still quite common to find logs without IP addresses. Evidence, please. > There are still a number of unix implementations that have syslog's and > wtmp's that don't have anything but the in-addr response (and only 64 > bytes of that). Evidence, please. > For example, Linux stores the in-addr for IPv4, and the > IP address for IPv6. There is no one single "Linux". There are many different versions of the Linux kernel. There are many Linux distributions that may or may not make use of a particular Linux kernel. For any particular subsystem, there are probably at least two to six or more different major variants of that system, and a particular distribution may or may not choose to use a particular one. > However, I am not saying it is inappropriate to store in-addr as secondary > information. I am saying it is inappropriate to use in-addr as the primary > information. Those are different things. Insofar as this statement goes, I agree. If only you would not use this as a jumping-off point for making every possible attempt to destroy all possible use of reverse DNS. > You seem to miss the point: PTR information can _never_ be relied by > itself. There is no case where it can be relied on. It is silly to keep > repeating this point. Who said that we'd be doing this, or suggesting this? Everything I've read (so far) indicates that we're talking about making use of this information as an added data point, above and beyond the bare IP address. > Yes. Only the IP address can be relied on. If you have the IP address, > you don't need the IN-ADDR. Wrong. It can be a useful piece of information, information that may not be around in a few days or a few months, when you decide to try to look up that IP address. It's important not to destroy or throw away information unnecessarily. > _YOU_ can do whatever you want to. Just don't expect the rest of use to > change our IN-ADDR zones to suit your misguided and illogical convictions. It is entirely within your right to choose to do whatever you want with your DNS zones. However, I must insist once again that you refrain from removing from others their own right to make the same choice. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 22:15:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14286 for ; Mon, 7 Apr 2003 22:15:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h381ofRN015663 for ; Tue, 8 Apr 2003 03:50:41 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h381ofwk015662 for dnsop-outgoing; Tue, 8 Apr 2003 03:50:41 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from whale.cnnic.net.cn ([159.226.6.187]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h381obRN015656 for ; Tue, 8 Apr 2003 03:50:38 +0200 (MEST) Received: from cnniczh ([159.226.7.114]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id HD054A00.LOE for ; Tue, 8 Apr 2003 09:50:34 +0800 Message-ID: <01eb01c2fd71$abde4e80$7207e29f@cnniczh> Reply-To: "zhang hong" From: "zhang hong" To: Subject: Are there any ipv6 root servers? Date: Tue, 8 Apr 2003 09:53:37 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-dnsop@cafax.se Precedence: bulk Hello, Are there any root servers that have ipv6 address and support ipv6 DNS? I heard that f-root and h-root have supported ipv6, but not sure. Thanks! Best Regards Zhang Hong #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 23:16:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15359 for ; Mon, 7 Apr 2003 23:16:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h382sVRN016041 for ; Tue, 8 Apr 2003 04:54:31 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h382sVOF016040 for dnsop-outgoing; Tue, 8 Apr 2003 04:54:31 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from four.songbird.com (four.songbird.com [206.14.4.5]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h382sTRN016035 for ; Tue, 8 Apr 2003 04:54:30 +0200 (MEST) Received: (from kent@localhost) by four.songbird.com (8.11.6/8.11.6) id h3823ZT07724 for dnsop@cafax.se; Mon, 7 Apr 2003 19:03:35 -0700 Date: Mon, 7 Apr 2003 19:03:35 -0700 From: kent@songbird.com To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030407190335.A7350@songbird.com> Mail-Followup-To: dnsop@cafax.se References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from brad.knowles@skynet.be on Tue, Apr 08, 2003 at 02:10:13AM +0200 Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, Apr 08, 2003 at 02:10:13AM +0200, Brad Knowles wrote: > > Yes. Only the IP address can be relied on. If you have the IP address, > > you don't need the IN-ADDR. > > Wrong. It can be a useful piece of information, information that > may not be around in a few days or a few months, when you decide to > try to look up that IP address. It's important not to destroy or > throw away information unnecessarily. It should be pointed out that an IP address cannot always be "relied on", either. IP addresses and ptr records are just two different kinds of information, with different characteristics. The usefulness of either depends on the context. As far as the draft is concerned, I believe that its conclusion should be: Population of the inverse tree with useful information should be encouraged, but neither required nor relied upon. Other than that, I think the draft could be expanded to include more examples of the disparate ways that the inverse tree is actually used in practice, both good and bad. Kent #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 7 23:34:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15543 for ; Mon, 7 Apr 2003 23:34:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h383DuRN016178 for ; Tue, 8 Apr 2003 05:13:56 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h383Dus4016177 for dnsop-outgoing; Tue, 8 Apr 2003 05:13:56 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h383DtRN016172 for ; Tue, 8 Apr 2003 05:13:55 +0200 (MEST) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003040803134800100di5jbe>; Tue, 8 Apr 2003 03:13:49 +0000 Date: Mon, 7 Apr 2003 20:13:47 -0700 (PDT) From: Doug Barton To: zhang hong cc: dnsop@cafax.se Subject: Re: Are there any ipv6 root servers? In-Reply-To: <01eb01c2fd71$abde4e80$7207e29f@cnniczh> Message-ID: <20030407201236.L3963@znfgre.tberna.bet> References: <01eb01c2fd71$abde4e80$7207e29f@cnniczh> Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, 8 Apr 2003, zhang hong wrote: > Hello, > > Are there any root servers that have ipv6 address and support ipv6 DNS? This is an easy question to answer for yourself: $ for i in a b c d e f g h i j k l m ; do host -t AAAA $i.root-servers.net done Doug -- I'm the kind of man a woman thinks she can change #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 00:08:59 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16133 for ; Tue, 8 Apr 2003 00:08:58 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h383mLRN016446 for ; Tue, 8 Apr 2003 05:48:21 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h383mLGZ016445 for dnsop-outgoing; Tue, 8 Apr 2003 05:48:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from as.vix.com (as.vix.com [204.152.187.70]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h383mKRN016440 for ; Tue, 8 Apr 2003 05:48:20 +0200 (MEST) Received: by as.vix.com (Postfix, from userid 716) id E789A379EF4; Tue, 8 Apr 2003 03:48:18 +0000 (GMT) To: dnsop@cafax.se Subject: Re: Are there any ipv6 root servers? References: <01eb01c2fd71$abde4e80$7207e29f@cnniczh> From: Paul Vixie Date: 08 Apr 2003 03:48:18 +0000 In-Reply-To: <01eb01c2fd71$abde4e80$7207e29f@cnniczh> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk > Are there any root servers that have ipv6 address and support ipv6 DNS? yes. but the root.cache file, root zone, and root-servers.net zone do not yet list them. you can edit your root.cache file locally to add them, but the information in root.cache is generally only used at nameserver boot time and won't affect your ongoing operations. > I heard that f-root and h-root have supported ipv6, but not sure. so speaketh http://www.root-servers.org/, so it must be true :-). -- Paul Vixie #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 02:32:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00534 for ; Tue, 8 Apr 2003 02:32:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h386ACRN017830 for ; Tue, 8 Apr 2003 08:10:12 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h386ACuT017829 for dnsop-outgoing; Tue, 8 Apr 2003 08:10:12 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h386A6RN017817 for ; Tue, 8 Apr 2003 08:10:11 +0200 (MEST) Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA03391 for ; Tue, 8 Apr 2003 00:09:55 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HD000EWEH4ITO@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Tue, 08 Apr 2003 00:09:54 -0600 (MDT) Received: from sun.com (dsl093-078-011.sfo2.dsl.speakeasy.net [66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HD000BO6H4HBB@mail.sun.net> for dnsop@cafax.se; Tue, 08 Apr 2003 00:09:54 -0600 (MDT) Date: Mon, 07 Apr 2003 23:11:17 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-reply-to: <3E91F80F.2090409@daimlerchrysler.com> To: Kevin Darcy Cc: dnsop@cafax.se Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT On Monday, April 7, 2003, at 03:13 PM, Kevin Darcy wrote: > Alain Durand wrote: > >> 3- Several people have made the case that apps who rely on the >> existence of PTR >> are broken and should be fixed. Although I have some sympathy for >> this argument, I consider it a long term goal. In the meantime, >> there >> is an operation issue when the reverse tree is not populated >> correctly, >> and I understand it would be good to RECOMMEND to populate it. > > So, if I interpret you correctly, you want to pay lip service to > fixing broken apps (that have broken for years) while at the same time > removing a significant incentive for those apps to get fixed. No. I recognize those apps do exist. What I'm saying is: "If you care about them, make sure they work". Just being pragmatic. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 03:21:16 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01207 for ; Tue, 8 Apr 2003 03:21:15 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3870MRN018250 for ; Tue, 8 Apr 2003 09:00:22 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3870MC8018249 for dnsop-outgoing; Tue, 8 Apr 2003 09:00:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3870LRN018244 for ; Tue, 8 Apr 2003 09:00:21 +0200 (MEST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3870A624134; Tue, 8 Apr 2003 00:00:10 -0700 (PDT) From: Bill Manning Message-Id: <200304080700.h3870A624134@boreas.isi.edu> Subject: Re: Are there any ipv6 root servers? In-Reply-To: <01eb01c2fd71$abde4e80$7207e29f@cnniczh> from zhang hong at "Apr 8, 3 09:53:37 am" To: zhangh@cnnic.net.cn Date: Tue, 8 Apr 2003 00:00:10 -0700 (PDT) Cc: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit % Hello, % % Are there any root servers that have ipv6 address and support ipv6 DNS? % I heard that f-root and h-root have supported ipv6, but not sure. % Thanks! several do. www.root-servers.org list addresses for f and h others have IPv6 addresses but have chosen to not list them on that site at this time. there is no formal support for IPv6 transport in the production Internet at this time. It is possible to hand modify the hints file to add these records. There is also a testbed that has native IPv6 support (and has had for about 5 years), supports IDN lables and DNSSEC signed zones. www.rs.net if you want to play --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). #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 03:24:18 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01267 for ; Tue, 8 Apr 2003 03:24:16 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3878ARN018333 for ; Tue, 8 Apr 2003 09:08:10 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3878A7u018332 for dnsop-outgoing; Tue, 8 Apr 2003 09:08:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38789RN018327 for ; Tue, 8 Apr 2003 09:08:09 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3878626088792; Tue, 8 Apr 2003 03:08:07 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <20030407190335.A7350@songbird.com> References: <20030407190335.A7350@songbird.com> Date: Tue, 8 Apr 2003 09:01:02 +0200 To: kent@songbird.com From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 7:03 PM -0700 2003/04/07, kent@songbird.com wrote: > It should be pointed out that an IP address cannot always be "relied > on", either. Indeed. This is a point that I had made earlier, but which appears to have been conveniently ignored by the destructionists. > IP addresses and ptr records are just two different kinds > of information, with different characteristics. The usefulness of > either depends on the context. Agreed. > As far as the draft is concerned, I believe that its conclusion should > be: > > Population of the inverse tree with useful information should be > encouraged, but neither required nor relied upon. I would modify that to state that software authors (and OS vendors) should not use it by default, or at least not by itself -- the IP address should also be provided. However, the owner of the system should be free to configure the software to use this information, if they so choose. > Other than that, I think the draft could be expanded to include more > examples of the disparate ways that the inverse tree is actually used > in practice, both good and bad. Agreed. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 04:26:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02393 for ; Tue, 8 Apr 2003 04:26:22 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3885ERN019042 for ; Tue, 8 Apr 2003 10:05:14 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3885EmF019041 for dnsop-outgoing; Tue, 8 Apr 2003 10:05:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from whale.cnnic.net.cn ([159.226.6.187]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3885CRN019036 for ; Tue, 8 Apr 2003 10:05:13 +0200 (MEST) Received: from cnniczh ([159.226.7.114]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id HD0MGM00.KSH for ; Tue, 8 Apr 2003 16:05:10 +0800 Message-ID: <02a601c2fda6$00865fc0$7207e29f@cnniczh> Reply-To: "zhang hong" From: "zhang hong" To: References: <200304080700.h3870A624134@boreas.isi.edu> Subject: Re: Are there any ipv6 root servers? Date: Tue, 8 Apr 2003 16:08:13 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-dnsop@cafax.se Precedence: bulk Thanks Bill, Paul, I have another question. Some gTLDs and ccTLDs have IPv6 DNS now. While current root zone doesn't contain IPv6 referral (glue for 'AAAA') for these TLD name servers. Does this mean TLD IPv6 servers will not be asked in current DNS resolution, until their IPv6 addresses are added in root zone file? Thanks! BRs Zhang Hong ----- Original Message ----- From: "Bill Manning" To: Cc: Sent: Tuesday, April 08, 2003 3:00 PM Subject: Re: Are there any ipv6 root servers? > % Hello, > % > % Are there any root servers that have ipv6 address and support ipv6 DNS? > % I heard that f-root and h-root have supported ipv6, but not sure. > % Thanks! > > several do. www.root-servers.org list addresses for f and h > others have IPv6 addresses but have chosen to not list them on > that site at this time. > > there is no formal support for IPv6 transport in the production > Internet at this time. It is possible to hand modify the hints > file to add these records. There is also a testbed that has native IPv6 > support (and has had for about 5 years), supports IDN lables and > DNSSEC signed zones. www.rs.net if you want to play > > > --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). > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 06:31:29 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05024 for ; Tue, 8 Apr 2003 06:31:28 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38A8ZRN020314 for ; Tue, 8 Apr 2003 12:08:35 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h38A8ZLe020313 for dnsop-outgoing; Tue, 8 Apr 2003 12:08:35 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38A8ZRN020308 for ; Tue, 8 Apr 2003 12:08:35 +0200 (MEST) Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h38A8ZhI011885 for ; Tue, 8 Apr 2003 12:08:35 +0200 Date: Tue, 8 Apr 2003 12:08:34 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: dnsop@cafax.se Subject: Re: Are there any ipv6 root servers? In-Reply-To: <02a601c2fda6$00865fc0$7207e29f@cnniczh> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, 8 Apr 2003, zhang hong wrote: > I have another question. > > Some gTLDs and ccTLDs have IPv6 DNS now. While current root zone > doesn't contain IPv6 referral (glue for 'AAAA') for these TLD name servers. > > Does this mean TLD IPv6 servers will not be asked in current DNS resolution, > until their IPv6 addresses are added in root zone file? Its the caching issue again. For example, although 'ns.ripe.net' has a AAAA record only available in the 'ripe.net' zone, it doesn't get asked over v6 by 'virgin' caches as the result of a TLD delegation from the root. However, if the resolver cache has cached the AAAA for 'ns.ripe.net' as a result of querying a nameserver for 'ripe.net' for something else, then they do direct further queries over v6 (if they have v6 connectivity of course), as borne out by looking at the queries received by ns.ripe.net. Kind regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 10:06:45 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11212 for ; Tue, 8 Apr 2003 10:06:43 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38DcFRN022173 for ; Tue, 8 Apr 2003 15:38:15 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h38DcFVP022172 for dnsop-outgoing; Tue, 8 Apr 2003 15:38:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h38DcERN022167 for ; Tue, 8 Apr 2003 15:38:14 +0200 (MEST) Received: (qmail 46605 invoked by uid 1013); 8 Apr 2003 13:38:14 -0000 Date: Tue, 8 Apr 2003 15:38:14 +0200 From: Markus Stumpf To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030408153814.P8692@Space.Net> References: <20030407201122.J8692@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dean@av8.com on Mon, Apr 07, 2003 at 04:30:05PM -0400 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, Apr 07, 2003 at 04:30:05PM -0400, Dean Anderson wrote: > > There is a much easier way to find out all the domains hosted by us than > > to ask for the PTR records of each and every IP of e.g. our /16. > > Really? What is it? Know your tools and ask your LIRs. > So, you expect everyone to give out their customer lists? Not every ISP > shares your hubris. That's not our fault. And if you mean that it's impossible, if I want Example Co Ltd as a customer, to find out where they have Internet connectivity from, just because you don't add reverse records, you're rather naive. Oh btw. the example I made is one customer, so adding one or 100 PTR records doesn't make much difference in matters of losing customers and it was the explicit wish of that customer to add the records. > > > Perhaps you want to rethink that long PTR list. And at > > > some point, it will be too big for a UDP reply. I hadn't even thought > > > about that until I looked at your big list. Then what? > > > > Then we don't add other names. > > If you don't add them, then their reverse is broken, according to this > proposal. 1) it isn't, according to this proposal 2) the software knows about reverse resolving first, as it gets the IP address, looks up the PTR and validates the info by doing a forward lookup of the name(s) it got from the PTR. If it doesn't get names in the PTR it will not lookup these names. 3) if UDP buffer is too small DNS software automatically switches to TCP (or at least it should). \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 10:26:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13652 for ; Tue, 8 Apr 2003 10:26:38 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38E7WRN022533 for ; Tue, 8 Apr 2003 16:07:32 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h38E7WQ3022532 for dnsop-outgoing; Tue, 8 Apr 2003 16:07:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38E7TRN022527 for ; Tue, 8 Apr 2003 16:07:30 +0200 (MEST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h38E6hI14157; Tue, 8 Apr 2003 07:06:43 -0700 (PDT) From: Bill Manning Message-Id: <200304081406.h38E6hI14157@boreas.isi.edu> Subject: Re: Are there any ipv6 root servers? In-Reply-To: <001001c2fda2$3d3ad3f0$6207e29f@enum1> from bill at "Apr 8, 3 03:41:17 pm" To: bill@cnnic.cn (bill) Date: Tue, 8 Apr 2003 07:06:43 -0700 (PDT) Cc: bmanning@ISI.EDU, zhangh@cnnic.net.cn, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit % > there is no formal support for IPv6 transport in the production % > Internet at this time. It is possible to hand modify the hints % > file to add these records. There is also a testbed that has native IPv6 % > support (and has had for about 5 years), supports IDN lables and % > DNSSEC signed zones. www.rs.net if you want to play % > % % I read page linked by the above, one thing interested me is ENUM support. Is there any progress on that? % % Thanks. % % Bill of CNNIC ;) Yes. we may have something to report on by the next Ripe mtg. --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). #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 10:26:48 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13686 for ; Tue, 8 Apr 2003 10:26:45 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38EAgRN022591 for ; Tue, 8 Apr 2003 16:10:42 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h38EAg8a022590 for dnsop-outgoing; Tue, 8 Apr 2003 16:10:42 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38EAcRN022585 for ; Tue, 8 Apr 2003 16:10:39 +0200 (MEST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h38EAVM16474; Tue, 8 Apr 2003 07:10:31 -0700 (PDT) From: Bill Manning Message-Id: <200304081410.h38EAVM16474@boreas.isi.edu> Subject: Re: Are there any ipv6 root servers? In-Reply-To: <02a601c2fda6$00865fc0$7207e29f@cnniczh> from zhang hong at "Apr 8, 3 04:08:13 pm" To: zhangh@cnnic.net.cn Date: Tue, 8 Apr 2003 07:10:31 -0700 (PDT) Cc: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit that is correct. if you want to explore native IPv6 resolution, you should look at the testbed. outputs from the testbed are used as input to the ICANN process so tht eventually we might see IPv6 support in the root. % Thanks Bill, Paul, % % I have another question. % % Some gTLDs and ccTLDs have IPv6 DNS now. While current root zone % doesn't contain IPv6 referral (glue for 'AAAA') for these TLD name servers. % % Does this mean TLD IPv6 servers will not be asked in current DNS resolution, % until their IPv6 addresses are added in root zone file? % Thanks! % % BRs % % Zhang Hong % % ----- Original Message ----- % From: "Bill Manning" % To: % Cc: % Sent: Tuesday, April 08, 2003 3:00 PM % Subject: Re: Are there any ipv6 root servers? % % % > % Hello, % > % % > % Are there any root servers that have ipv6 address and support ipv6 DNS? % > % I heard that f-root and h-root have supported ipv6, but not sure. % > % Thanks! % > % > several do. www.root-servers.org list addresses for f and h % > others have IPv6 addresses but have chosen to not list them on % > that site at this time. % > % > there is no formal support for IPv6 transport in the production % > Internet at this time. It is possible to hand modify the hints % > file to add these records. There is also a testbed that has native IPv6 % > support (and has had for about 5 years), supports IDN lables and % > DNSSEC signed zones. www.rs.net if you want to play % > % > % > --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). % > #---------------------------------------------------------------------- % > # To unsubscribe, send a message to . % % % #---------------------------------------------------------------------- % # To unsubscribe, send a message to . % -- --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). #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 13:49:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23795 for ; Tue, 8 Apr 2003 13:49:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38HMfRN025119 for ; Tue, 8 Apr 2003 19:22:41 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h38HMfL1025118 for dnsop-outgoing; Tue, 8 Apr 2003 19:22:41 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from fxodpr13.extra.daimlerchrysler.com (fxodpr13.extra.daimlerchrysler.com [129.9.82.74]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38HMdRN025110 for ; Tue, 8 Apr 2003 19:22:40 +0200 (MEST) Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id h38HMXiv011390 for ; Tue, 8 Apr 2003 13:22:33 -0400 (EDT) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAABCaOpw; Tue, 8 Apr 03 13:22:33 -0400 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003040813223313692 for ; Tue, 08 Apr 2003 13:22:33 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr2-hme0.shdc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h38HMXkT022513 for ; Tue, 8 Apr 2003 13:22:33 -0400 (EDT) Received: from daimlerchrysler.com (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.12.8/8.9.1) with ESMTP id h38HLie9027297 for ; Tue, 8 Apr 2003 13:21:44 -0400 (EDT) Message-ID: <3E930528.4AE78F0@daimlerchrysler.com> Date: Tue, 08 Apr 2003 13:21:44 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt References: <9D8681EA-6928-11D7-9601-00039376A6AA@sun.com> <3E91F80F.2090409@daimlerchrysler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Brad Knowles wrote: > At 6:13 PM -0400 2003/04/07, Kevin Darcy wrote: > > > So, if I interpret you correctly, you want to pay lip service to > > fixing broken apps (that have broken for years) while at the same > > time removing a significant incentive for those apps to get fixed. > > So, if I understand you correctly, we should jump right to > breaking all applications without any intermediate step where we > suggest that people stop depending on certain behaviour by default. It's not the job of the IETF to project-manage each organization's migration from a standards-non-compliant piece of software to a standards-compliant one. That's something each organization will have to work out for itself, in its own way, in its own time. As for "breaking all applications", it's a little naive to think that everyone will immediately remove all of their PTR records the moment that the RFC is published. But, I think if our long-term goal is to eliminate all software dependencies on reverse DNS, we should at the very least make recommendations that are consistent with that long-term goal, rather than recommendations, e.g. "you SHOULD continue to populate reverse DNS" which are plainly incompatible with that goal. Otherwise, we've got horses pulling the cart in opposite directions and that doesn't exactly facilitate steady progress... - Kevin #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 19:30:29 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08201 for ; Tue, 8 Apr 2003 19:30:28 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38N5wRN029009 for ; Wed, 9 Apr 2003 01:05:58 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h38N5wre029008 for dnsop-outgoing; Wed, 9 Apr 2003 01:05:58 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38N5uRN029003 for ; Wed, 9 Apr 2003 01:05:57 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id TAA10369; Tue, 8 Apr 2003 19:04:29 -0400 Date: Tue, 8 Apr 2003 19:04:35 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Markus Stumpf cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <20030408153814.P8692@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, 8 Apr 2003, Markus Stumpf wrote: > On Mon, Apr 07, 2003 at 04:30:05PM -0400, Dean Anderson wrote: > > > There is a much easier way to find out all the domains hosted by us than > > > to ask for the PTR records of each and every IP of e.g. our /16. > > > > Really? What is it? > > Know your tools and ask your LIRs. Most registries won't give this information out anymore. (for the obvious reason). One can't easily get copies of the com or net zones (to look for domains with certain nameservers). > > So, you expect everyone to give out their customer lists? Not every ISP > > shares your hubris. > > That's not our fault. And if you mean that it's impossible, if I want > Example Co Ltd as a customer, to find out where they have Internet > connectivity from, just because you don't add reverse records, you're > rather naive. Thats the reverse of what I stated. Given a company, Of course, I can certainly find out something about its IP addresses, for some obvious public names, anyway. Certain agencies host their public sites on different connections just to hide this information. You have done something different: This proposal maks possible an easy answer to the question: Given an ISP, who are the customers? > Oh btw. the example I made is one customer, so adding one or 100 PTR > records doesn't make much difference in matters of losing customers > and it was the explicit wish of that customer to add the records. I don't have too many customers ask for in-addr. I usually give it to them if they ask, but I frequently don't setup anything that isn't convenient, or isn't useful traceroutes. I know of a number of very large ISPs that refuse such requests flat out. If you have one or more /8's, it gets to be a lot of work to manage 16 million reverse entries. Most places don't want to fully populate that. Maybe that's why few or none of the big ISP's are asking for this. Ok, lets play along. Assuming for the moment that in-addr could be trusted, lets look at the proposal: > > > > Perhaps you want to rethink that long PTR list. And at > > > > some point, it will be too big for a UDP reply. I hadn't even thought > > > > about that until I looked at your big list. Then what? > > > > > > Then we don't add other names. > > > > If you don't add them, then their reverse is broken, according to this > > proposal. > > 1) it isn't, according to this proposal Not every IP and domain needs forward and reverse? Really? I must have misunderstood the proposal somewhere. If you drop xcust.com from your PTR list, then when I see a message from xcust.com in my logs, and I do a forward/reverse/forward test on xcust.com, that test will fail. That violates this proposal, right? > 2) the software knows about reverse resolving first, as it gets the IP > address, looks up the PTR and validates the info by doing a forward > lookup of the name(s) it got from the PTR. > If it doesn't get names in the PTR it will not lookup these names. So if you have a thousand domains on one IP, and I have to do this test, I have to test a thousand domains? What happens if you have a PTR record (say ycust.com), that you haven't removed yet, and ycust.com has changed the forward address, so that when I test the forward (having gotten it on your list of PTRs), the test fails. Then what? I should keep doing the test until it succeeds? Or should I reject it as "not completely working according to this draft"? > 3) if UDP buffer is too small DNS software automatically switches to TCP > (or at least it should). Ok, but that adds a lot of overhead. Now we have to consider many more tcp connections on servers, leading to resource starvation. Sounds pretty complicated, for such a "simple" proposal. I'm not convinced that even if there were trust in in-addr, that your scheme works in common cases. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 8 22:19:00 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12390 for ; Tue, 8 Apr 2003 22:18:59 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h391u3RN001055 for ; Wed, 9 Apr 2003 03:56:03 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h391u3MX001054 for dnsop-outgoing; Wed, 9 Apr 2003 03:56:03 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h391u2RN001049 for ; Wed, 9 Apr 2003 03:56:02 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6CF3B18ED; Tue, 8 Apr 2003 21:55:56 -0400 (EDT) Date: Tue, 08 Apr 2003 21:55:56 -0400 From: Rob Austein To: dnsop@cafax.se Subject: Re: preconfigured keys or ds's In-Reply-To: <20030331132915.GA2912@atoom.net> References: <20030331132915.GA2912@atoom.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030409015556.6CF3B18ED@thrintun.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk Almost lost this one under other traffic. At Mon, 31 Mar 2003 15:29:15 +0200, Miek Gieben wrote: > > I would like to see the following documented, but I don't know for sure > if it is a dnssec or dnsop issue: > > The preconfigured keys for resolvers are large and are hard to compare > and read (by humans). DS records on the other hand are much smaller > and easier to handle. I think it would be better to preconfigure > DS records in stead of zone keys for resolvers. This is also how > my perl resolver works. This sounds like a reasonable implementation choice. > Where to put this? In the dnssec drafts or in a seperate dnsop BCP? The current DNSSECbis drafts don't talk about using trusted DS RRs as a starting point, only trusted KEYs. Given the last paragraph of section 2.4.1 of draft-ietf-dnsext-delegation-signer-13.txt, this looks like an oversight (probably mine, since I was probably the last person to work on the relevant text in the DNSSECbis drafts). So the DNSSECbis spec needs fixing, and I don't expect anybody to argue against the fix, but for process reasons it'd be best to post an explanation to namedroppers first, so I'll do that. Because of the above, at least part of this is a DNSEXT issue. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 9 10:59:15 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01853 for ; Wed, 9 Apr 2003 10:59:13 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39EZBRN007017 for ; Wed, 9 Apr 2003 16:35:11 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h39EZBOo007016 for dnsop-outgoing; Wed, 9 Apr 2003 16:35:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39EZ8RN007008 for ; Wed, 9 Apr 2003 16:35:08 +0200 (MEST) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F2C1A15210; Wed, 9 Apr 2003 23:35:46 +0900 (JST) Date: Wed, 09 Apr 2003 23:34:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Dean Anderson Cc: Rob Austein , Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-dnsop@cafax.se Precedence: bulk >>>>> On Fri, 4 Apr 2003 16:50:57 -0500 (EST), >>>>> Dean Anderson said: > I think you are misunderstanding the draft. (snip) >> 2. applications should not rely on reverse mapping for several >> purposes as they currently do. The discouraged purposes include: >> - rejecting ftp/telnet connections just due to the lack of reverse >> mapping or failure of reverse-forward-reverse match. >> - filtering rule in TCP wrappers due to the lack of reverse mapping >> - regarding e-mail messages as spam if the sender address does not >> have a reverse mapping > This is where you misunderstand. Although it seems contradictory to some > of the other language in the draft, the proponents don't think these are > inappropriate uses. The idea is to make everyone else change their usage > of reverse so that these kinds of uses won't deny large numbers regular, > ordinary users, as is the case now. I won't be surprised if I misunderstand the intention, and, in fact, your understanding and mine are different. So, I'd first like to hear from the author about the intention. Then we can go back to Rob's original question. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 9 13:49:32 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07659 for ; Wed, 9 Apr 2003 13:49:30 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39HQPRN008956 for ; Wed, 9 Apr 2003 19:26:25 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h39HQO9L008955 for dnsop-outgoing; Wed, 9 Apr 2003 19:26:24 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39HQNRN008950 for ; Wed, 9 Apr 2003 19:26:23 +0200 (MEST) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E68C115210; Thu, 10 Apr 2003 02:27:04 +0900 (JST) Date: Wed, 09 Apr 2003 23:14:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brad Knowles Cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: owner-dnsop@cafax.se Precedence: bulk >>>>> On Fri, 4 Apr 2003 09:57:49 +0200, >>>>> Brad Knowles said: >> But it is not very clear what the "proper operation" means. > "Proper operation" should also include any security-related functions. >> I picked >> up the examples of the discouraged usage from Section 3 based on my >> understanding of the draft. If I read it correctly, however, then I'd >> wonder why people who seemed to want rely on such a usage >> (e.g. rejecting ftp connections) are supporting the draft. > It's a matter of what is done by the programmer (assuming some > sort of "proper operation" based on rDNS), versus what may be done by > the administrator/operator (choosing to configure their machines in a > particular way so as to require correct rDNS before they allow you to > proceed). > We want to discourage programmers from depending on something > like this, while allowing owners/operators/administrators to choose > to configure their machines in whatever way they feel is appropriate. Okay, but I still see a subtle point. According to your message, - The draft wants to discourage programmers from depending on rDNS for "proper operation." - The draft will still (implicitly?) allow owners/operators/administrators to choose depending on rDNS for "proper operation." But, Does the draft also ***want to discourage*** owners/operators/administrators from depending on rDNS for proper operation? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 9 18:44:29 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19043 for ; Wed, 9 Apr 2003 18:44:27 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39MNkRN012237 for ; Thu, 10 Apr 2003 00:23:46 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h39MNkhs012236 for dnsop-outgoing; Thu, 10 Apr 2003 00:23:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39MNiRN012231 for ; Thu, 10 Apr 2003 00:23:45 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h39MNZpa061386; Wed, 9 Apr 2003 18:23:42 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> Date: Thu, 10 Apr 2003 00:19:10 +0200 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: Brad Knowles , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 11:14 PM +0900 2003/04/09, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > Okay, but I still see a subtle point. According to your message, > > - The draft wants to discourage programmers from depending on rDNS for > "proper operation." Correct. > - The draft will still (implicitly?) allow > owners/operators/administrators to choose depending on rDNS for > "proper operation." Also correct. > But, > > Does the draft also ***want to discourage*** > owners/operators/administrators from depending on rDNS for proper > operation? My view is that the draft should say something like: ... owners/operators/administrators MAY choose to configure their software to make use of rDNS as an added source of information when deciding whether or not to provide some service, or the level of service to be provided. However, rDNS (or the lack thereof) SHOULD NOT be used as the only source of information when making decisions of this sort. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 10 12:00:52 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24909 for ; Thu, 10 Apr 2003 12:00:50 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AFbDRN021775 for ; Thu, 10 Apr 2003 17:37:13 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AFbD5j021774 for dnsop-outgoing; Thu, 10 Apr 2003 17:37:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from fxshpr06.extra.daimlerchrysler.com (fxshpr08.extra.daimlerchrysler.com [129.9.80.165]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AFbBRN021769 for ; Thu, 10 Apr 2003 17:37:12 +0200 (MEST) Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.12.8/8.9.0) id h3AFYurv019162 for ; Thu, 10 Apr 2003 11:34:56 -0400 (EDT) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAABuaiBL; Thu, 10 Apr 03 11:34:56 -0400 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003041011370918461 for ; Thu, 10 Apr 2003 11:37:09 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h3AFb9Au018477 for ; Thu, 10 Apr 2003 11:37:09 -0400 (EDT) Received: from daimlerchrysler.com (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.12.8/8.9.1) with ESMTP id h3AFaMe9014467 for ; Thu, 10 Apr 2003 11:36:22 -0400 (EDT) Message-ID: <3E958F75.8177B781@daimlerchrysler.com> Date: Thu, 10 Apr 2003 11:36:22 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Brad Knowles wrote: > At 11:14 PM +0900 2003/04/09, JINMEI Tatuya / > =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > > > Okay, but I still see a subtle point. According to your message, > > > > - The draft wants to discourage programmers from depending on rDNS for > > "proper operation." > > Correct. > > > - The draft will still (implicitly?) allow > > owners/operators/administrators to choose depending on rDNS for > > "proper operation." > > Also correct. > > > But, > > > > Does the draft also ***want to discourage*** > > owners/operators/administrators from depending on rDNS for proper > > operation? > > My view is that the draft should say something like: > > ... owners/operators/administrators MAY choose to configure > their software to make use of rDNS as an added source of > information when deciding whether or not to provide some > service, or the level of service to be provided. > > However, rDNS (or the lack thereof) SHOULD NOT be used as > the only source of information when making decisions of > this sort. So, a little bogosity is fine, just don't go overboard (???) Come on, let's not dance around the point here. Either reverse DNS is bogus or it isn't. We should say what we mean and mean what we say. Dithering gets us nowhere. - Kevin #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 10 18:15:04 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09815 for ; Thu, 10 Apr 2003 18:15:03 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ALnwRN026251 for ; Thu, 10 Apr 2003 23:49:58 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ALnwsG026250 for dnsop-outgoing; Thu, 10 Apr 2003 23:49:58 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ALnuRN026245 for ; Thu, 10 Apr 2003 23:49:57 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3ALmSZe068677; Thu, 10 Apr 2003 17:49:54 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <3E958F75.8177B781@daimlerchrysler.com> References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> <3E958F75.8177B781@daimlerchrysler.com> Date: Thu, 10 Apr 2003 23:41:45 +0200 To: Kevin Darcy From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 11:36 AM -0400 2003/04/10, Kevin Darcy wrote: > Come on, let's not dance around the point here. Either reverse DNS >is bogus or > it isn't. We should say what we mean and mean what we say. Dithering gets us > nowhere. Reverse DNS is not the sole arbiter of what is good and what is not, and should not be treated as such. It remains a useful tool. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 10 18:30:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10527 for ; Thu, 10 Apr 2003 18:30:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AMDpRN026542 for ; Fri, 11 Apr 2003 00:13:51 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AMDp86026541 for dnsop-outgoing; Fri, 11 Apr 2003 00:13:51 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from fxodpr13.extra.daimlerchrysler.com (fxodpr13.extra.daimlerchrysler.com [129.9.82.74]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AMDoRN026536 for ; Fri, 11 Apr 2003 00:13:50 +0200 (MEST) Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id h3AMDow3024559 for ; Thu, 10 Apr 2003 18:13:50 -0400 (EDT) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAJMaW9V; Thu, 10 Apr 03 18:13:50 -0400 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003041018134928209 for ; Thu, 10 Apr 2003 18:13:49 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr2-hme0.shdc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h3AMDnkT002715 for ; Thu, 10 Apr 2003 18:13:49 -0400 (EDT) Received: from daimlerchrysler.com (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.12.8/8.9.1) with ESMTP id h3AMD1e9017011 for ; Thu, 10 Apr 2003 18:13:01 -0400 (EDT) Message-ID: <3E95EC6D.FED5CAA9@daimlerchrysler.com> Date: Thu, 10 Apr 2003 18:13:01 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt References: <200303311144.GAA02561@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit The draft is a bad draft. First of all, from a strictly editorial standpoint, there is much language in it which appears on the surface to be normative, but it is far from clear whether it is intended as such. I am referring to the lowercase "must"s and the "are permitted" language. But, more fundamentally, the draft basically comes off as saying "it's a bad idea to rely on X, but you have to (or _should_, see my above comment about pseudo-normative language) do X anyway", where X is, of course, "maintain reverse records". What's the point of this? Either it's a bad idea to use reverse records, for security/auditing/logging purposes, or it is not. If it's a bad idea, we shouldn't be recommending that the practice be continued. If it's *not* a bad idea, then it should be explained not only why it's a good idea, but specifically how the benefits outweigh the costs (false positives, etc.) of doing it. - Kevin Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations Working Group of the IETF. > > Title : Requiring DNS IN-ADDR Mapping > Author(s) : D. Senie > Filename : draft-ietf-dnsop-inaddr-required-04.txt > Pages : 5 > Date : 2003-3-28 > > Mapping of addresses to names has been a feature of DNS. Many sites, > implement it, many others don't. Some applications attempt to use it > as a part of a security strategy. The goal of this document is to > encourage proper deployment of address to name mappings, and provide > guidance for their use. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-inaddr-required-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-dnsop-inaddr-required-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-dnsop-inaddr-required-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <2003-3-28142222.I-D@ietf.org> #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 10 18:30:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10526 for ; Thu, 10 Apr 2003 18:30:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AMD9RN026531 for ; Fri, 11 Apr 2003 00:13:09 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AMD98O026530 for dnsop-outgoing; Fri, 11 Apr 2003 00:13:09 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from fxodpr13.extra.daimlerchrysler.com (fxodpr13.extra.daimlerchrysler.com [129.9.82.74]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AMD7RN026523 for ; Fri, 11 Apr 2003 00:13:07 +0200 (MEST) Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id h3AMD6iG024523 for ; Thu, 10 Apr 2003 18:13:06 -0400 (EDT) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAZ9aq5V; Thu, 10 Apr 03 18:13:06 -0400 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003041018130526773 for ; Thu, 10 Apr 2003 18:13:05 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h3AMD6Au022940 for ; Thu, 10 Apr 2003 18:13:06 -0400 (EDT) Received: from daimlerchrysler.com (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.12.8/8.9.1) with ESMTP id h3AMCHe9017003 for ; Thu, 10 Apr 2003 18:12:17 -0400 (EDT) Message-ID: <3E95EC41.B110DEA0@daimlerchrysler.com> Date: Thu, 10 Apr 2003 18:12:17 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> <3E958F75.8177B781@daimlerchrysler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Brad Knowles wrote: > At 11:36 AM -0400 2003/04/10, Kevin Darcy wrote: > > > Come on, let's not dance around the point here. Either reverse DNS > >is bogus or > > it isn't. We should say what we mean and mean what we say. Dithering gets us > > nowhere. > > Reverse DNS is not the sole arbiter of what is good and what is > not, and should not be treated as such. It remains a useful tool. For leaf nodes at least, the cost of its abuses outweighs the benefits of its uses. IMO. - Kevin #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 10 19:46:59 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12402 for ; Thu, 10 Apr 2003 19:46:58 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ANMvRN027210 for ; Fri, 11 Apr 2003 01:22:57 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ANMvoM027209 for dnsop-outgoing; Fri, 11 Apr 2003 01:22:57 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ANMuRN027204 for ; Fri, 11 Apr 2003 01:22:56 +0200 (MEST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.7/8.11.7) with ESMTP id h3ANMsq09131 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 10 Apr 2003 19:22:55 -0400 Message-Id: <5.2.0.9.2.20030410191637.02a9e9b8@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 10 Apr 2003 19:22:14 -0400 To: dnsop@cafax.se From: Daniel Senie Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <3E95EC6D.FED5CAA9@daimlerchrysler.com> References: <200303311144.GAA02561@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk At 06:13 PM 4/10/2003, you wrote: >The draft is a bad draft. First of all, from a strictly editorial >standpoint, there is much >language in it which appears on the surface to be normative, but it is far >from clear >whether it is intended as such. I am referring to the lowercase "must"s >and the "are >permitted" language. Thank you for that feedback. I'll improve the language in the next revision. >But, more fundamentally, the draft basically comes off as saying "it's a >bad idea to rely on >X, but you have to (or _should_, see my above comment about >pseudo-normative language) do X >anyway", where X is, of course, "maintain reverse records". What's the >point of this? The point is to: a) instruct application writers that Best Current Practice is to NOT rely on INADDR as a means of "authentication" and b) instruct Network Operators that Best Current Practice is to implement and provide INADDR. > Either >it's a bad idea to use reverse records, for security/auditing/logging >purposes, or it is >not. If it's a bad idea, we shouldn't be recommending that the practice be >continued. It is bad practice to make use of INADDR in an automated fashion within applications. It is however quite useful to have the INADDR information in logs and auditing as one of many clues when looking at historical information, and it is quite helpful to have functional INADDR information when trying to track down problems with routing, peering, etc. > If >it's *not* a bad idea, then it should be explained not only why it's a >good idea, but >specifically how the benefits outweigh the costs (false positives, etc.) >of doing it. What appears to be needed, if following my a & b above, is to strengthen the arguments on both sides, explaining at the same time why INADDR really SHOULD be implemented by network operators, and why application writers SHOULD NOT rely on this information. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 10 20:21:51 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13049 for ; Thu, 10 Apr 2003 20:21:51 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B00PRN027567 for ; Fri, 11 Apr 2003 02:00:25 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3B00PZC027566 for dnsop-outgoing; Fri, 11 Apr 2003 02:00:25 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B00NRN027561 for ; Fri, 11 Apr 2003 02:00:24 +0200 (MEST) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003041100001805100ne5oue>; Fri, 11 Apr 2003 00:00:18 +0000 Date: Thu, 10 Apr 2003 17:00:18 -0700 (PDT) From: Doug Barton To: Daniel Senie cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <5.2.0.9.2.20030410191637.02a9e9b8@mail.amaranth.net> Message-ID: <20030410164248.J91788@12-234-22-23.pyvrag.nggov.pbz> References: <200303311144.GAA02561@ietf.org> <5.2.0.9.2.20030410191637.02a9e9b8@mail.amaranth.net> Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Thu, 10 Apr 2003, Daniel Senie wrote: > What appears to be needed, if following my a & b above, is to strengthen > the arguments on both sides, explaining at the same time why INADDR really > SHOULD be implemented by network operators, and why application writers > SHOULD NOT rely on this information. I think this is getting closer to something reasonable, except that I'd change the last bit to say, "and why all consumers of INADDR information should be aware of the limitations of same." We're making a big mistake if we assume that we can speak authoritatively on the quality of all INADDR data on the net. I have a very high degree of confidence in the quality of the INADDR information on the hundreds of netblocks that I maintain because it's a priority in my enterprise. OTOH, I have a high degree of skepticism for someone else's data, and I act accordingly. In the FreeBSD project we have a saying, "Tools, not policy." I think that perspective is very valuable here as well. Doug -- I'm the kind of man a woman thinks she can change #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 10 21:27:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14552 for ; Thu, 10 Apr 2003 21:27:23 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B18lRN028165 for ; Fri, 11 Apr 2003 03:08:47 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3B18lUd028164 for dnsop-outgoing; Fri, 11 Apr 2003 03:08:47 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B18jRN028159 for ; Fri, 11 Apr 2003 03:08:46 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3B18QZQ080933; Thu, 10 Apr 2003 21:08:43 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <3E95EC41.B110DEA0@daimlerchrysler.com> References: <200303311144.GAA02561@ietf.org> <20030402223212.5111218E1@thrintun.hactrn.net> <3E958F75.8177B781@daimlerchrysler.com> <3E95EC41.B110DEA0@daimlerchrysler.com> Date: Fri, 11 Apr 2003 02:49:41 +0200 To: Kevin Darcy From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 6:12 PM -0400 2003/04/10, Kevin Darcy wrote: >> Reverse DNS is not the sole arbiter of what is good and what is >> not, and should not be treated as such. It remains a useful tool. > > For leaf nodes at least, the cost of its abuses outweighs the benefits of its > uses. IMO. Perhaps. Perhaps not. In your sphere of influence, you get to make that decision. However, neither you nor anyone else should be making the decision to prohibit others from making their own decision in this regard. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 10 22:15:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14551 for ; Thu, 10 Apr 2003 21:27:23 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B18nRN028174 for ; Fri, 11 Apr 2003 03:08:49 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3B18nLJ028173 for dnsop-outgoing; Fri, 11 Apr 2003 03:08:49 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B18lRN028168 for ; Fri, 11 Apr 2003 03:08:48 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3B18QZS080933; Thu, 10 Apr 2003 21:08:46 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <3E95EC6D.FED5CAA9@daimlerchrysler.com> References: <200303311144.GAA02561@ietf.org> <3E95EC6D.FED5CAA9@daimlerchrysler.com> Date: Fri, 11 Apr 2003 02:53:46 +0200 To: Kevin Darcy From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 6:13 PM -0400 2003/04/10, Kevin Darcy wrote: > The draft is a bad draft. Then propose something better. Or at least propose improvements to what's there. > But, more fundamentally, the draft basically comes off as saying "it's > a bad idea to rely on X, but you have to (or _should_, see my above > comment about pseudo-normative language) do X anyway", where X is, of > course, "maintain reverse records". What's the point of this? Either > it's a bad idea to use reverse records, for security/auditing/logging > purposes, or it is not. If it's a bad idea, we shouldn't be recommending > that the practice be continued. If it's *not* a bad idea, then it should > be explained not only why it's a good idea, but specifically how the > benefits outweigh the costs (false positives, etc.) of doing it. As said before, it's a bad idea to depend on rDNS as the sole source of information as to what is good or bad, but it remains a useful tool to help provide additional data when making decisions. Therefore, rDNS SHOULD be maintained for both IPv4 and IPv6 (either manually or using some sort of automated tools). What I believe that we are trying to discourage is the programmers who decide to depend on rDNS as the sole arbiter of all goodness. This is the bad behaviour that should be eliminated. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 11 04:47:19 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04107 for ; Fri, 11 Apr 2003 04:47:19 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B8RQRN002167 for ; Fri, 11 Apr 2003 10:27:26 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3B8RPYa002166 for dnsop-outgoing; Fri, 11 Apr 2003 10:27:25 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from fedex.is.co.za (fedex.is.co.za [196.4.160.243]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B8RHRN002161 for ; Fri, 11 Apr 2003 10:27:24 +0200 (MEST) Received: from hypatia.dns.net (c4-ndf-87.dial-up.net [196.34.159.215]) by fedex.is.co.za (Postfix) with ESMTP id 45D14B8720; Fri, 11 Apr 2003 10:27:06 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id h3B8T0R25733; Fri, 11 Apr 2003 10:29:00 +0200 Date: Fri, 11 Apr 2003 10:29:00 +0200 From: Andras Salamon To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <20030411082900.GA25683@dns.net> References: <200303311144.GAA02561@ietf.org> <5.2.0.9.2.20030410191637.02a9e9b8@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20030410191637.02a9e9b8@mail.amaranth.net> User-Agent: Mutt/1.4.1i Sender: owner-dnsop@cafax.se Precedence: bulk On Thu, Apr 10, 2003 at 07:22:14PM -0400, Daniel Senie wrote: > The point is to: > a) instruct application writers that Best Current Practice is to NOT rely > on INADDR as a means of "authentication" and > > b) instruct Network Operators that Best Current Practice is to implement > and provide INADDR. This is a nice crisp way to summarise the draft. In an IN-ADDR context, this is just a restatement of the usual `conservative in generation, liberal in acceptance' credo of the IETF, so I don't think one can disagree with it without also disagreeing with the basic principles of the IETF. It would be useful to emphasize this specific wording in the draft, perhaps in the abstract or as a preamble to section 4. -- Andras Salamon andras@dns.net #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 11 11:22:30 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17140 for ; Fri, 11 Apr 2003 11:22:29 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BEsxRN005849 for ; Fri, 11 Apr 2003 16:54:59 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3BEsxmW005848 for dnsop-outgoing; Fri, 11 Apr 2003 16:54:59 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from momotombo.TechFak.Uni-Bielefeld.DE (momotombo.TechFak.Uni-Bielefeld.DE [129.70.136.107]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BEsvRN005843 for ; Fri, 11 Apr 2003 16:54:58 +0200 (MEST) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id h3BEsvQ00505 for ; Fri, 11 Apr 2003 16:54:57 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id h3BEsvV07367 for ; Fri, 11 Apr 2003 16:54:57 +0200 (MEST) Message-Id: <200304111454.h3BEsvV07367@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-reply-to: Your message of "Fri, 11 Apr 2003 10:29:00 +0200." <20030411082900.GA25683@dns.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Fri, 11 Apr 2003 16:54:56 +0200 From: Peter Koch Sender: owner-dnsop@cafax.se Precedence: bulk Andras Salamon wrote: > This is a nice crisp way to summarise the draft. In an IN-ADDR context, > this is just a restatement of the usual `conservative in generation, > liberal in acceptance' credo of the IETF, so I don't think one can > disagree with it without also disagreeing with the basic principles of > the IETF. but it leads to these typical no-win situations in case of problems. If one end "relies" upon proper reverse mapping and the other end does not provide for it, would you think both are equally wrong? -Peter #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 11 12:55:28 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21070 for ; Fri, 11 Apr 2003 12:55:26 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BGV0RN006618 for ; Fri, 11 Apr 2003 18:31:00 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3BGV0EX006617 for dnsop-outgoing; Fri, 11 Apr 2003 18:31:00 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BGUwRN006612 for ; Fri, 11 Apr 2003 18:30:59 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA20087; Fri, 11 Apr 2003 12:26:02 -0400 Date: Fri, 11 Apr 2003 12:26:11 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Daniel Senie cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <5.2.0.9.2.20030410191637.02a9e9b8@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk > The point is to: > > a) instruct application writers that Best Current Practice is to NOT rely > on INADDR as a means of "authentication" and Of course, the obvious flaw is that most if not all of the proponents don't see any of the uses described in Section 3 as being "authentication". The only thing they acknowledge as being "authentication" seems to be the BSD r-commands. > b) instruct Network Operators that Best Current Practice is to implement > and provide INADDR. For what purpose? So that the persons doing activities described in Section 3 can do so? They aren't doing these things now, largely, only because so many sites don't maintain reverse records to their liking. I have an idea. Some people have created nameserver extensions that automatically create an A record response to queries of a certain form h-.theirzone, and likewise handle in-addr.arpa queries to return names of this format. These responses are generated from the contents of the query, so no maintanence is required. Lets just extend and standardize this idea and create a f-addr.arpa zone. The purpose of this zone is to automatically generate A records for queries of the form h----.f-addr.arpa. The A record returned will have to form: 'IN A ---' Since we know the answer from the contents of both these queries, we can push this functionality into the resolver, so that the nameserver isn't bothered having to respond to these trivial queries. With a couple special cases added to the resolver, everyone is happy. Much load is removed from nameservers, and the people who want consistent responses to in-addr, have them. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 11 21:35:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07496 for ; Fri, 11 Apr 2003 21:35:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3C1CERN010610 for ; Sat, 12 Apr 2003 03:12:14 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3C1CEaB010609 for dnsop-outgoing; Sat, 12 Apr 2003 03:12:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3C1CCRN010604 for ; Sat, 12 Apr 2003 03:12:12 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3C1BBZU089868; Fri, 11 Apr 2003 21:11:56 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Sat, 12 Apr 2003 02:58:04 +0200 To: Dean Anderson From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: Daniel Senie , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 12:26 PM -0400 2003/04/11, Dean Anderson wrote: > I have an idea. Some people have created nameserver extensions that > automatically create an A record response to queries of a certain form > h-.theirzone, and likewise handle in-addr.arpa queries to > return names of this format. These responses are generated from the > contents of the query, so no maintanence is required. Doesn't work. This removes control over the data from the person who has been assigned the space. > Since we know the answer from the contents of both these queries, we can > push this functionality into the resolver, so that the nameserver isn't > bothered having to respond to these trivial queries. With a couple > special cases added to the resolver, everyone is happy. Much load is > removed from nameservers, and the people who want consistent responses to > in-addr, have them. Also doesn't work. Since you are so into making optimizations, let's try this -- since everything liquid or solid going into your body is only going to come back out again, why not optimize this process and eliminate both the entrance and the exit? Sure would make things a lot cleaner, in a whole lot of ways. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 11 23:07:50 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08726 for ; Fri, 11 Apr 2003 23:07:48 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3C2k0RN012091 for ; Sat, 12 Apr 2003 04:46:00 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3C2k0h1012090 for dnsop-outgoing; Sat, 12 Apr 2003 04:46:00 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3C2jwRN012085 for ; Sat, 12 Apr 2003 04:45:59 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id WAA16104; Fri, 11 Apr 2003 22:41:17 -0400 Date: Fri, 11 Apr 2003 22:41:27 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Brad Knowles cc: Daniel Senie , Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Sat, 12 Apr 2003, Brad Knowles wrote: > At 12:26 PM -0400 2003/04/11, Dean Anderson wrote: > > > I have an idea. Some people have created nameserver extensions that > > automatically create an A record response to queries of a certain form > > h-.theirzone, and likewise handle in-addr.arpa queries to > > return names of this format. These responses are generated from the > > contents of the query, so no maintanence is required. > > Doesn't work. This removes control over the data from the person > who has been assigned the space. Who needs control when you have consistency? > > Since we know the answer from the contents of both these queries, we can > > push this functionality into the resolver, so that the nameserver isn't > > bothered having to respond to these trivial queries. With a couple > > special cases added to the resolver, everyone is happy. Much load is > > removed from nameservers, and the people who want consistent responses to > > in-addr, have them. > > Also doesn't work. Why? Are you saying this can't be programmed into the resolver? Its seems that when you say "doesn't work", you really mean "I don't want that". (followed by wah, wah, wah). > Since you are so into making optimizations, let's try this -- > since everything liquid or solid going into your body is only going > to come back out again, why not optimize this process and eliminate > both the entrance and the exit? Sure would make things a lot > cleaner, in a whole lot of ways. I have to give credit for this idea to you: Entrance and Exit are the same, so they can be optimized away. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Apr 12 06:31:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25099 for ; Sat, 12 Apr 2003 06:31:37 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3CA9iRN014665 for ; Sat, 12 Apr 2003 12:09:44 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3CA9ijh014664 for dnsop-outgoing; Sat, 12 Apr 2003 12:09:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3CA9gRN014659 for ; Sat, 12 Apr 2003 12:09:43 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3CA9cZK039127; Sat, 12 Apr 2003 06:09:38 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Sat, 12 Apr 2003 12:08:47 +0200 To: Dean Anderson From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: Brad Knowles , Daniel Senie , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 10:41 PM -0400 2003/04/11, Dean Anderson wrote: >> Doesn't work. This removes control over the data from the person >> who has been assigned the space. > > Who needs control when you have consistency? Okay, so if someone were to fire a gun at your head every second precisely on the second, that would be okay because they have consistency, even though you don't have control? >> Also doesn't work. > > Why? Are you saying this can't be programmed into the resolver? > > Its seems that when you say "doesn't work", you really mean "I don't want > that". (followed by wah, wah, wah). See above. It is a further "optimization" of an "optimization" that is proven to be false. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Apr 12 10:36:11 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29016 for ; Sat, 12 Apr 2003 10:36:10 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3CEB1RN015899 for ; Sat, 12 Apr 2003 16:11:01 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3CEB1R5015898 for dnsop-outgoing; Sat, 12 Apr 2003 16:11:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3CEAxRN015893 for ; Sat, 12 Apr 2003 16:11:00 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id KAA24496; Sat, 12 Apr 2003 10:06:19 -0400 Date: Sat, 12 Apr 2003 10:06:29 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Brad Knowles cc: Daniel Senie , Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Sat, 12 Apr 2003, Brad Knowles wrote: > At 10:41 PM -0400 2003/04/11, Dean Anderson wrote: > > >> Doesn't work. This removes control over the data from the person > >> who has been assigned the space. > > > > Who needs control when you have consistency? > > Okay, so if someone were to fire a gun at your head every second > precisely on the second, that would be okay because they have > consistency, even though you don't have control? As long as they consistently fire in exactly the same direction, at exactly the same time, yes. I can duck--they taught me to do that at MIT. Actually, they taught me not to pee on my fingers, but that's another (but strangely similar) story... Never mind, you wouldn't understand. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Apr 12 17:38:25 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05231 for ; Sat, 12 Apr 2003 17:38:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3CLCARN018060 for ; Sat, 12 Apr 2003 23:12:10 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3CLCADa018059 for dnsop-outgoing; Sat, 12 Apr 2003 23:12:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3CLC9RN018054 for ; Sat, 12 Apr 2003 23:12:10 +0200 (MEST) Received: from mine.club-internet.fr (f12m-6-42.d1.club-internet.fr [212.195.69.42]) by relay-1m.club-internet.fr (Postfix) with ESMTP id C35DE16CA for ; Sat, 12 Apr 2003 23:12:06 +0200 (CEST) Message-Id: <5.2.0.9.0.20030412224731.02fc8dc0@mail.club-internet.fr> X-Sender: jefsey@mail.club-internet.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 12 Apr 2003 22:56:55 +0200 To: dnsop@cafax.se From: "J-F C. (Jefsey) Morfin" Subject: were there global name space oriented work? In-Reply-To: <200304081410.h38EAVM16474@boreas.isi.edu> References: <02a601c2fda6$00865fc0$7207e29f@cnniczh> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk On 16:10 08/04/03, Bill Manning said: > that is correct. if you want to explore native IPv6 resolution, you > should look at the testbed. outputs from the testbed are used as input > to the ICANN process so tht eventually we might see IPv6 support in the > root. In working on the dot-root test bed concept and on my attempt of a global name space draft, I came across perspectives supporting the different adressing schemes: internet, telephone, domotic, radio/TV frequencies (channels), postal adressing/EDI, Teletex, telematics as a single homogenous continuity. With a DNS consistent semantic (but based on user centric and on multilateral concepts as well as on the domain hierarchy). It seems it is not so far from the initial "internetting" 1973 specs, 1978 intl file organization, 83/86 namespace/X121 support, SMS usage, user demands. Obviously the name server system would use a quite different structure (BTW free from DoS) but Bind would still work the same. Yet security/stability could be simplified, increased and/or differently adressed? Nothing formalized yet and by far. But I would be interested to know if some works are/were carried into such directions? I was told there was an attempt by the DoD to integrate X121 at a given time? Were could I get an ENUM situation brief? Thanks to anyone with suggestions/comments. jfc >% Thanks Bill, Paul, >% >% I have another question. >% >% Some gTLDs and ccTLDs have IPv6 DNS now. While current root zone >% doesn't contain IPv6 referral (glue for 'AAAA') for these TLD name servers. >% >% Does this mean TLD IPv6 servers will not be asked in current DNS resolution, >% until their IPv6 addresses are added in root zone file? >% Thanks! >% >% BRs >% >% Zhang Hong >% >% ----- Original Message ----- >% From: "Bill Manning" >% To: >% Cc: >% Sent: Tuesday, April 08, 2003 3:00 PM >% Subject: Re: Are there any ipv6 root servers? >% >% >% > % Hello, >% > % >% > % Are there any root servers that have ipv6 address and support ipv6 DNS? >% > % I heard that f-root and h-root have supported ipv6, but not sure. >% > % Thanks! >% > >% > several do. www.root-servers.org list addresses for f and h >% > others have IPv6 addresses but have chosen to not list them on >% > that site at this time. >% > >% > there is no formal support for IPv6 transport in the production >% > Internet at this time. It is possible to hand modify the hints >% > file to add these records. There is also a testbed that has native IPv6 >% > support (and has had for about 5 years), supports IDN lables and >% > DNSSEC signed zones. www.rs.net if you want to play >% > >% > >% > --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). >% > #---------------------------------------------------------------------- >% > # To unsubscribe, send a message to . >% >% >% #---------------------------------------------------------------------- >% # To unsubscribe, send a message to . >% > > >-- >--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). > >#---------------------------------------------------------------------- ># To unsubscribe, send a message to . > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03 #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 14 13:43:57 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13763 for ; Mon, 14 Apr 2003 13:43:55 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3EHOIRN007964 for ; Mon, 14 Apr 2003 19:24:18 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3EHOIES007963 for dnsop-outgoing; Mon, 14 Apr 2003 19:24:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from fxodpr13.extra.daimlerchrysler.com (fxodpr13.extra.daimlerchrysler.com [129.9.82.74]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3EHOGRN007958 for ; Mon, 14 Apr 2003 19:24:16 +0200 (MEST) Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id h3EHOCKK001591 for ; Mon, 14 Apr 2003 13:24:12 -0400 (EDT) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAApiaWgd; Mon, 14 Apr 03 13:24:12 -0400 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003041413241121912 for ; Mon, 14 Apr 2003 13:24:11 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h3EHOC4D028431 for ; Mon, 14 Apr 2003 13:24:12 -0400 (EDT) Received: from daimlerchrysler.com (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.12.8/8.9.1) with ESMTP id h3EHNOe9018026 for ; Mon, 14 Apr 2003 13:23:24 -0400 (EDT) Message-ID: <3E9AEE8C.C82F45EF@daimlerchrysler.com> Date: Mon, 14 Apr 2003 13:23:24 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt References: <200303311144.GAA02561@ietf.org> <3E95EC6D.FED5CAA9@daimlerchrysler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Brad Knowles wrote: > At 6:13 PM -0400 2003/04/10, Kevin Darcy wrote: > > > The draft is a bad draft. > > Then propose something better. Or at least propose improvements > to what's there. "Accept what is proposed or propose something yourself" is a false dilemma As a third alternative, we could do *nothing* and let reverse DNS wither away of its own accord, as it becomes less and less reliable over time. If we want to publish a document that says *only* to not rely on reverse DNS, I'd be OK with that. It's the "X is bad, but still keep on supporting X", schizoid part that I'm having a problem with... - Kevin #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 17 10:09:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22037 for ; Thu, 17 Apr 2003 10:09:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HDnsRN016837 for ; Thu, 17 Apr 2003 15:49:54 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HDnrBO016836 for dnsop-outgoing; Thu, 17 Apr 2003 15:49:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HDnqRN016831 for ; Thu, 17 Apr 2003 15:49:53 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3HDnnhv059044; Thu, 17 Apr 2003 09:49:50 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <3E9AEE8C.C82F45EF@daimlerchrysler.com> References: <200303311144.GAA02561@ietf.org> <3E95EC6D.FED5CAA9@daimlerchrysler.com> <3E9AEE8C.C82F45EF@daimlerchrysler.com> Date: Thu, 17 Apr 2003 14:48:45 +0200 To: Kevin Darcy From: Brad Knowles Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 1:23 PM -0400 2003/04/14, Kevin Darcy wrote: > It's the "X is bad, but still keep on supporting X", > schizoid part that I'm having a problem with... Therein lies the problem. We're not saying "X is bad, but still keep on supporting X". We're saying "X *by itself* is bad -- you should not use X this way. X is useful when utilized correctly, so you should keep supporting X". -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 21 01:53:25 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24108 for ; Mon, 21 Apr 2003 01:53:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3L5WnRN021705 for ; Mon, 21 Apr 2003 07:32:49 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3L5Wn0i021704 for dnsop-outgoing; Mon, 21 Apr 2003 07:32:49 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3L5WjRN021699 for ; Mon, 21 Apr 2003 07:32:46 +0200 (MEST) Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h3L5j9F29452; Mon, 21 Apr 2003 14:45:10 +0900 (KST) Message-ID: <006901c307c7$565f0520$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "DNSOP WG" Cc: "autonet" Subject: Proposal for IPv6 DNS Autoconfiguration Date: Mon, 21 Apr 2003 14:32:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id h3L5WlRN021700 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hello, dnsop members! I posted my new draft of DNS autoconfiguration in IPv6 host, of which title is "IPv6 Router Advertisement based DNS Autoconfiguration". http://www.ietf.org/internet-drafts/draft-jeong-ipv6-ra-dns-autoconf-00.txt In this draft, I descibed four configurations related to DNS as follows; a) Advertisement of domain and DNS server in a site b) Auto-generation of host DNS name based on the known domain c) Auto-registration of the host DNS name with the known DNS server d) Auto-configuration of recursive DNS server for DNS name resolution My scheme is based on IPv6 Router Advertisement (RA). I think it can be used together with DHCPv6's DNS-related options. I welcome your comments on my idea. I would like to know this draft is valuable enough to discuss as working group draft. Thanks a lot. Regards, Jaehoon #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 21 07:53:57 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11030 for ; Mon, 21 Apr 2003 07:53:56 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LBY7RN023462 for ; Mon, 21 Apr 2003 13:34:07 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LBY7aA023461 for dnsop-outgoing; Mon, 21 Apr 2003 13:34:07 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LBY6RN023456 for ; Mon, 21 Apr 2003 13:34:06 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09694; Mon, 21 Apr 2003 07:31:20 -0400 (EDT) Message-Id: <200304211131.HAA09694@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: dnsop@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-jeong-ipv6-ra-dns-autoconf-00.txt Date: Mon, 21 Apr 2003 07:31:20 -0400 Sender: owner-dnsop@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Router Advertisement based DNS Autoconfiguration Author(s) : J. Jeong et al. Filename : draft-jeong-ipv6-ra-dns-autoconf-00.txt Pages : 11 Date : 2003-4-18 This document specifies the steps a node takes in deciding how to autoconfigure its domain name per interface in IP version 6 and the address of recursive DNS server. The autoconfiguration process includes a node's creating a domain name for its global address, verifying the uniqueness of the name in the domain where it is placed and registering both the regular domain name and inverse domain name information of the node with DNS server automatically. Also, it autoconfigures the address of recursive DNS server for DNS name resolution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeong-ipv6-ra-dns-autoconf-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jeong-ipv6-ra-dns-autoconf-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jeong-ipv6-ra-dns-autoconf-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-18131718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jeong-ipv6-ra-dns-autoconf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jeong-ipv6-ra-dns-autoconf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-18131718.I-D@ietf.org> --OtherAccess-- --NextPart-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 22 20:25:18 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02472 for ; Tue, 22 Apr 2003 20:25:17 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3N00ERN014274 for ; Wed, 23 Apr 2003 02:00:14 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3N00EkB014273 for dnsop-outgoing; Wed, 23 Apr 2003 02:00:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout2.samsung.com (u25.gpu114.samsung.co.kr [203.254.224.25]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3N00BRN014267 for ; Wed, 23 Apr 2003 02:00:12 +0200 (MEST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HDR00K47S090T@mailout2.samsung.com> for dnsop@cafax.se; Wed, 23 Apr 2003 09:00:09 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HDR00F5ORZ9PQ@mailout2.samsung.com> for dnsop@cafax.se; Wed, 23 Apr 2003 08:59:33 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HDR007F7RZ8IA@mmp1.samsung.com> for dnsop@cafax.se; Wed, 23 Apr 2003 08:59:33 +0900 (KST) Date: Wed, 23 Apr 2003 08:58:31 +0900 From: Soohong Daniel Park Subject: IPv6 Extensions for DNS Plug and Play To: dnsop@cafax.se, namedroppers@ops.ietf.org Cc: "'Syam Madanapalli'" , "'Soohong Daniel Park'" Message-id: <00d101c3092b$13c95070$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_gLeQvODsI9ILIdugDRNyDw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-dnsop@cafax.se Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_gLeQvODsI9ILIdugDRNyDw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi folks This initial draft was spoke in 56 IETF meeting. After then this draft is revised and added many section. Look into it and let me know your comments. --------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Extensions for DNS Plug and Play Author(s) : S. Park, S. Madanapalli Filename : draft-park-ipv6-extensions-dns-pnp-00.txt Pages : 30 Date : 2003-4-21 This document proposes automatic configuration of domain name (FQDN) for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as a part of IPv6 plug and play feature. 6DNAC allows the automatic registration of domain name and corresponding IPv6 Addresses with the DNS server. In order to provide 6DNAC function, Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAC does not require any changes to the existing DNS system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-ipv6-extensions-dns-pnp-0 0.txt Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics Tel:+82-31-200-4508 Fax:+82-31-200-3147 mailto:soohong.park@samsung.com --Boundary_(ID_gLeQvODsI9ILIdugDRNyDw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT IPv6 Extensions for DNS Plug and Play

Hi folks

This initial draft was spoke in 56 IETF meeting.
After then this draft is revised and added many section.
Look into it and let me know your comments.

---------------------------
A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : IPv6 Extensions for DNS Plug and Play
        Author(s)       : S. Park, S. Madanapalli
        Filename        : draft-park-ipv6-extensions-dns-pnp-00.txt
        Pages           : 30
        Date            : 2003-4-21
       
This document proposes automatic configuration of domain name (FQDN) for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as a part of IPv6 plug and play feature. 6DNAC allows the automatic registration of domain name and corresponding IPv6 Addresses with the DNS server. In order to provide 6DNAC function, Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAC does not require any changes to the existing DNS system.

A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-ipv6-extensions-dns-pnp-00.txt







Daniel (Soohong Daniel Park)
Mobile Platform Lab,SAMSUNG Electronics
Tel:+82-31-200-4508 Fax:+82-31-200-3147
mailto:soohong.park@samsung.com

--Boundary_(ID_gLeQvODsI9ILIdugDRNyDw)-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From vFUSIzWPanK@emn.fr Wed Apr 23 07:09:37 2003 Received: from 61.11.33.38 (M010P024.adsl.highway.telekom.at [62.47.169.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11687 for ; Wed, 23 Apr 2003 07:09:30 -0400 (EDT) Date: Wed, 23 Apr 2003 07:09:30 -0400 (EDT) X-Rim: dVAxl63OTDHTJOUh8BbKiz--40883364 Received: from 113.79.144.188 (HELO med.kyushu-u.ac.jp) (113.79.144.188) by maths.abdn.ac.uk with ESMTP id for ; Wed, 5 Mar 2003 02:03:11 -0600 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Message-Id: <5.0.0.358953006.CQzmGqkq@ksk.sala.se> To: "dnsop-archive@lists.ietf.org" From: "Melonie Hubbs" Subject: ADV: 100% safe sexual enhancement. Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="==CimUdo6VEFDz" kAsGeHD07h3zKoukssZqDFRea6DpRHSKMLG4NqPwvLmRh input of technology professionals - will cut through the Newspeak fog and --==CimUdo6VEFDz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 Cgo8aHRtbD4KPGhlYWQ+PC9oZWFkPgo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIj4KPGNlbnRl cj4KPGJyPgo8IS0tMTQ5NzIzMzc1OC0tPjxhIGhyZWY9Imh0dHA6Ly8xOTMuMjMxLjI0OC43 Mi92My9pbmRleC5waHA/ZWcyMDAyIj48aW1nIGJvcmRlcj0wIHNyYz0iaHR0cDovLzE5My4y MzEuMjQ4Ljc5L2dwMS5naWYiID48L2E+Cjxicj48YnI+Cjxmb250IHNpemU9Ii0yIj4KVGhp cyBvZmZlciBpcyBicm91Z2h0IHRvIHlvdSBieSBIZWFsdGggYW5kIEZpdCAzMDAwLCBJbmMu IElmIHlvdSB3aXNoIHRvIGJlIHJlbW92ZWQgYW5kIG5vdCByZWNlaXZlIG1haWwgZnJvbSB1 cywgcGxlYXNlIDxhIGhyZWY9Imh0dHA6Ly8xOTMuMjMxLjI0OC43Mi9yZW1vdmUucGhwP2Vn MjAwMiI+Z28gaGVyZS48L2E+Cjxicj4KPC9mb250Pgo8L2NlbnRlcj4KPCEtLTU1MjQ0NjA4 OC0tPgo8IS0tCnRlc3RpbmcgcHJpb3IgdG8gcmVsZWFzZS4KIldoYXQgY2l0eSdzIHBvbGlj ZSBmb3JjZSBkaWQgQ2hhcmxpZSBDaGFuIHdvcmsgd2l0aD8iICJIb25vbHVsdSIKLS0+Cjwv Ym9keT48L2h0bWw+Cgo= --==CimUdo6VEFDz-- From owner-dnsop@cafax.se Wed Apr 23 21:11:32 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16956 for ; Wed, 23 Apr 2003 21:11:31 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3O0pWRN029380 for ; Thu, 24 Apr 2003 02:51:32 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3O0pWMg029379 for dnsop-outgoing; Thu, 24 Apr 2003 02:51:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3O0pURN029374 for ; Thu, 24 Apr 2003 02:51:31 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 4FFB6137F04 for ; Wed, 23 Apr 2003 17:51:29 -0700 (PDT) Date: Wed, 23 Apr 2003 17:51:26 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: draft-ietf-dnsop-serverid-01.txt From: David Conrad To: dnsop@cafax.se Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit So, this draft is going to expire soonish. Is there anything I need to do to it? I don't remember any additional comments since Atlanta. Can it be pushed to last call? Tnx, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 24 18:42:59 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09300 for ; Thu, 24 Apr 2003 18:42:58 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3OMLiRN012275 for ; Fri, 25 Apr 2003 00:21:44 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3OMLiGg012274 for dnsop-outgoing; Fri, 25 Apr 2003 00:21:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from slimsixten.besserwisser.org (slimsixten.besserwisser.org [213.212.3.212]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3OMLhRN012269 for ; Fri, 25 Apr 2003 00:21:44 +0200 (MEST) Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h3OMLiS9006442 for ; Fri, 25 Apr 2003 00:21:45 +0200 (CEST) Date: Thu, 24 Apr 2003 17:58:12 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <166260000.1051199892@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1848262778==========" Sender: owner-dnsop@cafax.se Precedence: bulk --==========1848262778========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Tuesday, April 08, 2003 19:04:35 -0400 Dean Anderson wrote: >> > Really? What is it? >>=20 >> Know your tools and ask your LIRs. >=20 > Most registries won't give this information out anymore. (for the obvious > reason). One can't easily get copies of the com or net zones (to look = for > domains with certain nameservers). Hey, come on. All the RIRen have public whois. You can pretty much find out anything about any network that is routed on the Net (and a bunch of others, too) via whois queries. The format is not coherent, it is not scalable, but it is there.=20 That together with a decent public looking-glass will tell the interested person pretty much anything you might want to know.=20 DNS need not be applied in this process, it is merely the pretty-traceroute icing on an already sweet cake of data.=20 So, how about talking DNS operations again, for a change?=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1848262778========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+qAmX02/pMZDM1cURAnrnAJsFqBQngKKsUbkN5z4jfPyaRDYGVwCfVVL/ Fw9riTs15OcE2nxEXaZQdQ8= =nKX8 -----END PGP SIGNATURE----- --==========1848262778==========-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Apr 24 23:14:41 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13997 for ; Thu, 24 Apr 2003 23:14:39 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3P2pmRN015482 for ; Fri, 25 Apr 2003 04:51:48 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3P2pmdw015481 for dnsop-outgoing; Fri, 25 Apr 2003 04:51:48 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3P2pkRN015476 for ; Fri, 25 Apr 2003 04:51:47 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id WAA07424; Thu, 24 Apr 2003 22:46:27 -0400 Date: Thu, 24 Apr 2003 22:46:52 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <166260000.1051199892@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.cafax.se id h3P2plRN015477 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit On Thu, 24 Apr 2003, [ISO-8859-1] Måns Nilsson wrote: > > > --On Tuesday, April 08, 2003 19:04:35 -0400 Dean Anderson > wrote: > >> > Really? What is it? > >> > >> Know your tools and ask your LIRs. > > > > Most registries won't give this information out anymore. (for the obvious > > reason). One can't easily get copies of the com or net zones (to look for > > domains with certain nameservers). > > Hey, come on. All the RIRen have public whois. You can pretty much find out > anything about any network that is routed on the Net (and a bunch of > others, too) via whois queries. The format is not coherent, it is not > scalable, but it is there. > > That together with a decent public looking-glass will tell the interested > person pretty much anything you might want to know. You can find out about the ISP, which is appropriate. You cannot find out about the ISP's customers, which is not always appropriate. > DNS need not be applied in this process, it is merely the pretty-traceroute > icing on an already sweet cake of data. I agree it is pretty traceroute icing. I also agree that DNS need not be applied to this process. Maybe we are getting somewhere. --Dean #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 25 01:51:08 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16493 for ; Fri, 25 Apr 2003 01:51:07 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3P5WJRN016485 for ; Fri, 25 Apr 2003 07:32:19 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3P5WJtY016484 for dnsop-outgoing; Fri, 25 Apr 2003 07:32:19 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from slimsixten.besserwisser.org (slimsixten.besserwisser.org [213.212.3.212]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3P5WIRN016479 for ; Fri, 25 Apr 2003 07:32:18 +0200 (MEST) Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h3P5WHS7005746 for ; Fri, 25 Apr 2003 07:32:17 +0200 (CEST) Date: Fri, 25 Apr 2003 07:32:16 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <377410000.1051248736@localhost.besserwisser.org> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1097735387==========" Sender: owner-dnsop@cafax.se Precedence: bulk --==========1097735387========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Thursday, April 24, 2003 22:46:52 -0400 Dean Anderson wrote: >> That together with a decent public looking-glass will tell the = interested >> person pretty much anything you might want to know. >=20 > You can find out about the ISP, which is appropriate. You cannot find out > about the ISP's customers, which is not always appropriate. Worng. Let's look at the source addres of your mail and mine.=20 $ whois -a 130.105.11.4 OrgName: Open Software Foundation=20 OrgID: OSF Address: 529 Main St. City: Boston StateProv: MA PostalCode: 02129 Country: US NetRange: 130.105.0.0 - 130.105.255.255=20 CIDR: 130.105.0.0/16=20 NetName: OSF NetHandle: NET-130-105-0-0-1 Parent: NET-130-0-0-0-0 NetType: Direct Allocation NameServer: STARSHIP.AV8.COM NameServer: CONCORDE.AV8.COM Comment: =20 RegDate: 1988-07-20 Updated: 1998-12-21 TechHandle: DA31-ARIN TechName: Anderson, Dean A. TechPhone: +1-617-242-3091 TechEmail: dean@av8.com=20 # ARIN WHOIS database, last updated 2003-04-24 20:10 # Enter ? for additional hints on searching ARIN's WHOIS database. ARIN needs a step for the route info too, so we get the source AS from BGP, and find the following AS-path: 2603 1239 2548 11784 which is Nordunet, Sprint, Allegiance Telecom and finally you.=20 $ whois -a AS11784=20 OrgName: Plain Aivation, Inc=20 OrgID: PLAINA=20 Address: P.O. Box 7286 City: Nashua StateProv: NH PostalCode: 03060 Country: US ASNumber: 11784 =20 ASName: ASN-AV8=20 ASHandle: AS11784=20 Comment: =20 RegDate: 1998-12-17 Updated: 1998-12-17 TechHandle: DA31-ARIN TechName: Anderson, Dean A. TechPhone: +1-617-242-3091 TechEmail: dean@av8.com # ARIN WHOIS database, last updated 2003-04-24 20:10 # Enter ? for additional hints on searching ARIN's WHOIS database. and over to mine:=20 $ whois -r 213.212.3.212=20 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 213.212.3.192 - 213.212.3.223 netname: MANSNILSSON descr: Mans Nilsson country: SE admin-c: MN1334-RIPE tech-c: MN1334-RIPE status: ASSIGNED PA mnt-by: DPNOC changed: registry@dataphone.net 20000203 source: RIPE route: 213.212.0.0/18 descr: Dataphone Communication Networks origin: AS8289 mnt-by: DPNOC changed: registry@dataphone.net 19990914 source: RIPE person: Mans Nilsson address: Royal Institute of Technology address: KTH/SUNET address: S-100 44 STOCKHOLM address: SE phone: +46 8 790 60 00 fax-no: +46 8 24 11 79 e-mail: mansaxel@sunet.se nic-hdl: MN1334-RIPE mnt-by: SUNET-MNT changed: mansaxel@sunet.se 20010321 changed: mansaxel@sunet.se 20021216 source: RIPE I haven't bothered with the traceroutes. It should by now be painfully obvious to most people that there is no privacy gained from removing reverse DNS, and your argument for this is not holding water..=20 >> DNS need not be applied in this process, it is merely the >> pretty-traceroute icing on an already sweet cake of data. >=20 > I agree it is pretty traceroute icing. I also agree that DNS need not be > applied to this process. Maybe we are getting somewhere. Come on, and read what I write. I am trying to tell you that it is orthagonal to the issue at hand. Can we drop the privacy argument, please?=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1097735387========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+qMhh02/pMZDM1cURAr00AJ9KBSsFvOK2doQsBnv46Eb17xv0RACeLeA4 uRPFsHNXGnFpA+2p5ttB4n8= =4lRy -----END PGP SIGNATURE----- --==========1097735387==========-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 25 02:29:23 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28618 for ; Fri, 25 Apr 2003 02:29:22 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3P66jRN016827 for ; Fri, 25 Apr 2003 08:06:45 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3P66jxR016826 for dnsop-outgoing; Fri, 25 Apr 2003 08:06:45 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from citation.av8.net (relay2.av8.net [130.105.12.4] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3P66iRN016819 for ; Fri, 25 Apr 2003 08:06:44 +0200 (MEST) Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id CAA28003; Fri, 25 Apr 2003 02:00:37 -0400 Date: Fri, 25 Apr 2003 02:01:02 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In-Reply-To: <377410000.1051248736@localhost.besserwisser.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.cafax.se id h3P66jRN016822 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Maybe you want to look more closely. That hasn't revealed anything about my customers. As I recall, you were the person with all your customers on your in-addr, right? --Dean On Fri, 25 Apr 2003, [ISO-8859-1] Måns Nilsson wrote: > > > --On Thursday, April 24, 2003 22:46:52 -0400 Dean Anderson > wrote: > > >> That together with a decent public looking-glass will tell the interested > >> person pretty much anything you might want to know. > > > > You can find out about the ISP, which is appropriate. You cannot find out > > about the ISP's customers, which is not always appropriate. > > Worng. Let's look at the source addres of your mail and mine. > > $ whois -a 130.105.11.4 > > OrgName: Open Software Foundation > OrgID: OSF > Address: 529 Main St. > City: Boston > StateProv: MA > PostalCode: 02129 > Country: US > > NetRange: 130.105.0.0 - 130.105.255.255 > CIDR: 130.105.0.0/16 > NetName: OSF > NetHandle: NET-130-105-0-0-1 > Parent: NET-130-0-0-0-0 > NetType: Direct Allocation > NameServer: STARSHIP.AV8.COM > NameServer: CONCORDE.AV8.COM > Comment: > RegDate: 1988-07-20 > Updated: 1998-12-21 > > TechHandle: DA31-ARIN > TechName: Anderson, Dean A. > TechPhone: +1-617-242-3091 > TechEmail: dean@av8.com > > # ARIN WHOIS database, last updated 2003-04-24 20:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > > ARIN needs a step for the route info too, so we get the source AS from BGP, > and find the following AS-path: 2603 1239 2548 11784 which is Nordunet, > Sprint, Allegiance Telecom and finally you. > > $ whois -a AS11784 > > OrgName: Plain Aivation, Inc > OrgID: PLAINA > Address: P.O. Box 7286 > City: Nashua > StateProv: NH > PostalCode: 03060 > Country: US > > ASNumber: 11784 > ASName: ASN-AV8 > ASHandle: AS11784 > Comment: > RegDate: 1998-12-17 > Updated: 1998-12-17 > > TechHandle: DA31-ARIN > TechName: Anderson, Dean A. > TechPhone: +1-617-242-3091 > TechEmail: dean@av8.com > > # ARIN WHOIS database, last updated 2003-04-24 20:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > > and over to mine: > > $ whois -r 213.212.3.212 > % This is the RIPE Whois server. > % The objects are in RPSL format. > % > % Rights restricted by copyright. > % See http://www.ripe.net/ripencc/pub-services/db/copyright.html > > inetnum: 213.212.3.192 - 213.212.3.223 > netname: MANSNILSSON > descr: Mans Nilsson > country: SE > admin-c: MN1334-RIPE > tech-c: MN1334-RIPE > status: ASSIGNED PA > mnt-by: DPNOC > changed: registry@dataphone.net 20000203 > source: RIPE > > route: 213.212.0.0/18 > descr: Dataphone Communication Networks > origin: AS8289 > mnt-by: DPNOC > changed: registry@dataphone.net 19990914 > source: RIPE > > person: Mans Nilsson > address: Royal Institute of Technology > address: KTH/SUNET > address: S-100 44 STOCKHOLM > address: SE > phone: +46 8 790 60 00 > fax-no: +46 8 24 11 79 > e-mail: mansaxel@sunet.se > nic-hdl: MN1334-RIPE > mnt-by: SUNET-MNT > changed: mansaxel@sunet.se 20010321 > changed: mansaxel@sunet.se 20021216 > source: RIPE > > I haven't bothered with the traceroutes. It should by now be painfully > obvious to most people that there is no privacy gained from removing > reverse DNS, and your argument for this is not holding water.. > > >> DNS need not be applied in this process, it is merely the > >> pretty-traceroute icing on an already sweet cake of data. > > > > I agree it is pretty traceroute icing. I also agree that DNS need not be > > applied to this process. Maybe we are getting somewhere. > > Come on, and read what I write. I am trying to tell you that it is > orthagonal to the issue at hand. Can we drop the privacy argument, please? > > -- > Måns Nilsson Systems Specialist > +46 70 681 7204 KTHNOC MN1334-RIPE > > We're sysadmins. To us, data is a protocol-overhead. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Apr 25 02:46:55 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28943 for ; Fri, 25 Apr 2003 02:46:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3P6RKRN017094 for ; Fri, 25 Apr 2003 08:27:20 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3P6RKXM017093 for dnsop-outgoing; Fri, 25 Apr 2003 08:27:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from slimsixten.besserwisser.org (slimsixten.besserwisser.org [213.212.3.212]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3P6RJRN017088 for ; Fri, 25 Apr 2003 08:27:19 +0200 (MEST) Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h3P6R2S7018610; Fri, 25 Apr 2003 08:27:03 +0200 (CEST) Date: Fri, 25 Apr 2003 08:27:02 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Dean Anderson cc: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt Message-ID: <416110000.1051252022@localhost.besserwisser.org> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1012896650==========" Sender: owner-dnsop@cafax.se Precedence: bulk --==========1012896650========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Friday, April 25, 2003 02:01:02 -0400 Dean Anderson wrote: > Maybe you want to look more closely. That hasn't revealed anything about > my customers. No, but about you. EOFFTOPIC: This communication will now end.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1012896650========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+qNU202/pMZDM1cURAqQhAKCVpeZCbszl9RWXxg7YqELlaWsKJgCdE3Pd bqk+agdZnXpHu0RiU63jEkI= =Y5C5 -----END PGP SIGNATURE----- --==========1012896650==========-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Apr 27 16:35:25 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01514 for ; Sun, 27 Apr 2003 16:35:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3RKGrRN013061 for ; Sun, 27 Apr 2003 22:16:53 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3RKGqTi013060 for dnsop-outgoing; Sun, 27 Apr 2003 22:16:52 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3RKGpRN013055 for ; Sun, 27 Apr 2003 22:16:51 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 89A5518E6 for ; Sun, 27 Apr 2003 16:16:49 -0400 (EDT) Date: Sun, 27 Apr 2003 16:16:49 -0400 From: Rob Austein To: dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030427201649.89A5518E6@thrintun.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk At Wed, 23 Apr 2003 17:51:26 -0700, David R. Conrad wrote: > > So, this draft is going to expire soonish. > > Is there anything I need to do to it? I don't remember any additional > comments since Atlanta. > > Can it be pushed to last call? I was really hoping that somebody else would say this, but ok, I'll say it, and will recuse myself from the chair role on this draft if it seems necessary. While I understand and respect the author's intentions in attempting to remove the BIND-specific aspects of an existing hack, this opens up a nasty can of worms: 1) The draft asks IANA to allocate a new TLD, and a class-specific TLD at that; 2) The draft specifies behavior for the (conceptual) zone corresponding to that new class-specific TLD which is totally inconsistant with the usual DNS data coherence model. Furthermore, even ignoring the above issues, this looks like a protocol document than an ops document. I can see two ways forward, depending on what the author and the WG want to do: a) Strip this back down to an Informational doc describing an existing BIND hack; or b) Change focus to trying to draft some useful behavior for the STATUS opcode, and move the work over to DNSEXT. Comments? #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Apr 27 19:42:43 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04980 for ; Sun, 27 Apr 2003 19:42:41 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3RNPDRN014335 for ; Mon, 28 Apr 2003 01:25:13 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3RNPCNX014334 for dnsop-outgoing; Mon, 28 Apr 2003 01:25:12 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sa.vix.com (sa.vix.com [204.152.187.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3RNPBRN014329 for ; Mon, 28 Apr 2003 01:25:12 +0200 (MEST) Received: by sa.vix.com (Postfix, from userid 716) id 06F361394B; Sun, 27 Apr 2003 23:25:10 +0000 (GMT) To: dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt References: <20030427201649.89A5518E6@thrintun.hactrn.net> From: Paul Vixie Date: 27 Apr 2003 23:25:09 +0000 In-Reply-To: <20030427201649.89A5518E6@thrintun.hactrn.net> Message-ID: Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk > ... > While I understand and respect the author's intentions in attempting > to remove the BIND-specific aspects of an existing hack, this opens up > a nasty can of worms: > > 1) The draft asks IANA to allocate a new TLD, and a class-specific TLD > at that; > > 2) The draft specifies behavior for the (conceptual) zone > corresponding to that new class-specific TLD which is totally > inconsistant with the usual DNS data coherence model. > > Furthermore, even ignoring the above issues, this looks like a > protocol document than an ops document. i agree on all three points. the problem we solved with VERSION.BIND back in bind8 and now with the recent addition of HOSTNAME.BIND caused some other problems. it's unquestionably bad that we pirate a TLD in the CHAOS namespace for our version/hostname data. it's questionably bad that we do it by default, requiring people who want version/hostname privacy to have to make a config change to get it. however, not doing these things would have been worse, and trying to get IETF and IANA to allocate us some kind of QNAME/QCLASS/QTYPE for it would have been much much far worser even. > I can see two ways forward, depending on what the author and the WG > want to do: > > a) Strip this back down to an Informational doc describing an existing > BIND hack; or > > b) Change focus to trying to draft some useful behavior for the STATUS > opcode, and move the work over to DNSEXT. > > Comments? while i agree with your complaints about the draft, i think that your proposed alternatives are worse. STATUS will run into untold middlebox problems and will also take several years to finish the main part of the argument about. having an rfc number, even if only informational or experimental, that would seem to sanction TLD piracy of this form would be the biggest can of worms mentioned so far on this topic. therefore i support drc's draft as written, since it's the least of all known evils. right now a number of non-BIND implementations answer for VERSION.BIND and sometimes also HOSTNAME.BIND in the CHAOS class, just for feature-level competition. i regret choosing .BIND as the pirate TLD in the CHAOS class for this; it should have been .NAMESERVER or something else, and there should have been at least a technote describing it, and i should have sought an experimental rfc for it. -- Paul Vixie #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Apr 27 20:37:13 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05684 for ; Sun, 27 Apr 2003 20:37:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S0NgRN014742 for ; Mon, 28 Apr 2003 02:23:42 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S0NgfZ014741 for dnsop-outgoing; Mon, 28 Apr 2003 02:23:42 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S0NeRN014736 for ; Mon, 28 Apr 2003 02:23:41 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3S0Na5a071629; Sun, 27 Apr 2003 20:23:38 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: <20030427201649.89A5518E6@thrintun.hactrn.net> Date: Mon, 28 Apr 2003 02:22:51 +0200 To: Paul Vixie From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 11:25 PM +0000 2003/04/27, Paul Vixie wrote: > therefore i support drc's draft as written, since it's the least of all > known evils. right now a number of non-BIND implementations answer for > VERSION.BIND and sometimes also HOSTNAME.BIND in the CHAOS class, just > for feature-level competition. Note that NSD already supports VERSION.SERVER, presumably as a result of the work on the draft (or maybe some earlier document or discussion). > i regret choosing .BIND as the pirate TLD > in the CHAOS class for this; it should have been .NAMESERVER or something > else, and there should have been at least a technote describing it, and > i should have sought an experimental rfc for it. The draft is pretty old, and appears to me to have some useful information and suggestions. I'd at least like to see it go towards an experimental or informational RFC, and perhaps beyond. However, I must also agree with Rob that this seems to be more of a protocol/policy issue and I'm not sure that it should be dealt with in DNSOP. His suggestion of passing this to DNSEXT seems to be appropriate. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Apr 27 22:38:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07131 for ; Sun, 27 Apr 2003 22:38:53 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S2MERN016244 for ; Mon, 28 Apr 2003 04:22:14 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S2MEj5016243 for dnsop-outgoing; Mon, 28 Apr 2003 04:22:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S2MCRN016238 for ; Mon, 28 Apr 2003 04:22:13 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id EE8E0137F09; Sun, 27 Apr 2003 19:22:10 -0700 (PDT) Date: Sun, 27 Apr 2003 19:22:06 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dnsop@cafax.se To: Rob Austein From: David Conrad In-Reply-To: <20030427201649.89A5518E6@thrintun.hactrn.net> Message-Id: <350735C6-7920-11D7-A953-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Given their fundamental nature, I am curious as to why you didn't raise these issues way back when I first submitted this draft or at the DNSOP meeting where this was discussed, however... On Sunday, April 27, 2003, at 01:16 PM, Rob Austein wrote: > While I understand and respect the author's intentions in attempting > to remove the BIND-specific aspects of an existing hack, this opens up > a nasty can of worms: It would seem difficult to do pretty much anything in the IETF these days without opening up a nasty can of worms. > 1) The draft asks IANA to allocate a new TLD, and a class-specific TLD > at that; > > 2) The draft specifies behavior for the (conceptual) zone > corresponding to that new class-specific TLD which is totally > inconsistant with the usual DNS data coherence model. > > Furthermore, even ignoring the above issues, this looks like a > protocol document than an ops document. The draft attempts to document existing operational practice and modify that practice slightly so it is more generally acceptable to non-BIND implementations. It also tries to address an operational requirement of being able to identify which machine is responding to a query by extending the existing practice. It is working code (in at least 3 independent DNS servers I am aware of). There is no modification to the DNS protocol proposed in the draft. There are no new RR types defined or clarification of any existing RR type behavior. I do not believe it appropriate for this draft to be in DNSEXT. > I can see two ways forward, depending on what the author and the WG > want to do: > > a) Strip this back down to an Informational doc describing an existing > BIND hack; or It was always my intent for this to be informational. > b) Change focus to trying to draft some useful behavior for the STATUS > opcode, and move the work over to DNSEXT. You forgot the smiley. > Comments? This draft attempts to extend an existing practice in as simple a way as possible to address an immediate operational concern, namely being able to determine which nameserver out of a set of anycast'ed nameservers is responding to a request. It would be distressing if this were to get bogged down in yet another IETF swamp. Rgds, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 00:51:11 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08908 for ; Mon, 28 Apr 2003 00:51:10 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S4XmRN017011 for ; Mon, 28 Apr 2003 06:33:48 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S4Xmj5017010 for dnsop-outgoing; Mon, 28 Apr 2003 06:33:48 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S4XkRN017005 for ; Mon, 28 Apr 2003 06:33:47 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19A0Km-000DNW-V7; Sun, 27 Apr 2003 21:33:45 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 27 Apr 2003 21:33:44 -0700 To: David Conrad Cc: Rob Austein , dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt References: <20030427201649.89A5518E6@thrintun.hactrn.net> <350735C6-7920-11D7-A953-000393DB42B2@nominum.com> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > Given their fundamental nature, I am curious as to why you didn't raise > these issues way back when I first submitted this draft or at the DNSOP > meeting where this was discussed, however... because rob is shy and i raised some of them and another rather fundamental one. what i really need to know is the unique identity of the server who gave me the result i just received in response to a 'normal' query. this is especially needed in an environment where servers may be anycast. this may be an edns thing. i.e., why do i care what broken version of software some server is running if i am not sure it is the server which gave me the result? randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 01:43:08 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09670 for ; Mon, 28 Apr 2003 01:43:08 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S5PrRN017338 for ; Mon, 28 Apr 2003 07:25:53 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S5Pq2J017337 for dnsop-outgoing; Mon, 28 Apr 2003 07:25:52 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S5PpRN017332 for ; Mon, 28 Apr 2003 07:25:52 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 320F3137F09; Sun, 27 Apr 2003 22:25:50 -0700 (PDT) Date: Sun, 27 Apr 2003 22:25:32 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Rob Austein , dnsop@cafax.se To: Randy Bush From: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Randy, Feel free to come back after you've actually read the draft. In particular, the third and fourth paragraphs of section 4. I added the fourth paragraph specifically for you as you seemed confused in Atlanta. Even put you into the acknowledgments. The least you could do is read it. Thanks, -drc On Sunday, April 27, 2003, at 09:33 PM, Randy Bush wrote: >> Given their fundamental nature, I am curious as to why you didn't >> raise >> these issues way back when I first submitted this draft or at the >> DNSOP >> meeting where this was discussed, however... > > because rob is shy and i raised some of them and another rather > fundamental one. what i really need to know is the unique identity > of the server who gave me the result i just received in response to > a 'normal' query. this is especially needed in an environment > where servers may be anycast. this may be an edns thing. > > i.e., why do i care what broken version of software some server is > running if i am not sure it is the server which gave me the result? > > randy > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 01:55:07 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09804 for ; Mon, 28 Apr 2003 01:55:07 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S5doRN017442 for ; Mon, 28 Apr 2003 07:39:50 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S5doFi017441 for dnsop-outgoing; Mon, 28 Apr 2003 07:39:50 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S5dmRN017435 for ; Mon, 28 Apr 2003 07:39:49 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19A1Mh-000DTL-7E; Sun, 27 Apr 2003 22:39:47 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 27 Apr 2003 22:39:46 -0700 To: David Conrad Cc: Rob Austein , dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt References: Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > In particular, the third and fourth paragraphs of section 4. I added > the fourth paragraph specifically for you as you seemed confused in > Atlanta. Even put you into the acknowledgments. The least you could > do is read it. i did read the draft. you don't get my point. and i wasn't in atlanta, my wife was dying. anything else? randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 02:08:13 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18210 for ; Mon, 28 Apr 2003 02:08:12 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S5tARN017587 for ; Mon, 28 Apr 2003 07:55:10 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S5tATX017586 for dnsop-outgoing; Mon, 28 Apr 2003 07:55:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S5t9RN017581 for ; Mon, 28 Apr 2003 07:55:09 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3AB1A137F15; Sun, 27 Apr 2003 22:55:08 -0700 (PDT) Date: Sun, 27 Apr 2003 22:55:04 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Rob Austein , dnsop@cafax.se To: Randy Bush From: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > i did read the draft. you don't get my point. Obviously not. Want to try to speak for yourself instead of having Rob interpret for you? > and i wasn't in > atlanta, my wife was dying. My condolences on your loss. I guess it must have been in Yokohama. > anything else? Yes. Speak for yourself instead of getting other people to act as your mouthpiece. If you have issues with a draft, bring them to the attention of the author in a timely manner either directly or via the working group mailing list. > Indeed. Thanks, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 02:10:42 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20604 for ; Mon, 28 Apr 2003 02:10:41 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S5wNRN017626 for ; Mon, 28 Apr 2003 07:58:23 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S5wNWH017625 for dnsop-outgoing; Mon, 28 Apr 2003 07:58:23 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sa.vix.com (sa.vix.com [204.152.187.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S5wMRN017615 for ; Mon, 28 Apr 2003 07:58:22 +0200 (MEST) Received: by sa.vix.com (Postfix, from userid 716) id 47EF01394B; Mon, 28 Apr 2003 05:58:21 +0000 (GMT) To: dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt References: From: Paul Vixie Date: 28 Apr 2003 05:58:21 +0000 In-Reply-To: Message-ID: Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk david.conrad@nominum.com (David Conrad) writes: > On Sunday, April 27, 2003, at 09:33 PM, Randy Bush wrote: > > > ... what i really need to know is the unique identity of the server > > who gave me the result i just received in response to a 'normal' query. > > this is especially needed in an environment where servers may be > > anycast. this may be an edns thing. it would be pretty easy to use edns to solicit/carry a server identity blob but in thinking about this i've been unable to determine what that would have to look like. answering nameserver's hostname might not be fully qualified, answering nameserver host addresses might not have working PTR, so putting a hostname blob in won't work. the nameserver service address might be NAT'd, and in addition, might be the same as a local rfc1918 address nearby the initiator, so, putting a host address blob in won't work. if one assumed the existence of an 802.3 48-bit address (ethernet, fddi, etc) and further assumed that these were universally unique, then one could put one or more of these (a host might be have more than one attached interface) into an edns blob... but it would not help the initiator to do anything except know that two responses had come from the same distant, yet anonymous, nameserver. and it could be spoofed for anti-security reasons. all of this stuff would be subject to middlebox corruption, either by middleboxes who chose to change it when they shouldn't, or chose not to change it when they should, or change it in wrong (or even evil) ways. in other words, before we can decide how to encode or solicit or carry nameserver identity, we have to decide the conceptual meaning of identity as applied to nameservers. if i loadbalance by running two processes on a dual-processor system, but they respond to the same address/port combos even though each one could have its own configuration, how many identities do i have? that sort of thing. -- Paul Vixie #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 02:21:03 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21856 for ; Mon, 28 Apr 2003 02:21:02 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S64GRN017763 for ; Mon, 28 Apr 2003 08:04:16 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S64GsT017762 for dnsop-outgoing; Mon, 28 Apr 2003 08:04:16 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S64ERN017757 for ; Mon, 28 Apr 2003 08:04:15 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19A1kL-000DUs-Oo; Sun, 27 Apr 2003 23:04:13 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 27 Apr 2003 23:04:13 -0700 To: David Conrad Cc: Rob Austein , dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt References: Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit >> i did read the draft. you don't get my point. > Obviously not. Want to try to speak for yourself instead of > having Rob interpret for you? you provide how to ask a server to tell some things about itself. but, in an anycast universe, when i have a result 'of interest' in my hand, i don't know to which server to send the query. and, if i knew the server, i probably don't need to know, all i need to do is send To: noc Subject: broken server the server with unique identity gave me the suspicious result to query . unfortunately, i can not ascertain , and you provide no help. > Speak for yourself instead of getting other people to act as your > mouthpiece. i never asked rob to say anything. please keep your black helicopter theories down in caliwood. and refrain from accusations which you can not substantiate. > If you have issues with a draft, bring them to the attention of > the author in a timely manner either directly or via the working > group mailing list. i did. you just did not get it. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 02:51:50 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22406 for ; Mon, 28 Apr 2003 02:51:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S6XVRN018296 for ; Mon, 28 Apr 2003 08:33:31 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3S6XV2x018295 for dnsop-outgoing; Mon, 28 Apr 2003 08:33:31 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3S6XURN018290 for ; Mon, 28 Apr 2003 08:33:30 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id F4035137F09; Sun, 27 Apr 2003 23:33:28 -0700 (PDT) Date: Sun, 27 Apr 2003 23:33:26 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Rob Austein , dnsop@cafax.se To: Randy Bush From: David Conrad In-Reply-To: Message-Id: <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Randy, On Sunday, April 27, 2003, at 11:04 PM, Randy Bush wrote: > you provide how to ask a server to tell some things about itself. > but, in an anycast universe, when i have a result 'of interest' in > my hand, i don't know to which server to send the query. and, if i > knew the server, i probably don't need to know, all i need to do is > send > > To: noc > Subject: broken server > > the server with unique identity gave me the suspicious > result to query . > > unfortunately, i can not ascertain , and you provide no help. Thank you. If the server at a particular IP address returns to query , you issue a CH class ID.SERVER query to that IP address from the same client that received the suspicious result (making the assumption that the routing system has not changed the server that will receive that query). If you do not have access to the client or there is a potential for the routing system to have changed which server will receive the CH class ID.SERVER query, you can either ask the NOC for the non-anycast IP addresses associated with the server and try each in turn or let the folks at the NOC do their job and figure it out themselves. Does this address your concern or do I still not get it? Rgds, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 08:27:23 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28446 for ; Mon, 28 Apr 2003 08:27:22 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SC0FRN020873 for ; Mon, 28 Apr 2003 14:00:15 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3SC0Ff9020872 for dnsop-outgoing; Mon, 28 Apr 2003 14:00:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SC0DRN020865 for ; Mon, 28 Apr 2003 14:00:13 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19A7Ip-000DoQ-NH; Mon, 28 Apr 2003 05:00:11 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 28 Apr 2003 05:00:11 -0700 To: David Conrad Cc: Rob Austein , dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt References: <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > If the server at a particular IP address returns to query , > you issue a CH class ID.SERVER query to that IP address from the same > client that received the suspicious result (making the assumption that > the routing system has not changed the server that will receive that > query). that assumption is not at all safe randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 10:42:16 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03386 for ; Mon, 28 Apr 2003 10:42:15 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SEMBRN022369 for ; Mon, 28 Apr 2003 16:22:11 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3SEMBWv022368 for dnsop-outgoing; Mon, 28 Apr 2003 16:22:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SEMARN022363 for ; Mon, 28 Apr 2003 16:22:10 +0200 (MEST) Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h3SEMASt016513; Mon, 28 Apr 2003 16:22:10 +0200 Date: Mon, 28 Apr 2003 16:22:09 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: Randy Bush cc: David Conrad , Subject: Re: draft-ietf-dnsop-serverid-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 28 Apr 2003, Randy Bush wrote in reply to David Conrad: > > If the server at a particular IP address returns to query , > > you issue a CH class ID.SERVER query to that IP address from the same > > client that received the suspicious result (making the assumption that > > the routing system has not changed the server that will receive that > > query). > > that assumption is not at all safe Myself, I've found that said assumption holds fairly true for: verify problem @nameserver dig identifier @nameserver verify problem @nameserver where the results from the two enclosing verifies are identical, and the command sequence is executed one after the other in quick succession, and is repeated several times to discount rapid routing instabilities, which is what most people do when performing diagnostics of a problem. Without going into unique identifiers being returned with the query (ref Vixie's mail on the subject), this does appear to be a workable solution for 95% of cases, the other 5% being silly load-balancer games (eg, queries of one type being directed to a specific host) which you cannot diagnose being external to the load-balancer. --==-- Bruce. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 13:12:35 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07185 for ; Mon, 28 Apr 2003 13:12:34 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SGstRN024148 for ; Mon, 28 Apr 2003 18:54:55 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3SGstHl024147 for dnsop-outgoing; Mon, 28 Apr 2003 18:54:55 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SGsrRN024142 for ; Mon, 28 Apr 2003 18:54:54 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id F0654137F15; Mon, 28 Apr 2003 09:54:51 -0700 (PDT) Date: Mon, 28 Apr 2003 09:54:50 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Rob Austein , dnsop@cafax.se To: Randy Bush From: David Conrad In-Reply-To: Message-Id: <207E4C23-799A-11D7-A953-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Which is why I added the second paragraph (which you didn't quote) to my response to you. Rgds, -drc On Monday, April 28, 2003, at 05:00 AM, Randy Bush wrote: >> If the server at a particular IP address returns to query , >> you issue a CH class ID.SERVER query to that IP address from the same >> client that received the suspicious result (making the assumption that >> the routing system has not changed the server that will receive that >> query). > > that assumption is not at all safe > > randy > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 18:39:43 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17732 for ; Mon, 28 Apr 2003 18:39:42 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SMIhRN027369 for ; Tue, 29 Apr 2003 00:18:43 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3SMIhrM027368 for dnsop-outgoing; Tue, 29 Apr 2003 00:18:43 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SMIWRN027348 for ; Tue, 29 Apr 2003 00:18:42 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3SMI7ta070484; Mon, 28 Apr 2003 18:18:30 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Mon, 28 Apr 2003 23:23:38 +0200 To: Paul Vixie From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 5:58 AM +0000 2003/04/28, Paul Vixie wrote: > in other words, before we can decide how to encode or solicit or carry > nameserver identity, we have to decide the conceptual meaning of identity > as applied to nameservers. if i loadbalance by running two processes on > a dual-processor system, but they respond to the same address/port combos > even though each one could have its own configuration, how many identities > do i have? that sort of thing. Indeed, when I set up the caching nameserver farm at AOL in '96, I had four DEC Alpha 4100s with four processors each, 4GB of RAM, and four copies of BIND 8 running on each machine, each process listening to a different virtual interface/IP address that was bound to the same physical address. I benchmarked the processes, and each one could handle about 2000 queries per second, regardless of whether I was running one or four processes, or anywhere in-between. Dunno what happened to that farm. I'll have to ask some friends & former co-workers who might still be there. I'm thinking we might be able to do this with hashes of public crypto keys. Each process would need a unique public key/private key pair for successful secure control via remote processes (e.g., rndc and such like), and this key could be kept in a separate file for each instance of each nameserver. You could either include the public part (or hash thereof) in each EDNS response, or include a portion. However, I fear that we're getting well away from operational issues, and this aspect of the discussion should probably be taken up within DNSEXT. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 18:39:46 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17748 for ; Mon, 28 Apr 2003 18:39:45 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SMIcRN027360 for ; Tue, 29 Apr 2003 00:18:38 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3SMIckK027359 for dnsop-outgoing; Tue, 29 Apr 2003 00:18:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SMIRRN027347 for ; Tue, 29 Apr 2003 00:18:37 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3SMI7tY070484; Mon, 28 Apr 2003 18:18:25 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> References: <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> Date: Mon, 28 Apr 2003 23:12:26 +0200 To: David Conrad From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: Randy Bush , Rob Austein , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 11:33 PM -0700 2003/04/27, David Conrad wrote: > If the server at a particular IP address returns to query , > you issue a CH class ID.SERVER query to that IP address from the same > client that received the suspicious result (making the assumption that > the routing system has not changed the server that will receive that > query). Regretfully, in a load-balanced world this won't work. An incoming query to a single IP address could be redirected to any of the back-end servers. > If you do not have access to the client or there is a potential for > the routing system to have changed which server will receive the CH > class ID.SERVER query, you can either ask the NOC for the non-anycast > IP addresses associated with the server and try each in turn or let > the folks at the NOC do their job and figure it out themselves. The server may not have a publicly accessible non-anycast or non-load-balanced address. > Does this address your concern or do I still not get it? I think we may have to just concede that there are going to be issues in an anycast or load-balanced environment, and maybe give some serious thought as to how we might work towards solving this problem in an EDNS environment. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 18:39:46 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17749 for ; Mon, 28 Apr 2003 18:39:45 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SMIZRN027354 for ; Tue, 29 Apr 2003 00:18:35 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3SMIZOJ027353 for dnsop-outgoing; Tue, 29 Apr 2003 00:18:35 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SMINRN027346 for ; Tue, 29 Apr 2003 00:18:33 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3SMI7tW070484; Mon, 28 Apr 2003 18:18:19 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Mon, 28 Apr 2003 23:02:21 +0200 To: Randy Bush From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: David Conrad , Rob Austein , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 11:04 PM -0700 2003/04/27, Randy Bush wrote: > To: noc > Subject: broken server > > the server with unique identity gave me the suspicious > result to query . > > unfortunately, i can not ascertain , and you provide no help. In an anycast or load-balanced world, I don't think it's possible to ascertain . You would have to have the server attach some sort of unique identifier to each and every response, and that identifier would have to be persistent across program restarts, reboots, changes of IP address, etc.... If the identifier wasn't unique in this manner, when someone complains that a particular server (according to the unique identifier) is screwed-up, you would have no way of determining which server it might have been. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 21:49:05 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21827 for ; Mon, 28 Apr 2003 21:49:04 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3T1PQRN029814 for ; Tue, 29 Apr 2003 03:25:26 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3T1PPXx029812 for dnsop-outgoing; Tue, 29 Apr 2003 03:25:25 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3T1PLRN029805 for ; Tue, 29 Apr 2003 03:25:21 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19AJs0-000LKr-00; Tue, 29 Apr 2003 01:25:21 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19ACLO-0003x3-G3; Mon, 28 Apr 2003 10:23:10 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 28 Apr 2003 10:23:09 -0700 To: Bruce Campbell Cc: dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt References: Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > Myself, I've found that said assumption holds fairly true for: > verify problem @nameserver > dig identifier @nameserver > verify problem @nameserver > where the results from the two enclosing verifies are identical, > and the command sequence is executed one after the other in quick > succession, and is repeated several times to discount rapid > routing instabilities, which is what most people do when > performing diagnostics of a problem. and do i have to hold my left leg up in the air and clap my hands three times too? :-) determinism is one of the redeeming features of digital computers. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 21:49:14 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21842 for ; Mon, 28 Apr 2003 21:49:13 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3T1PPRN029811 for ; Tue, 29 Apr 2003 03:25:25 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3T1PMwD029806 for dnsop-outgoing; Tue, 29 Apr 2003 03:25:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3T1PJRN029800 for ; Tue, 29 Apr 2003 03:25:19 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19AJrx-000LMq-00; Tue, 29 Apr 2003 01:25:18 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19AD2v-00041p-W9; Mon, 28 Apr 2003 11:08:10 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 28 Apr 2003 11:08:09 -0700 To: Paul Vixie Cc: dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt References: Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit >> ... what i really need to know is the unique identity of the >> server who gave me the result i just received in response to a >> 'normal' query. this is especially needed in an environment >> where servers may be anycast. this may be an edns thing. > it would be pretty easy to use edns to solicit/carry a server > identity blob but in thinking about this i've been unable to > determine what that would have to look like. my experience in managing servers is that they have a unique unicast ip address. even the anycast ones do so that they can be managed, transfer zones, ... > the nameserver service address might be NAT'd i don't care. they deserve the hell into which they consigned themselves. > if i loadbalance by running two processes on a dual-processor > system, but they respond to the same address/port combos even > though each one could have its own configuration, how many > identities do i have? too many :-) so cat the pid or something similarly disgusting. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Apr 28 22:30:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22563 for ; Mon, 28 Apr 2003 22:30:12 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3T28ERN000742 for ; Tue, 29 Apr 2003 04:08:14 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3T28Exw000741 for dnsop-outgoing; Tue, 29 Apr 2003 04:08:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3T28DRN000736 for ; Tue, 29 Apr 2003 04:08:13 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E95FE137F0A; Mon, 28 Apr 2003 19:08:11 -0700 (PDT) Date: Mon, 28 Apr 2003 19:08:09 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Bruce Campbell , dnsop@cafax.se To: Randy Bush From: David Conrad In-Reply-To: Message-Id: <6C6CE976-79E7-11D7-BCDA-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit If it was, then you wouldn't have raised the issue, now would you? Rgds, -drc On Monday, April 28, 2003, at 10:23 AM, Randy Bush wrote: >> Myself, I've found that said assumption holds fairly true for: >> verify problem @nameserver >> dig identifier @nameserver >> verify problem @nameserver >> where the results from the two enclosing verifies are identical, >> and the command sequence is executed one after the other in quick >> succession, and is repeated several times to discount rapid >> routing instabilities, which is what most people do when >> performing diagnostics of a problem. > > and do i have to hold my left leg up in the air and clap my hands > three times too? :-) > > determinism is one of the redeeming features of digital computers. > > randy > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 07:00:50 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12091 for ; Tue, 29 Apr 2003 07:00:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TAfLRN005045 for ; Tue, 29 Apr 2003 12:41:21 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TAfLi6005044 for dnsop-outgoing; Tue, 29 Apr 2003 12:41:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TAfKRN005039 for ; Tue, 29 Apr 2003 12:41:20 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3TAfEtU030569; Tue, 29 Apr 2003 06:41:18 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Tue, 29 Apr 2003 12:25:43 +0200 To: Randy Bush From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: Bruce Campbell , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 10:23 AM -0700 2003/04/28, Randy Bush wrote: > determinism is one of the redeeming features of digital computers. It's nice, but computers have also taught us that there are some systems where determinism is just not possible. Chaos Theory would be virtually nothing without computers, and yet there is nothing deterministic about it. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 07:00:51 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12090 for ; Tue, 29 Apr 2003 07:00:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TAfJRN005037 for ; Tue, 29 Apr 2003 12:41:19 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TAfJJS005036 for dnsop-outgoing; Tue, 29 Apr 2003 12:41:19 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TAfHRN005031 for ; Tue, 29 Apr 2003 12:41:18 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3TAfEtS030569; Tue, 29 Apr 2003 06:41:15 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Tue, 29 Apr 2003 12:24:34 +0200 To: Bruce Campbell From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: Randy Bush , David Conrad , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 4:22 PM +0200 2003/04/28, Bruce Campbell wrote: > Myself, I've found that said assumption holds fairly true for: > > verify problem @nameserver > dig identifier @nameserver > verify problem @nameserver This is exactly what I did for my presentation at LISA 2002. I ran 35 cycles like this (with a short sleep between cycles), and if all 35 came up exactly the same way (i.e., 1 & 3 worked, but 2 did not), then I considered this sufficient evidence to claim that the server is probably broken in the case of the middle query. Still, it's not deterministic, and any number of samples that can be counted by a human being are going to be vanishingly small compared to the real workload of the server. At best, it's a "good" indication, for some value of "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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 07:51:07 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12089 for ; Tue, 29 Apr 2003 07:00:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TAfQRN005053 for ; Tue, 29 Apr 2003 12:41:26 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TAfQ2U005052 for dnsop-outgoing; Tue, 29 Apr 2003 12:41:26 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TAfPRN005047 for ; Tue, 29 Apr 2003 12:41:25 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3TAfEtW030569; Tue, 29 Apr 2003 06:41:22 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Tue, 29 Apr 2003 12:28:47 +0200 To: Randy Bush From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: Paul Vixie , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 11:08 AM -0700 2003/04/28, Randy Bush wrote: > my experience in managing servers is that they have a unique > unicast ip address. even the anycast ones do so that they can be > managed, transfer zones, ... True, but if you have multiple server processes per IP address, or perhaps multiple IP addresses with different "views" assigned to each? > i don't care. they deserve the hell into which they consigned > themselves. Problem is, they're now inflicting this hell on the rest of the Internet, and we also have to live with this problem. It would be nice if we could give them some method to help make this easier. > so cat the pid or something similarly disgusting. Neither IP address nor pid will necessarily survive restarting the program, rebooting the machine, etc.... This makes it impossible to be able to determine which machine might have been broken when we get a claim at some time in the future. We need something that will be unique per server process (not per machine), and will be persistent across program restarts, server reboots, changes of IP address, etc.... -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 08:52:42 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15292 for ; Tue, 29 Apr 2003 08:52:41 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TCVNRN006399 for ; Tue, 29 Apr 2003 14:31:23 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TCVNfS006398 for dnsop-outgoing; Tue, 29 Apr 2003 14:31:23 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TCVLRN006393 for ; Tue, 29 Apr 2003 14:31:22 +0200 (MEST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3TCLOZj085739; Tue, 29 Apr 2003 08:21:24 -0400 (EDT) Message-Id: <200304291221.h3TCLOZj085739@nic-naa.net> To: Brad Knowles cc: Randy Bush , Bruce Campbell , dnsop@cafax.se, brunner@nic-naa.net Subject: Re: draft-ietf-dnsop-serverid-01.txt In-Reply-To: Your message of "Tue, 29 Apr 2003 12:25:43 +0200." Date: Tue, 29 Apr 2003 08:21:24 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-dnsop@cafax.se Precedence: bulk > Chaos Theory would > be virtually nothing without computers, and yet there is nothing > deterministic about it. Umm. Not Fractional dimension Hausdorff topology, not strange attractors, not epicycles or any part of Ergodic theory, not ... Preparing steak a la Mandelbrot requires a copious quantity of garlic. "Nothing deterministic"... Hmm ... no. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 15:47:13 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08188 for ; Tue, 29 Apr 2003 15:47:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TJNrRN010956 for ; Tue, 29 Apr 2003 21:23:53 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TJNrYI010955 for dnsop-outgoing; Tue, 29 Apr 2003 21:23:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from momotombo.TechFak.Uni-Bielefeld.DE (momotombo.TechFak.Uni-Bielefeld.DE [129.70.136.107]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TJNqRN010950 for ; Tue, 29 Apr 2003 21:23:52 +0200 (MEST) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id h3TJNpm26220 for ; Tue, 29 Apr 2003 21:23:51 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h3TJNpb10740 for ; Tue, 29 Apr 2003 21:23:51 +0200 (MEST) Message-Id: <200304291923.h3TJNpb10740@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt In-reply-to: Your message of "Mon, 28 Apr 2003 23:12:26 +0200." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Tue, 29 Apr 2003 21:23:50 +0200 From: Peter Koch Sender: owner-dnsop@cafax.se Precedence: bulk > Regretfully, in a load-balanced world this won't work. An You're right, but the draft targets another problem. It documents existing practise while suggesting to change some implementation specific identifiers to more generic ones. The draft's topic is initiated by an operational question, i.e. identifying servers in an "anycast set". There's nothing I can see in the dnsop charter that precludes this from being dealt with here, so I'm in favor of keeping the document here and advance it. To answer David's initial question, I do not feel it's ready for last call. First, I agree that the en passant reassignment of the CHAOS class is a problem. It's not even clear that IANA (whichever instance) is in charge of allocating a TLD there, at least I do not see a hint in RFC 2929. Since it's probably unwise to wait for an officially blessed TLD, it might be better to change to a subdomain of the ARPA TLD. The problem remains to find who's in charge of managing that in the CH class. That aside, it should be explicitly stated that queries MUST NOT be processed with recursion. With respect to the Security Considerations I think it supports "security by obscurity" a bit. While it may be useful to conceal or even change the "real" IP address of an anycast nameserver in critical infrastructure to avoid (D)DoS to this address, I'd rather not encourage filtering identity queries. People may do so anyway, but even today I may choose (although it wouldn't be too wise) not to answer DNS queries originating from certain IP addresses. If it were that critical, IP address based filtering wouldn't suffice. And, if Joe user is expected to submit the IDENT string with a problem report, he should be able to retrieve it in the first place. -Peter #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 15:47:16 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08203 for ; Tue, 29 Apr 2003 15:47:15 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TJQIRN010981 for ; Tue, 29 Apr 2003 21:26:18 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TJQI6j010980 for dnsop-outgoing; Tue, 29 Apr 2003 21:26:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TJQGRN010975 for ; Tue, 29 Apr 2003 21:26:17 +0200 (MEST) Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HE40004UE08Z3@eListX.com> for dnsop@cafax.se; Tue, 29 Apr 2003 15:26:32 -0400 (EDT) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h3TJMCQZ059459; Tue, 29 Apr 2003 15:22:12 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 29 Apr 2003 15:26:03 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: draft-ietf-dnsop-serverid-01.txt In-reply-to: <20030427201649.89A5518E6@thrintun.hactrn.net> X-Sender: post@localhost To: Rob Austein , dnsop@cafax.se Message-id: <5.1.1.6.2.20030429152414.01969260@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: Sender: owner-dnsop@cafax.se Precedence: bulk At 16:16 2003-04-27, Rob Austein wrote: >At Wed, 23 Apr 2003 17:51:26 -0700, David R. Conrad wrote: > >I can see two ways forward, depending on what the author and the WG >want to do: > >a) Strip this back down to an Informational doc describing an existing > BIND hack; or > >b) Change focus to trying to draft some useful behavior for the STATUS > opcode, and move the work over to DNSEXT. > >Comments? Not option B, please. Olafur #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 17:17:35 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10932 for ; Tue, 29 Apr 2003 17:17:33 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TKt3RN012041 for ; Tue, 29 Apr 2003 22:55:03 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TKt3aM012040 for dnsop-outgoing; Tue, 29 Apr 2003 22:55:03 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TKt2RN012035 for ; Tue, 29 Apr 2003 22:55:02 +0200 (MEST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.7/8.11.7) with ESMTP id h3TKt0830873 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO) for ; Tue, 29 Apr 2003 16:55:01 -0400 Message-Id: <5.2.1.1.2.20030429164037.01b9fe30@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 29 Apr 2003 16:47:13 -0400 To: dnsop@cafax.se From: Daniel Senie Subject: Re: draft-ietf-dnsop-serverid-01.txt In-Reply-To: References: <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk At 05:12 PM 4/28/2003, Brad Knowles wrote: >At 11:33 PM -0700 2003/04/27, David Conrad wrote: > >> If the server at a particular IP address returns to query , >> you issue a CH class ID.SERVER query to that IP address from the same >> client that received the suspicious result (making the assumption that >> the routing system has not changed the server that will receive that >> query). > > Regretfully, in a load-balanced world this won't work. An > incoming query to a single IP address could be redirected to any of the > back-end servers. > >> If you do not have access to the client or there is a potential for >> the routing system to have changed which server will receive the CH >> class ID.SERVER query, you can either ask the NOC for the non-anycast >> IP addresses associated with the server and try each in turn or let >> the folks at the NOC do their job and figure it out themselves. > > The server may not have a publicly accessible non-anycast or > non-load-balanced address. I don't think that matters. The issue isn't about getting back and talking to that system. It's about being able to have SOME way for the owner of a set of systems to identify RELIABLY the server which generated a specific reply. It'd be helpful in tracking back problems, but need not be in a form that is readable to anyone but the owner of the servers. Given the number of issues I've seen with load balancers that play stupid DNS tricks, those systems would also benefit from having some sort of unique identifier transmitted for the same reason. What should the identifier be? Something that's been hashed might work. I don't have a strong opinion on WHAT the value is, provided some method is determined for generating it. Given the concerns about multiple interfaces per machine, and multiple name service servers per host, it may make the most sense to consider some reasonable means of determining a "default" value (which would suffice for simple configurations of a single service server) and a way to configure the value for more advanced situations. Persistence across reboots/restarts could be addressed by configuration. It's not clear if it's worth the effort to try to devise an automated algorithm for dealing with complex environments, where simple configuration values might be sufficient. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 19:23:45 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16457 for ; Tue, 29 Apr 2003 19:23:45 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TMxMRN013204 for ; Wed, 30 Apr 2003 00:59:22 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TMxMT6013203 for dnsop-outgoing; Wed, 30 Apr 2003 00:59:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from edge.twig.com (office.twig.com [198.107.54.151]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TMxKRN013198 for ; Wed, 30 Apr 2003 00:59:21 +0200 (MEST) Received: from edge.twig.com (localhost [127.0.0.1]) by edge.twig.com (8.12.9/8.12.9) with ESMTP id h3TMxIAD024118; Tue, 29 Apr 2003 22:59:18 GMT Message-Id: <200304292259.h3TMxIAD024118@edge.twig.com> From: rad@twig.com (Richard Doty) To: Daniel Senie cc: dnsop@cafax.se Subject: Re: draft-ietf-dnsop-serverid-01.txt In-reply-to: (Message from Daniel Senie of Tue, 29 Apr 2003 16:47:13 -0400.) <5.2.1.1.2.20030429164037.01b9fe30@mail.amaranth.net> Date: Tue, 29 Apr 2003 22:59:07 +0000 Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, 29 Apr 2003 16:47:13 -0400 Daniel Senie wrote: > At 05:12 PM 4/28/2003, Brad Knowles wrote: > >At 11:33 PM -0700 2003/04/27, David Conrad wrote: > > > >> If the server at a particular IP address returns to query , > >> you issue a CH class ID.SERVER query to that IP address from the same > >> client that received the suspicious result (making the assumption that > >> the routing system has not changed the server that will receive that > >> query). > > > > Regretfully, in a load-balanced world this won't work. An > > incoming query to a single IP address could be redirected to any of the > > back-end servers. > > > >> If you do not have access to the client or there is a potential for > >> the routing system to have changed which server will receive the CH > >> class ID.SERVER query, you can either ask the NOC for the non-anycast > >> IP addresses associated with the server and try each in turn or let > >> the folks at the NOC do their job and figure it out themselves. > > > > The server may not have a publicly accessible non-anycast or > > non-load-balanced address. > > I don't think that matters. The issue isn't about getting back and talking > to that system. It's about being able to have SOME way for the owner of a > set of systems to identify RELIABLY the server which generated a specific > reply. I may be agreeing with you, not sure. Asking an anycasted nameserver for its ident does not tell you who answered some other query. Without unicast access to the nameserver, the nameserver ident info would need to be included in the answer to a normal query. (e.g. I ask for a PTR, get back PTR and ident of nameserver that gave me the PTR) Which sort of obviates a specific ident query. > It'd be helpful in tracking back problems, but need not be in a form > that is readable to anyone but the owner of the servers. Given the number > of issues I've seen with load balancers that play stupid DNS tricks, those > systems would also benefit from having some sort of unique identifier > transmitted for the same reason. > > What should the identifier be? Something that's been hashed might work. I > don't have a strong opinion on WHAT the value is, provided some method is > determined for generating it. Given the concerns about multiple interfaces > per machine, and multiple name service servers per host, it may make the > most sense to consider some reasonable means of determining a "default" > value (which would suffice for simple configurations of a single service > server) and a way to configure the value for more advanced situations. > Persistence across reboots/restarts could be addressed by configuration. > It's not clear if it's worth the effort to try to devise an automated > algorithm for dealing with complex environments, where simple configuration > values might be sufficient. > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 19:29:29 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16521 for ; Tue, 29 Apr 2003 19:29:29 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TNBfRN013370 for ; Wed, 30 Apr 2003 01:11:41 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3TNBf6X013369 for dnsop-outgoing; Wed, 30 Apr 2003 01:11:41 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3TNBeRN013364 for ; Wed, 30 Apr 2003 01:11:40 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3TNBatS083925; Tue, 29 Apr 2003 19:11:38 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <5.2.1.1.2.20030429164037.01b9fe30@mail.amaranth.net> References: <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> <5.2.1.1.2.20030429164037.01b9fe30@mail.amaranth.net> Date: Wed, 30 Apr 2003 00:28:21 +0200 To: Daniel Senie From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 4:47 PM -0400 2003/04/29, Daniel Senie wrote: > I don't think that matters. The issue isn't about getting back and > talking to that system. So far as that goes, that's fine. My point was that the public IP address would not be a suitable identifier, because there may not be a public IP address. > It's about being able to have SOME way for > the owner of a set of systems to identify RELIABLY the server which > generated a specific reply. Unless you find some way to modify the DNS protocol so that you can attach a unique identifier to each and every response, I don't see how this is possible. At best, all you could determine is which server answered the VERSION.SERVER (or whatever) query, which would not necessarily have any bearing whatsoever on which server might answer any particular query before or after that one. > It'd be helpful in tracking back problems, > but need not be in a form that is readable to anyone but the owner of > the servers. Given the number of issues I've seen with load balancers > that play stupid DNS tricks, those systems would also benefit from > having some sort of unique identifier transmitted for the same reason. This certainly is at least part of the goal. > What should the identifier be? Something that's been hashed might work. > I don't have a strong opinion on WHAT the value is, provided some > method is determined for generating it. Agreed. > Given the concerns about > multiple interfaces per machine, and multiple name service servers > per host, it may make the most sense to consider some reasonable > means of determining a "default" value (which would suffice for > simple configurations of a single service server) and a way to > configure the value for more advanced situations. The problem is that the situation where something like this is most needed is in those very complex situations. The simple configurations probably don't need this sort of thing. So, while we might still end up going the KISS direction, I think we want to give some serious consideration to the more complex situations and try our best to hash these issues out pretty thoroughly. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 20:58:38 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19305 for ; Tue, 29 Apr 2003 20:58:37 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U0dYRN014164 for ; Wed, 30 Apr 2003 02:39:34 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3U0dYxv014163 for dnsop-outgoing; Wed, 30 Apr 2003 02:39:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U0dWRN014158 for ; Wed, 30 Apr 2003 02:39:33 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 2F0F7137F04; Tue, 29 Apr 2003 17:39:32 -0700 (PDT) Date: Tue, 29 Apr 2003 17:39:32 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , Paul Vixie , dnsop@cafax.se To: Brad Knowles From: David Conrad In-Reply-To: Message-Id: <35723D98-7AA4-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, April 29, 2003, at 03:28 AM, Brad Knowles wrote: > At 11:08 AM -0700 2003/04/28, Randy Bush wrote: > >> my experience in managing servers is that they have a unique >> unicast ip address. even the anycast ones do so that they can be >> managed, transfer zones, ... > > True, but if you have multiple server processes per IP address, or > perhaps multiple IP addresses with different "views" assigned to each? The draft says 'per server'. I'll modify that to 'per server process'. As 'views' are implementation specific, I'd prefer not to reference them. > We need something that will be unique per server process (not per > machine), and will be persistent across program restarts, server > reboots, changes of IP address, etc.... A value in a configuration file won't suffice? Rgds, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 20:58:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19306 for ; Tue, 29 Apr 2003 20:58:37 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U0Y1RN014068 for ; Wed, 30 Apr 2003 02:34:01 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3U0Y1xW014067 for dnsop-outgoing; Wed, 30 Apr 2003 02:34:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U0XxRN014062 for ; Wed, 30 Apr 2003 02:34:00 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 930EB137F04; Tue, 29 Apr 2003 17:33:58 -0700 (PDT) Date: Tue, 29 Apr 2003 17:33:57 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Bruce Campbell , Randy Bush , To: Brad Knowles From: David Conrad In-Reply-To: Message-Id: <6DF2A584-7AA3-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Brad, On Tuesday, April 29, 2003, at 03:24 AM, Brad Knowles wrote: > Still, it's not deterministic, and any number of samples that can be > counted by a human being are going to be vanishingly small compared to > the real workload of the server. At best, it's a "good" indication, > for some value of "good". Unless the DNS protocol is modified to include server identifying information for each and every query (and we modify DNS using applications to archive that information), there is no solution to this problem that I am aware of. Regardless of whether anycast is being used, you first have to notice a problem, then you have to figure out which IP address provided the bad response (since ordering of NSes between queries is not guaranteed). Given this is a multi-step process, the use of sampling is pretty much required. However, this whole issue is a rare corner case. If the draft was talking about something people had to rely on, the lack of determinism in a corner case might be worth arguing about. However, the draft isn't. It is talking about a minor modification to an existing convention that merely _helps_ when trying to track down a problem. Rgds, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 21:12:29 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19688 for ; Tue, 29 Apr 2003 21:12:27 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U0mfRN014276 for ; Wed, 30 Apr 2003 02:48:41 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3U0mfxE014275 for dnsop-outgoing; Wed, 30 Apr 2003 02:48:41 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U0mdRN014270 for ; Wed, 30 Apr 2003 02:48:40 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id CB96D137F04; Tue, 29 Apr 2003 17:48:38 -0700 (PDT) Date: Tue, 29 Apr 2003 17:48:38 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dnsop@cafax.se To: Peter Koch From: David Conrad In-Reply-To: <200304291923.h3TJNpb10740@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-Id: <7B18A9C0-7AA5-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Peter, Thanks for the comments (sorry for the slow reply)... On Tuesday, April 29, 2003, at 12:23 PM, Peter Koch wrote: > To answer David's initial question, I do not feel it's ready for last > call. OK. > First, I agree that the en passant reassignment of the CHAOS class is a > problem. It's not even clear that IANA (whichever instance) is in > charge of > allocating a TLD there, at least I do not see a hint in RFC 2929. Yeah. So, I looked into this a (very small) bit and couldn't figure out who to ask at MIT to see if anyone there still uses CHAOSNet and/or whether it would be OK to use the .SERVER domain for this purpose (or perhaps to see what their reaction is to the existing use of .BIND). > Since it's probably unwise to wait for an officially blessed TLD, it > might > be better to change to a subdomain of the ARPA TLD. I am highly skeptical this would be faster, but maybe I'm too cynical. > The problem remains > to find who's in charge of managing that in the CH class. Yes. Suggestions welcome. > That aside, it should be explicitly stated that queries MUST NOT be > processed with recursion. Agreed. > With respect to the Security Considerations I think it supports > "security by > obscurity" a bit. While it may be useful to conceal or even change the > "real" IP address of an anycast nameserver in critical infrastructure > to > avoid (D)DoS to this address, I'd rather not encourage filtering > identity > queries. I tend to agree that not providing identifying information sort of defeats the purpose, however my thought here was that if I didn't put "implementors SHOULD provide a way to limit who can query" we'd get stuck in the privacy/security swamp. Rgds, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 21:26:29 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20374 for ; Tue, 29 Apr 2003 21:26:28 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U17wRN014454 for ; Wed, 30 Apr 2003 03:07:58 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3U17wXu014453 for dnsop-outgoing; Wed, 30 Apr 2003 03:07:58 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U17vRN014446 for ; Wed, 30 Apr 2003 03:07:57 +0200 (MEST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.7/8.11.7) with ESMTP id h3U17r813286 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO); Tue, 29 Apr 2003 21:07:54 -0400 Message-Id: <5.2.1.1.2.20030429200615.01b9e6a0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 29 Apr 2003 20:58:51 -0400 To: Brad Knowles From: Daniel Senie Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: dnsop@cafax.se In-Reply-To: References: <5.2.1.1.2.20030429164037.01b9fe30@mail.amaranth.net> <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> <5.2.1.1.2.20030429164037.01b9fe30@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk At 06:28 PM 4/29/2003, Brad Knowles wrote: >At 4:47 PM -0400 2003/04/29, Daniel Senie wrote: > >> I don't think that matters. The issue isn't about getting back and >> talking to that system. > > So far as that goes, that's fine. My point was that the public > IP address would not be a suitable identifier, because there may not be a > public IP address. > >> It's about being able to have SOME way for >> the owner of a set of systems to identify RELIABLY the server which >> generated a specific reply. > > Unless you find some way to modify the DNS protocol so that you > can attach a unique identifier to each and every response, I don't see > how this is possible. I agree with you. The only way I see to provide information about the server that provided the response would be to include that information in the additional section of the response. Since the additional section would not normally contain whatever record we might add to express this, we would certainly learn just how liberal servers are in what they receive. > At best, all you could determine is which server answered the > VERSION.SERVER (or whatever) query, which would not necessarily have any > bearing whatsoever on which server might answer any particular query > before or after that one. Once the response is received, no amount of asking further questions will give you certain knowledge. If a need exists to solve this problem, it's likely the answer is in adjusting protocol. Are we interested in a solution? >> It'd be helpful in tracking back problems, >> but need not be in a form that is readable to anyone but the owner of >> the servers. Given the number of issues I've seen with load balancers >> that play stupid DNS tricks, those systems would also benefit from >> having some sort of unique identifier transmitted for the same reason. > > This certainly is at least part of the goal. > >> What should the identifier be? Something that's been hashed might work. >> I don't have a strong opinion on WHAT the value is, provided some >> method is determined for generating it. > > Agreed. > >> Given the concerns about >> multiple interfaces per machine, and multiple name service servers >> per host, it may make the most sense to consider some reasonable >> means of determining a "default" value (which would suffice for >> simple configurations of a single service server) and a way to >> configure the value for more advanced situations. > > The problem is that the situation where something like this is > most needed is in those very complex situations. The simple > configurations probably don't need this sort of thing. > > So, while we might still end up going the KISS direction, I think > we want to give some serious consideration to the more complex situations > and try our best to hash these issues out pretty thoroughly. It may well be that choosing the method of deciding the unique identifier is the least of our troubles. Let's worry about how to transmit the data, and if we can transmit the data first. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 21:56:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21052 for ; Tue, 29 Apr 2003 21:56:23 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U1OpRN015103 for ; Wed, 30 Apr 2003 03:24:51 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3U1OpjK015102 for dnsop-outgoing; Wed, 30 Apr 2003 03:24:51 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U1OmRN015097 for ; Wed, 30 Apr 2003 03:24:48 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3U1OYtY091539; Tue, 29 Apr 2003 21:24:46 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <35723D98-7AA4-11D7-B0B2-000393DB42B2@nominum.com> References: <35723D98-7AA4-11D7-B0B2-000393DB42B2@nominum.com> Date: Wed, 30 Apr 2003 03:19:33 +0200 To: David Conrad From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: Brad Knowles , Randy Bush , Paul Vixie , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 5:39 PM -0700 2003/04/29, David Conrad wrote: > The draft says 'per server'. I'll modify that to 'per server process'. > As 'views' are implementation specific, I'd prefer not to reference them. The technique used in BIND may be implementation specific, but the concept is not. I would not be at all surprised if other servers adopt a similar technique, and therefore I'd suggest that the issue at least be considered. > A value in a configuration file won't suffice? That would be fine by me. I don't really care what it is, so long as it meets the criteria previously mentioned. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 21:56:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21051 for ; Tue, 29 Apr 2003 21:56:23 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U1UlRN015645 for ; Wed, 30 Apr 2003 03:30:47 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3U1Ul06015644 for dnsop-outgoing; Wed, 30 Apr 2003 03:30:47 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U1UkRN015639 for ; Wed, 30 Apr 2003 03:30:46 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3U1UetS091847; Tue, 29 Apr 2003 21:30:42 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <5.2.1.1.2.20030429200615.01b9e6a0@mail.amaranth.net> References: <5.2.1.1.2.20030429164037.01b9fe30@mail.amaranth.net> <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> <518783F5-7943-11D7-A953-000393DB42B2@nominum.com> <5.2.1.1.2.20030429164037.01b9fe30@mail.amaranth.net> <5.2.1.1.2.20030429200615.01b9e6a0@mail.amaranth.net> Date: Wed, 30 Apr 2003 03:28:48 +0200 To: Daniel Senie From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: Brad Knowles , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 8:58 PM -0400 2003/04/29, Daniel Senie wrote: > I agree with you. The only way I see to provide information about > the server that provided the response would be to include that > information in the additional section of the response. Since the > additional section would not normally contain whatever record we > might add to express this, we would certainly learn just how > liberal servers are in what they receive. Hmm. That's a cool idea -- use the additional section, perhaps with a TXT record containing the unique identifier information for the particular server in question. I like it. I'm not sure, but I don't think it would require any protocol modifications, but we'd definitely want to give it some pretty extensive field testing first. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Apr 29 22:22:35 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22007 for ; Tue, 29 Apr 2003 22:22:34 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U1wrRN015975 for ; Wed, 30 Apr 2003 03:58:53 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3U1wr0C015974 for dnsop-outgoing; Wed, 30 Apr 2003 03:58:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3U1wpRN015969 for ; Wed, 30 Apr 2003 03:58:52 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id BBDD6137F12; Tue, 29 Apr 2003 18:58:50 -0700 (PDT) Date: Tue, 29 Apr 2003 18:58:50 -0700 Subject: Re: draft-ietf-dnsop-serverid-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brad Knowles , dnsop@cafax.se To: Daniel Senie From: David Conrad In-Reply-To: <5.2.1.1.2.20030429200615.01b9e6a0@mail.amaranth.net> Message-Id: <49EAC910-7AAF-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Daniel, On Tuesday, April 29, 2003, at 05:58 PM, Daniel Senie wrote: > Once the response is received, no amount of asking further questions > will give you certain knowledge. In theory, yup. > If a need exists to solve this problem, it's likely the answer is in > adjusting protocol. Are we interested in a solution? I suspect this would be a topic for DNSEXT. In the meantime, given a server returning bogus information is most likely unrelated to routing instability which is where the CH class ID.SERVER hack wouldn't work, wouldn't it be nice to have an imperfect way of handling the vast majority of cases? Rgds, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 08:04:22 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29379 for ; Wed, 30 Apr 2003 08:04:21 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UBgGRN020496 for ; Wed, 30 Apr 2003 13:42:16 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UBgGxC020495 for dnsop-outgoing; Wed, 30 Apr 2003 13:42:16 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UBg4RN020490 for ; Wed, 30 Apr 2003 13:42:15 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3UBg1tS045174; Wed, 30 Apr 2003 07:42:03 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <49EAC910-7AAF-11D7-B0B2-000393DB42B2@nominum.com> References: <49EAC910-7AAF-11D7-B0B2-000393DB42B2@nominum.com> Date: Wed, 30 Apr 2003 13:12:33 +0200 To: David Conrad From: Brad Knowles Subject: Re: draft-ietf-dnsop-serverid-01.txt Cc: Daniel Senie , Brad Knowles , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 6:58 PM -0700 2003/04/29, David Conrad wrote: > In the meantime, given a server returning bogus information is most > likely unrelated to routing instability which is where the CH class > ID.SERVER hack wouldn't work, wouldn't it be nice to have an imperfect > way of handling the vast majority of cases? Having ID.SERVER is certainly an improvement over what we have now, which is nothing. I think we can worry about the other issues separately. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:11:34 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24395 for ; Wed, 30 Apr 2003 17:10:29 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UKZLRN026308 for ; Wed, 30 Apr 2003 22:35:21 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UKZL8S026307 for dnsop-outgoing; Wed, 30 Apr 2003 22:35:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UKZKRN026302 for ; Wed, 30 Apr 2003 22:35:21 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19AyIS-000LbY-00 for dnsop@cafax.se; Wed, 30 Apr 2003 20:35:20 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19AyIM-000APp-24 for dnsop@cafax.se; Wed, 30 Apr 2003 13:35:14 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Apr 2003 13:35:13 -0700 To: dns op wg Subject: example.com Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit the iesg wonders whether it should be seriously pushing back on domain names used as examples in drafts that are not drawn from rfc 2606. the opinion of dnsop is solicited. thanks. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:18:40 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24520 for ; Wed, 30 Apr 2003 17:18:39 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UKwrRN026548 for ; Wed, 30 Apr 2003 22:58:53 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UKwrli026547 for dnsop-outgoing; Wed, 30 Apr 2003 22:58:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UKwqRN026542 for ; Wed, 30 Apr 2003 22:58:52 +0200 (MEST) Received: by smtp2.arin.net (Postfix, from userid 5003) id A33F13A8; Wed, 30 Apr 2003 16:58:51 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 386B7363; Wed, 30 Apr 2003 16:58:51 -0400 (EDT) Received: from [192.136.136.70] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 220201; Wed, 30 Apr 2003 16:48:26 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: References: Date: Wed, 30 Apr 2003 16:58:57 -0400 To: Randy Bush From: Edward Lewis Subject: Re: example.com Cc: dns op wg Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1 Sender: owner-dnsop@cafax.se Precedence: bulk No - I think there are more serious problems to be concerned with. Other thoughts: I don't think that the value of data elements (such as a domain name) impact the chance that a document can be clearly used by multiple, independent implementation parties to produce interoperable code. I would encourage the use of the example domains in the ID-nits document, but label it as an unenforced suggestion. At 13:35 -0700 4/30/03, Randy Bush wrote: >the iesg wonders whether it should be seriously pushing back on >domain names used as examples in drafts that are not drawn from >rfc 2606. the opinion of dnsop is solicited. thanks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:28:23 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24774 for ; Wed, 30 Apr 2003 17:27:18 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UL8URN026740 for ; Wed, 30 Apr 2003 23:08:30 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UL8Uri026739 for dnsop-outgoing; Wed, 30 Apr 2003 23:08:30 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from 12-234-22-23.client.attbi.com (12-234-22-23.client.attbi.com [12.234.22.23]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UL8SRN026729 for ; Wed, 30 Apr 2003 23:08:29 +0200 (MEST) Received: from dougbarton.net (master.dougb.net [10.0.0.2]) by 12-234-22-23.client.attbi.com (8.12.9/8.12.9) with ESMTP id h3UL8QaZ090548; Wed, 30 Apr 2003 14:08:27 -0700 (PDT) (envelope-from DougB@dougbarton.net) Message-ID: <3EB03B4A.60002@dougbarton.net> Date: Wed, 30 Apr 2003 14:08:26 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush CC: dns op wg Subject: Re: example.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > the iesg wonders whether it should be seriously pushing back on > domain names used as examples in drafts that are not drawn from > rfc 2606. Yes, they should. I think the reasoning is obvious ... Doug #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:29:38 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24837 for ; Wed, 30 Apr 2003 17:29:37 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UL67RN026687 for ; Wed, 30 Apr 2003 23:06:07 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UL67hP026686 for dnsop-outgoing; Wed, 30 Apr 2003 23:06:07 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UL66RN026681 for ; Wed, 30 Apr 2003 23:06:06 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19AymD-000Nvj-00; Wed, 30 Apr 2003 21:06:05 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19AykI-000ASu-6w; Wed, 30 Apr 2003 14:04:06 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Apr 2003 14:04:05 -0700 To: Edward Lewis Cc: dns op wg Subject: Re: example.com References: Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit >> the iesg wonders whether it should be seriously pushing back on >> domain names used as examples in drafts that are not drawn from >> rfc 2606. the opinion of dnsop is solicited. thanks. > No - I think there are more serious problems to be concerned with. > Other thoughts: > I don't think that the value of data elements (such as a domain name) > impact the chance that a document can be clearly used by multiple, > independent implementation parties to produce interoperable code. > > I would encourage the use of the example domains in the ID-nits > document, but label it as an unenforced suggestion. people cut and paste from examples. what if queries are generated to foo.x? how did 192.0.2.0/24 become glowing slag? randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:33:17 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24948 for ; Wed, 30 Apr 2003 17:33:16 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULEaRN026854 for ; Wed, 30 Apr 2003 23:14:36 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULEa0K026853 for dnsop-outgoing; Wed, 30 Apr 2003 23:14:36 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULEZRN026848 for ; Wed, 30 Apr 2003 23:14:35 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19AyuQ-000OkR-00; Wed, 30 Apr 2003 21:14:35 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19AyuM-000AUx-VZ; Wed, 30 Apr 2003 14:14:31 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Apr 2003 14:14:30 -0700 To: Doug Barton Cc: dns op wg Subject: Re: example.com References: <3EB03B4A.60002@dougbarton.net> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit >> the iesg wonders whether it should be seriously pushing back on >> domain names used as examples in drafts that are not drawn from >> rfc 2606. > Yes, they should. I think the reasoning is obvious ... i suspect it is not obvious to all. so you might help explain a bit. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:49:42 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25259 for ; Wed, 30 Apr 2003 17:49:41 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULQFRN027052 for ; Wed, 30 Apr 2003 23:26:15 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULQFLE027051 for dnsop-outgoing; Wed, 30 Apr 2003 23:26:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULQERN027046 for ; Wed, 30 Apr 2003 23:26:14 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3A2EB137F0E; Wed, 30 Apr 2003 14:26:13 -0700 (PDT) Date: Wed, 30 Apr 2003 14:26:12 -0700 Subject: Re: example.com Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , dns op wg To: Edward Lewis From: David Conrad In-Reply-To: Message-Id: <5E16A9D2-7B52-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit me too On Wednesday, April 30, 2003, at 01:58 PM, Edward Lewis wrote: > No - I think there are more serious problems to be concerned with. > > Other thoughts: > I don't think that the value of data elements (such as a domain > name) impact the chance that a document can be clearly used by > multiple, independent implementation parties to produce > interoperable > code. > > I would encourage the use of the example domains in the ID-nits > document, > but label it as an unenforced suggestion. > > At 13:35 -0700 4/30/03, Randy Bush wrote: >> the iesg wonders whether it should be seriously pushing back on >> domain names used as examples in drafts that are not drawn from >> rfc 2606. the opinion of dnsop is solicited. thanks. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > It's true, my last college class really was "Introduction to Ada." > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:49:43 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25258 for ; Wed, 30 Apr 2003 17:49:41 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULT2RN027106 for ; Wed, 30 Apr 2003 23:29:02 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULT2EA027105 for dnsop-outgoing; Wed, 30 Apr 2003 23:29:02 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from 12-234-22-23.client.attbi.com (12-234-22-23.client.attbi.com [12.234.22.23]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULT1RN027100 for ; Wed, 30 Apr 2003 23:29:01 +0200 (MEST) Received: from dougbarton.net (master.dougb.net [10.0.0.2]) by 12-234-22-23.client.attbi.com (8.12.9/8.12.9) with ESMTP id h3ULT0aZ090865; Wed, 30 Apr 2003 14:29:00 -0700 (PDT) (envelope-from DougB@dougbarton.net) Message-ID: <3EB0401C.8020905@dougbarton.net> Date: Wed, 30 Apr 2003 14:29:00 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush CC: dns op wg Subject: Re: example.com References: <3EB03B4A.60002@dougbarton.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: >>>the iesg wonders whether it should be seriously pushing back on >>>domain names used as examples in drafts that are not drawn from >>>rfc 2606. >> >>Yes, they should. I think the reasoning is obvious ... > > > i suspect it is not obvious to all. so you might help explain a > bit. Well, the first two paragraphs of section two lay out the reasoning I'm referring to. There is no reason to use other names in the documentation when there are perfectly suitable examples designed specifically to be used in documentation available. In addition to the general issue of not using domain names that could someday be allocated for a real purpose, actually "following our own rules" increases the perception of professionalism of the work product on the part of those who come after. To people with a high level of technical sophistication, these are trivial matters. However, we can't know the audience down the road, so the more internally consistent the products of the IETF process are, the lower the barrier of understanding to the real point of a given document. Doug #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:53:26 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25383 for ; Wed, 30 Apr 2003 17:53:25 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULVKRN027144 for ; Wed, 30 Apr 2003 23:31:20 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULVK3T027143 for dnsop-outgoing; Wed, 30 Apr 2003 23:31:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULVIRN027138 for ; Wed, 30 Apr 2003 23:31:19 +0200 (MEST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3ULVFI17422; Wed, 30 Apr 2003 14:31:15 -0700 (PDT) From: Bill Manning Message-Id: <200304302131.h3ULVFI17422@boreas.isi.edu> Subject: Re: example.com In-Reply-To: from Randy Bush at "Apr 30, 3 02:04:05 pm" To: randy@psg.com (Randy Bush) Date: Wed, 30 Apr 2003 14:31:15 -0700 (PDT) Cc: edlewis@arin.net, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit % how did 192.0.2.0/24 become glowing slag? % % randy because the IANA earmarked it for documentation purposes. --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). #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:55:25 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25446 for ; Wed, 30 Apr 2003 17:55:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULW1RN027170 for ; Wed, 30 Apr 2003 23:32:01 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULW1fZ027169 for dnsop-outgoing; Wed, 30 Apr 2003 23:32:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULW0RN027164 for ; Wed, 30 Apr 2003 23:32:00 +0200 (MEST) Received: by smtp2.arin.net (Postfix, from userid 5003) id 5873E3B8; Wed, 30 Apr 2003 17:32:00 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id DAF3A362; Wed, 30 Apr 2003 17:31:59 -0400 (EDT) Received: from [192.136.136.50] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 220265; Wed, 30 Apr 2003 17:21:35 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: References: Date: Wed, 30 Apr 2003 17:32:06 -0400 To: Randy Bush From: Edward Lewis Subject: Re: example.com Cc: Edward Lewis , dns op wg Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1 Sender: owner-dnsop@cafax.se Precedence: bulk At 14:04 -0700 4/30/03, Randy Bush wrote: >people cut and paste from examples. what if queries are generated >to foo.x? how did 192.0.2.0/24 become glowing slag? If the IESG wants to worry about what names are in the domain name examples, go ahead. I was just throwing out some reasons why I think that time is better spent on other issues. The reason I stick to "example.com." or "example." is that if I were to say, use "slashdot.net." in an RFC, I might be slashdot-ting them. I try to stick to examples that, if abused, hurt only me and not an innocent bystander. I, for one, am not concerned about an RFC inducing folks to hit the root servers with bogus domain names. Popular commercial code is more efficient at doing this than the RFCs. I will abide by using "example." because I think it is wise to use safe examples. But, since you asked, I would say that the time commitment to strictly enforce this is time that is in the 'diminishing returns' category. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:59:37 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25598 for ; Wed, 30 Apr 2003 17:59:36 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULXxRN027219 for ; Wed, 30 Apr 2003 23:33:59 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULXxU6027218 for dnsop-outgoing; Wed, 30 Apr 2003 23:33:59 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULXwRN027213 for ; Wed, 30 Apr 2003 23:33:58 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19AzDB-0000Qk-00; Wed, 30 Apr 2003 21:33:57 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19AzD7-000AWQ-It; Wed, 30 Apr 2003 14:33:53 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Apr 2003 14:33:53 -0700 To: Bill Manning Cc: dnsop@cafax.se Subject: Re: example.com References: <200304302131.h3ULVFI17422@boreas.isi.edu> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit >> how did 192.0.2.0/24 become glowing slag? > because the IANA earmarked it for documentation purposes. that was long after. it was in sunos docs and people actually used it, cut and paste. thus it became useless. so folk asked sri to slag it. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 17:59:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25560 for ; Wed, 30 Apr 2003 17:58:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULcaRN027323 for ; Wed, 30 Apr 2003 23:38:36 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULcahA027322 for dnsop-outgoing; Wed, 30 Apr 2003 23:38:36 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULcZRN027317 for ; Wed, 30 Apr 2003 23:38:35 +0200 (MEST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3ULcMk24219; Wed, 30 Apr 2003 14:38:22 -0700 (PDT) From: Bill Manning Message-Id: <200304302138.h3ULcMk24219@boreas.isi.edu> Subject: Re: example.com In-Reply-To: from Randy Bush at "Apr 30, 3 02:33:53 pm" To: randy@psg.com (Randy Bush) Date: Wed, 30 Apr 2003 14:38:21 -0700 (PDT) Cc: bmanning@ISI.EDU, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit % >> how did 192.0.2.0/24 become glowing slag? % > because the IANA earmarked it for documentation purposes. % % that was long after. it was in sunos docs and people actually used it, % cut and paste. thus it became useless. so folk asked sri to slag it. % % randy You are thinking of 192.2.200.0/24 not 192.0.2.0/24 --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). #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 18:00:15 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25657 for ; Wed, 30 Apr 2003 18:00:14 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULfFRN027435 for ; Wed, 30 Apr 2003 23:41:15 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULfFCo027434 for dnsop-outgoing; Wed, 30 Apr 2003 23:41:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULfERN027429 for ; Wed, 30 Apr 2003 23:41:14 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19AzKD-00010h-00; Wed, 30 Apr 2003 21:41:14 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19AzK8-000AX4-9i; Wed, 30 Apr 2003 14:41:08 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Apr 2003 14:41:07 -0700 To: Bill Manning Cc: dnsop@cafax.se Subject: Re: example.com References: <200304302138.h3ULcMk24219@boreas.isi.edu> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit >> that was long after. it was in sunos docs and people actually used it, >> cut and paste. thus it became useless. so folk asked sri to slag it. > You are thinking of 192.2.200.0/24 not 192.0.2.0/24 could be. long day. sorry. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 18:20:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27052 for ; Wed, 30 Apr 2003 18:19:18 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UM0ZRN027930 for ; Thu, 1 May 2003 00:00:35 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UM0ZdU027929 for dnsop-outgoing; Thu, 1 May 2003 00:00:35 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UM0YRN027922 for ; Thu, 1 May 2003 00:00:34 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Azcv-0002wg-00; Wed, 30 Apr 2003 22:00:33 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19Azcr-000AYk-4S; Wed, 30 Apr 2003 15:00:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Apr 2003 15:00:28 -0700 To: Alain Durand Cc: dns op wg Subject: Re: example.com References: Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > In a related category, but not DNSop specific, the IESG should enforce > the usage of documentation prefixes, such as the one recently reserved > by APNIC for IPv6. There is little value to enforcing one without the > other... i don't think this is the place for general id nits discussion. too much noise and most interested parties not here. i asked dnsop specifically to learn of any technical ops issues. and i really meant the question. are there technical ops issues? randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 19:00:25 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28805 for ; Wed, 30 Apr 2003 19:00:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UMZTRN028532 for ; Thu, 1 May 2003 00:35:29 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UMZTdl028531 for dnsop-outgoing; Thu, 1 May 2003 00:35:29 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UMZRRN028526 for ; Thu, 1 May 2003 00:35:28 +0200 (MEST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3UMPBZj024870; Wed, 30 Apr 2003 18:25:11 -0400 (EDT) Message-Id: <200304302225.h3UMPBZj024870@nic-naa.net> To: Randy Bush cc: dns op wg , brunner@nic-naa.net Subject: Re: example.com In-Reply-To: Your message of "Wed, 30 Apr 2003 13:35:13 PDT." Date: Wed, 30 Apr 2003 18:25:11 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-dnsop@cafax.se Precedence: bulk 2. TLDs for Testing, & Documentation Examples .{test,example,invalid,localhost} Useful for private roots and partitioned nets that will heal w/o collision? Yes. Useful for discussing IANA (iso3166) or ICANN ({g,s}TLD) registries? No. Personal preference: .tld 3. Reserved Example Second Level Domain Names example.{com,net,org} Useful for discussing SLDs and registries other-than above? Yes. Verisign (and now PIR) -centric? Yes. Useful for discussing corporate and publid registries with polices unlike the CNO model? No. Personal use (draft-brunner-epp-smtp-nn.txt): .nld (somewhere in the delegation-chain, probably not holland) .tld (top of the delegation-chain (minus rhs ".")) e.g., epp+smtp@utterly-bogus.nld Other use (provreg mailing list): sld.tld, (somewhere specific in the delegation-chain) I agree with Ed, there are more serious problems. Eric #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 19:00:26 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28804 for ; Wed, 30 Apr 2003 19:00:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UMabRN028553 for ; Thu, 1 May 2003 00:36:37 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UMabZ0028552 for dnsop-outgoing; Thu, 1 May 2003 00:36:37 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UMaZRN028546 for ; Thu, 1 May 2003 00:36:35 +0200 (MEST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3UMaXC24211 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 30 Apr 2003 18:36:34 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h3UMaW64016057 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 30 Apr 2003 18:36:33 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h3UMaWfx016053 for ; Wed, 30 Apr 2003 18:36:32 -0400 Message-Id: <200304302236.h3UMaWfx016053@marajade.sandelman.ottawa.on.ca> To: dns op wg Subject: Re: example.com In-reply-to: Your message of "Wed, 30 Apr 2003 14:04:05 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 30 Apr 2003 18:36:31 -0400 From: Michael Richardson Sender: owner-dnsop@cafax.se Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Randy" == Randy Bush writes: Randy> people cut and paste from examples. what if queries are generated Randy> to foo.x? how did 192.0.2.0/24 become glowing slag? Are you saying that 192.0.2.0/24 got screwed by documents? I thought that it was Sun that screwed that up by making zillions of workstations in the 1980s with 192.0.1.1 as their first IP and 192.0.2.1 as the IP for their second ethernet card. Anyway, I was looking the document that sets 192.0.2.0/24 aside for examples, I couldn't find it. I was also looking for an IPv6 equivalent. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPrBP7oqHRg3pndX9AQHI2QQAgL9PCwbWTq89nDVaZlUSFO6GQMduqjl9 tqqmc5UGwKRoxNkQr32dD3Ga/7KPqzIQwiGdCDgWNyF9yO83Ww70GeXQ9peYI9ll THSdPqCSIYsw+vITY6wasVvJAxdE8UWhtzWn8nVBzc3RyoIVi5ZlqVtWkFiUL8xL hC+uj2A+HCA= =ZxO1 -----END PGP SIGNATURE----- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 19:05:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27051 for ; Wed, 30 Apr 2003 18:19:18 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULvORN027843 for ; Wed, 30 Apr 2003 23:57:24 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ULvON1027842 for dnsop-outgoing; Wed, 30 Apr 2003 23:57:24 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ULvMRN027837 for ; Wed, 30 Apr 2003 23:57:23 +0200 (MEST) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA16395 for ; Wed, 30 Apr 2003 15:57:21 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HE6001MPFLPQI@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Wed, 30 Apr 2003 15:56:13 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HE6005M6FLOIH@mail.sun.net> for dnsop@cafax.se; Wed, 30 Apr 2003 15:56:13 -0600 (MDT) Date: Wed, 30 Apr 2003 14:57:43 -0700 From: Alain Durand Subject: Re: example.com In-reply-to: To: Randy Bush Cc: dns op wg Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT On Wednesday, April 30, 2003, at 01:35 PM, Randy Bush wrote: > the iesg wonders whether it should be seriously pushing back on > domain names used as examples in drafts that are not drawn from > rfc 2606. the opinion of dnsop is solicited. thanks. It would be great! In a related category, but not DNSop specific, the IESG should enforce the usage of documentation prefixes, such as the one recently reserved by APNIC for IPv6. There is little value to enforcing one without the other... - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 19:13:06 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29102 for ; Wed, 30 Apr 2003 19:12:01 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UMeYRN028623 for ; Thu, 1 May 2003 00:40:34 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UMeYQ7028622 for dnsop-outgoing; Thu, 1 May 2003 00:40:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UMeXRN028617 for ; Thu, 1 May 2003 00:40:33 +0200 (MEST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 40A37137F15; Wed, 30 Apr 2003 15:40:32 -0700 (PDT) Date: Wed, 30 Apr 2003 15:40:31 -0700 Subject: Re: example.com Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alain Durand , dns op wg To: Randy Bush From: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit From a technical perspective, it would make sense to use the documentation set-asides as specified. However, as I indicated, I agree with Ed in that there appear to be plenty of other things that cause constipation within the IESG without adding requirements for ultimately futile attempts at protecting people from themselves to the list. However, this is decidedly non-technical. On Wednesday, April 30, 2003, at 03:00 PM, Randy Bush wrote: >> In a related category, but not DNSop specific, the IESG should enforce >> the usage of documentation prefixes, such as the one recently reserved >> by APNIC for IPv6. There is little value to enforcing one without the >> other... > > i don't think this is the place for general id nits discussion. too > much > noise and most interested parties not here. > > i asked dnsop specifically to learn of any technical ops issues. and i > really meant the question. are there technical ops issues? > > randy > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 20:19:58 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01158 for ; Wed, 30 Apr 2003 20:19:57 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UNtARN029440 for ; Thu, 1 May 2003 01:55:10 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UNtAcO029439 for dnsop-outgoing; Thu, 1 May 2003 01:55:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UNt9RN029428 for ; Thu, 1 May 2003 01:55:09 +0200 (MEST) Received: from [10.0.1.2] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h3UNt2tU096404; Wed, 30 Apr 2003 19:55:07 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: Date: Thu, 1 May 2003 01:54:51 +0200 To: Randy Bush From: Brad Knowles Subject: Re: example.com Cc: Alain Durand , dns op wg Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 3:00 PM -0700 2003/04/30, Randy Bush wrote: > i asked dnsop specifically to learn of any technical ops issues. and i > really meant the question. are there technical ops issues? No, I don't think there are any technical ops issues. Indeed, I think we probably have fairly broad consensus that, on purely technical grounds, we should definitely be doing the sort of things recommended by the referenced RFCs. -- 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(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Apr 30 21:51:17 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02660 for ; Wed, 30 Apr 2003 21:50:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h411PHRN000678 for ; Thu, 1 May 2003 03:25:17 +0200 (MEST) Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h411PHJW000677 for dnsop-outgoing; Thu, 1 May 2003 03:25:17 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from zydeco.netbusters.com (zydeco.netbusters.com [66.92.86.178]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h411PARN000672 for ; Thu, 1 May 2003 03:25:13 +0200 (MEST) Received: by zydeco.netbusters.com (Postfix, from userid 513) id 9E03AB63C9; Thu, 1 May 2003 01:25:09 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 9CA667EC1D for ; Wed, 30 Apr 2003 21:25:09 -0400 (EDT) Date: Wed, 30 Apr 2003 21:25:09 -0400 (EDT) From: Donald Eastlake 3rd X-X-Sender: dee3@zydeco.netbusters.com To: dns op wg Subject: Re: example.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk I wouldn't have bothered writing and pushing through the RFC if I didn't think it was reasonably important. Using real existing domain names can lead to operational problems such a denial of service, if some test or example is buggy and runs on the real internet and it may also lead to legal liability if it somehow interferes with a company's operations or is considered to dilute their trade mark. Of course, there are rare cases, usually in DNS related documents, where you need a country code example or something, in which case you just do the best you can. (Earlier drafts of the document reserved one of the "local use" country codes that ISO says it will never assign to a country but Postel nixed all but the four TLDs listed in the RFC.) Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Wed, 30 Apr 2003, Randy Bush wrote: > Date: Wed, 30 Apr 2003 13:35:13 -0700 > From: Randy Bush > To: dns op wg > Subject: example.com > > the iesg wonders whether it should be seriously pushing back on > domain names used as examples in drafts that are not drawn from > rfc 2606. the opinion of dnsop is solicited. thanks. > > randy > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to .