From owner-dnsop@lists.uoregon.edu Fri Apr 1 02:48:39 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23032 for ; Fri, 1 Apr 2005 02:48:39 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j316o6ZJ023324; Thu, 31 Mar 2005 22:50:06 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j316o607023323; Thu, 31 Mar 2005 22:50:06 -0800 (PST) Received: from smtp.denic.de (smtp.denic.de [81.91.161.3]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j316o3eW023224 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 31 Mar 2005 22:50:05 -0800 (PST) Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1DHFyg-0005Gl-Fx; Fri, 01 Apr 2005 08:49:58 +0200 In-Reply-To: <20050329090358.GA19235@atoom.net> To: dnsop Subject: Re: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Marcos Sanz/Denic Message-ID: Date: Fri, 1 Apr 2005 08:49:53 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 01.04.2005 08:49:58, Serialize complete at 01.04.2005 08:49:58 Content-Type: text/plain; charset="US-ASCII" Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Marcos Sanz/Denic Miek, > Sam argues: > Section 4.4.2 suggests storing DNSKEYs, not DSs. I think this is bad > advice -- DS message digest algorithms may be used for signaling (of, > for example, use of NSEC3), so the child may want to choose the > message digest algorithm. Rather than require the parent to > support them all, why not just let the child provide the hash? > > I argue: > My opinion in this is that the DS is a parental record and as such a child may > not even be aware that it exists. This reminds me of the discussion had not a long time ago about the epp-dnssec documents. There, we achieved consensus about the child providing the DS record to the parent and *optionally* key information (and so reflects it epp-secdns-07). IMHO operational practices should be coherent with that (well, or the other way round). Regards, Marcos . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 1 04:11:28 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04749 for ; Fri, 1 Apr 2005 04:11:28 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j3189poo004710; Fri, 1 Apr 2005 00:09:52 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j3189pfD004709; Fri, 1 Apr 2005 00:09:51 -0800 (PST) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j3189oUU004656 for ; Fri, 1 Apr 2005 00:09:50 -0800 (PST) Received: by postman.ripe.net (Postfix, from userid 8) id 89EA425040; Fri, 1 Apr 2005 10:09:44 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 90CC224F72; Fri, 1 Apr 2005 10:09:43 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j3189het032457; Fri, 1 Apr 2005 10:09:43 +0200 Date: Fri, 1 Apr 2005 10:09:43 +0200 From: "Olaf M. Kolkman" To: Marcos Sanz/Denic Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03 Message-Id: <20050401100943.0b2290b8.olaf@ripe.net> In-Reply-To: References: <20050329090358.GA19235@atoom.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,SUBJ_HAS_UNIQ_ID X-RIPE-Spam-Status: U 0.247756 / -4.6 X-RIPE-Signature: c66ae6552af6b0b24064029c39145485 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: "Olaf M. Kolkman" Content-Transfer-Encoding: 7bit Sam writes: > Section 4.4.2 suggests storing DNSKEYs, not DSs. I think this is bad > advice -- DS message digest algorithms may be used for signaling (of, > for example, use of NSEC3), so the child may want to choose the > message digest algorithm. Rather than require the parent to > support them all, why not just let the child provide the hash? The text sais: Should considder if DNSKEY and/or DS are stored. It gives a few argument for storing the DNSKEY and generating the DS. It does not give arguments agains storing the DS. I find it difficult to use your argument "DS message digest algorithms may be used for signaling (of, for example, use of NSEC3)". This signalling mechanism only exists on the drawing board and the draft really describes the initial (testbed and workshop) experiences. Marcos Sanz wrote: > This reminds me of the discussion had not a long time ago about the > epp-dnssec documents. There, we achieved consensus about the child > providing the DS record to the parent and *optionally* key information > (and so reflects it epp-secdns-07). IMHO operational practices should be > coherent with that (well, or the other way round). But that disscussion specifically pertained to the EPP protocol, which is only used in a subset of the DNS operations. AFAIU EPP is mostly used between registries and registrars. Although one of the signing implementation will courteously spit out a DSset, the registrants may still not be able to generate a DS set. These registrants will always have access to the DNSKEY so I think it is fair to suggest to registries to allow for the keys travel to the registries. (I could see the registrars having a system where the DS set is generated for the registrant through a web interface. That webinterface fetches the DNSKEYs from the currently running zone. It selects the SEP keys, allow the user to select one of those keys -- but has a sensible default based on the currently configured DS RR -- and has a button to select the hash. After the interaction with the custommer is finished the EPP protocol takes over from there and signals the information to the registry.) Anyway, back to the matter at hand: I'd be happy to extend paragraph 4.4.2 with the arguments from the EPP discussion to only store the DS RRs (I am hesitant to refer to the EPP document because that will keep the document waiting for the reference to become stable, besides I could not find the argumentation for the choice in the epp-secdns document itself -- I may have overlooked it) Below is a suggestion. Somebody who was really deeply involved in EPP may recall stronger, or even the real, argument :-) . Suggestions: > 4.4.2 Storing Keys So Hashes Can Be Regenerated Change of title: 4.4.2 Storing Keys or Hashes? > When designing a registry system one should consider if the DNSKEYs > and/or the corresponding DSs are stored. Storing DNSKEYs will help > during troubleshooting while the overhead of calculating DS records > from them is minimal. Insert: On the other hand registries may be hesitant to generate data for custommers. That could be a reason to only accept what the data that is published in the DNS; NS and DS RRs. > Having an out-of-band mechanism, such as a Whois database, to find > out which keys are used to generate DS Resource Records for specific > owners and/or zones may also help with troubleshooting. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 1 04:33:37 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05984 for ; Fri, 1 Apr 2005 04:33:36 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j318n5PC025540; Fri, 1 Apr 2005 00:49:06 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j318n53D025539; Fri, 1 Apr 2005 00:49:05 -0800 (PST) Received: from sol.nlnetlabs.nl (sol.nlnetlabs.nl [213.154.224.43]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j318n4Fl025532 for ; Fri, 1 Apr 2005 00:49:05 -0800 (PST) Received: from elektron.atoom.net (vhe-530008.sshn.net [195.169.222.38]) by sol.nlnetlabs.nl (Postfix) with ESMTP id CD0BF1880CC for ; Fri, 1 Apr 2005 10:49:03 +0200 (CEST) Received: by elektron.atoom.net (Postfix, from userid 1000) id B79E0128260; Fri, 1 Apr 2005 10:49:03 +0200 (CEST) Date: Fri, 1 Apr 2005 10:49:03 +0200 From: Miek Gieben To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03 Message-ID: <20050401084903.GB7961@atoom.net> Mail-Followup-To: dnsop@lists.uoregon.edu References: <20050329090358.GA19235@atoom.net> <20050401100943.0b2290b8.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050401100943.0b2290b8.olaf@ripe.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Miek Gieben [On 01 Apr, @ 10:09, Olaf wrote in "Re: [dnsop] paragraph 4.4.2 in ..."] > > 4.4.2 Storing Keys So Hashes Can Be Regenerated > > Change of title: > 4.4.2 Storing Keys or Hashes? > > > When designing a registry system one should consider if the DNSKEYs > > and/or the corresponding DSs are stored. Storing DNSKEYs will help > > during troubleshooting while the overhead of calculating DS records > > from them is minimal. > > Insert: > On the other hand registries may be hesitant to generate data for > custommers. That could be a reason to only accept what the data > that is published in the DNS; NS and DS RRs. > > > > Having an out-of-band mechanism, such as a Whois database, to find > > out which keys are used to generate DS Resource Records for specific > > owners and/or zones may also help with troubleshooting. I, for one, have no trouble with this change, -- grtz, - Miek http://www.miek.nl http://www.nlnetlabs.nl . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 1 05:27:54 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09546 for ; Fri, 1 Apr 2005 05:27:54 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j319TrBZ016318; Fri, 1 Apr 2005 01:29:54 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j319Tr65016317; Fri, 1 Apr 2005 01:29:53 -0800 (PST) Received: from smtp.denic.de (smtp.denic.de [81.91.161.3]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j319TnpT016278 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 1 Apr 2005 01:29:52 -0800 (PST) Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1DHITC-0002PF-Dl; Fri, 01 Apr 2005 11:29:38 +0200 In-Reply-To: <20050401100943.0b2290b8.olaf@ripe.net> To: "Olaf M. Kolkman" Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Marcos Sanz/Denic Message-ID: Date: Fri, 1 Apr 2005 11:29:31 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 01.04.2005 11:29:38, Serialize complete at 01.04.2005 11:29:38 Content-Type: text/plain; charset="US-ASCII" Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Marcos Sanz/Denic Olaf, > Suggestions: > > > 4.4.2 Storing Keys So Hashes Can Be Regenerated > > Change of title: > 4.4.2 Storing Keys or Hashes? Much better. > > When designing a registry system one should consider if the DNSKEYs > > and/or the corresponding DSs are stored. Storing DNSKEYs will help > > during troubleshooting while the overhead of calculating DS records > > from them is minimal. > > Insert: > On the other hand registries may be hesitant to generate data for > custommers. That could be a reason to only accept what the data > that is published in the DNS; NS and DS RRs. Fine for me! Best regards, Marcos . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 1 08:22:52 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23487 for ; Fri, 1 Apr 2005 08:22:51 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j31CJrHR000738; Fri, 1 Apr 2005 04:19:53 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j31CJr1F000737; Fri, 1 Apr 2005 04:19:53 -0800 (PST) Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j31CJpTB000702 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 1 Apr 2005 04:19:52 -0800 (PST) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 01 Apr 2005 07:19:45 -0500 id 0058400B.424D3C61.00004536 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Olaf M. Kolkman'" , "'Marcos Sanz/Denic'" Cc: dnsop@lists.uoregon.edu Subject: RE: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03 Date: Fri, 1 Apr 2005 07:19:37 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF0749C950@dul1wnexmb01.vcorp.ad.vrsn.com> 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.6626 Importance: Normal In-Reply-To: <20050401100943.0b2290b8.olaf@ripe.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: "Scott Hollenbeck" Content-Transfer-Encoding: 7bit > I'd be happy to extend paragraph 4.4.2 with the arguments from the EPP > discussion to only store the DS RRs (I am hesitant to refer to the EPP > document because that will keep the document waiting for the reference > to become stable, besides I could not find the argumentation for the > choice in the epp-secdns document itself -- I may have overlooked it) > Below is a suggestion. Somebody who was really deeply involved in EPP > may recall stronger, or even the real, argument :-) . Olaf, I asked the IESG to review my document yesterday. It's finished (barring last call and IESG review issues) as far as I'm concerned. The rationale is described in the archives of this mailing list. However, it's probably better that the material be included in your document since yours is specifically focused on operational practices. -Scott- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 1 14:22:52 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27887 for ; Fri, 1 Apr 2005 14:22:51 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j31IQPMl018226; Fri, 1 Apr 2005 10:26:25 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j31IQPbt018218; Fri, 1 Apr 2005 10:26:25 -0800 (PST) Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j31IQNLF017969 for ; Fri, 1 Apr 2005 10:26:24 -0800 (PST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j31IMdS1021777 for ; Fri, 1 Apr 2005 13:22:39 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAbhaOHQ; Fri, 1 Apr 05 13:22:37 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j31IOSq8019256; Fri, 1 Apr 2005 13:24:28 -0500 (EST) Date: Fri, 1 Apr 2005 13:24:27 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: "Olaf M. Kolkman" cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Samuel Weiler How about something with a little more explanation and a slightly stronger suggestion? When designing a registry system one should consider which of the DNSKEYs and/or the corresponding DSs to store [or accept from registrants?]. Since a child zone might wish to have a DS published using a message digest algorithm not yet understood by the registry, the registry can't count on being able to generate the DS record from a raw DNSKEY. Thus, we recommend that registry system at least support storing [accepting] DS records. It may also be useful to store [accept] DNSKEYs, since having them may help during troubleshooting and, so long as the child's chosen message digest is supported, the overhead of generating DS records from them is minimal. Having an out-of-band mechanism, such as a Whois database, to find out which keys are used to generate DS Resource Records for specific owners and/or zones may also help with troubleshooting. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Fri Apr 1 16:25:06 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22672 for ; Fri, 1 Apr 2005 16:25:06 -0500 (EST) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j31KNpJu014874; Fri, 1 Apr 2005 12:23:51 -0800 (PST) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j31KNpHm014867; Fri, 1 Apr 2005 12:23:51 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j31KNorE014830 for ; Fri, 1 Apr 2005 12:23:50 -0800 (PST) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.2/8.13.2) with ESMTP id j31KNg7x019739; Fri, 1 Apr 2005 12:23:42 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.2/8.12.11/Submit) id j31KNeQI019738; Fri, 1 Apr 2005 12:23:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 1 Apr 2005 12:23:40 -0800 From: David Meyer To: dnsop@lists.uoregon.edu Cc: sra@isc.org, Suzanne_Woolf@isc.org Subject: [dnsop] WGLC for draft-ietf-dnsop-serverid-04.txt Message-ID: <20050401202340.GA19562@1-4-5.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: David Meyer --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks This note starts the WG Last Call for comments on draft-ietf-dnsop-serverid-04.txt, "Identifying an Authoritative Name Server". It can be found on =20 =09 ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-serverid-04.txt Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG.=20 This Last Call will end on 15 Apr 2005 at 1400 PST (UTC/GMT-8). Thanks, Dave & Rob --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCTa3MORgD1qCZ2KcRAmDeAJ9eR8/LDZBJ4eLxVOFC/n3peXlMIACfZpSa f0WR+XGkiGQn3s0ZYZSgs40= =8bwY -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From kwesi_consultants@indiatimes.com Sun Apr 3 17:22:05 2005 Received: from indiatimes260.com ([217.164.234.177]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27187 for ; Sun, 3 Apr 2005 17:22:03 -0400 (EDT) Message-Id: <200504032122.RAA27187@ietf.org> From: "Bar. Stephen Kwesi" To: dnsop-archive@ietf.org Reply-To: kwesi_consultants@walla.com Subject: From Bar. Stephen kwesi Date: Mon, 04 Apr 2005 01:18:49 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="e0c90d13-a4a4-11d9-8dd4-000d88177f2d" This is a multi-part message in MIME format --e0c90d13-a4a4-11d9-8dd4-000d88177f2d Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable BARRISTER STEPHEN KWESI KWESI CONSULTANTS ACCRA-GHANA TEL/FAX: 00233243601078 EMAIL: kwesi_consultants@walla.com HUMANE/CORDIAL REQUEST FOR ASSISTANCE DEAR FRIEND, I AM BAR. STEPHEN KWESI, A PRACTISING LAWYER AS WELL AS A HUMAN RIGHT = ACTIVIST HERE IN GHANA. I AM CONTACTING YOU BASED ON A DISCUSSION I HAD WITH ONE MISS MARY FATI WHOM = I HAPPEN TO MEET IN THE REFUGEE CAMP IN ONE OF MY REUTINE VISITATIONS TO THE = REFUGEE CAMPS. THE LITTLE MARY (24) IS ORIGINALLY FROM THE WAR ENGULFED AREA OF DARFUR =96 = SUDAN. SHE LOST HER PARENTS AND SIBBLINGS IN THE COST OF THE WAR AND SHE IS ALL = ALONE NOW BUT SHE WAS FORTUNATE TO FIND A SAFE IN HER FATHER=92S PRIVATE ROOM = AND THIS SAFE CONTAINS A TOTAL SUM OF SIXTEEN MILLION, FIVE HUNDRED THOUSAND = UNITED STATES DOLLARS ONLY (US$16,500,000.00). THIS SAFE WAS SUCCESSFULLY DEPOSITED WITH A PRIVATE SECURITY COMPANY HERE IN = GHANA AS FAMILY BELONGINGS, WHICH I HAVE CONFIRMED WITH THE COMPANY AS SHE = HAS HANDED OVER ALL THE RELEVANT DOCUMENTS OF THIS DEPOSIT TO ME. I HAVE CONFIRMED HER NEEDS AND THEY INCLUDE, HELPING HER RECEIVE HER FUND IN = A SECURED ACCOUNT, HELPING HER ARRANGE A TRAVELLING DOCUMENT OUT OF GHANA, = ASSISTING HER IN A WAY TO COMPLETE HER EDUCATION AND FINALLY AND MOST = IMPORTANTLY GUIDING HER IN INVESTMENT PURPOSES WITH THIS FUND. MY DEAR, I HAVE LITTLE KNOWLEDGE ABOUT YOUR ABILITY AND WOULD WANT YOU TO = WORK WITH ME IN HELPING THIS LITTLE GIRL WHOSE SITUATION IS QUIT PITIABLE. = YOU WILL BE COMPENSATED APPROPRIATELY. I WILL LINK YOU UP TO HER IF YOU WISH = TO OTHERWISE WE COULD DISCUSS ON POSSIBLE WAYS OF FINALISING THIS = TRANSACTION. YOU CAN REACH ME DIRECTLY ON THE ABOVE TELEPHONE NUMBER OR EMAIL OR YOU CAN = REACH LITTLE MARY VIA HER EMAIL ADDRESS; mary_fati80@yahoo.com REGARDS, BAR. STEPHEN KWESI --e0c90d13-a4a4-11d9-8dd4-000d88177f2d-- From kwesi_consultants@indiatimes.com Sun Apr 3 17:26:06 2005 Received: from indiatimes240.com ([217.164.234.177]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27328 for ; Sun, 3 Apr 2005 17:26:00 -0400 (EDT) Message-Id: <200504032126.RAA27328@ietf.org> From: "Bar. Stephen Kwesi" To: dnsop-archive@ietf.org Reply-To: kwesi_consultants@walla.com Subject: From Bar. Stephen kwesi Date: Mon, 04 Apr 2005 01:22:46 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="e0c91088-a4a4-11d9-8dd4-000d88177f2d" This is a multi-part message in MIME format --e0c91088-a4a4-11d9-8dd4-000d88177f2d Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable BARRISTER STEPHEN KWESI KWESI CONSULTANTS ACCRA-GHANA TEL/FAX: 00233243601078 EMAIL: kwesi_consultants@walla.com HUMANE/CORDIAL REQUEST FOR ASSISTANCE DEAR FRIEND, I AM BAR. STEPHEN KWESI, A PRACTISING LAWYER AS WELL AS A HUMAN RIGHT = ACTIVIST HERE IN GHANA. I AM CONTACTING YOU BASED ON A DISCUSSION I HAD WITH ONE MISS MARY FATI WHOM = I HAPPEN TO MEET IN THE REFUGEE CAMP IN ONE OF MY REUTINE VISITATIONS TO THE = REFUGEE CAMPS. THE LITTLE MARY (24) IS ORIGINALLY FROM THE WAR ENGULFED AREA OF DARFUR =96 = SUDAN. SHE LOST HER PARENTS AND SIBBLINGS IN THE COST OF THE WAR AND SHE IS ALL = ALONE NOW BUT SHE WAS FORTUNATE TO FIND A SAFE IN HER FATHER=92S PRIVATE ROOM = AND THIS SAFE CONTAINS A TOTAL SUM OF SIXTEEN MILLION, FIVE HUNDRED THOUSAND = UNITED STATES DOLLARS ONLY (US$16,500,000.00). THIS SAFE WAS SUCCESSFULLY DEPOSITED WITH A PRIVATE SECURITY COMPANY HERE IN = GHANA AS FAMILY BELONGINGS, WHICH I HAVE CONFIRMED WITH THE COMPANY AS SHE = HAS HANDED OVER ALL THE RELEVANT DOCUMENTS OF THIS DEPOSIT TO ME. I HAVE CONFIRMED HER NEEDS AND THEY INCLUDE, HELPING HER RECEIVE HER FUND IN = A SECURED ACCOUNT, HELPING HER ARRANGE A TRAVELLING DOCUMENT OUT OF GHANA, = ASSISTING HER IN A WAY TO COMPLETE HER EDUCATION AND FINALLY AND MOST = IMPORTANTLY GUIDING HER IN INVESTMENT PURPOSES WITH THIS FUND. MY DEAR, I HAVE LITTLE KNOWLEDGE ABOUT YOUR ABILITY AND WOULD WANT YOU TO = WORK WITH ME IN HELPING THIS LITTLE GIRL WHOSE SITUATION IS QUIT PITIABLE. = YOU WILL BE COMPENSATED APPROPRIATELY. I WILL LINK YOU UP TO HER IF YOU WISH = TO OTHERWISE WE COULD DISCUSS ON POSSIBLE WAYS OF FINALISING THIS = TRANSACTION. YOU CAN REACH ME DIRECTLY ON THE ABOVE TELEPHONE NUMBER OR EMAIL OR YOU CAN = REACH LITTLE MARY VIA HER EMAIL ADDRESS; mary_fati80@yahoo.com REGARDS, BAR. STEPHEN KWESI --e0c91088-a4a4-11d9-8dd4-000d88177f2d-- From owner-dnsop@lists.uoregon.edu Mon Apr 4 07:41:36 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20693 for ; Mon, 4 Apr 2005 07:41:35 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j34Aqxpq001771; Mon, 4 Apr 2005 03:52:59 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j34Aqxmj001770; Mon, 4 Apr 2005 03:52:59 -0700 (PDT) Received: from netmon.hz.zj.cn ([202.101.172.20]) by darkwing.uoregon.edu (8.13.4/8.13.4) with SMTP id j34AqiF6001647 for ; Mon, 4 Apr 2005 03:52:52 -0700 (PDT) Received: (qmail 26094 invoked from network); 4 Apr 2005 18:52:30 +0800 Received: from unknown (HELO localhost) (jshen@202.96.96.35) by netmon.hz.zj.cn with SMTP; 4 Apr 2005 18:52:30 +0800 Date: Mon, 4 Apr 2005 18:52:39 +0800 From: jing shen X-Mailer: The Bat! (v3.0) Professional X-Priority: 3 (Normal) Message-ID: <5492333.20050404185239@christmas.9966.org> To: "Olaf M. Kolkman" CC: dnsop@lists.uoregon.edu Subject: [dnsop] Performance measurement data for queryperf In-Reply-To: <20050401100943.0b2290b8.olaf@ripe.net> References: <20050329090358.GA19235@atoom.net> <20050401100943.0b2290b8.olaf@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: jing shen Content-Transfer-Encoding: 7bit Hi, I've set up a server group with anycast structure. Now, I want to measure its performance by using queryperf(Nominum's version). I've got some log from my currernt servers, but I met problem with converting log file to queryperf input file. The record in log file looks like: Feb 11 20:38:12.143 queries: info: client 218.72.102.64#1098: query: www.pywg.3322.org IN A I use "perl -n -e 'print "$1 $2 \n" if /query: ([^]+) IN ([A-Z]+)/' 1.txt" to generate queryperf input file, but it only generate record with domain name, no record type is filtered in. Is there any problem with my regular expression? Secondly, is there any standard query data for server performance test? Is there any tools to collect incoming query data and CPU, memory utilization with very short period? ( I tried top for that, but it only shows one CPU information while my server has two CPU installed) thanks Joe . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 05:53:08 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00827 for ; Tue, 5 Apr 2005 05:53:08 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j358rs4e007709; Tue, 5 Apr 2005 01:53:54 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j358rsVv007701; Tue, 5 Apr 2005 01:53:54 -0700 (PDT) Received: from sol.nlnetlabs.nl (sol.nlnetlabs.nl [213.154.224.43]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j358rqvt007525 for ; Tue, 5 Apr 2005 01:53:53 -0700 (PDT) Received: from elektron.atoom.net (vhe-530008.sshn.net [195.169.222.38]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 009C4188B05 for ; Tue, 5 Apr 2005 10:53:49 +0200 (CEST) Received: by elektron.atoom.net (Postfix, from userid 1000) id E3051281068F; Tue, 5 Apr 2005 10:53:49 +0200 (CEST) Date: Tue, 5 Apr 2005 10:53:49 +0200 From: Miek Gieben To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03 Message-ID: <20050405085349.GA28638@atoom.net> Mail-Followup-To: dnsop@lists.uoregon.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Miek Gieben [On 01 Apr, @ 20:24, Samuel wrote in "Re: [dnsop] paragraph 4.4.2 in ..."] > How about something with a little more explanation and a slightly > stronger suggestion? to come back to this. I'd like Olaf's suggestion more, basicly because it's just one extra (short) paragraph, -- grtz, - Miek http://www.miek.nl http://www.nlnetlabs.nl . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 06:28:02 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03702 for ; Tue, 5 Apr 2005 06:28:01 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j359gCfr010775; Tue, 5 Apr 2005 02:42:12 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j359gCYF010774; Tue, 5 Apr 2005 02:42:12 -0700 (PDT) Received: from sol.nlnetlabs.nl (sol.nlnetlabs.nl [213.154.224.43]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j359gBvT010766 for ; Tue, 5 Apr 2005 02:42:11 -0700 (PDT) Received: from elektron.atoom.net (vhe-530008.sshn.net [195.169.222.38]) by sol.nlnetlabs.nl (Postfix) with ESMTP id D657C1881B1 for ; Tue, 5 Apr 2005 11:42:09 +0200 (CEST) Received: by elektron.atoom.net (Postfix, from userid 1000) id BFA3D2818974; Tue, 5 Apr 2005 11:42:09 +0200 (CEST) Date: Tue, 5 Apr 2005 11:42:09 +0200 From: Miek Gieben To: dnsop Subject: [dnsop] draft serverid-04 Message-ID: <20050405094209.GA30436@atoom.net> Mail-Followup-To: dnsop Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Miek Gieben Hello, Just finished reading serverid-04.txt and I consider it a good document. But one nagging question remains, as it does not specify a new mechanism, but only lays down the requirements. Are there any plans to create a followup draft which actually specifies a new mechanism? -- grtz, - Miek http://www.miek.nl http://www.nlnetlabs.nl . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 09:54:47 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21665 for ; Tue, 5 Apr 2005 09:54:46 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35CoW4l008855; Tue, 5 Apr 2005 05:50:32 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35CoWsW008848; Tue, 5 Apr 2005 05:50:32 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35CoUL1008770 for ; Tue, 5 Apr 2005 05:50:31 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j35CoAm22838; Tue, 5 Apr 2005 15:50:10 +0300 Date: Tue, 5 Apr 2005 15:50:10 +0300 (EEST) From: Pekka Savola To: David Meyer cc: dnsop@lists.uoregon.edu, sra@isc.org, Suzanne_Woolf@isc.org Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-serverid-04.txt In-Reply-To: <20050401202340.GA19562@1-4-5.net> Message-ID: References: <20050401202340.GA19562@1-4-5.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Fri, 1 Apr 2005, David Meyer wrote: > Please review the document carefully, and send your > feedback to the list. Please also indicate whether or > not you believe that this document is ready to go to the > IESG. First time I read this document. It's a great start, but requires still a little bit of polish (one or two revisions) in particular wrt. spelling out the requirements to be more useful. Below... substantial ----------- Identifying an Authoritative Name Server ==> let's start with the name. It's not 100% clear what the focus of the document is; identifying any name server (a recursive resolver included, non-authoritative), or just identifying authoritative name servers. I submit that we should do the former, so the title is too narrow. (I didn't check whether elsewhere in the doc there is a need for adjusting) ==> further, the title could describe what the document actually does, maybe something like "Identifying the DNS Server: Requirements and Existing Conventions" 1. It requires an additional query to correlate between the answer to a DNS query under normal conditions and the supposed identity of the server receiving the query. There are a number of situations in which this simply isn't reliable. 2. It reserves an entire class in the DNS (CHAOS) for what amounts to one zone. While CHAOS class is defined in [RFC1034] and [RFC1035], it's not clear that supporting it solely for this purpose is a good use of the namespace or of implementation effort. ==> these need spelling out. 1) the last sentence probably refers to setups which are load balanced so that one query can go on one host while the next could go to the another. This is an important consideration, worth stating out (maybe also where this might happen and why) 2) As the specs already support multiple classes, this begs to question, "why is it a problem?" Implementations already have to support multiple classes (I guess) and I doubt it has anything to do with name space conservation. I guess it could have something to with DNSSEC being in a different class, but these issues should be explicitly spelled out. .... 1. The mechanism adopted MUST be in-band for the DNS protocol. That is, it needs to allow the query for the server's identifying information to be part of a normal, operational query. It SHOULD also permit a separate, dedicated query for the server's identifying information. ==> "MUST be in-band" is not explicit enough because hostname.bind is also in-band (though maybe with different definition of "band"). I guess the main point is that the server identification request/reply MUST be piggybackable on regular DNS packets to avoid the disadvantage 1). 4. It should be possible to return a unique identifier for a server without requiring the exposure of information that may be non-public and considered sensitive by the operator, such as a hostname or unicast IP address maintained for administrative purposes. ==> a bit more explicit description might not hurt. It is not clear to me at least how this kind of identifier would be useful if it's just a random blob (whatever the implementation decides to blurt out)? Also, it's not clear what you mean by "unicast IP address.. for admin purposes". Some kind of private back-end addresses? I'd assume that anycasting hosts would also have a stable, globally routable unicast address which could be returned (and which could be very useful for debugging purposes) here. So, I guess the biggest thing is to consider what kind of information for server identification the operators using this feature would like to get. I'd at least like to get a global unicast IP address which I could use to query working/non-working server directly to test their behaviour for debugging purposes. semi-editorial -------------- ==> the document includes MUST, SHOULD, etc. keywords, which are generally considered a bit inappropriate in a requirements document. I'd just downgrade them to the lower case, but if there's consensus to keep them, at least their use needs to be defined (e.g., with reference to RFC2119) ==> there is some amount of overlap with introduction and rationale (and introduction pretty closely follows the abstract). Introduction being as short as it is, I might consider compressing section 1 and 2 to one, eliminating the overlap and having nice and concise introduction and problem statement in one. Software Consortium [BIND] support a way of identifying a particular server via the use of a standard, if somewhat unusual, DNS query. ==> s/standard/specific/ (let's not confuse this with anything standardized.. :) [...] This mechanism, which is an extension of the BIND convention of using CHAOS class TXT RR queries to sub-domains of the "BIND." domain for version information, has been copied by several name server vendors. For reference, the other well-known name used by recent versions of BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A query for a TXT RR for this name will return an administratively defined string which defaults to the version of the server responding. This is, however, not generally implemented by other vendors. ==> large chunk of the text appears to be overlapping. Reword? 5. IANA Considerations This document proposes no specific IANA action. Protocol extensions, if any, to meet the requirements described are out of scope for this document. Should such extensions be specified and adopted by normal IETF process, the specification will include appropriate guidance to IANA. ==> I don't think this needs to be in the final RFC, so I'd put in a note here like "RFC-editor: please remove prior to publication" or the like. editorial --------- ==> I'd suggest using compact=no, subcompact=yes to compress to save the paper a bit :) Recent versions of the commonly deployed Berkeley Internet Name Domain implementation of the DNS protocol suite from the Internet ==> how recent? Hasn't this been in there for a long time already? 3. It is simple to configure. An administrator can easily turn on this feature and control the results of the relevant query. ==> turn on? Isn't it on by default? Is the default setting implementation-specific? How about turning off if default to on? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 11:26:28 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00425 for ; Tue, 5 Apr 2005 11:26:27 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35EeMad017796; Tue, 5 Apr 2005 07:40:22 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35EeMY4017794; Tue, 5 Apr 2005 07:40:22 -0700 (PDT) Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35EeJLu017749 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 5 Apr 2005 07:40:21 -0700 (PDT) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/03/01/sjaenick) with ESMTP id j35EIkVv004283 for ; Tue, 5 Apr 2005 16:18:46 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j35EIkq18239 for ; Tue, 5 Apr 2005 16:18:46 +0200 (MEST) Message-Id: <200504051418.j35EIkq18239@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@lists.uoregon.edu Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-serverid-04.txt In-reply-to: Your message of "Fri, 01 Apr 2005 12:23:40 -0800." <20050401202340.GA19562@1-4-5.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18234.1112710725.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Tue, 05 Apr 2005 16:18:46 +0200 From: Peter Koch Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Peter Koch > This note starts the WG Last Call for comments on > draft-ietf-dnsop-serverid-04.txt, "Identifying an This document is heading Informational status, I guess. Here are some minor nits: o The hostname.bind mechanism not only works for authoritative (for what?) servers but regardless of the set of zones served (if any at all). It's not clear to me why the scope is restricted here (just see that Pekka's making the same point). o Given that the draft addresses "authoritative" servers and that it suggests the querying magic be part of a normal DNS query, what should a 'recursive server' do once it sees this type of query? o In 4.2 it's OK to say a CLASS *or* top level domain, because we want neither o The list of requirements should address scaling, i.e. is this new query to be issued for (manual) debugging only or should one be able to activate it by default on a resolver/recursive server? What impact on load and/or packet size may it have (the query/response should not force anyone to TCP)? o Security considerations could add that no one should trust the magic ID returned, especially not to weigh one response more than another. It's not a security measure and does not provide for authenticity. However, it might be useful to be able to apply signatures to the ID. o "hostname.bind" should be consistently written and ISC's CI police might want to review section 3. -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 13:27:52 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10881 for ; Tue, 5 Apr 2005 13:27:52 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35GXxcb029975; Tue, 5 Apr 2005 09:33:59 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35GXw5R029974; Tue, 5 Apr 2005 09:33:58 -0700 (PDT) Received: from postboy.ripe.net (postboy.ripe.net [193.0.0.201]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35GXvTO029873 for ; Tue, 5 Apr 2005 09:33:58 -0700 (PDT) Received: by postboy.ripe.net (Postfix, from userid 8) id CC45B6A51B; Tue, 5 Apr 2005 18:33:50 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postboy.ripe.net (Postfix) with ESMTP id A5CC36A6C6 for ; Tue, 5 Apr 2005 18:33:47 +0200 (CEST) Received: from x53.ripe.net (x53.ripe.net [193.0.1.53]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j35GXleu007349 for ; Tue, 5 Apr 2005 18:33:47 +0200 Date: Tue, 5 Apr 2005 18:33:47 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x53.ripe.net To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-serverid-04.txt In-Reply-To: <20050401202340.GA19562@1-4-5.net> Message-ID: References: <20050401202340.GA19562@1-4-5.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.110151 / -5.9 X-RIPE-Signature: c6d77c56e0e7b545a0731764af94fda0 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Bruce Campbell On Fri, 1 Apr 2005, David Meyer wrote: > This note starts the WG Last Call for comments on > draft-ietf-dnsop-serverid-04.txt, "Identifying an > Authoritative Name Server". It can be found on > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-serverid-04.txt With regards to 3.2.1 and 4.1 of this document (identification being in-band with the query), what would be the reasons _against_ suggesting that implementations be able to deal with multiple queries within a single packet, ie: www.example.com/IN/A magic.server.identifier.string/CH/TXT and get back a single packet containing answers to both queries. The initial reasons that I can come up with are: *) Answering multiple queries is not implemented at present on most nameserver implementations. *) The meaning of flags becomes confused. *) When debugging a resolving nameserver, where is the answer to the identification string originated from? --==-- Bruce. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 13:35:41 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11408 for ; Tue, 5 Apr 2005 13:35:40 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35DbnVC006047; Tue, 5 Apr 2005 06:37:49 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35DbnZ9006046; Tue, 5 Apr 2005 06:37:49 -0700 (PDT) Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35Dbl67006030 for ; Tue, 5 Apr 2005 06:37:48 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j35DY2id007892 for ; Tue, 5 Apr 2005 09:34:02 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlsayAp; Tue, 5 Apr 05 09:33:59 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j35DZlio001582; Tue, 5 Apr 2005 09:35:47 -0400 (EDT) Date: Tue, 5 Apr 2005 09:35:47 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Miek Gieben cc: dnsop Subject: Re: [dnsop] draft serverid-04 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Samuel Weiler > Just finished reading serverid-04.txt and I consider it a good > document. But one nagging question remains, as it does not specify a > new mechanism, but only lays down the requirements. Are there any > plans to create a followup draft which actually specifies a new > mechanism? draft-austein-dnsext-nsid-01.txt, now expired. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 15:07:06 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19871 for ; Tue, 5 Apr 2005 15:07:05 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35IQxCE029023; Tue, 5 Apr 2005 11:26:59 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35IQxvN029020; Tue, 5 Apr 2005 11:26:59 -0700 (PDT) Received: from sol.nlnetlabs.nl (sol.nlnetlabs.nl [213.154.224.43]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35IQwLW028961 for ; Tue, 5 Apr 2005 11:26:58 -0700 (PDT) Received: from elektron.atoom.net (vhe-530008.sshn.net [195.169.222.38]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 2BF3418801D for ; Tue, 5 Apr 2005 20:26:56 +0200 (CEST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 16C7B28041B9; Tue, 5 Apr 2005 20:26:56 +0200 (CEST) Date: Tue, 5 Apr 2005 20:26:56 +0200 From: Miek Gieben To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 Message-ID: <20050405182655.GA15607@atoom.net> Mail-Followup-To: dnsop@lists.uoregon.edu References: <20050405094209.GA30436@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Miek Gieben [On 05 Apr, @ 20:14, Paul wrote in "Re: [dnsop] draft serverid-04 ..."] > > Just finished reading serverid-04.txt and I consider it a good > > document. But one nagging question remains, as it does not specify a new > > mechanism, but only lays down the requirements. Are there any plans to > > create a followup draft which actually specifies a new mechanism? > > i'm planning to submit a draft recommending that "id" be bidirectional > (so, both clientid and serverid) with the client's id being the solicitation > of the server's id. this doesn't require rev'ing the EDNS version number but will that still require more than one query? As I see it, the whole idea of this draft and the one from Rob (which implements the EDNS tweaking you mention), is to retrieve this information with a single query. -- grtz, - Miek http://www.miek.nl http://www.nlnetlabs.nl . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 15:14:07 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21342 for ; Tue, 5 Apr 2005 15:14:07 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35IEgwH002155; Tue, 5 Apr 2005 11:14:42 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35IEgiX002149; Tue, 5 Apr 2005 11:14:42 -0700 (PDT) Received: from sa.vix.com (sa.vix.com [204.152.187.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35IEfIR001973 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 5 Apr 2005 11:14:41 -0700 (PDT) Received: by sa.vix.com (Postfix, from userid 716) id ECDDD190D4; Tue, 5 Apr 2005 18:14:34 +0000 (GMT) To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 References: <20050405094209.GA30436@atoom.net> From: Paul Vixie Date: 05 Apr 2005 18:14:34 +0000 In-Reply-To: <20050405094209.GA30436@atoom.net> Message-ID: Lines: 23 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@lists.uoregon.edu Precedence: bulk Reply-To: Paul Vixie > Just finished reading serverid-04.txt and I consider it a good > document. But one nagging question remains, as it does not specify a new > mechanism, but only lays down the requirements. Are there any plans to > create a followup draft which actually specifies a new mechanism? i'm planning to submit a draft recommending that "id" be bidirectional (so, both clientid and serverid) with the client's id being the solicitation of the server's id. this doesn't require rev'ing the EDNS version number or anything hard like that. i will propose a registry of attributes so that the client can, if it wants to, offer an opaque universal identifier, a nat-opaque transport address, current latitude and longitude, preferred human language, and other things to be defined later. this is primarily for mobility support, since i'm not confused into thinking that the internet is the web or vice versa. but since we've not succeeded in keeping dns server operators from producing policy-based rather than fact-based answers, i think it's time that we fully support non-universal dns. obviously this will require that caching be disabled in policy-based responses. and it's a loophole that the alternate-roots crowd will just love. but it's time to answer the community's needs in this regard. to that end, i don't think that the current draft goes nearly far enough. -- Paul Vixie . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 17:33:17 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19888 for ; Tue, 5 Apr 2005 17:33:16 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35KjEFO014136; Tue, 5 Apr 2005 13:45:14 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35KjDqV014135; Tue, 5 Apr 2005 13:45:13 -0700 (PDT) Received: from karoshi.com (vacation.karoshi.com [198.32.6.68]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35KjCVN014106 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 5 Apr 2005 13:45:13 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j35Kj7KN015993; Tue, 5 Apr 2005 20:45:07 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j35Kj6W5015990; Tue, 5 Apr 2005 20:45:06 GMT Date: Tue, 5 Apr 2005 20:45:06 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 Message-ID: <20050405204506.GC15882@vacation.karoshi.com.> References: <20050405094209.GA30436@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: bmanning@vacation.karoshi.com On Tue, Apr 05, 2005 at 06:14:34PM +0000, Paul Vixie wrote: > > Just finished reading serverid-04.txt and I consider it a good > > document. But one nagging question remains, as it does not specify a new > > mechanism, but only lays down the requirements. Are there any plans to > > create a followup draft which actually specifies a new mechanism? > > i'm planning to submit a draft recommending that "id" be bidirectional > (so, both clientid and serverid) with the client's id being the solicitation > of the server's id. this doesn't require rev'ing the EDNS version number > or anything hard like that. i will propose a registry of attributes so > that the client can, if it wants to, offer an opaque universal identifier, > a nat-opaque transport address, current latitude and longitude, preferred > human language, and other things to be defined later. this is primarily > for mobility support, since i'm not confused into thinking that the internet > is the web or vice versa. but since we've not succeeded in keeping dns > server operators from producing policy-based rather than fact-based answers, > i think it's time that we fully support non-universal dns. obviously this > will require that caching be disabled in policy-based responses. and it's > a loophole that the alternate-roots crowd will just love. but it's time > to answer the community's needs in this regard. > > to that end, i don't think that the current draft goes nearly far enough. > -- > Paul Vixie 01apr is a few weeks back thataway... :) that said, i'm in favor of the client being able to give up information about itself. --bill . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 19:16:57 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29444 for ; Tue, 5 Apr 2005 19:16:56 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35MGSv8006402; Tue, 5 Apr 2005 15:16:28 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35MGSt6006401; Tue, 5 Apr 2005 15:16:28 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35MGQK1006304 for ; Tue, 5 Apr 2005 15:16:27 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 9DB8E2B5 for ; Tue, 5 Apr 2005 18:16:20 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0732A41EA for ; Tue, 5 Apr 2005 18:16:20 -0400 (EDT) Date: Tue, 05 Apr 2005 18:16:19 -0400 From: Rob Austein To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 In-Reply-To: References: <20050405094209.GA30436@atoom.net> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050405221620.0732A41EA@thrintun.hactrn.net> Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Rob Austein In my opinion, Paul is proposing that we attempt to solve a different problem than dnsop-serverid and austein-nsid attempt to solve. This says nothing about the merits of Paul's proposal-to-be, just that, again in my opinion, it is a nontrivial change in goal. The goal of dnsop-serverid and austein-nsid is to attempt to answer loud cries for help that we have been receiving from the root zone server operators (among others) for many years now. Personally, I do not view the tasks of identifying the server and identifying the client as at all symmetric in a protocol like DNS, so it's not obvious to me that such mechanisms should be linked. Since dnsop-serverid is in WG last call, it would be useful to know whether the WG: a) Agrees with my characterization of Paul's proposal as a change (or expansion, if you prefer) of the goals for this work item; b) Agrees with Paul on this change in goals. Silence will be interpreted as "yes" on (a) and "no" on (b). Finally, please note that nothing above rules out future work along the lines Paul suggests. The issue on the table is just whether we need to reopen dnsop-serverid to address Paul's point. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Tue Apr 5 20:42:54 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05887 for ; Tue, 5 Apr 2005 20:42:54 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35Nx5HQ009587; Tue, 5 Apr 2005 16:59:05 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j35Nx5PY009584; Tue, 5 Apr 2005 16:59:05 -0700 (PDT) Received: from sa.vix.com (sa.vix.com [204.152.187.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j35Nx4BA009447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 5 Apr 2005 16:59:04 -0700 (PDT) Received: by sa.vix.com (Postfix, from userid 716) id 65F2313E4A; Tue, 5 Apr 2005 23:58:58 +0000 (GMT) To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 References: <20050405182655.GA15607@atoom.net> From: Paul Vixie Date: 05 Apr 2005 23:58:58 +0000 In-Reply-To: <20050405182655.GA15607@atoom.net> Message-ID: Lines: 21 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@lists.uoregon.edu Precedence: bulk Reply-To: Paul Vixie > > i'm planning to submit a draft recommending that "id" be bidirectional > > (so, both clientid and serverid) with the client's id being the > > solicitation of the server's id. this doesn't require rev'ing the EDNS > > version number > > but will that still require more than one query? no. it uses the presence of an ID option inside the EDNS OPT RR in the request to signal the desire to see one in the response. > As I see it, the whole idea of this draft and the one from Rob (which > implements the EDNS tweaking you mention), is to retrieve this > information with a single query. yes, that's still the goal. and to rob's observation that the need for this in clients isn't symmetric to the need for it in servers, i think we can answer that by making a small change to the serverid and/or nsid drafts making it symmetrical, saying that no client-side options are defined at this time, and making the server's response into an attribute/value list. -- Paul Vixie . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 6 04:35:44 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14451 for ; Wed, 6 Apr 2005 04:35:43 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j367ctEE012142; Wed, 6 Apr 2005 00:38:55 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j367ctVN012141; Wed, 6 Apr 2005 00:38:55 -0700 (PDT) Received: from shell-ng.nominum.com (shell-ng.nominum.com [81.200.64.181]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j367crwS012102 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 6 Apr 2005 00:38:54 -0700 (PDT) Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 9B169568AD for ; Wed, 6 Apr 2005 00:38:47 -0700 (PDT) (envelope-from david.conrad@nominum.com) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050405094209.GA30436@atoom.net> References: <20050405094209.GA30436@atoom.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [dnsop] draft serverid-04 Date: Wed, 6 Apr 2005 00:38:43 -0700 To: dnsop X-Mailer: Apple Mail (2.619.2) Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: David Conrad Content-Transfer-Encoding: 7bit Hi, Apologies in advance for the length of this message. As a person 'somewhat' involved in inflicting this topic into dnsop in the first place and being listed as a co-author (although Suzanne should get the credit for keeping this alive), I have to admit I'm confused. My intent in writing the original draft was to document existing practice and behavior (a txt query in the chaos class for {version,hostname}.bind) and suggest an alternative with minimal changes that would be less offensive to other vendors (a txt query in the chaos class for {version,id}.server). The reason I suggested the approach I did was that I figured the folks who implemented chaos/txt *.bind (which, surprisingly enough, isn't just BIND) would find it trivial to change the string queried for. Mucking about with anything any more complicated than that (e.g., OPT RRs, the status opcode, multiple questions per query, or whatever) would imply code changes and thus, require significantly more work (in a relative sense). In fact, as I was coming up with my original draft, I asked some other DNS server implementors if they'd be willing to do chaos/txt id.server and they had indicated that it wouldn't be out of the question. The reason I thought this functionality would be useful was because the root servers were then just beginning (!) to be anycasted and one of the concerns expressed about this approach for strengthening the roots was that if an anycast root server instance went off into the weeds, it would be nice to be able to identify the culprit instance. In other words, my goal was to suggest something _simple_ to meet an actual and immediate _operational_ need. A novel and heretical thought, I know. I was and am perfectly well aware that my original proposal was far from optimal, however I felt it had the best chance of actually being implemented in real live operational servers before hell froze over. Unfortunately, after a particularly unpleasant public exchange with Randy Bush (for which I belatedly apologize to dnsop participants who had to wade through it), I gave up in disgust. Subsequently, Suzannne took on the responsibility of continuing tilting at this particular windmill. I have now actually read the current draft and I must be missing something. I apologize if this has been hashed out while I was off being distracted by other things and the answer is obvious to everyone else, but... One of the major objections against the original server.id approach was that the chaos/txt query would only be sent after someone noticed the server at a particular IP address was being bad, implying this reactive query could take a different path and end up identifying the wrong server. However, unless the "good answer" (the characteristics of which are described in the draft) exists in each and every query, anyone experiencing difficulties that require identification of a particular server will need to send additional queries with the necessary flags to include the {opt RR, status opcode, additional question, whatever} that tells the server to identify itself. Obviously, if you have to do this, the query might take a different path and get you no closer to what you need to know than an out-of-band approach. If I assume the identifying thingie is always on, then you get into the problems of dealing with DNS servers/load balancers/firewalls/NAT boxes that do not (and likely never will) understand such esoterica as any of the possible solutions discussed. This implies we'll have to do the same sort of silliness we do with EDNS0 which also implies the identifying thingie simply can't be used. Of course, one could argue that broken and/or obsolete servers would get replaced but experience has shown it exceedingly difficult to get people to upgrade their servers, even for root level exploits in those servers. A more reasonable argument can be made that DNS servers/load balancers/firewalls/NAT boxes/etc. may treat class chaos queries different than class IN queries, however class chaos queries are obviously made today and they get responded to, thus there is at least some running code that indicates they 'work' (for some definition of that variable). This obviously can't be said of any of the in-band proposals. Lastly, regardless of whether the identifying thingie is always on or not, I believe in the vast majority of cases, you'll need some DNS savvy person to actually research and discover that a server instance is misbehaving. As such, for an in-band solution to be any different than an out-of-band solution, you'll need to log every response on the off chance that badness will occur. This seems unlikely to me. With regards to the other disadvantages of the current approach (which, by extension can be applied to the id.server approach): - section 3.2, #2 If there is anyone today who is actually using the CHAOS class as it was originally intended, I would be fascinated to hear about it. While I was not the one who chose to use the CHAOS class for this query, I would bet that person's life (:-)) that the version.bind query or functional equivalent is the _only_ current use of that class. Given class CH is specified in RFC 1034/1035 and it is both inadvisable and has proven well nigh impossible (at least in the real world) to remove anything defined and implemented in the Internet today, I would argue that we might as well take advantage of the CHAOS class's existence. This particular use of the CHAOS class is supported by the DNS specifications -- the only protocol violation that might occur is in those name servers that are used for CHAOS naming. I suspect this set of name servers is rather small. Of course it can be (and has been) argued that implementing class CH is a waste of time. I don't disagree. I know of at least one DNS server implementation that implements only the ability to answer a TXT query for a particular string (no points for guessing what string). Alternatively, an implementor may choose to not implement the identification mechanism (whatever it might be) and simply accept the fact that they will be decreasing the chances that their server will be used in anycast/load balancing situations. That's fine too. There are plenty of DNS servers out there these days. - section 3.2, #3 As I mentioned above, there are multiple implementations that support the general concept, if not the exact implementation of chaos/txt version.bind. Those implementations include BIND, Nominum ANS, PowerDNS, MyDNS, and NSD (at least). There are probably others, but I didn't bother to investigate further. There were some folks who, when I asked, indicated it would be a lot easier for them to get management to agree if the TLD was changed to something less vendor specific, thus I chose "server". Of the folk I spoke to who didn't dismiss the idea out of hand due to the use of class CH, all indicated id.server would be an acceptable alternative. However, this was a (long) while back, so things might have changed. In any event, what am I missing? Is there some reason we're trying to make this more complicated that it has to be? Or is this yet another example of the OSIfication of the IETF? Thanks, -drc . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 6 10:09:24 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14919 for ; Wed, 6 Apr 2005 10:09:24 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36D5UGV012964; Wed, 6 Apr 2005 06:05:30 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j36D5U0L012963; Wed, 6 Apr 2005 06:05:30 -0700 (PDT) Received: from sol.nlnetlabs.nl (sol.nlnetlabs.nl [213.154.224.43]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36D5TtN012944 for ; Wed, 6 Apr 2005 06:05:29 -0700 (PDT) Received: from elektron.atoom.net (vhe-530008.sshn.net [195.169.222.38]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 62A6F188159 for ; Wed, 6 Apr 2005 15:05:27 +0200 (CEST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 51EF72804F07; Wed, 6 Apr 2005 15:05:27 +0200 (CEST) Date: Wed, 6 Apr 2005 15:05:27 +0200 From: Miek Gieben To: dnsop@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 Message-ID: <20050406130527.GC14603@atoom.net> Mail-Followup-To: dnsop@lists.uoregon.edu References: <20050405094209.GA30436@atoom.net> <20050405221620.0732A41EA@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050405221620.0732A41EA@thrintun.hactrn.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Miek Gieben [On 06 Apr, @ 00:16, Rob wrote in "Re: [dnsop] draft serverid-04 ..."] > Since dnsop-serverid is in WG last call, it would be useful to know > whether the WG: > > a) Agrees with my characterization of Paul's proposal as a change (or > expansion, if you prefer) of the goals for this work item; > > b) Agrees with Paul on this change in goals. > > Silence will be interpreted as "yes" on (a) and "no" on (b). > > Finally, please note that nothing above rules out future work along > the lines Paul suggests. The issue on the table is just whether we > need to reopen dnsop-serverid to address Paul's point. > > I think Paul's idea has some merit. Also I think that serverid should go forward to at least document the current practise. The whole id.server stuff is already the defacto standard, there is nothing the IETF can do about that, -- grtz, - Miek http://www.miek.nl http://www.nlnetlabs.nl . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 6 10:56:56 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19896 for ; Wed, 6 Apr 2005 10:56:56 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36DnsOQ007707; Wed, 6 Apr 2005 06:49:54 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j36DnsZu007705; Wed, 6 Apr 2005 06:49:54 -0700 (PDT) Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36Dnp6H007685 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 6 Apr 2005 06:49:53 -0700 (PDT) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/03/01/sjaenick) with ESMTP id j36DnoB4027311 for ; Wed, 6 Apr 2005 15:49:50 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j36DnnD19930 for ; Wed, 6 Apr 2005 15:49:49 +0200 (MEST) Message-Id: <200504061349.j36DnnD19930@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@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 In-reply-to: Your message of "Tue, 05 Apr 2005 18:16:19 EDT." <20050405221620.0732A41EA@thrintun.hactrn.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19925.1112795388.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 06 Apr 2005 15:49:49 +0200 From: Peter Koch Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Peter Koch > a) Agrees with my characterization of Paul's proposal as a change (or > expansion, if you prefer) of the goals for this work item; Learning more about the resolvers out there would be *very* helpful, but that isn't achieved by them providing an ID, they'd have to tell their version (or feature list or ...). That, however could lead to all those "intelligent" features of webservers, giving blinking domain names to resolver X and those with smell and taste to resolver Y. That's only very remotely related to "hostname.bind". Also, I do not yet understand why the resolver should "pay" for the server's ID by presenting its own first, especially since the ID need not be meaningful and may even change over time. We aimed at debugging, not feature negotiation. > b) Agrees with Paul on this change in goals. I'd like to have an agreed upon debugging aid *soon*. > Silence will be interpreted as "yes" on (a) and "no" on (b). You may take these as my words of silence. -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From mascarena@fadmail.com Wed Apr 6 11:59:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29244; Wed, 6 Apr 2005 11:59:41 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJD4o-0004ga-GP; Wed, 06 Apr 2005 12:08:24 -0400 Received: from [61.105.28.140] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DJCwM-00025B-T8; Wed, 06 Apr 2005 11:59:40 -0400 Authentication-Results: hypochlorous.es from=premium.middletown.es; domainkeys=neutral (no sig) X-Originating-IP: [92.240.228.71] Received: from premium.pilfer.es (EHLO premium.buffalo.es) by premium.decommission.es with SMTP; Wed, 06 Apr 2005 14:56:27 -0200 Date: Wed, 06 Apr 2005 11:55:27 -0500 From: "Nicholas Hannah" To: discuss@ietf.org Cc: discuss-admin@ietf.org, discuss-archive@ietf.org, discuss-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-archive@ietf.org, dmin@ietf.org, dnsind-archive@ietf.org, dnsop-archive@ietf.org, dnssec-archive@ietf.org Subject: Notification: We offer low rates Message-ID: <116941.0878.mascarena@fadmail.com> X-Mailer: Kana Connect 6 X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Aimee Bowen to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From kronos@didamail.com Wed Apr 6 12:14:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00622; Wed, 6 Apr 2005 12:14:28 -0400 (EDT) Received: from [211.199.31.29] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJDJ7-00055u-9d; Wed, 06 Apr 2005 12:23:11 -0400 Delivered-To: boletus@commune.dreamhost.com Received: from anton.dreamhost.com by bathe.dreamhost.com (Pingofix) with ESMTP id 0CC5A46D9B for ; Wed, 06 Apr 2005 22:03:04 +0500 Message-ID: Date: Wed, 06 Apr 2005 21:05:04 +0400 From: "Nickolas Esparza" To: Subject: High rates? Not with us! low fixed rate X-Mailer: Mailman v2.0.5 X-SpamTest-Info: Profile: Formal (167/041168) X-SpamTest-Info: Profile: Detect Hard No RBL (4/030538) X-Spam-Score: 16.7 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Rhea Burgess to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-dnsop@lists.uoregon.edu Wed Apr 6 12:20:21 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01162 for ; Wed, 6 Apr 2005 12:20:21 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36FHkH9021772; Wed, 6 Apr 2005 08:17:46 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j36FHkV7021767; Wed, 6 Apr 2005 08:17:46 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36FHjqc021670 for ; Wed, 6 Apr 2005 08:17:45 -0700 (PDT) Received: by postman.ripe.net (Postfix, from userid 8) id EED352424A; Wed, 6 Apr 2005 17:17:36 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0053C240F2; Wed, 6 Apr 2005 17:17:35 +0200 (CEST) Received: from x53.ripe.net (x53.ripe.net [193.0.1.53]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j36FHZeu007055; Wed, 6 Apr 2005 17:17:35 +0200 Date: Wed, 6 Apr 2005 17:17:35 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x53.ripe.net To: Peter Koch cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 In-Reply-To: <200504061349.j36DnnD19930@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: References: <200504061349.j36DnnD19930@grimsvotn.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.011483 / -5.9 X-RIPE-Signature: f83f935988590c5a880b2319af068a57 Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Bruce Campbell On Wed, 6 Apr 2005, Peter Koch wrote: > Also, I do not yet understand why > the resolver should "pay" for the server's ID by presenting its own first, > especially since the ID need not be meaningful and may even change over > time. The client does need to 'pay' to get that information, although I suspect my reasoning is somewhat different than other's. If you have a 'small' option to set on the inbound packet that results in the server's outbound packet being significantly larger due to debugging information, the miscreants will eventually stumble on it as being yet another nifty method by which DNS can be used as an amplification attack against a 3rd party. In the long run, this would result in administrators disabling the debug/identifier 'feature' to avoid being used for such an attack, which is not what we want. It would be better for any debugging solution to have a penalty so it does not get used in such a fashion, and thus administrators leave it enabled. If the penalty is the client handing out _a_ string (preferably with a minimum size), that is acceptable. ( Yes yes, other aspects of DNS can still be used as amplifiers, but theres no point us making it too easy. ) > > b) Agrees with Paul on this change in goals. > > I'd like to have an agreed upon debugging aid *soon*. urm... I'll agree with Paul in (ab)using EDNS0 for client/server ID, because its slightly more elegant than magic-string in the query section, but I don't agree with a complete change in goals for server-id. I'd like to see server-id continue to be used as the case for having a diagnostic interface enabled, to document old practice, and _to contain a pointer to the preferred practice_. Since the last point is missing, don't publish server-id-04 at the present time. ( I don't think publishing-as-RFC a document that says 'something with these properties would be cool, but we don't have that yet' is a good idea. ) > > Silence will be interpreted as "yes" on (a) and "no" on (b). -- Bruce Campbell. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From herself@fadmail.com Wed Apr 6 13:04:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05246; Wed, 6 Apr 2005 13:04:02 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJE56-0006P1-PT; Wed, 06 Apr 2005 13:12:46 -0400 Received: from 82-38-137-37.cable.ubr03.hali.blueyonder.co.uk ([82.38.137.37]) by mx2.foretec.com with smtp (Exim 4.24) id 1DJDwX-0003TK-3p; Wed, 06 Apr 2005 13:03:57 -0400 Authentication-Results: bianco.es from=premium.therein.es; domainkeys=neutral (no sig) X-Originating-IP: [153.160.192.41] Received: from premium.jackanapes.es (EHLO premium.leachate.es) by premium.lewd.es with SMTP; Wed, 06 Apr 2005 16:52:13 -0100 Date: Wed, 06 Apr 2005 19:52:13 +0200 From: "Jarred Winters" To: discuss@ietf.org Cc: discuss-admin@ietf.org, discuss-archive@ietf.org, discuss-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-archive@ietf.org, dmin@ietf.org, dnsind-archive@ietf.org, dnsop-archive@ietf.org, dnssec-archive@ietf.org, donny.gifford@ietf.org Subject: Pre-approved Application #GZYJV824 Message-ID: <119341.2939.herself@fadmail.com> X-Mailer: Kana Connect 6 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Sylvester Conn to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-dnsop@lists.uoregon.edu Wed Apr 6 14:57:59 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15781 for ; Wed, 6 Apr 2005 14:57:59 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36I3T6W004796; Wed, 6 Apr 2005 11:03:29 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j36I3SUc004794; Wed, 6 Apr 2005 11:03:28 -0700 (PDT) Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36I3Qmp004670 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 6 Apr 2005 11:03:27 -0700 (PDT) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/03/01/sjaenick) with ESMTP id j36I3LOj019173 for ; Wed, 6 Apr 2005 20:03:22 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j36I3Lw20464 for ; Wed, 6 Apr 2005 20:03:21 +0200 (MEST) Message-Id: <200504061803.j36I3Lw20464@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@lists.uoregon.edu Subject: Re: [dnsop] draft serverid-04 In-reply-to: Your message of "Wed, 06 Apr 2005 17:17:35 +0200." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20462.1112810600.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 06 Apr 2005 20:03:21 +0200 From: Peter Koch Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Peter Koch Bruce Campbell wrote: > ( Yes yes, other aspects of DNS can still be used as amplifiers, but > theres no point us making it too easy. ) the amplification is not larger than with a standard DNS query, even without DNSSEC. > > I'd like to have an agreed upon debugging aid *soon*. > > urm... I'll agree with Paul in (ab)using EDNS0 for client/server ID, > because its slightly more elegant than magic-string in the query section, Just to clarify: i do not believe a TLD in any class gives sooner results than an EDNS0 option, so we agree here. > ( I don't think publishing-as-RFC a document that says 'something with > these properties would be cool, but we don't have that yet' is a good > idea. ) You want the word 'requirements' in the title? -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Wed Apr 6 15:20:57 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18911 for ; Wed, 6 Apr 2005 15:20:56 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36IItPW005870; Wed, 6 Apr 2005 11:18:55 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j36IIta7005868; Wed, 6 Apr 2005 11:18:55 -0700 (PDT) Received: from shell-ng.nominum.com (shell-ng.nominum.com [81.200.64.181]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j36IIs40005699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 6 Apr 2005 11:18:54 -0700 (PDT) Received: from [81.200.65.30] (dhcp-30.wl.nominum.com [81.200.65.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 8E8A4568AD; Wed, 6 Apr 2005 11:18:46 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <200504061803.j36I3Lw20464@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200504061803.j36I3Lw20464@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dnsop@lists.uoregon.edu From: David Conrad Subject: Re: [dnsop] draft serverid-04 Date: Wed, 6 Apr 2005 11:18:44 -0700 To: Peter Koch X-Mailer: Apple Mail (2.619.2) Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: David Conrad Content-Transfer-Encoding: 7bit Hi Peter, On Apr 6, 2005, at 11:03 AM, Peter Koch wrote: > Just to clarify: i do not believe a TLD in any class gives sooner > results > than an EDNS0 option, so we agree here. Why do you believe this? Rgds, -drc . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 7 07:27:36 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09986 for ; Thu, 7 Apr 2005 07:27:35 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j37AQat5020405; Thu, 7 Apr 2005 03:26:37 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j37AQacj020402; Thu, 7 Apr 2005 03:26:36 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j37AQZoj020375 for ; Thu, 7 Apr 2005 03:26:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 466E926C0D0; Thu, 7 Apr 2005 12:26:31 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx2.nic.fr (Postfix) with ESMTP id 2B06026C0CB; Thu, 7 Apr 2005 12:26:30 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id j37APkBw1509636; Thu, 7 Apr 2005 12:25:46 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 92FCD16A9F8; Thu, 7 Apr 2005 12:26:24 +0200 (CEST) Date: Thu, 7 Apr 2005 12:26:24 +0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: dnsop@lists.uoregon.edu Subject: [dnsop] Re: draft serverid-04 Message-ID: <20050407102624.GC22004@nic.fr> References: <20050405094209.GA30436@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Stephane Bortzmeyer [Yes, I know we should not FTT.] On Tue, Apr 05, 2005 at 06:14:34PM +0000, Paul Vixie wrote a message of 23 lines which said: > obviously this will require that caching be disabled in policy-based > responses. This is not mandatory. HTTP has similar features and they don't imply cache disabling. See RFC 2616, 13.6 "Caching Negotiated Responses". . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-dnsop@lists.uoregon.edu Thu Apr 7 11:14:16 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03363 for ; Thu, 7 Apr 2005 11:14:15 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j37EMaE7014697; Thu, 7 Apr 2005 07:22:36 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j37EMaX9014696; Thu, 7 Apr 2005 07:22:36 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j37EMZ36014668 for ; Thu, 7 Apr 2005 07:22:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8F12B26C0B1; Thu, 7 Apr 2005 16:22:31 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 88C2426C098; Thu, 7 Apr 2005 16:22:30 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j37ELCIm621703; Thu, 7 Apr 2005 16:21:12 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 60D8316AAC1; Thu, 7 Apr 2005 16:22:30 +0200 (CEST) Date: Thu, 7 Apr 2005 16:22:30 +0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: Stephane Bortzmeyer , dnsop@lists.uoregon.edu Subject: [dnsop] Re: draft serverid-04 Message-ID: <20050407142230.GA9909@nic.fr> References: <20050407102624.GC22004@nic.fr> <20050407135441.BF96513971@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050407135441.BF96513971@sa.vix.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Stephane Bortzmeyer On Thu, Apr 07, 2005 at 01:54:41PM +0000, Paul Vixie wrote a message of 16 lines which said: > as long as the requestor knows to only reuse if the same request > criteria was present, caching would be fine. a caching requestor > would then have to be willing to cache several different responses, > each having the same q-tuple but different request criteria. Yes, this is what the HTTP proxy/cache Squid does. See for instance http://www.squid-cache.org/bugs/show_bug.cgi?id=649. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From jsweet@emailaccount.com Fri Apr 8 01:26:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14311; Fri, 8 Apr 2005 01:26:00 -0400 (EDT) Received: from [210.92.57.79] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJm8x-0001Uo-6k; Fri, 08 Apr 2005 01:35:01 -0400 Received: from ukrainian-jcoppens.com (EHLO barnacle.jcoppens.com) by princeton.jcoppens.com with SMTP; Fri, 08 Apr 2005 03:19:10 -0300 Date: Fri, 08 Apr 2005 05:21:10 -0100 From: "Emery Park" To: discuss@ietf.org Cc: discuss-admin@ietf.org, discuss-archive@ietf.org, discuss-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-archive@ietf.org, dmin@ietf.org, dnsind-archive@ietf.org, dnsop-archive@ietf.org, dnssec-archive@ietf.org, donny.gifford@ietf.org, dorthy.bruno@ietf.org, doyle.crouch@ietf.org, dp@ietf.org Subject: Lowest rates in 45 years Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [223], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Philip Mayes to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From awelker@emailaccount.com Fri Apr 8 04:53:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19669; Fri, 8 Apr 2005 04:53:40 -0400 (EDT) Received: from [218.39.141.247] (helo=SAMSUNG-EMWA65G) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJpNu-0007zb-QR; Fri, 08 Apr 2005 05:02:43 -0400 Received: from intangible-jcoppens.com (EHLO dock.jcoppens.com) by kerosene.jcoppens.com with SMTP; Fri, 08 Apr 2005 11:43:01 +0200 Date: Fri, 08 Apr 2005 11:41:01 +0200 From: "Antony Farr" To: dnsind-archive@ietf.org Cc: dnsop-archive@ietf.org, dnssec-archive@ietf.org, donny.gifford@ietf.org, dorthy.bruno@ietf.org, doyle.crouch@ietf.org, dp@ietf.org Subject: Instant low rates Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [403], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 4.3 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Allie Berger to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From busitzky@doneasy.com Fri Apr 8 04:56:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19854; Fri, 8 Apr 2005 04:56:36 -0400 (EDT) Received: from cpe-144-136-125-24.nsw.bigpond.net.au ([144.136.125.24]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJpQk-00084z-24; Fri, 08 Apr 2005 05:05:40 -0400 Authentication-Results: drown.es from=premium.pursuant.es; domainkeys=neutral (no sig) X-Originating-IP: [68.74.232.53] Received: from premium.chronography.es (EHLO premium.thankful.es) by premium.querulous.es with SMTP; Fri, 08 Apr 2005 05:52:15 -0400 Date: Fri, 08 Apr 2005 08:56:15 -0100 From: "Callie Sweeney" To: discuss@ietf.org Cc: discuss-admin@ietf.org, discuss-archive@ietf.org, discuss-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-archive@ietf.org, dmin@ietf.org, dnsind-archive@ietf.org, dnsop-archive@ietf.org, dnssec-archive@ietf.org, donny.gifford@ietf.org, dorthy.bruno@ietf.org, doyle.crouch@ietf.org, dp@ietf.org Subject: You've been selected for a low rate Message-ID: <112741.1793.busitzky@doneasy.com> X-Mailer: Kana Connect 6 X-Spam-Score: 2.6 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Guillermo Keller to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From josephmorimai2001@web-mail.com.ar Fri Apr 8 08:28:48 2005 Received: from web1.belizeweb.com (mail.belizeweb.com [206.27.238.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11744 for ; Fri, 8 Apr 2005 08:28:48 -0400 (EDT) Date: Fri, 8 Apr 2005 03:08:44 -0600 Message-Id: <200504080308.AA4290052374@web1.belizeweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From: "Barrister. Joseph Morimai" Reply-To: X-Sender: To: Subject: # From London & Urgent Reply Needed # X-Mailer: Content-Transfer-Encoding: quoted-printable From : Barrister. Joseph Morimai Kindest Attention, Firstly, not to cause you embarrassment, I am Mr. Joseph Morimai, a Papua N= ew Guinean by Nationality, a Solicitor at law based in the United Kingdom a= nd the personal attorney to Late Mr. Bonnet Roux a National of France, who = used to be a private contractor with the Halliburton Company in Saudi Arabi= a, herein after shall be referred to as my client. On the 21st of April 200= 1, he and his wife with their three children were involved in an auto crash= all occupants of the vehicle unfortunately lost their lives. Since then, I have made several enquiries with his country's embassies to l= ocate any of my clients extended relatives, this has also proved unsuccessf= ul. After these several unsuccessful attempts, I decided to contact you wit= h this business partnership proposal. I have contacted you to assist in rep= atriating a huge amount of money left behind by my Client before they get c= onfiscated or declared unserviceable by the Bank where this huge deposit wa= s lodged. The deceased had a deposit valued presently at =A330,000,000.00 and the Ban= k has issued me a notice to provide his next of kin or Beneficiary by Will = otherwise have the account confiscated within the next thirty official work= ing days. Since I have been unsuccessful in locating the relatives for over three yea= rs now, I seek your consent to present you as the next of kin / Will Benefi= ciary to the deceased so that the proceeds of this account valued at =A330M= illion can be paid to you. This will be disbursed or shared in these percentages, 60% to me and 40% to= you. I have all necessary legal documents that can be used to Back up any claim = will be obtained From the Court of England with the Certificate Of Deposit = which has been issued to me by the Bank. All I require is your honest Co-o= peration, Confidentiality and Trust to enable us see this project through. I guarantee you that this will be executed under a legitimate Arrangement t= hat will protect you from any breach of the law. All the relevant documents= that will give you the legal backing to claim the fund will be processed. Please acknowledge receipt of this message by e-mail as I am based in the U= nited Kingdom. And please provide me the following below; this is to enable= me commence immediate preparation of all legal documents that will back up= our claim. 1. Full Name 2. Your Telephone Number and Fax Number 3. Your Contact Address. Your urgent response will be highly anticipated and Appreciated. Best regards, Barrister. Joseph Morimai. From josephmorimai2001@web-mail.com.ar Fri Apr 8 08:29:52 2005 Received: from web1.belizeweb.com (mail.belizeweb.com [206.27.238.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11805 for ; Fri, 8 Apr 2005 08:29:52 -0400 (EDT) Date: Fri, 8 Apr 2005 03:08:44 -0600 Message-Id: <200504080308.AA4290052374@web1.belizeweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From: "Barrister. Joseph Morimai" Reply-To: X-Sender: To: Subject: # From London & Urgent Reply Needed # X-Mailer: Content-Transfer-Encoding: quoted-printable From : Barrister. Joseph Morimai Kindest Attention, Firstly, not to cause you embarrassment, I am Mr. Joseph Morimai, a Papua N= ew Guinean by Nationality, a Solicitor at law based in the United Kingdom a= nd the personal attorney to Late Mr. Bonnet Roux a National of France, who = used to be a private contractor with the Halliburton Company in Saudi Arabi= a, herein after shall be referred to as my client. On the 21st of April 200= 1, he and his wife with their three children were involved in an auto crash= all occupants of the vehicle unfortunately lost their lives. Since then, I have made several enquiries with his country's embassies to l= ocate any of my clients extended relatives, this has also proved unsuccessf= ul. After these several unsuccessful attempts, I decided to contact you wit= h this business partnership proposal. I have contacted you to assist in rep= atriating a huge amount of money left behind by my Client before they get c= onfiscated or declared unserviceable by the Bank where this huge deposit wa= s lodged. The deceased had a deposit valued presently at =A330,000,000.00 and the Ban= k has issued me a notice to provide his next of kin or Beneficiary by Will = otherwise have the account confiscated within the next thirty official work= ing days. Since I have been unsuccessful in locating the relatives for over three yea= rs now, I seek your consent to present you as the next of kin / Will Benefi= ciary to the deceased so that the proceeds of this account valued at =A330M= illion can be paid to you. This will be disbursed or shared in these percentages, 60% to me and 40% to= you. I have all necessary legal documents that can be used to Back up any claim = will be obtained From the Court of England with the Certificate Of Deposit = which has been issued to me by the Bank. All I require is your honest Co-o= peration, Confidentiality and Trust to enable us see this project through. I guarantee you that this will be executed under a legitimate Arrangement t= hat will protect you from any breach of the law. All the relevant documents= that will give you the legal backing to claim the fund will be processed. Please acknowledge receipt of this message by e-mail as I am based in the U= nited Kingdom. And please provide me the following below; this is to enable= me commence immediate preparation of all legal documents that will back up= our claim. 1. Full Name 2. Your Telephone Number and Fax Number 3. Your Contact Address. Your urgent response will be highly anticipated and Appreciated. Best regards, Barrister. Joseph Morimai. From owner-dnsop@lists.uoregon.edu Fri Apr 8 14:40:25 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21450 for ; Fri, 8 Apr 2005 14:40:25 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j38Hb2qW010991; Fri, 8 Apr 2005 10:37:02 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j38Hb2r8010988; Fri, 8 Apr 2005 10:37:02 -0700 (PDT) Received: from sa.vix.com (sa.vix.com [204.152.187.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j37DsnYM026438 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 7 Apr 2005 06:54:49 -0700 (PDT) Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BF96513971; Thu, 7 Apr 2005 13:54:41 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Stephane Bortzmeyer Cc: dnsop@lists.uoregon.edu Subject: [dnsop] Re: draft serverid-04 In-Reply-To: Message from Stephane Bortzmeyer of "Thu, 07 Apr 2005 12:26:24 +0200." <20050407102624.GC22004@nic.fr> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 07 Apr 2005 13:54:41 +0000 Message-Id: <20050407135441.BF96513971@sa.vix.com> Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Paul Vixie > [Yes, I know we should not FTT.] believe it or not i'm not just trolling with this stuff. > > obviously this will require that caching be disabled in policy-based > > responses. > > This is not mandatory. HTTP has similar features and they don't imply > cache disabling. See RFC 2616, 13.6 "Caching Negotiated Responses". upon reflection, you're right. as long as the requestor knows to only reuse if the same request criteria was present, caching would be fine. a caching requestor would then have to be willing to cache several different responses, each having the same q-tuple but different request criteria. this is dangerous since it will involve talking to ed lewis in his most agitated state. mostly listening, actually. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From eluvial@doramail.com Sun Apr 10 02:44:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27455; Sun, 10 Apr 2005 02:44:36 -0400 (EDT) Received: from [61.81.185.122] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKWKX-0005Eo-18; Sun, 10 Apr 2005 02:54:04 -0400 Received: from analytic-jcoppens.com (EHLO irredeemable.jcoppens.com) by mink.jcoppens.com with SMTP; Sun, 10 Apr 2005 13:40:41 +0600 Date: Sun, 10 Apr 2005 08:31:41 +0100 From: "Russ Spence" To: dnsop-archive@ietf.org Cc: dnssec-archive@ietf.org, donny.gifford@ietf.org, dorthy.bruno@ietf.org, doyle.crouch@ietf.org, dp@ietf.org Subject: Become one of the low rates Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [412], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 8.5 (++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Eldon Turner to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-dnsop@lists.uoregon.edu Tue Apr 12 03:35:07 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03496 for ; Tue, 12 Apr 2005 03:35:07 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j3C6l4ga026956; Mon, 11 Apr 2005 23:47:04 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j3C6l4tR026945; Mon, 11 Apr 2005 23:47:04 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j3C6l2JH026908 for ; Mon, 11 Apr 2005 23:47:03 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j3C6kdr03489; Tue, 12 Apr 2005 09:46:39 +0300 Date: Tue, 12 Apr 2005 09:46:39 +0300 (EEST) From: Pekka Savola To: David Meyer cc: dnsop@lists.uoregon.edu, sra@isc.org, david.kessens@nokia.com Subject: Re: [dnsop] please review draft-malamud-keyword-discovery-03.txt In-Reply-To: <20050331173226.GA26657@1-4-5.net> Message-ID: References: <20050331071906.GA15752@1-4-5.net> <20050331173226.GA26657@1-4-5.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: Pekka Savola On Thu, 31 Mar 2005, David Meyer wrote: >> Our AD (and others) have asked if we could review >> draft-malamud-keyword-discovery-03.txt. If you have the >> time, a critical review would be much appreciated. > > Brief update. The IESG would like our feedback on this > document within a 2 weeks, if possible (say by around 15 > Apr 2005). In trying to get the folks to take a peek and to get the comments started, here's my opinion (already expressed in another forum): This seems like an interesting approach, but I do not think the implications of this have been sufficiently reviewed, especially by the DNSOPs community. Maybe this would also warrant a bit more discussion in the "anti-spam" communitities (whichever those are). .... The document seems to assume that the users are able to insert properly formatted and correct solicitation keywords in the message, which can be sanely parsed by a computer. Effectively, this allows anyone to perform a DoS on someone else's resources (assuming specifying something like net.example.adv would result in everyone going and taking a look at "adv" policy at example.net -- thus flooding example.net). A maliscious advertiser could also insert improperly formatted keywords, or insert 100 such keywords which will time out, consuming even more processing than receiving the message would have done. Improperly formatted entries like 'No-Solicit: dont-spam-me-plaase' also cause the root servers to be bombarded with bogus DNS queries. Maybe the parser needs to discard some more bogus entries, but how to do that properly is an open issue. This should probably be discussed in the draft, and security issues fleshed out in Security Considerations. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From haisley@doramail.com Tue Apr 12 17:13:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12148; Tue, 12 Apr 2005 17:13:42 -0400 (EDT) Received: from [84.217.42.26] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLSrH-00087b-58; Tue, 12 Apr 2005 17:23:44 -0400 Delivered-To: ginsberg@glamour.dreamhost.com Received: from dolly.dreamhost.com by grebe.dreamhost.com (Pingofix) with ESMTP id 7CC6A01D9B for ; Wed, 13 Apr 2005 02:10:32 +0400 Message-ID: Date: Tue, 12 Apr 2005 15:10:32 -0700 From: "Frankie Cullen" To: Subject: Become one of the low rates X-Mailer: Mailman v2.0.2 X-SpamTest-Info: Profile: Formal (167/041178) X-SpamTest-Info: Profile: Detect Hard No RBL (4/030506) X-Spam-Score: 1.7 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Adolph Spaulding to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-dnsop@lists.uoregon.edu Wed Apr 13 09:20:53 2005 Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24396 for ; Wed, 13 Apr 2005 09:20:52 -0400 (EDT) Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j3DCPGnL029888; Wed, 13 Apr 2005 05:25:17 -0700 (PDT) Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j3DCPGrO029887; Wed, 13 Apr 2005 05:25:16 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j3DCPFLp029846 for ; Wed, 13 Apr 2005 05:25:15 -0700 (PDT) Received: by postman.ripe.net (Postfix, from userid 8) id E76E825A9A; Wed, 13 Apr 2005 14:25:09 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 1D22C25AA6; Wed, 13 Apr 2005 14:25:07 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j3DCP7et016379; Wed, 13 Apr 2005 14:25:07 +0200 Date: Wed, 13 Apr 2005 14:25:06 +0200 From: "Olaf M. Kolkman" To: Samuel Weiler Cc: dnsop@lists.uoregon.edu Subject: Re: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03 Message-Id: <20050413142506.5777bafc.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_05,SUBJ_HAS_UNIQ_ID X-RIPE-Spam-Status: U 0.255156 / -2.4 X-RIPE-Signature: 074f5b1078f10061d98e037f899a632e Sender: owner-dnsop@lists.uoregon.edu Precedence: bulk Reply-To: "Olaf M. Kolkman" Content-Transfer-Encoding: 7bit On Fri, 1 Apr 2005 13:24:27 -0500 (EST) Samuel Weiler wrote: > How about something with a little more explanation and a slightly > stronger suggestion? I added a small paragraph to your suggested text the section now reads as quoted below. If there are no further comments on this I think we addresses all the last call issues. We will roll the draft shortly. --Olaf 4.4.2 Storing Keys or Hashes? When designing a registry system one should consider which of the DNSKEYs and/or the corresponding DSs to store. Since a child zone might wish to have a DS published using a message digest algorithm not yet understood by the registry, the registry can't count on being able to generate the DS record from a raw DNSKEY. Thus, we recommend that registry system at least support storing DS records. It may also be useful to store DNSKEYs, since having them may help during troubleshooting and, so long as the child's chosen message digest is supported, the overhead of generating DS records from them is minimal. Having an out-of-band mechanism, such as a Whois database, to find out which keys are used to generate DS Resource Records for specific owners and/or zones may also help with troubleshooting. The storage considerations also relate the design of the customer interface and the method by which data is transfered between registrant and registry; Will the child zone owner be able to upload DS RRs with unknown hash algorithms or does the interface only allows DNSKEYs? In the registry-registrar model one can use the DNSSEC EPP protocol extensions [9] which allows transfer of DS RRs and optionally DNSKEY RRs. -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From alvaa@yebox.com Thu Apr 14 13:50:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06074; Thu, 14 Apr 2005 13:50:31 -0400 (EDT) Received: from 92.3.100-84.rev.gaoland.net ([84.100.3.92]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DM8e2-0001sa-SH; Thu, 14 Apr 2005 14:00:55 -0400 Authentication-Results: dialup.es from=premium.done.es; domainkeys=neutral (no sig) X-Originating-IP: [29.22.38.206] Received: from premium.sirius.es (EHLO premium.oaken.es) by premium.pocono.es with SMTP; Thu, 14 Apr 2005 22:48:18 +0400 Date: Thu, 14 Apr 2005 16:41:18 -0200 From: "Marshall Goldberg" To: discuss@ietf.org Cc: discuss-admin@ietf.org, discuss-archive@ietf.org, discuss-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-archive@ietf.org, dmin@ietf.org, dnsind-archive@ietf.org, dnsop-archive@ietf.org, dnssec-archive@ietf.org, donny.gifford@ietf.org, dorthy.bruno@ietf.org Subject: Become one of the low rates Message-ID: <111841.5490.alvaa@yebox.com> X-Mailer: Kana Connect 6 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Olin Parsons to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From socscie@fadmail.com Fri Apr 15 06:59:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16697; Fri, 15 Apr 2005 06:59:40 -0400 (EDT) Received: from [220.70.68.107] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMOiC-0000LB-KK; Fri, 15 Apr 2005 07:10:14 -0400 X-Apparently-To: discuss@ietf.org X-Sieve: CMU Sieve 2.2 Received: from yuh.hollerith.pochta.ru ([unix socket]) by parke.embryology.pochta.ru (Cyrus v2.2.4) with LMTPA; Fri, 15 Apr 2005 15:54:32 +0400 Date: Fri, 15 Apr 2005 09:00:32 -0300 From: "Stacy Link" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: discuss@ietf.org Cc: discuss-admin@ietf.org, discuss-archive@ietf.org, discuss-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-archive@ietf.org, dmin@ietf.org, dnsind-archive@ietf.org, dnsop-archive@ietf.org, dnssec-archive@ietf.org, donny.gifford@ietf.org, dorthy.bruno@ietf.org, doyle.crouch@ietf.org Subject: Become a homeowner with low rates X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 15.3 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Lorene Mock to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From almonds@emailaccount.com Fri Apr 15 13:13:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22489; Fri, 15 Apr 2005 13:13:54 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMUYQ-0000iX-5a; Fri, 15 Apr 2005 13:24:32 -0400 Received: from hem62-1-82-238-49-19.fbx.proxad.net ([82.238.49.19]) by mx2.foretec.com with smtp (Exim 4.24) id 1DMTek-00076F-PC; Fri, 15 Apr 2005 12:26:59 -0400 Received: from cellulose.ft-onward.com (HELO trenton.com 66.8.115.78) by cpa.com with EMQP; Fri, 15 Apr 2005 15:06:38 -0300 Date: Fri, 15 Apr 2005 13:06:38 -0500 From: "Samantha Knight" Message-Id: To: discuss@ietf.org Cc: discuss-admin@ietf.org, discuss-archive@ietf.org, discuss-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-archive@ietf.org, dmin@ietf.org, dnsind-archive@ietf.org, dnsop-archive@ietf.org, dnssec-archive@ietf.org, donny.gifford@ietf.org, dorthy.bruno@ietf.org, doyle.crouch@ietf.org, dp@ietf.org Subject: Notification: We offer low rates X-Mailer: CompuServe 7.0 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Joshua Peck to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From uhay@doramail.com Fri Apr 15 17:44:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01636; Fri, 15 Apr 2005 17:44:38 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYmR-0003fo-Lb; Fri, 15 Apr 2005 17:55:17 -0400 Received: from d57-55-109.home.cgocable.net ([24.57.55.109]) by mx2.foretec.com with smtp (Exim 4.24) id 1DMYc5-0006TB-F2; Fri, 15 Apr 2005 17:44:36 -0400 Received: from dielectric.davison-leggy.com (HELO mnemonic.com 66.4.160.20) by dadaist.com with EMQP; Fri, 15 Apr 2005 17:32:49 -0500 Date: Sat, 16 Apr 2005 02:35:49 +0400 From: "Wilbert Mccoy" Message-Id: To: dmin@ietf.org Cc: dnsind-archive@ietf.org, dnsop-archive@ietf.org, dnssec-archive@ietf.org, donny.gifford@ietf.org, dorthy.bruno@ietf.org, doyle.crouch@ietf.org, dp@ietf.org Subject: Become a homeowner with low rates X-Mailer: CompuServe 7.0 X-Spam-Score: 8.0 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Jocelyn Mccullough to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s.