From owner-namedroppers@ops.ietf.org Mon Dec 1 10:17:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14277 for ; Mon, 1 Dec 2003 10:17:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQpgO-000MOG-Kx for namedroppers-data@psg.com; Mon, 01 Dec 2003 15:09:52 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQpgB-000MNy-Ka for namedroppers@ops.ietf.org; Mon, 01 Dec 2003 15:09:39 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hB1F9Q18021819 for ; Mon, 1 Dec 2003 10:09:26 -0500 (EST) Message-ID: <023601c3b81d$217edb30$b9370681@barnacle> From: "Scott Rose" To: Subject: comment on nsec+ draft Date: Mon, 1 Dec 2003 10:09:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Comment on section 2.1.1 in draft-ietf-dnsext-nsec-rdata-00: The text suggests expanding compressed names in the RDATA of the NSEC RR, but DNSSECbis Q22 mentions not wanting to specifically address compressed names. The text in Section 2.1.1 could be dropped as well. Minor difference, but the draft would conflict with the statement in the DNSSECbis docs, and it is text that would appear in the DNSSECbis doc set. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 1 15:39:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28103 for ; Mon, 1 Dec 2003 15:39:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQufG-000CLQ-8t for namedroppers-data@psg.com; Mon, 01 Dec 2003 20:29:02 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQueH-000CIh-6h for namedroppers@ops.ietf.org; Mon, 01 Dec 2003 20:28:01 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26884; Mon, 1 Dec 2003 15:27:45 -0500 (EST) Message-Id: <200312012027.PAA26884@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-00.txt Date: Mon, 01 Dec 2003 15:27:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-00.txt Pages : 9 Date : 2003-12-1 This document defines updates the NSEC resource record RDATA format to cover all type codes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-1151814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1151814.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 1 15:39:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28125 for ; Mon, 1 Dec 2003 15:39:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQuez-000CKd-AS for namedroppers-data@psg.com; Mon, 01 Dec 2003 20:28:45 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQueO-000CJ3-6I for namedroppers@ops.ietf.org; Mon, 01 Dec 2003 20:28:08 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26898; Mon, 1 Dec 2003 15:27:53 -0500 (EST) Message-Id: <200312012027.PAA26898@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-25.txt Date: Mon, 01 Dec 2003 15:27:52 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-25.txt Pages : 22 Date : 2003-12-1 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-25.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-25.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-25.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-1151825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-25.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-25.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1151825.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 2 00:16:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20544 for ; Tue, 2 Dec 2003 00:16:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AR2lb-000AdQ-9L for namedroppers-data@psg.com; Tue, 02 Dec 2003 05:08:07 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AR2lD-000AcU-Mq for namedroppers@ops.ietf.org; Tue, 02 Dec 2003 05:07:43 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id hB257gRb020517 for ; Tue, 2 Dec 2003 00:07:42 -0500 (EST) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAZIaGeO; Tue, 2 Dec 03 00:07:42 -0500 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003120200074224389 for ; Tue, 02 Dec 2003 00:07:42 -0500 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by odconpr2-hme0.oddc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003120200074224264 for ; Tue, 02 Dec 2003 00:07:42 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr2-hme0.shdc.chrysler.com (8.12.10/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id hB257gwq001467 for ; Tue, 2 Dec 2003 00:07:42 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id hB257Bhp007788 for ; Tue, 2 Dec 2003 00:07:11 -0500 (EST) Message-ID: <3FCC1DFF.3040109@daimlerchrysler.com> Date: Tue, 02 Dec 2003 00:07:11 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Fixing QTYPE=* Recursion (was Re: Issue: Add a new QTYPE) References: <3FC42517.4090404@daimlerchrysler.com> <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> <5523.1069838436@munnari.OZ.AU> In-Reply-To: <5523.1069838436@munnari.OZ.AU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Prior to the Thanksgiving break, I received a number of replies from various WG members in the "Add a new QTYPE" thread, going in different directions, and it occurs to me that the branching of the thread is largely due to insufficient specificity on my part. I apologize for that. I've been throwing around terms like "complete response" without really attempting any kind of definition for them. Truth be told, I'm still thinking QTYPE=* recursion through in my head. This message is an attempt to give some form to my current thinking on the subject, presented to see if my clarification proposal has any chance of gaining traction in the WG. The behavior I'm trying to crystallize with the term "complete response" is that the results of a recursive QTYPE=* query should at all times be identical to the combined results of (theoretically) issuing separate but simultaneous recursive queries of each record type that is known to the querier. Corollaries: 1) When I say "at all times", I mean that in the case of an intermediate caching server, not only should the *initial* QTYPE=* query yield the same results as if it were actually separate queries, but any *subsequent* QTYPE=* queries of the same name should yield the same results as if all previous QTYPE=* queries were actually composed of separate queries too, and take into consideration what lingering effects those separate queries would have had on the cache contents. When attempting to answer from cached data, this corollary naturally implies that both positive *and* negative caching must be factors in the overall result (for the nitpickers out there, consider that CNAMEs, at least, make it impossible for a name to own records of *all* known record types, even if an implementation only has "knowledge" of the 1034/1035 RR definitions, so it is always the case that at least one queried record type for a given name will get a NODATA response, assuming that the responder is RFC 2308-aware). 2) If any of the RRsets for record types seen in the previous QTYPE=* query have expired, then a conforming responder cannot give a "complete" answer from cache and *must* recurse to answer the query, although it would be up to the responder whether it recurses the whole QTYPE=* query, or just one or more type-specific queries to fill in the missing RRset(s). 3) One of the necessary rules of this "combining" process is that if negative-caching records of differing expiration timestamps are encountered, the combined result will reflect the most proximate expiration timestamp. Admittedly, this devalues negative caching somewhat in this particular situation, but is necessary to maintain the integrity of the mechanism, much as minimizing TTLs within a positively-cached RRset was perceived (RFC 2181) as necessary to maintain cache integrity. Ultimately, my thinking is that reconstructability of "complete" QTYPE=* responses from cache gives rise to a requirement that all QTYPE=* responses, whether from cache or authoritative data, include a "complementary" negative caching record (Authority Section SOA RR) in addition to any answers that are given in the Answer Section. I call this "complementary" because it implies a NODATA for all record types which are absent from the actual answer, e.g. if the answer to a particular QTYPE=* query consists of an A RRset and an MX RRset, then the "complementary" negative caching record would imply NODATA for all other potential RRsets (NS, PTR, SRV, CNAME and so forth). As long as the "complementary" negative caching record and all of the relevant "positively" cached RRsets are still unexpired, a "complete" answer -- which might include updated RDATAs and/or TTLs for the "positive" RRsets, but will not include any RRsets still precluded by the "complementary" negative caching record -- can be constructed from a cache for any subsequent QTYPE=* queries of the same name without having to resort to recursing the query. Particularly-clever resolvers may, under some low-TTL circumstances, still choose to pre-emptively recurse the QTYPE=* query or a type-specific query, in order to improve the quality of their cache and/or their response and therefore avoid unnecessary queries in the near future from downstream resolvers. "Complementary" negative caching solves, I believe, the "completeness" issue, as defined, but raises the possibility of interoperability problems with modern-but-pre-clarification resolvers which will not be expecting negative-caching records to accompany answerful (ANCOUNT>0) responses. This lack-of-expectation could arise because RFC 2308 defined NODATA negative-caching responses quite narrowly as having "no relevant answers in the answer section". That definition would need to be loosened in order for "complementary" negative caching to become legal. The interoperability question this change raises is, do any implementations actually *ignore* or *reject* relevant contents of the Answer Section solely because there is also an SOA in the Authority Section? A quick code check of BIND 9 implies that the Answer Section RRs of a response to a recursed query are processed before it even looks at the Authority Section, and even if it subsequently finds an SOA record there, it will simply ignore it (in accordance with RFC 1034's "optional" negative caching pseudo-specification). So initial indications are that BIND 9 would not have a problem with this, and, although I am less sure about them, it would surprise me if any other implementations would have a problem either -- such a restrictive implementation would never have been able to interoperate with pre-2308 forms of "optional" negative caching. Pre-clarification resolvers are more likely by far to simply ignore the "illegal" negative-caching record, than to choke on it. But the proof is in the pudding, of course; that's what interoperability testing is all about... Requiring a "complementary" negative caching record should also have the beneficial effect of definitively (again, this would need to be confirmed in field interoperability tests) marking a QTYPE=* answer as coming from a conforming implementation or not -- if the response contains a "complementary" negative caching record, then the querier can be confident that the responder understands the newly-clarified semantics and either recursed for the answer or was able to properly construct it from cache or authoritative data; conversely, if the response is non-authoritative and lacks the "complementary" negative caching record, then the querier is put on notice that the answer may be incomplete and it should take appropriate backup measures, as configured, in a similar fashion to how it deals with malformed responses, e.g. trying other upstream forwarders, if configured, or bypassing forwarders altogether and trying to query authoritative servers directly. If all other measures of dealing with the backlevel response have failed, it could return the possibly-partial answer _as_is_ and hope that the client/caller is sophisticated enough to realize that the absence of the "complementary" negative caching record from the response implies that the answer may be incomplete. Perhaps there could even be a new flag in resolver APIs to indicate whether the caller would accept a possibly-incomplete answer to a QTYPE=* query... - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 2 20:00:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26711 for ; Tue, 2 Dec 2003 20:00:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARLDH-0003CS-MI for namedroppers-data@psg.com; Wed, 03 Dec 2003 00:49:55 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARLD5-0003BN-13 for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 00:49:43 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id UAA26173 for ; Tue, 2 Dec 2003 20:53:50 -0500 Date: Tue, 2 Dec 2003 19:47:12 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: namedroppers@ops.ietf.org Subject: List administration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I was following this message from Nanog, in which Randy Bush is complaining about Verizon spam filtering. What is alarming, is the change that Mr. Bush put into the PSG mail system, which also handles namedroppers email. I think that if PSG does not have the resources to handle the mail for namedroppers without capriciously deleted mail, then it should be handed to someone else who does have the resources. I would like to volunteer Av8 Internet as a more suitable and resourceful host for the namedroppers site. I need not remind anyone of the past administration problems with Dan Bernstein and others which have resulted in censure and administrative changes to the administration of Namedroppers by PSG and Mr. Bush. These problems have been repeated, and it seems that we are at the start of yet another administration "problem". It seems to me that no matter what we do, we will never rid ourselves of a constant stream of administrative problems if we keep the hosting the list at PSG. By contrast, Av8 Internet has no political axe to grind over whose email to send and whose to interfere with. Av8 does not interfere with anyone's email, nor will it ever capriciously delete anyone's email, nor will it ever abuse its administrative privileges for personal harrassment. Dean Anderson CEO Av8 Internet, Inc ---------- Forwarded message ---------- Date: Mon, 1 Dec 2003 11:10:16 -0800 From: Randy Bush To: Jared Mauch Cc: Suresh Ramasubramanian , nanog@nanog.org Subject: Re: incorrect spam setups cause spool messes on forwarders > I think he's saying that they were unable to perform the > validation hence the 450. If the validation was successful, > they'd return a 200 series code, if it was unsuccessful, they > would return a 500 series code. nice words, but crap. due to needs to spool mail for sites in countries with very poor connectivity, mail spool time here is quite long. if verizon and others seem unable to decide in weeks, why should i pay the penalty? but, i guess the problem is easily solved with exim config. i have set it so that if it can not deliver to verizon in say one hour, it dumps the mail. verizon.net * F,1h,5m life is simple, except for verizon users i guess. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 08:36:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14488 for ; Wed, 3 Dec 2003 08:36:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARX3b-0007lO-L8 for namedroppers-data@psg.com; Wed, 03 Dec 2003 13:28:43 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARX3O-0007kd-Jg for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 13:28:30 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB3DSR2w039707; Wed, 3 Dec 2003 14:28:27 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB3DTWWq025408; Wed, 3 Dec 2003 14:29:32 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB3DTW4X025407; Wed, 3 Dec 2003 14:29:32 +0100 Date: Wed, 3 Dec 2003 14:29:32 +0100 From: Miek Gieben To: Jakob Schlyter Cc: IETF DNSEXT WG Subject: Re: nsec++ Message-ID: <20031203132932.GA25240@atoom.net> Mail-Followup-To: Jakob Schlyter , IETF DNSEXT WG 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 X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 27 Nov, @16:21, Jakob wrote in "nsec++ ..."] > my initial version of the draft respecifying the rdata format for nsec has > been submitted to the drafts editor and can also be found at the following > address: > > http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-00.txt i'm looking at the draft from: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-00.txt I have made the following observations: 1. Introduction: amount of space it uses for the common case of a few types with an owner name; that it can represent owner names with all possible type present in packets of approximately 8.5 kilobytes; that the representation is simple to implement. Efficient searching of the I didn't closely follow the NSEC discussion...but where is this 8.5 kilobytes coming from? 2.1.2 The List of Type Bit Map(s) Field: the bitmap MUST be removed. Blocks is presented in increasing numerical order. "|" denotes concatenation NSEC RDATA = ( Window Block # | Bitmap Length | Bitmap ) + Shouldn't that be: Type Bit Map = ( Window Block # | Bitmap Length | Bitmap ) or Type Bit Maps = ( Window Block # | Bitmap Length | Bitmap ) + Also I only now notice the '+', more that can be made more explicit. I'm also missing some text on how to calculate the type from the bitmap (although that would not be difficult). I assume something like: Window Block # * 256 + Bit # (in Bitmap). 2.3 NSEC RR Example: Maybe it is an idea to also include the NSEC RR with integers instead of RRtypes, thus: alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC or alfa.example.com. 86400 IN NSEC host.example.com. 1 23 47 48 (i'm too lazy to lookup the correct typecodes for the types) This integer stuff, was that already in the NXT record? If not, why is it here? (unknown RRs probably). Can I mix integers and real types in a NSEC RR? grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 08:58:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15164 for ; Wed, 3 Dec 2003 08:58:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARXR5-0008qE-Up for namedroppers-data@psg.com; Wed, 03 Dec 2003 13:52:59 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARXQk-0008on-SZ for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 13:52:39 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id DE4341958B; Wed, 3 Dec 2003 14:52:37 +0100 (CET) Date: Wed, 3 Dec 2003 14:52:37 +0100 (CET) From: Jakob Schlyter To: Miek Gieben Cc: IETF DNSEXT WG Subject: Re: nsec++ In-Reply-To: <20031203132932.GA25240@atoom.net> Message-ID: References: <20031203132932.GA25240@atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Dec 2003, Miek Gieben wrote: > 1. Introduction: > > amount of space it uses for the common case of a few types with an > owner name; that it can represent owner names with all possible type > present in packets of approximately 8.5 kilobytes; that the > representation is simple to implement. Efficient searching of the > > I didn't closely follow the NSEC discussion...but where is this 8.5 > kilobytes coming from? worst case is 256 blocks, each represented using 34 bytes. this results in about 8.5 kbytes. > 2.1.2 The List of Type Bit Map(s) Field: > > the bitmap MUST be removed. Blocks is presented in increasing > numerical order. > > "|" denotes concatenation > > NSEC RDATA = ( Window Block # | Bitmap Length | Bitmap ) + > > Shouldn't that be: > > Type Bit Map = ( Window Block # | Bitmap Length | Bitmap ) > > or > > Type Bit Maps = ( Window Block # | Bitmap Length | Bitmap ) + > > Also I only now notice the '+', more that can be made more explicit. I suggest the 2nd version since it is a list of bit maps. or should we write something like: NSEC RDATA = Next Domain Name | ( Window Block # | Bitmap Length | Bitmap ) + > I'm also missing some text on how to calculate the type from the > bitmap (although that would not be difficult). > > I assume something like: Window Block # * 256 + Bit # (in Bitmap). please send text. > 2.3 NSEC RR Example: > > Maybe it is an idea to also include the NSEC RR with integers instead > of RRtypes, thus: > > alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC > or > alfa.example.com. 86400 IN NSEC host.example.com. 1 23 47 48 > (i'm too lazy to lookup the correct typecodes for the types) > > This integer stuff, was that already in the NXT record? If not, > why is it here? (unknown RRs probably). unknown RRs can be represented either as integers or TYPE# notation. > Can I mix integers and real types in a NSEC RR? the current text does not allow mixing I think. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 09:01:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15371 for ; Wed, 3 Dec 2003 09:01:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARXVQ-00097P-Ft for namedroppers-data@psg.com; Wed, 03 Dec 2003 13:57:28 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARXVE-00096z-Ks for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 13:57:16 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB3Dv22w039987; Wed, 3 Dec 2003 14:57:07 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB3Dw7Wq026097; Wed, 3 Dec 2003 14:58:07 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB3Dw7g6026096; Wed, 3 Dec 2003 14:58:07 +0100 Date: Wed, 3 Dec 2003 14:58:07 +0100 From: Miek Gieben To: Jakob Schlyter Cc: IETF DNSEXT WG Subject: Re: nsec++ Message-ID: <20031203135807.GA25957@atoom.net> Mail-Followup-To: Jakob Schlyter , IETF DNSEXT WG References: <20031203132932.GA25240@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 X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 03 Dec, @14:52, Jakob wrote in "Re: nsec++ ..."] > worst case is 256 blocks, each represented using 34 bytes. this results in > about 8.5 kbytes. ahh, so simple :) > > Type Bit Maps = ( Window Block # | Bitmap Length | Bitmap ) + > > > > Also I only now notice the '+', more that can be made more explicit. > > I suggest the 2nd version since it is a list of bit maps. or should we > write something like: > > NSEC RDATA = Next Domain Name | > ( Window Block # | Bitmap Length | Bitmap ) + The paragraph is called "2.1.2 The List of Type Bit Map(s) Field", so I think my second suggestion is more consistent. > > I'm also missing some text on how to calculate the type from the > > bitmap (although that would not be difficult). > > > > I assume something like: Window Block # * 256 + Bit # (in Bitmap). > > please send text. will do, > > Can I mix integers and real types in a NSEC RR? > > the current text does not allow mixing I think. maybe it should say that? grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 09:04:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15404 for ; Wed, 3 Dec 2003 09:04:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARXZs-0009Mi-Dp for namedroppers-data@psg.com; Wed, 03 Dec 2003 14:02:04 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARXZg-0009M3-KA for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 14:01:52 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id B1FCD1958B; Wed, 3 Dec 2003 15:01:51 +0100 (CET) Date: Wed, 3 Dec 2003 15:01:51 +0100 (CET) From: Jakob Schlyter To: Miek Gieben Cc: IETF DNSEXT WG Subject: Re: nsec++ In-Reply-To: <20031203135807.GA25957@atoom.net> Message-ID: References: <20031203132932.GA25240@atoom.net> <20031203135807.GA25957@atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Dec 2003, Miek Gieben wrote: > > > Can I mix integers and real types in a NSEC RR? > > > > the current text does not allow mixing I think. > > maybe it should say that? I think it already does: "The Type Bit Map field is represented either as a sequence of RR type mnemonics or as a sequence of unsigned decimal integers denoting the RR type codes." i.e., one type of sequence OR another type of sequence. if it allowed mixing, it would probably say: "The Type Bit Map field is represented as a sequence of RR type mnemonics or unsigned decimal integers denoting the RR type codes." jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 09:06:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15439 for ; Wed, 3 Dec 2003 09:06:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARXcC-0009Wb-Kk for namedroppers-data@psg.com; Wed, 03 Dec 2003 14:04:28 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARXc0-0009Vi-Rn for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 14:04:17 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB3E3x2w040095; Wed, 3 Dec 2003 15:04:04 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB3E55Wq026307; Wed, 3 Dec 2003 15:05:05 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB3E556H026306; Wed, 3 Dec 2003 15:05:05 +0100 Date: Wed, 3 Dec 2003 15:05:04 +0100 From: Miek Gieben To: Jakob Schlyter Cc: IETF DNSEXT WG Subject: Re: nsec++ Message-ID: <20031203140504.GB25957@atoom.net> Mail-Followup-To: Jakob Schlyter , IETF DNSEXT WG References: <20031203132932.GA25240@atoom.net> <20031203135807.GA25957@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 X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 03 Dec, @15:01, Jakob wrote in "Re: nsec++ ..."] > I think it already does: > > "The Type Bit Map field is represented either as a sequence of RR type > mnemonics or as a sequence of unsigned decimal integers denoting the RR > type codes." > > i.e., one type of sequence OR another type of sequence. if it allowed > mixing, it would probably say: > > "The Type Bit Map field is represented as a sequence of RR type mnemonics > or unsigned decimal integers denoting the RR type codes." yep, you're right, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 09:53:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17180 for ; Wed, 3 Dec 2003 09:53:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARYK3-000Bfh-92 for namedroppers-data@psg.com; Wed, 03 Dec 2003 14:49:47 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARYJT-000Be5-9F for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 14:49:11 +0000 Received: from nlnetlabs.nl (eidolon.nlnetlabs.nl [IPv6:2001:7b8:206:1:240:f4ff:fe37:7af9]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB3En72w040801 for ; Wed, 3 Dec 2003 15:49:07 +0100 (CET) (envelope-from erik@nlnetlabs.nl) Message-ID: <3FCDF7E3.8070608@nlnetlabs.nl> Date: Wed, 03 Dec 2003 15:49:07 +0100 From: Erik Rozendaal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Empty non-terminals and NSEC records Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The example zone in the draft-ietf-dnsext-dnssec-protocol-03.txt document contains the following records (among others and excluding RRSIG records): ns2.example. 3600 IN A 192.0.2.2 3600 NSEC *.w.example. A RRSIG NSEC *.w.example. 3600 IN MX 1 ai.example. 3600 NSEC x.w.example. MX RRSIG NSEC Notice there are no RRs for the w.example. domain, making it an empty non-terminal. According to the original DNS RFCs empty non-terminals do exist (in other words, querying for w.example. will not result in NXDOMAIN but in NODATA). However, the signed version does not include proper NSEC records for w.example. Is this intentional and expected behaviour? Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 14:01:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29436 for ; Wed, 3 Dec 2003 14:01:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARc77-000OSy-Da for namedroppers-data@psg.com; Wed, 03 Dec 2003 18:52:41 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARc6u-000ORn-ED for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 18:52:28 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB3IqPw5002563; Wed, 3 Dec 2003 10:52:25 -0800 (PST) Received: from cisco.com ([161.44.65.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEJ91299; Wed, 3 Dec 2003 13:52:23 -0500 (EST) Message-ID: <3FCE30E7.6040505@cisco.com> Date: Wed, 03 Dec 2003 13:52:23 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakob Schlyter CC: IETF DNSEXT WG Subject: Re: nsec++ References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jakob Schlyter wrote: > my initial version of the draft respecifying the rdata format for nsec has > been submitted to the drafts editor and can also be found at the following > address: > > http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-00.txt > > > please send comments to namedroppers, I assume this will be folded into the dnssec-records draft, and this draft will die. Assuming this is roughly to replace section 4 of that document, I think we've lost some good text about the composition of the bitmap(s). From 4.1.2: Each bit in the Type Bit Map field corresponds to an RR type. Bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. If a bit is set to 1, it indicates that an RRset of that type is present for the NSEC RR's owner name. If a bit is set to 0, it indicates that no RRset of that type present for the NSEC RR's owner name. That is, you've added description of block numbering and bitmap length, but lost all description of bitmap construction, and substituted a reference to RFC2535. Moreover, the notion of "window blocks" is never explicitly described as corresponding to the upper 8 bits of an RR typecode. I'd recommend changing para. 2 of 2.1.2, as follows: The RR type space is split into 256 window blocks, each representing the low-order 8 bits of the 16-bit RR type space. Each block that has at least one active RR type is encoded using a single octet window number (from 0 to 255), a single octet bitmap length (from 1 to 32) indicating the number of octets used for the window block's bitmap, and up to 32 octets (256 bits) of bitmap. Blocks are present in the NSEC RR data in increasing numerical order. "|" denotes concatenation Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. For window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window block 1, bit 1 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 1, it indicates that an RRset of that type is present for the NSEC RR's owner name. If a bit is set to 0, it indicates that no RRset of that type is present for the NSEC RR's owner name. Bits representing pseudo-RR types MUST be set to 0, since they do not appear in zone data. If encountered, they must be ignored upon reading. Blocks with no types present MUST NOT be included. Trailing zero octets in the bitmap MUST be omitted. The length of each block's bitmap is determined by the type code with the largest numerical value, within that block, among the set of RR types present at the NSEC RR's owner name. Trailing zero octets not specified MUST be interpretted as zero octets. This paragraph: A zone MUST NOT generate an NSEC RR for any domain name that only holds glue records. Doesn't seem to belong the section describing the type bitmap field. It belongs in Section 2. It is not related to "wire-format", but to when an NSEC RR should exist. Additional comments: - If the TYPE# notation can be used for unknown RR types in a symbolic list of RR types, then this should be explicitly mentioned. Otherwise, the presense of one unknown type would force the entire set to be printed using decimal notation. - An example of the actual binary data (octet by octet) for an NSEC RR using at least two non-sequential "window blocks" would be useful. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 14:13:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29691 for ; Wed, 3 Dec 2003 14:13:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARcJj-000PHd-DX for namedroppers-data@psg.com; Wed, 03 Dec 2003 19:05:43 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARcJN-000PFj-Bb for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 19:05:21 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7p1+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id hB3J5JG24059; Wed, 3 Dec 2003 20:05:20 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id hB3J5J708209; Wed, 3 Dec 2003 20:05:19 +0100 (MET) Message-Id: <200312031905.hB3J5J708209@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: Jakob Schlyter Cc: IETF DNSEXT WG Subject: Re: nsec++ In-reply-to: Your message of "Wed, 03 Dec 2003 15:01:51 +0100." 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: <8206.1070478318.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 03 Dec 2003 20:05:19 +0100 From: Peter Koch X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > i.e., one type of sequence OR another type of sequence. if it allowed > mixing, it would probably say: > > "The Type Bit Map field is represented as a sequence of RR type mnemonics > or unsigned decimal integers denoting the RR type codes." For the sake of consistency with RFC 3597 I'd use the TYPEnnn convention and don't see any reason not to allow "mixed" format. "The Type Bit Map field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation as of section 5 of [RFC 3597] MUST be used, otherwise it MAY {SHOULD NOT} be used." Other comments: 2.0 The NSEC RR is class independent. -> The NSEC RR RDATA format is class independent and defined for all classes. {The RR or the contents of the RR really is class dependent} 2.1.1 Owner names of RRsets not authoritative for the given zone (such as glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name. Isn't this already covered by the reference to canonical sort order? Anyway, owner names or RRSets are not "authoritative for" the zone but are "in" the zone (or not). Section 4 of AXFR clarify, which still hasn't made it to RFC, has some wording about this. If a discussion is appropriate here, the "empty non-leaf node" problem could be solved, too. (short: NSEC may point to siblings, children or parents, but not to nephews). 2.1.2 Bits representing pseudo-RR types MUST be set to 0, since they do not appear in zone data. If encountered, they must be ignored upon reading. The term "pseudo-RR" needs a definition. Again stealing from 3597 I'd say: Bits representing Meta-TYPEs or QTYPEs as specified in [RFC 2929] (section 3.1) or within the range reserved for assignment only to QTYPEs and Meta-TYPEs MUST be set to 0 ... This may also change the maximum length calculation a bit (although 2929 doesn't explicitly say that the TYPE reservation is valid for classes other than IN), which could be provided in an appendix. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 14:22:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29909 for ; Wed, 3 Dec 2003 14:22:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARcSE-000PmZ-8z for namedroppers-data@psg.com; Wed, 03 Dec 2003 19:14:30 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARcRx-000PlU-ME for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 19:14:13 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DD33018E4 for ; Wed, 3 Dec 2003 14:14:12 -0500 (EST) Date: Wed, 03 Dec 2003 14:14:12 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Empty non-terminals and NSEC records In-Reply-To: <3FCDF7E3.8070608@nlnetlabs.nl> References: <3FCDF7E3.8070608@nlnetlabs.nl> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031203191412.DD33018E4@thrintun.hactrn.net> X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 03 Dec 2003 15:49:07 +0100, Erik Rozendaal wrote: > > The example zone in the draft-ietf-dnsext-dnssec-protocol-03.txt document > contains the following records (among others and excluding RRSIG records): > > ns2.example. 3600 IN A 192.0.2.2 > 3600 NSEC *.w.example. A RRSIG NSEC > *.w.example. 3600 IN MX 1 ai.example. > 3600 NSEC x.w.example. MX RRSIG NSEC > > Notice there are no RRs for the w.example. domain, making it an empty > non-terminal. According to the original DNS RFCs empty non-terminals do > exist (in other words, querying for w.example. will not result in NXDOMAIN > but in NODATA). > > However, the signed version does not include proper NSEC records for > w.example. Is this intentional and expected behaviour? Er, if empty non-terminal nodes had NSEC RRs, they wouldn't be empty. The approach we took in the DNSSECbis docs was to talk about RRsets and owner names of RRsets rather than name existance per se. If you're asking what the form of a response should be for a query w.example, it'd be the form covered in 3.1.3.2: note that section 3.1.3.2 deliberately does not specify the RCODE. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 14:36:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00529 for ; Wed, 3 Dec 2003 14:36:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARcja-00014L-11 for namedroppers-data@psg.com; Wed, 03 Dec 2003 19:32:26 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARcjN-00013D-3v for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 19:32:13 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hB3JVx18022558 for ; Wed, 3 Dec 2003 14:31:59 -0500 (EST) Message-ID: <01f301c3b9d4$1f804090$b9370681@barnacle> From: "Scott Rose" To: "IETF DNSEXT WG" References: <3FCE30E7.6040505@cisco.com> Subject: Re: nsec++ Date: Wed, 3 Dec 2003 14:32:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Josh Littlefield" To: "Jakob Schlyter" Cc: "IETF DNSEXT WG" Sent: Wednesday, December 03, 2003 1:52 PM Subject: Re: nsec++ > Jakob Schlyter wrote: > > > my initial version of the draft respecifying the rdata format for nsec has > > been submitted to the drafts editor and can also be found at the following > > address: > > > > http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-00.txt > > > > > > please send comments to namedroppers, > > I assume this will be folded into the dnssec-records draft, and this > draft will die. Assuming this is roughly to replace section 4 of that > document, I think we've lost some good text about the composition of the > bitmap(s). From 4.1.2: > (DNSSICbis-editor) It won't be a full replacement - just some of the RDATA field descriptions. We'll try to keep much of the descriptive text that is already there (as long as it is relevant). That includes the examples. If you think we need better (or different) examples, please let the editors know. (/DNSSECbis-editor) I like the idea of having a binary format of an example as well. May help seeing how the bitmap field looks as "octet value" "octet value" "bit string" or something besides just the text example. I could live without it too. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 14:57:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01309 for ; Wed, 3 Dec 2003 14:57:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARd3P-0002jP-Hm for namedroppers-data@psg.com; Wed, 03 Dec 2003 19:52:55 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARd3B-0002hu-EO for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 19:52:41 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.10/8.12.9) with ESMTP id hB3Jqd8V026275; Wed, 3 Dec 2003 11:52:40 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id hB3Jqdd1020567; Wed, 3 Dec 2003 11:52:39 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id hB3JqbE9007378; Wed, 3 Dec 2003 11:52:37 -0800 (PST) Date: Wed, 3 Dec 2003 11:52:37 -0800 (PST) Message-Id: <200312031952.hB3JqbE9007378@guava.araneus.fi> To: Jakob Schlyter Cc: IETF DNSEXT WG Subject: Re: nsec++ In-Reply-To: <200312031905.hB3J5J708209@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200312031905.hB3J5J708209@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Some comments on draft-ietf-dnsext-nsec-rdata-00.txt: > Blocks is presented in increasing numerical order. Should be "The blocks are...". > Owner names of RRsets not authoritative for the given zone (such as > glue records) MUST NOT be listed in the Next Domain Name unless at > least one authoritative RRset exists at the same owner name. > [...] > zone MUST NOT generate an NSEC RR for any domain name that only > holds glue records. These statements are outside the scope of the draft. The restrictions described here are not properties of the "DNSSEC NSEC RDATA Format" but of the DNSSEC protocol; they should be (and presumably already are) stated in the base DNSSEC protocol specification. > The Type Bit Map field is represented either as a sequence of RR type > mnemonics or as a sequence of unsigned decimal integers denoting the > RR type codes. I strongly suggest either allowing mixing of mnemonics and integers, or dropping the integers completely in favor of the TYPE# notation. The current requirement that the list has to be either all mnemonics or all integers serves no clear purpose and makes things needlessly hard on implementations. Suppose you are printing an NSEC record and have already printed a couple of mnemonics, and then you come across an unknown RR type - what should you do, go back and change the mnemonics you already printed to integers just to satisfy this requirement? -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 15:31:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04379 for ; Wed, 3 Dec 2003 15:31:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARdYP-0004zu-H9 for namedroppers-data@psg.com; Wed, 03 Dec 2003 20:24:57 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARdYC-0004z4-5v for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 20:24:44 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA29616 for ; Wed, 3 Dec 2003 16:25:13 -0500 Date: Wed, 3 Dec 2003 15:18:37 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: namedroppers@ops.ietf.org Subject: List administration (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Did this actually go out to the list? Or did it get subjected to some special "filtering" in further violation of IETF policies. I would appreciate it if some verizon customers would send me an 'ack'. --Dean ---------- Forwarded message ---------- Date: Tue, 2 Dec 2003 19:47:12 -0500 (EST) From: Dean Anderson To: namedroppers@ops.ietf.org Subject: List administration I was following this message from Nanog, in which Randy Bush is complaining about Verizon spam filtering. What is alarming, is the change that Mr. Bush put into the PSG mail system, which also handles namedroppers email. I think that if PSG does not have the resources to handle the mail for namedroppers without capriciously deleted mail, then it should be handed to someone else who does have the resources. I would like to volunteer Av8 Internet as a more suitable and resourceful host for the namedroppers site. I need not remind anyone of the past administration problems with Dan Bernstein and others which have resulted in censure and administrative changes to the administration of Namedroppers by PSG and Mr. Bush. These problems have been repeated, and it seems that we are at the start of yet another administration "problem". It seems to me that no matter what we do, we will never rid ourselves of a constant stream of administrative problems if we keep the hosting the list at PSG. By contrast, Av8 Internet has no political axe to grind over whose email to send and whose to interfere with. Av8 does not interfere with anyone's email, nor will it ever capriciously delete anyone's email, nor will it ever abuse its administrative privileges for personal harrassment. Dean Anderson CEO Av8 Internet, Inc ---------- Forwarded message ---------- Date: Mon, 1 Dec 2003 11:10:16 -0800 From: Randy Bush To: Jared Mauch Cc: Suresh Ramasubramanian , nanog@nanog.org Subject: Re: incorrect spam setups cause spool messes on forwarders > I think he's saying that they were unable to perform the > validation hence the 450. If the validation was successful, > they'd return a 200 series code, if it was unsuccessful, they > would return a 500 series code. nice words, but crap. due to needs to spool mail for sites in countries with very poor connectivity, mail spool time here is quite long. if verizon and others seem unable to decide in weeks, why should i pay the penalty? but, i guess the problem is easily solved with exim config. i have set it so that if it can not deliver to verizon in say one hour, it dumps the mail. verizon.net * F,1h,5m life is simple, except for verizon users i guess. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 15:33:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04494 for ; Wed, 3 Dec 2003 15:33:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARdco-0005Jv-6N for namedroppers-data@psg.com; Wed, 03 Dec 2003 20:29:30 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARdcL-0005HU-0p for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 20:29:01 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hB3KRC85029761; Wed, 3 Dec 2003 15:27:12 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031203094837.01f68568@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 15:28:11 -0500 To: Dean Anderson , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: List administration In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 19:47 2003-12-02, Dean Anderson wrote: >I think that if PSG does not have the resources to handle the mail for >namedroppers without capriciously deleted mail, then it should be handed >to someone else who does have the resources. There is a big difference between having resources and publicly intimidating a random ISP. Take your pick on what Randy was saying. >I would like to volunteer Av8 Internet as a more suitable and resourceful >host for the namedroppers site. Noted, please send me and my co-chair more details on your setup, for future reference. >I need not remind anyone of the past administration problems with Dan >Bernstein and others which have resulted in censure and administrative >changes to the administration of Namedroppers by PSG and Mr. Bush. These >problems have been repeated, and it seems that we are at the start of yet >another administration "problem". It seems to me that no matter what we >do, we will never rid ourselves of a constant stream of administrative >problems if we keep the hosting the list at PSG. This is all ancient history, there have NO problems raised to my (or my co-chairs) attention in many months. On the other hand there has not been a single SPAM, showing up on the list, and only few late postings from non subscribers. Overall the mailing list operation has been excellent. Rather than chastising Randy, we should be thanking him for a great job he has been doing. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 15:54:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05680 for ; Wed, 3 Dec 2003 15:54:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARdwu-0006ba-M7 for namedroppers-data@psg.com; Wed, 03 Dec 2003 20:50:16 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARdwY-0006Ya-Ft for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 20:49:54 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB3Knm2w048021; Wed, 3 Dec 2003 21:49:49 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB3KoxWq014213; Wed, 3 Dec 2003 21:50:59 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB3Kox1O014212; Wed, 3 Dec 2003 21:50:59 +0100 Date: Wed, 3 Dec 2003 21:50:58 +0100 From: Miek Gieben To: Scott Rose Cc: IETF DNSEXT WG Subject: Re: nsec++ Message-ID: <20031203205058.GA14189@atoom.net> Mail-Followup-To: Scott Rose , IETF DNSEXT WG References: <3FCE30E7.6040505@cisco.com> <01f301c3b9d4$1f804090$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f301c3b9d4$1f804090$b9370681@barnacle> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 03 Dec, @20:32, Scott wrote in "Re: nsec++ ..."] > (DNSSICbis-editor) > It won't be a full replacement - just some of the RDATA field descriptions. > We'll try to keep much of the descriptive text that is already there (as > long as it is relevant). That includes the examples. If you think we need > better (or different) examples, please let the editors know. > (/DNSSECbis-editor) Will this be in protocol-04? grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 15:56:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05850 for ; Wed, 3 Dec 2003 15:56:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARdzU-0006ng-W9 for namedroppers-data@psg.com; Wed, 03 Dec 2003 20:52:56 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARdzI-0006nD-Jg for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 20:52:44 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB3Kqb2w048040; Wed, 3 Dec 2003 21:52:37 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB3KrmWq014288; Wed, 3 Dec 2003 21:53:48 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB3KrmNb014287; Wed, 3 Dec 2003 21:53:48 +0100 Date: Wed, 3 Dec 2003 21:53:48 +0100 From: Miek Gieben To: Andreas Gustafsson Cc: Jakob Schlyter , IETF DNSEXT WG Subject: Re: nsec++ Message-ID: <20031203205348.GB14189@atoom.net> Mail-Followup-To: Andreas Gustafsson , Jakob Schlyter , IETF DNSEXT WG References: <200312031905.hB3J5J708209@grimsvotn.TechFak.Uni-Bielefeld.DE> <200312031952.hB3JqbE9007378@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312031952.hB3JqbE9007378@guava.araneus.fi> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 03 Dec, @20:52, Andreas wrote in "Re: nsec++ ..."] > > mnemonics or as a sequence of unsigned decimal integers denoting the > > RR type codes. > > I strongly suggest either allowing mixing of mnemonics and integers, > or dropping the integers completely in favor of the TYPE# notation. I second this, using TYPE# is more consistent with other places where unknown RRs can exist. grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 16:01:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06178 for ; Wed, 3 Dec 2003 16:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARe2b-00077N-RC for namedroppers-data@psg.com; Wed, 03 Dec 2003 20:56:09 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARe2H-00074p-J9 for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 20:55:49 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hB3KtH18006707 for ; Wed, 3 Dec 2003 15:55:17 -0500 (EST) Message-ID: <029a01c3b9df$c2ddfec0$b9370681@barnacle> From: "Scott Rose" To: "IETF DNSEXT WG" References: <3FCE30E7.6040505@cisco.com> <01f301c3b9d4$1f804090$b9370681@barnacle> <20031203205058.GA14189@atoom.net> Subject: Re: nsec++ Date: Wed, 3 Dec 2003 15:55:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Miek Gieben" > [On 03 Dec, @20:32, Scott wrote in "Re: nsec++ ..."] > > (DNSSICbis-editor) > > It won't be a full replacement - just some of the RDATA field descriptions. > > We'll try to keep much of the descriptive text that is already there (as > > long as it is relevant). That includes the examples. If you think we need > > better (or different) examples, please let the editors know. > > (/DNSSECbis-editor) > > Will this be in protocol-04? > The description of the RDATA would be in the Resoure Records draft. An example of what an NSEC RR looks like is in the records-05 (section 4.3). I would guess any example of a binary (or hex, or any other format) of a general NSEC RR would go there. Another example of a signed zone is in protocol-03, but that is for the example query/responses. > grtz Miek > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 16:26:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08502 for ; Wed, 3 Dec 2003 16:26:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AReRe-0009Vr-Vq for namedroppers-data@psg.com; Wed, 03 Dec 2003 21:22:02 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AReRS-0009UY-My for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 21:21:50 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB3LLj2w048216; Wed, 3 Dec 2003 22:21:45 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB3LMuWq014701; Wed, 3 Dec 2003 22:22:56 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB3LMuwi014700; Wed, 3 Dec 2003 22:22:56 +0100 Date: Wed, 3 Dec 2003 22:22:56 +0100 From: Miek Gieben To: Scott Rose Cc: IETF DNSEXT WG Subject: Re: nsec++ Message-ID: <20031203212256.GA14624@atoom.net> Mail-Followup-To: Scott Rose , IETF DNSEXT WG References: <3FCE30E7.6040505@cisco.com> <01f301c3b9d4$1f804090$b9370681@barnacle> <20031203205058.GA14189@atoom.net> <029a01c3b9df$c2ddfec0$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <029a01c3b9df$c2ddfec0$b9370681@barnacle> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 03 Dec, @21:55, Scott wrote in "Re: nsec++ ..."] > > > > Will this be in protocol-04? > > > The description of the RDATA would be in the Resoure Records draft. An > example of what an NSEC RR looks like is in the records-05 (section 4.3). I > would guess any example of a binary (or hex, or any other format) of a > general NSEC RR would go there. ok :) that's what I wanted to know, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 16:34:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08960 for ; Wed, 3 Dec 2003 16:34:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AReY5-000A2S-9o for namedroppers-data@psg.com; Wed, 03 Dec 2003 21:28:41 +0000 Received: from [211.30.118.161] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AReXs-000A1S-In for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 21:28:28 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hB3LSI3f002294; Thu, 4 Dec 2003 08:28:18 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200312032128.hB3LSI3f002294@drugs.dv.isc.org> To: Erik Rozendaal Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Empty non-terminals and NSEC records In-reply-to: Your message of "Wed, 03 Dec 2003 15:49:07 BST." <3FCDF7E3.8070608@nlnetlabs.nl> Date: Thu, 04 Dec 2003 08:28:18 +1100 X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The example zone in the draft-ietf-dnsext-dnssec-protocol-03.txt document > contains the following records (among others and excluding RRSIG records): > > ns2.example. 3600 IN A 192.0.2.2 > 3600 NSEC *.w.example. A RRSIG NSEC > *.w.example. 3600 IN MX 1 ai.example. > 3600 NSEC x.w.example. MX RRSIG NSEC > > Notice there are no RRs for the w.example. domain, making it an empty > non-terminal. According to the original DNS RFCs empty non-terminals do > exist (in other words, querying for w.example. will not result in NXDOMAIN > but in NODATA). > > However, the signed version does not include proper NSEC records for > w.example. Is this intentional and expected behaviour? > > Erik You don't need a NSEC record to know that w.example exists. You can prove that it exist with this NSEC record. ns2.example. NSEC *.w.example. A RRSIG NSEC The above record proves that "ns2.example.", "*.w.example.", "w.example.", "example." and "." exist. It also proves that "ns2.example." and "*.w.example." contain data. It also proves what data exists at "ns2.example.". It also proves that "w.example." is empty. It does not say whether "example" or "." contain data or not. Note "example." is the common subdomain of the two domains in the record. Note "w.example." is a interior domain between the common subdomain and the next domain name. Interior domains between the common subdomain and the next domain name are always empty. Mark > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 16:54:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10423 for ; Wed, 3 Dec 2003 16:54:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AResh-000BpX-Vj for namedroppers-data@psg.com; Wed, 03 Dec 2003 21:49:59 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AResT-000BoQ-7z for namedroppers@ops.ietf.org; Wed, 03 Dec 2003 21:49:45 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA10491; Wed, 3 Dec 2003 17:53:37 -0500 Date: Wed, 3 Dec 2003 16:47:00 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: List administration In-Reply-To: <6.0.0.22.2.20031203094837.01f68568@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Wed, 3 Dec 2003, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > At 19:47 2003-12-02, Dean Anderson wrote: > > >I think that if PSG does not have the resources to handle the mail for > >namedroppers without capriciously deleted mail, then it should be handed > >to someone else who does have the resources. > > There is a big difference between having resources and publicly > intimidating a random ISP. Take your pick on what Randy was saying. He said he was altering the operations of his mail servers to delete mail that wasn't delivered in one hour. This is unreasonable, regardless of what Verizon does. Sometimes mailservers or internet connections are down for short periods. I doubt all of the namedroppers subscribers have redundant connections, or even redundant mail servers. Those subscribers require queuing and one hour is certainly unreasonable. IETF lists should not be used as "intimidation" for apparently personal gain. I would say that IETF email lists should not be toyed with by the administrator. I don't know whether he made up the story. But obviously, he noticed the problem in the first place, so something brought it to his attention. He didn't say that Verizon customers were complaining to him that their mail was slow. He just said he didn't have the queue space to save the messages for more than one hour. I'd have to take him at his word. Especially when he says he has changed his mailserver configuration. This "one hour" change was inappropriate, and I would like some confirmation that this is no longer the case. I would also like to know whether he made up the story and never made any changes, or if he has backed out the changes. And while I can't really criticize him for being ineffective at intimidation, there are certainly better ways of publicly intimidating an ISP than making threats involving operations of IETF lists. The last DJB "scandal" was last January, and Randy stepped down from the chair in June. In the months where he does a good job, a good job was done. I congratulate him for that. But it seems that every once in while there is something that detracts from this. Namedroppers does seem remarkably free from spam, despite the fact that spammers could simply forge subscriber's addresses and post. I wonder if perhaps spammers don't want to spam namedroppers anymore. Or perhaps they just wanted the list administration to change, and after having made their point, don't care to spam the list anymore. Whatever the case, I guess we don't want to look a gift horse in the mouth. They stopped. We're glad. If Randy made them stop, I congratulate him on that, too. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 21:46:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22245 for ; Wed, 3 Dec 2003 21:46:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARjKx-0001YH-QW for namedroppers-data@psg.com; Thu, 04 Dec 2003 02:35:27 +0000 Received: from [203.143.238.93] (helo=gw.gbch.net) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ARjKj-0001XI-La for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 02:35:14 +0000 Received: (qmail 40740 invoked by uid 1001); 4 Dec 2003 12:35:08 +1000 Message-ID: Date: Thu, 4 Dec 2003 12:35:07 +1000 From: Greg Black To: Dean Anderson Cc: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: List administration References: <6.0.0.22.2.20031203094837.01f68568@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i; gjb-muttsend.sh 1.5 2003-10-01 X-Uptime: 8 days X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-PGP-Key-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-Request-PGP: http://www.gbch.net/keys/4B04B7D6.asc X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On 2003-12-03, Dean Anderson wrote: > On Wed, 3 Dec 2003, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > > > > At 19:47 2003-12-02, Dean Anderson wrote: > > > > >I think that if PSG does not have the resources to handle the mail for > > >namedroppers without capriciously deleted mail, then it should be handed > > >to someone else who does have the resources. > > > > There is a big difference between having resources and publicly > > intimidating a random ISP. Take your pick on what Randy was saying. > > He said he was altering the operations of his mail servers to delete mail > that wasn't delivered in one hour. This is unreasonable, regardless of > what Verizon does. Yes, it utterly unreasonable. Things go wrong in the real world: power utilities have disasters; fires, floods and solar flares cause problems; computer hardware loses its magic smoke. Many people have stopped using backup MX hosts, as these just seem to collect extra spam. Because of all these factors, mailing lists should be prepared to queue mail to subscribers for at least a few days. If some mailing list server is unwilling or unable to manage that, it needs to hand over the job to a competent organisation. Greg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 3 23:24:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26657 for ; Wed, 3 Dec 2003 23:24:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARkyv-0006P0-QK for namedroppers-data@psg.com; Thu, 04 Dec 2003 04:20:49 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARkyf-0006Np-Nn for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 04:20:33 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hB44If85031126; Wed, 3 Dec 2003 23:18:41 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.1.1.2.20031203231812.02a34398@wheresmymailserver.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 03 Dec 2003 23:20:23 -0500 To: namedroppers@ops.ietf.org, minutes@ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: IETF-58 DNSEXT minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,OPT_IN autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSEXT WG meeting, November 13, 2003. Accompanying slide set is available in PDF at: https://www.ietf.org/proceedings/03nov/slides/dnsext-1.pdf Item 0: Agenda Administrivia 5 min Working Group Docs 5 min Call for Interop Report 5 min Wild Card Clarify discussion 10 min DNSSECbis Doc discussion 90 min Evidenced by the time allotted on the agenda, the predominate focus of the meeting is on the latest round of DNSSEC definition document, dnssec-intro, dnssec-records, and dnssec-protocol. The other burning issue to be discussed lies in the wcard-clarify draft, which, although not discussing DNSSEC itself, has altered some of the work needed to finish off DNSSEC. Item 1: Administrivia (Note all agenda items are accompanied by a slide set.) Minutes from the Vienna meeting (July 2003) were posted http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01541.html An issue tracker has been introduced to manage comments and changes to working group documents. The purpose is to make sure all changes corresponding to WG decisions are made and that all changes are because of WG decisions (consensus). One issue tracker instance is as https://roundup.machshav.com/dnsext/index document editors can choose to use others. Item 2: WG Documents All of this is in slides. Documents seeing recent activity (with the focus of the WG): wcard-clarify and the three DNSSECbis documents. Docs in final stages: mdns, tkey renewal, case insensitive clarifications Docs stalled: 2536bis and 2539bis, DSA and Diff-Hellman KEY RR algorithms At IESG: AXFR clarify, DS RR, type code roll, key signing bit, opt-in, dhc-id, dns threats, discovery, others? Item 3: Call for Interop Reports In the past decade, many documents have made it to Proposed Standard, but none have made it to Draft Standard. An important ingredient for draft standard is a demonstration and documentation of interoperability. The WG has many documents to promote from proposed to draft standards, and this is an open call for work in this area. One interoperability report is making it's way through the process. I think this is TSIG, no progress has been made recently. Question from the floor: where should folks focus? Answer: Milestones on the charter page list what's needed, sequencing can be adjusted. Item 4: wcard-clarify Discussion This document was begun in January, became a WG item during the March 2003 SF meetings, and made progress through the Vienna meeting in July. A change in editor was requested by the first editor and a new one, Robert Elz, has been installed. Remaining issues include: a) Cache use of unexpanded wild card records b) Use of the "*" label in the interior of a name c) Handling of a CNAME RR at a wild card name d) Handling of a NS RR at a wild card name e) Procedural question - split document between clarify an fix Discussion started with (e): room recommendation is to keep the document as one. (Originally the document treated pre and post DNSSEC, now it treats only pre-DNSSEC.) Even though it is "clarifications," adjustments to the original definition are to be considered and included. The rationale for not splitting is that if it were done, we'd have too many documents in the process. Issue (4a): RFC 1034 says that a cache must not make use of a wild card record. (As opposed to a wild card record in the authoritative date.) While it makes sense that a cache must not synthesize records from a cached wild card record (because the cache doesn't have enough information), there's little reason that a cache can't answer with the record if the QNAME is for the wild card exactly. (I.e., *.example. IN A 1.1.1.1 in cache could be used for a query of [*.example. IN A].) The room's proposal was to allow the cache to answer if the record was an exact match for the data, leaving the restriction of not allowing cache synthesis from the record. Issue (4b): Whether or not "*" can be in the middle of a name. There was no discussion in the room on this one. The basic issue is that the draft goes to great length to talk about how this is handled. Later on, someone noticed that 1034 discourages this. Although there is no sentiment to allow these names, nor is there any common use, if the names are barred as in 1034, then more rules are needed to specify what happens when they are (mistakenly?) seen. If the rules aren't specified then behavior is unpredicatable - perhaps in ways that don't matter very much. An older mail list discussion leaned toward staying with 1034's definition. Issue (4c): Whether CNAME's are "chase" has been the most significant issue in this work. As it stands now, a CNAME RR at a wild card means that the wild card only comes into play when the query is for the wild card name itself and for the type CNAME. Implementers have suggested letting a CNAME at a wild card play the same role as a CNAME at an exact match, meaning that one step in the algorithm in 1034/4.3.2 would be altered. (Noting that the algorithm is a suggestion and not a specification.) This is the central issue on whether or not the document is merely a clarification or an adjustment to 1034. The sense seems to be to allow CNAMEs to be "chased" at a wild card, regardless of whether this is a clarification or an adjustment. One other suggestion was that DNAMEs ought to also be included in the discussion. Originally they were, and there still may be a blurb in the draft, but the DNAME specification has been seen as too confusing to clarify at this point. Issue (4d): Whether a wild card NS is permitted. For a while (since Vienna) it seemed that this would be viable. However, no one has cited a concrete application for this. In addition, there is a rule that only the authoritative source can synthesize an answer to a query, when issuing a referral, the answering party is inherently not authoritative. The sense of the room seemed to be for banning NS RR from wild cards. The downside to this is that enforcement should be defined. E.g., what happens on zone load, dynamic update addition, or records seen in an answer. (Also, when it comes to DNSSEC, how the signer treats this.) Other issues - one person asked about a restriction on SOA (a counter to the NS record). SOA's are already barred from being anywhere other than the apex. Item #5: The DNSSECbis documents The discussion centered around the dnssec-editor's list of 'official' questions. For convienence, the questions will be listed by number here and not by content. (Content is available in the slides.) The discussion began by listing the following questions as haven been recently settled: Q6, Q11, Q16, and Q17. In addition, Q15 was moved from open to settled during the week. The rest of the dicussion was organized by the open questions, followed by an issue concerning compression of names and the encoding of the NSEC RR. The current list of open questions are Q18, Q19, Q20, and Q21. Q18: conflicting rules between TTL settings on the RRSIG RR According to RFC 2181 the RRSIG's at a name comprise a set, ergo all should have the same TTL. According to RFC 2535 the (RR)SIG's ought to have the same TTL as their covering set. The discussion came down to a choice between making signature records a special case (RRSIG, SIG, or both) or adopting a means to make the dilemma disappear. E.g., adopting a bit in the RR type field to signify that the record was a signature. While there was a sentiment to "not break DNS to secure it" there was a stronger opinion to just recognize that the signature was an infrastructure record and therefore treat it as special. Hence it should take up the TTL from the RRset it signes and it is allowed for individual RRs in a SIG RRset to have different TTLs. Q19: suppression of duplicates The original specification leans toward but does not explicitly forbid the transmission of duplicate RR's (same envelope and RDATA). DNSSEC needs to define a canonical form so that the signer and verifier can work together. If not, there would be crypto-level errors which are hard to detect and isolate. There wasn't a clear mandate to alter the base DNS state on this. However, it was clear that there needs to be a canonical form between signer and verifier. Besides suppression of duplicates, sequencing and downcasing also have to be preserved. This isn't necesarily an on-the-wire issue, as both ends of the crypto process can repeat the same canonicalization process. Q20: expansion of wild card in authority section A wild card record would be appear in the authority section in a few cases. One might be the expansion of an NS RR - but wild card NS RR's seem to be on the road to elimination. (See the discussion on them in the wcard doc.) In the case of an NXDOMAIN, there would be a NSEC for the exact match and for the wild card, and with allowing CNAME's at a wild card to have the effect of continuing the lookup, possibly more. But none of these would involve expansion. The remaining case is the inclusion of a wild card NSEC record in a "no data" situation. The query name does not have an answer, but a wild card synthesis rule is in effect. However, the desired type is not represented. The sense of the room was to leave this name in the wild card form. Using the record for synthesis would appear to be confusing - first an NSEC claims the name does not exist and then there's an NSEC (synthesized) for the name. In either case, a resolver could figure this out given the label count, but the expansion serves no purpose. One other comment was that the result of this ought to be included in the wcard clarify draft - cleansing the issue of DNSSEC. IOW, under what conditions are sythesized records places in the authority section. Q21: (re)use of NSEC in cache According to NCACHE (RFC 2038), a cached negative answer can only be used by a cache to answer a newer query if the QNAME, QCLASS, and QTYPE match. With the NSEC RR, it is possible to reuse the negative answer for a match involving just the QNAME and QCLASS, if the QTYPE is absent from the bit field. The debate centered around if such a discussion was appropriate here or in an update to NCACHE (RFC 2308). On the other hand, the words in the proposed text used MAY - as in the cache MAY take advantage of this. As opposed to a MUST or SHOULD which actively promote the adoption of this "shortcut", MAY is neutral, encouraging experimentation. MUST NOT or SHOULD NOT are too strong in the other direction. Compression Guidelines: New DNS records are not supposed to be compressed. A discussion along the lines of "conservative on send, liberal on receive" ensued. Servers ought not compress, resolvers ought not have a fit over compressed data. The conversation was to be moved to the list over the wording of enforcement. NSEC encoding: The NXT record defines the encoding of types 1-127 and leave the rest open to future definition. This needed to be solved for NSEC. Working group chairs announced an appointment of a Document Editor for an Internet Draft processing this change: Jakob Schlyter. Five proposals were listed and briefly described. a) Extend bitmap for all types (0-127 are coverd by a simple bitmap) b) List types in sorted order c) Approach optimized for the first 256 types d) Approach optimized for the size of the record (skiplist of blocks) e) Approach close to d, using bitmap within blocks Comments: b & c don't allow a name to have 64K types simultaneously, max around half that. 'Course, a name with this is unlikely. The goal was to decide on one approach to seek a further definition. What followed was a beauty contest. In the first round, approaches b,c and e were chosen (people humming for more than one). In the second round, approach e was selected for further work. Wrap-up The three DNSSECbis documents are planned to be in WG last call by the end of the year. Following soon will be two authoritative implementations - BIND 9 and NSD. Two recursive servers will also be available - BIND 9 and IDsA (http://www.idsa.prd.fr). Acknowledgements These minutes are based on the notes made by Ed Lewis and Jaap Akkerhuis and the Jabber log by Andrew Newton. We would like to thank them for their quick submission and precise record of the meeting. Thanks to those who contributed to the constructive and productive admosphere during the meeting. Olafur and Olaf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 05:58:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19314 for ; Thu, 4 Dec 2003 05:58:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARr3n-000PG6-8n for namedroppers-data@psg.com; Thu, 04 Dec 2003 10:50:15 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARr3a-000PEZ-PK for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 10:50:02 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 1E7251958C; Thu, 4 Dec 2003 11:50:01 +0100 (CET) Date: Thu, 4 Dec 2003 11:50:00 +0100 (CET) From: Jakob Schlyter To: Peter Koch Cc: IETF DNSEXT WG Subject: Re: nsec++ In-Reply-To: <200312031905.hB3J5J708209@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: References: <200312031905.hB3J5J708209@grimsvotn.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Dec 2003, Peter Koch wrote: > > i.e., one type of sequence OR another type of sequence. if it allowed > > mixing, it would probably say: > > > > "The Type Bit Map field is represented as a sequence of RR type mnemonics > > or unsigned decimal integers denoting the RR type codes." > > For the sake of consistency with RFC 3597 I'd use the TYPEnnn convention > and don't see any reason not to allow "mixed" format. > > "The Type Bit Map field is represented as a sequence of RR type mnemonics. > When the mnemonic is not known, the TYPE representation as of section 5 > of [RFC 3597] MUST be used, otherwise it MAY {SHOULD NOT} be used." I agree, but do not think we need that last part. suggestion: The List of Type Bit Map(s) Field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation as described in RFC 3597 (section 5) MUST be used. > 2.0 > The NSEC RR is class independent. > > -> The NSEC RR RDATA format is class independent and defined for all > classes. > {The RR or the contents of the RR really is class dependent} updated. > 2.1.1 > > Owner names of RRsets not authoritative for the given zone (such as > glue records) MUST NOT be listed in the Next Domain Name unless at > least one authoritative RRset exists at the same owner name. > > Isn't this already covered by the reference to canonical sort order? > Anyway, owner names or RRSets are not "authoritative for" the zone > but are "in" the zone (or not). Section 4 of AXFR clarify, which still hasn't > made it to RFC, has some wording about this. > > If a discussion is appropriate here, the "empty non-leaf node" problem > could be solved, too. (short: NSEC may point to siblings, children or > parents, but not to nephews). as this text was copied from draft-ietf-dnsext-dnssec-records-05.txt, I'd like comments on this from the editors of that draft before changing anything. > 2.1.2 > > Bits representing pseudo-RR types MUST be set to 0, since they do not > appear in zone data. If encountered, they must be ignored upon > reading. > > The term "pseudo-RR" needs a definition. Again stealing from 3597 I'd say: > > Bits representing Meta-TYPEs or QTYPEs as specified in [RFC 2929] > (section 3.1) or within the range reserved for assignment only to > QTYPEs and Meta-TYPEs MUST be set to 0 ... > > This may also change the maximum length calculation a bit (although 2929 > doesn't explicitly say that the TYPE reservation is valid for classes > other than IN), which could be provided in an appendix. new text included. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 06:01:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19405 for ; Thu, 4 Dec 2003 06:01:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARrAm-000Pg9-In for namedroppers-data@psg.com; Thu, 04 Dec 2003 10:57:28 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARrAa-000PfY-HC for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 10:57:16 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 6B0961958C; Thu, 4 Dec 2003 11:57:15 +0100 (CET) Date: Thu, 4 Dec 2003 11:57:14 +0100 (CET) From: Jakob Schlyter To: Andreas Gustafsson Cc: IETF DNSEXT WG Subject: Re: nsec++ In-Reply-To: <200312031952.hB3JqbE9007378@guava.araneus.fi> Message-ID: References: <200312031905.hB3J5J708209@grimsvotn.TechFak.Uni-Bielefeld.DE> <200312031952.hB3JqbE9007378@guava.araneus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Dec 2003, Andreas Gustafsson wrote: > > Owner names of RRsets not authoritative for the given zone (such as > > glue records) MUST NOT be listed in the Next Domain Name unless at > > least one authoritative RRset exists at the same owner name. > > [...] > > zone MUST NOT generate an NSEC RR for any domain name that only > > holds glue records. > > These statements are outside the scope of the draft. The restrictions > described here are not properties of the "DNSSEC NSEC RDATA Format" > but of the DNSSEC protocol; they should be (and presumably already > are) stated in the base DNSSEC protocol specification. true, I'll remove this paragraph unless someone objects. > I strongly suggest either allowing mixing of mnemonics and integers, > or dropping the integers completely in favor of the TYPE# notation. fixed (see my reply to peter koch). jakob -- Jakob Schlyter +46 70 595 07 94 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 06:32:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20245 for ; Thu, 4 Dec 2003 06:32:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARrgl-0001WX-1d for namedroppers-data@psg.com; Thu, 04 Dec 2003 11:30:31 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARrgY-0001VK-TB for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 11:30:19 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 0DF061958C; Thu, 4 Dec 2003 12:30:18 +0100 (CET) Date: Thu, 4 Dec 2003 12:30:17 +0100 (CET) From: Jakob Schlyter To: Josh Littlefield Cc: IETF DNSEXT WG Subject: Re: nsec++ In-Reply-To: <3FCE30E7.6040505@cisco.com> Message-ID: References: <3FCE30E7.6040505@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Dec 2003, Josh Littlefield wrote: > I'd recommend changing para. 2 of 2.1.2, as follows: > > [..] thanks, I think your new text is much more clear - I've incorporated it with only small changes based on other comments. > This paragraph: > > A zone MUST NOT generate an NSEC RR for any domain name that only > holds glue records. > > Doesn't seem to belong the section describing the type bitmap field. It > belongs in Section 2. It is not related to "wire-format", but to when > an NSEC RR should exist. this paragraph has been removed as it describes protocol, not rdata format. > Additional comments: > > - If the TYPE# notation can be used for unknown RR types in a > symbolic list of RR types, then this should be explicitly mentioned. > Otherwise, the presense of one unknown type would force the entire set > to be printed using decimal notation. as of RFC3597, there is nothing special about the TYPE# notation. this paragraph has been updated, see my reply to peter koch. > - An example of the actual binary data (octet by octet) for an NSEC > RR using at least two non-sequential "window blocks" would be useful. I'll add this to the 'NSEC RR Example' section. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 07:54:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23442 for ; Thu, 4 Dec 2003 07:54:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARsvF-0005u0-Ov for namedroppers-data@psg.com; Thu, 04 Dec 2003 12:49:33 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARsv3-0005tQ-84 for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 12:49:21 +0000 Received: from nlnetlabs.nl (eidolon.nlnetlabs.nl [IPv6:2001:7b8:206:1:240:f4ff:fe37:7af9]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB4CnH2w053763; Thu, 4 Dec 2003 13:49:17 +0100 (CET) (envelope-from erik@nlnetlabs.nl) Message-ID: <3FCF2D4D.9050506@nlnetlabs.nl> Date: Thu, 04 Dec 2003 13:49:17 +0100 From: Erik Rozendaal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: namedroppers@ops.ietf.org Subject: Re: Q20: expanding wildcards in the authority section References: <265EC638-13FB-11D8-9A3D-000393C783A2@isi.edu> <20031127101627.667a2ad0.olaf@ripe.net> In-Reply-To: <20031127101627.667a2ad0.olaf@ripe.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > > Q20: Expansion of wild cards in the authority section. > > Default action, based on sense of the room at IETF58, is to not > expand the owner names of e.g. wildcard NSEC RRs. > > If there is no further prohibitive objections by December 8 this > will be taken as consensus of the working group. I find this rather inconsistent with the normal behavior of wildcards. Currently wildcard owner names are always expanded to match the SNAME. The current NSD DNSSEC implementation expands the wildcard NSEC record. However, changing it to not expand the wildcard is not a big deal. But I'd still prefer consistent wildcard behavior when the wildcard matches the SNAME. So (in order of preference) I'd like: 1. The wildcard MUST always be expanded when it matches SNAME. 2. The wildcard MUST NOT be expanded for NSEC records in the authority section even if it matches SNAME. 3. The wildcard MAY/SHOULD/SHOULD NOT be expanded. Option 3 has additional complications for the client/resolver and would not be a good idea in my opinion. I prefer option 1 but do not mind option 2. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 08:45:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25555 for ; Thu, 4 Dec 2003 08:45:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARtjM-0008qS-VT for namedroppers-data@psg.com; Thu, 04 Dec 2003 13:41:20 +0000 Received: from [211.30.118.161] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARtjA-0008pl-MQ for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 13:41:08 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hB4Df03f008688; Fri, 5 Dec 2003 00:41:00 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200312041341.hB4Df03f008688@drugs.dv.isc.org> To: Erik Rozendaal Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q20: expanding wildcards in the authority section In-reply-to: Your message of "Thu, 04 Dec 2003 13:49:17 BST." <3FCF2D4D.9050506@nlnetlabs.nl> Date: Fri, 05 Dec 2003 00:41:00 +1100 X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Olaf M. Kolkman wrote: > > > > Q20: Expansion of wild cards in the authority section. > > > > Default action, based on sense of the room at IETF58, is to not > > expand the owner names of e.g. wildcard NSEC RRs. > > > > If there is no further prohibitive objections by December 8 this > > will be taken as consensus of the working group. > > I find this rather inconsistent with the normal behavior of wildcards. > Currently wildcard owner names are always expanded to match the SNAME. > > The current NSD DNSSEC implementation expands the wildcard NSEC record. > However, changing it to not expand the wildcard is not a big deal. But I'd > still prefer consistent wildcard behavior when the wildcard matches the SNAME > . > > So (in order of preference) I'd like: > > 1. The wildcard MUST always be expanded when it matches SNAME. > 2. The wildcard MUST NOT be expanded for NSEC records in the authority > section even if it matches SNAME. > 3. The wildcard MAY/SHOULD/SHOULD NOT be expanded. > > Option 3 has additional complications for the client/resolver and would not > be a good idea in my opinion. > > I prefer option 1 but do not mind option 2. > > Erik Say you have QNAME c.example. QTYPE A And you get the following back: (expanded *) RCODE=NOERROR Answer count=0 c.example. NSEC b.example. TXT NSEC RRSIG c.example. RRSIG ... b.example. NSEC d.example. A NSEC RRSIG b.example. RRSIG ... (unexpanded *) RCODE=NOERROR Answer count=0 *.example. NSEC b.example. TXT NSEC RRSIG *.example. RRSIG ... b.example. NSEC d.example. A NSEC RRSIG b.example. RRSIG ... The tests the validator has to go through for NOERROR NODATA are: Does QNAME exist? **** Yes: Is it a empty node Yes: SUCCESS No: Does the type exist at the node? Yes: FAIL No: SUCCESS No: Does a wildcard exist? **** Yes: Does the type exist in the wildcard? **** Yes: FAIL No: SUCCESS No: FAIL Which of the above two answers makes it easier to answer the **** questions? Mark > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 09:05:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26044 for ; Thu, 4 Dec 2003 09:05:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARu3B-000AMA-1L for namedroppers-data@psg.com; Thu, 04 Dec 2003 14:01:49 +0000 Received: from [131.111.8.18] (helo=draco.cus.cam.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARu2r-000ALJ-2Q for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 14:01:29 +0000 Received: from cet1 by draco.cus.cam.ac.uk with local (Exim 4.30) id 1ARu2q-0006rn-2V for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 14:01:28 +0000 Subject: Re: List administration To: namedroppers@ops.ietf.org Date: Thu, 4 Dec 2003 14:01:28 +0000 (GMT) In-Reply-To: from "Greg Black" at Dec 4, 3 12:35:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit gjb@gbch.net (Greg Black) writes: > > On 2003-12-03, Dean Anderson wrote: [...] > > He said he was altering the operations of his mail servers to delete mail > > that wasn't delivered in one hour. This is unreasonable, regardless of > > what Verizon does. > > Yes, it utterly unreasonable. Things go wrong in the real > world: power utilities have disasters; fires, floods and solar > flares cause problems; computer hardware loses its magic smoke. > Many people have stopped using backup MX hosts, as these just > seem to collect extra spam. > > Because of all these factors, mailing lists should be prepared > to queue mail to subscribers for at least a few days. Make that "mail servers in general" rather than just mailing lists, and I have to agree, no argument. Locally the angels-on-a-pin contention has traditionally been whether 4 days or 5 days is the "right" timeout. However, I can certainly sympathise with Randy about the highly antisocial behaviour of servers that use 4xx codes unnecessarily to [not] reject suspected spam. We haven't heard his side of this yet, but often the right way to penalise such servers is not to shorten the ultimate timeout, but to decrease the retry rate for transmission attempts. Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 09:20:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26485 for ; Thu, 4 Dec 2003 09:20:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARuHx-000BDO-0Y for namedroppers-data@psg.com; Thu, 04 Dec 2003 14:17:05 +0000 Received: from [216.148.222.61] (helo=mail12-red-R.bigfish.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARuHM-000BCV-C2 for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 14:16:28 +0000 Received: from mail12-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail12-red-R.bigfish.com (Postfix) with ESMTP id 34F6112FCE7; Thu, 4 Dec 2003 14:16:28 +0000 (UCT) Received: by mail12-red (MessageSwitch) id 1070547388156841_24296; Thu, 4 Dec 2003 14:16:27 +0000 (UCT) Received: from darwin.altera.com (darwin.altera.com [66.35.227.3]) by mail12-red.bigfish.com (Postfix) with ESMTP id CE04012FB1B; Thu, 4 Dec 2003 14:16:27 +0000 (UCT) Received: from sunrise.altera.com (sunrise [137.57.1.1]) by darwin.altera.com (8.11.7p1+Sun/8.11.7) with ESMTP id hB4EBAl00026; Thu, 4 Dec 2003 06:11:10 -0800 (PST) Received: from sj-gw02.altera.priv.altera.com (exchange [137.57.216.60]) by sunrise.altera.com (8.12.9/8.12.9) with ESMTP id hB4EGQZZ003668; Thu, 4 Dec 2003 06:16:26 -0800 (PST) Received: from uk-ismsg02.altera.priv.altera.com ([137.57.183.231]) by sj-gw02.altera.priv.altera.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Dec 2003 06:16:26 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: nsec++ Date: Thu, 4 Dec 2003 14:16:24 -0000 Message-ID: <45E39EE2E44FD443AEFAC07728BF3B50074A0F@uk-ismsg02.altera.priv.altera.com> Thread-Topic: nsec++ Thread-Index: AcO6VdnqrFAUErDJTBKsxvBcXqr7HgAGRdyA From: "Andrew Draper" To: "Jakob Schlyter" Cc: "IETF DNSEXT WG" X-OriginalArrivalTime: 04 Dec 2003 14:16:26.0528 (UTC) FILETIME=[3422EA00:01C3BA71] X-BigFish: v X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, While not wishing to reopen (too much) the debate about how to encode = this efficiently, I have a suggestion which might make the encoding of = sparse NSEC records a lot smaller, while being only slightly harder to = understand and I think no harder to implement. If the types encoded are sparse then the bitmaps will tend to have a lot = of zeros at the start of them. For example the RDATA for: example.com. IN NSEC host.example.com. 385 will be encoded as, I think: 04 'h' 'o' 's' 't' 06 'e' 'x' 'a' 'm' 'p' 'l' 'e' 03 'c' 'o' 'm' = 00 01 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 (all numbers are in hex) which has a lot of superfluous zeros. There are three bits spare in the "bitmap length" byte (if you store = bitmap_length-1 instead of just bitmap_length) so it would be much more = efficient, for sparse bitmaps, if the block start was allowed to be on = any boundary of 32. The encoding of the same RR would then be: 04 'h' 'o' 's' 't' 06 'e' 'x' 'a' 'm' 'p' 'l' 'e' 03 'c' 'o' 'm' = 00 0C 00 02 If you like this then suggested text is below (I wrote this yesterday so = some of the alternative suggested descriptions of bitmap might be better = than this one): The type space is represented using one or more blocks. Each block starts at a location in type space which is a multiple of 32 and=20 describes upto 256 active types. Each block consists of a 13 bit start type number, a 5 bit length field (from 1 .. 32 octets) and a bitmap (covering upto 256 type codes) in network bit order (similar to NXT). Blocks with no types present MUST NOT be included. Blocks MUST NOT overlap. There MUST NOT be more than three leading zero octets in the bitmap. Trailing zero octets in the bitmap MUST be removed. =20 Blocks MUST be presented in increasing numerical order. Where two encodings are possible, the encoding which produces the smallest RRDATA size MUST be chosen. If two encodings produce the same RRDATA size then the one which uses the smallest number of blocks MUST be chosen. [ This last rule is required to handle edge cases such as NSEC host.example.com. 256 511 =20 or NSEC host.example.com. 264 288=20 An alternative would be to say "The start type of a block MUST be 256 or more greater than the start address of the previous block" but this is less efficient ] The format of each block is as shown below: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Start Type | Length | Bitmap of active types / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Bitmap of active types (continued) ... =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Start Type field indicates the numeric value of the first bit represented in the bitmap. The least significant 5 bits are always zero and are not stored in the RR. A value of 1 in this field indicates that the first bit in the bitmap represents type 32, a value of 1024 indicates that the first bit represents type 32768. The Length field holds the number of octet in the bitmap of active types, minus 1. A value of 0 in this field therefore indicates that the bitmap is one octet long, a value of 31 indicates that the bitmap is 32 octets. The Bitmap field is divided up into octets, one for each type. The presence of the first type is indicated by the least significant bit in the first octet, the next type by the second least significant bit etc. The second octet (if present) indicates the presence of the 9th to 16th types etc. Regards, Andy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 09:24:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26657 for ; Thu, 4 Dec 2003 09:24:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARuMz-000BT3-Uo for namedroppers-data@psg.com; Thu, 04 Dec 2003 14:22:17 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARuMn-000BST-Pq for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 14:22:05 +0000 Received: from nlnetlabs.nl (eidolon.nlnetlabs.nl [IPv6:2001:7b8:206:1:240:f4ff:fe37:7af9]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB4ELv2w054403; Thu, 4 Dec 2003 15:21:57 +0100 (CET) (envelope-from erik@nlnetlabs.nl) Message-ID: <3FCF4305.7030602@nlnetlabs.nl> Date: Thu, 04 Dec 2003 15:21:57 +0100 From: Erik Rozendaal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark.Andrews@isc.org CC: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: Q20: expanding wildcards in the authority section References: <200312041341.hB4Df03f008688@drugs.dv.isc.org> In-Reply-To: <200312041341.hB4Df03f008688@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: > > > Say you have > > QNAME c.example. > QTYPE A > > And you get the following back: > > (expanded *) > RCODE=NOERROR Answer count=0 > c.example. NSEC b.example. TXT NSEC RRSIG > c.example. RRSIG ... > b.example. NSEC d.example. A NSEC RRSIG > b.example. RRSIG ... Although the c.example. NSEC record looks a little funny, checking the RRSIG will show that the "true" owner name of the NSEC record is *.example. So the same information is present whether the * is expanded or not. And because checking RRSIGs is required anyway there is no additional processing. Also note that querying for QNAME c.example. QTYPE NSEC will also return c.example NSEC b.example. TXT NSEC RRSIG c.example RRSIG .... but this time in the answer section. And again the client will know the record was generated from a wildcard record. > > (unexpanded *) > RCODE=NOERROR Answer count=0 > *.example. NSEC b.example. TXT NSEC RRSIG > *.example. RRSIG ... > b.example. NSEC d.example. A NSEC RRSIG > b.example. RRSIG ... > > The tests the validator has to go through for NOERROR NODATA > are: > > Does QNAME exist? **** > Yes: Is it a empty node > Yes: SUCCESS > No: Does the type exist at the node? > Yes: FAIL > No: SUCCESS > No: Does a wildcard exist? **** > Yes: Does the type exist in the wildcard? **** > Yes: FAIL > No: SUCCESS > No: FAIL > > Which of the above two answers makes it easier to answer the > **** questions? Given that the client knows a name was generated from a wildcard I do not see any differences in the difficulties of answering the above questions. But your explanation does make it clearer to me why unexpanded wildcards were chosen, even though I still slightly prefer expanded wildcards. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 09:33:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27006 for ; Thu, 4 Dec 2003 09:33:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARuV8-000Bwt-Np for namedroppers-data@psg.com; Thu, 04 Dec 2003 14:30:42 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARuUv-000BwV-Ld for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 14:30:29 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB4EUM2w054478; Thu, 4 Dec 2003 15:30:22 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB4EVdXJ027002; Thu, 4 Dec 2003 15:31:39 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB4EVdRZ027001; Thu, 4 Dec 2003 15:31:39 +0100 Date: Thu, 4 Dec 2003 15:31:38 +0100 From: Miek Gieben To: Andrew Draper Cc: Jakob Schlyter , IETF DNSEXT WG Subject: Re: nsec++ Message-ID: <20031204143138.GA26856@atoom.net> Mail-Followup-To: Andrew Draper , Jakob Schlyter , IETF DNSEXT WG References: <45E39EE2E44FD443AEFAC07728BF3B50074A0F@uk-ismsg02.altera.priv.altera.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E39EE2E44FD443AEFAC07728BF3B50074A0F@uk-ismsg02.altera.priv.altera.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 04 Dec, @15:16, Andrew wrote in "RE: nsec++ ..."] > Hi, > > While not wishing to reopen (too much) the debate about how to encode this > efficiently, I have a suggestion which might make the encoding of sparse NSEC Uhm.... I _just_ finished the parsing of the previous nsec definition... I think we don't want to make the NSEC more difficult than it already is (compared to the NXT definition). So I would vote to keep the current NSEC definition as it as and get used to the fact is takes up a few more bytes, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 09:47:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27696 for ; Thu, 4 Dec 2003 09:47:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARuii-000CkP-Mx for namedroppers-data@psg.com; Thu, 04 Dec 2003 14:44:44 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARuiW-000Ck0-6x for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 14:44:32 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 5E03E1958B; Thu, 4 Dec 2003 15:44:31 +0100 (CET) Date: Thu, 4 Dec 2003 15:44:28 +0100 (CET) From: Jakob Schlyter To: Josh Littlefield Cc: IETF DNSEXT WG Subject: Re: nsec++ In-Reply-To: Message-ID: References: <3FCE30E7.6040505@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Dec 2003, Jakob Schlyter wrote: > > - An example of the actual binary data (octet by octet) for an NSEC > > RR using at least two non-sequential "window blocks" would be useful. > > I'll add this to the 'NSEC RR Example' section. 2.3 NSEC RR Example The following NSEC RR identifies the RRsets associated with alfa.example.com. and identifies the next authoritative name after alfa.example.com. alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234 The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry host.example.com. is the next authoritative name after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC mnemonics indicate there are A, MX, RRSIG, NSEC and TYPE1234 RRsets associated with the name alfa.example.com. The RDATA section of the NSEC RR above would be encoded as: 0x04 'h' 'o' 's' 't' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 Assuming that the resolver can authenticate this NSEC record, it could be used to prove that beta.example.com does not exist, or could be used to prove there is no AAAA record associated with alfa.example.com. Authenticated denial of existence is discussed in RFC 2535 [2]. jakob -- Jakob Schlyter +46 70 595 07 94 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 10:05:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28690 for ; Thu, 4 Dec 2003 10:05:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARuyR-000DX5-HH for namedroppers-data@psg.com; Thu, 04 Dec 2003 15:00:59 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARuyF-000DWX-4F for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 15:00:47 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB4F0e2w054650; Thu, 4 Dec 2003 16:00:40 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB4F1vXJ027605; Thu, 4 Dec 2003 16:01:57 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB4F1u8a027602; Thu, 4 Dec 2003 16:01:57 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 4 Dec 2003 16:01:56 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Andrew Draper cc: Jakob Schlyter , IETF DNSEXT WG Subject: RE: nsec++ In-Reply-To: <45E39EE2E44FD443AEFAC07728BF3B50074A0F@uk-ismsg02.altera.priv.altera.com> Message-ID: References: <45E39EE2E44FD443AEFAC07728BF3B50074A0F@uk-ismsg02.altera.priv.altera.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Dec 2003, Andrew Draper wrote: > Hi, > > While not wishing to reopen (too much) the debate about how to encode > this efficiently, I have a suggestion which might make the encoding of > sparse NSEC records a lot smaller, while being only slightly harder to > understand and I think no harder to implement. > > If the types encoded are sparse then the bitmaps will tend to have a lot > of zeros at the start of them. For example the RDATA for: > > example.com. IN NSEC host.example.com. 385 > > will be encoded as, I think: > > 04 'h' 'o' 's' 't' 06 'e' 'x' 'a' 'm' 'p' 'l' 'e' 03 'c' 'o' 'm' 00 > 01 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 > (all numbers are in hex) > > which has a lot of superfluous zeros. > > There are three bits spare in the "bitmap length" byte (if you store bitmap_length-1 instead of just bitmap_length) so it would be much more efficient, for sparse bitmaps, if the block start was allowed to be on any boundary of 32. > > The encoding of the same RR would then be: > > 04 'h' 'o' 's' 't' 06 'e' 'x' 'a' 'm' 'p' 'l' 'e' 03 'c' 'o' 'm' 00 > 0C 00 02 > > > If you like this then suggested text is below (I wrote this yesterday so some of the alternative suggested descriptions of bitmap might be better than this one): > > > The type space is represented using one or more blocks. Each block > starts at a location in type space which is a multiple of 32 and > describes upto 256 active types. Each block consists of a 13 bit > start type number, a 5 bit length field (from 1 .. 32 octets) and > a bitmap (covering upto 256 type codes) in network bit order > (similar to NXT). One of the design requirements, and therefor one of the reasons some proposals did not make it is that the bit map must be able to respresent every type in one bitmap. Your encoding gives us a worst case length of 69632 which is >64K Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 10:11:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29356 for ; Thu, 4 Dec 2003 10:11:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARv3y-000Ds4-OX for namedroppers-data@psg.com; Thu, 04 Dec 2003 15:06:42 +0000 Received: from [63.161.60.61] (helo=mail3-atl-R.bigfish.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARv3d-000Dqn-Gl for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 15:06:21 +0000 Received: from mail3-atl.bigfish.com (localhost.localdomain [127.0.0.1]) by mail3-atl-R.bigfish.com (Postfix) with ESMTP id EEE903E74EC; Thu, 4 Dec 2003 15:06:20 +0000 (UCT) Received: by mail3-atl (MessageSwitch) id 1070550380929813_5815; Thu, 4 Dec 2003 15:06:20 +0000 (UCT) Received: from darwin.altera.com (darwin.altera.com [66.35.227.3]) by mail3-atl.bigfish.com (Postfix) with ESMTP id 6F0023E72DD; Thu, 4 Dec 2003 15:06:20 +0000 (UCT) Received: from sunrise.altera.com (sunrise [137.57.1.1]) by darwin.altera.com (8.11.7p1+Sun/8.11.7) with ESMTP id hB4F12l09164; Thu, 4 Dec 2003 07:01:02 -0800 (PST) Received: from sj-gw02.altera.priv.altera.com (exchange [137.57.216.60]) by sunrise.altera.com (8.12.9/8.12.9) with ESMTP id hB4F6JZZ006796; Thu, 4 Dec 2003 07:06:19 -0800 (PST) Received: from uk-ismsg02.altera.priv.altera.com ([137.57.183.231]) by sj-gw02.altera.priv.altera.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Dec 2003 07:06:19 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: nsec++ Date: Thu, 4 Dec 2003 15:06:16 -0000 Message-ID: <45E39EE2E44FD443AEFAC07728BF3B5054B01D@uk-ismsg02.altera.priv.altera.com> Thread-Topic: nsec++ Thread-Index: AcO6d2wYWcKyofKMR8adTmYhSupv+wAAEYyQ From: "Andrew Draper" To: "Roy Arends" Cc: "Jakob Schlyter" , "IETF DNSEXT WG" X-OriginalArrivalTime: 04 Dec 2003 15:06:19.0099 (UTC) FILETIME=[2BD902B0:01C3BA78] X-BigFish: v X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Roy, I think the maximum size of my encoding is the same as the one specified = in version 0 of the draft. Use 256 blocks, each 34 octets long, gives = 8704 octets total. All I suggest changing is to allow the start value of each block to be = on a multiple of 32 instead of a multiple of 256. Regards, Andy > -----Original Message----- > From: Roy Arends [mailto:roy@logmess.com] > Sent: 04 December 2003 15:02 > To: Andrew Draper > Cc: Jakob Schlyter; IETF DNSEXT WG > Subject: RE: nsec++=20 >=20 >=20 > On Thu, 4 Dec 2003, Andrew Draper wrote: >=20 > > Hi, > > > > While not wishing to reopen (too much) the debate about how=20 > to encode > > this efficiently, I have a suggestion which might make the=20 > encoding of > > sparse NSEC records a lot smaller, while being only=20 > slightly harder to > > understand and I think no harder to implement. > > > > If the types encoded are sparse then the bitmaps will tend=20 > to have a lot > > of zeros at the start of them. For example the RDATA for: > > > > example.com. IN NSEC host.example.com. 385 > > > > will be encoded as, I think: > > > > 04 'h' 'o' 's' 't' 06 'e' 'x' 'a' 'm' 'p' 'l' 'e' =20 > 03 'c' 'o' 'm' 00 > > 01 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 > > (all numbers are in hex) > > > > which has a lot of superfluous zeros. > > > > There are three bits spare in the "bitmap length" byte (if=20 > you store bitmap_length-1 instead of just bitmap_length) so=20 > it would be much more efficient, for sparse bitmaps, if the=20 > block start was allowed to be on any boundary of 32. > > > > The encoding of the same RR would then be: > > > > 04 'h' 'o' 's' 't' 06 'e' 'x' 'a' 'm' 'p' 'l' 'e' =20 > 03 'c' 'o' 'm' 00 > > 0C 00 02 > > > > > > If you like this then suggested text is below (I wrote this=20 > yesterday so some of the alternative suggested descriptions=20 > of bitmap might be better than this one): > > > > > > The type space is represented using one or more blocks. =20 > Each block > > starts at a location in type space which is a multiple of 32 and > > describes upto 256 active types. Each block consists of a 13 bit > > start type number, a 5 bit length field (from 1 .. 32 octets) and > > a bitmap (covering upto 256 type codes) in network bit order > > (similar to NXT). >=20 > One of the design requirements, and therefor one of the reasons some > proposals did not make it is that the bit map must be able to=20 > respresent > every type in one bitmap. >=20 > Your encoding gives us a worst case length of 69632 which is >64K >=20 > Roy >=20 >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 11:01:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02516 for ; Thu, 4 Dec 2003 11:01:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARvpR-000GFp-Iy for namedroppers-data@psg.com; Thu, 04 Dec 2003 15:55:45 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARvpF-000GF0-5Y for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 15:55:33 +0000 Received: from nlnetlabs.nl (eidolon.nlnetlabs.nl [IPv6:2001:7b8:206:1:240:f4ff:fe37:7af9]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB4FtP2w055124; Thu, 4 Dec 2003 16:55:25 +0100 (CET) (envelope-from erik@nlnetlabs.nl) Message-ID: <3FCF58ED.60805@nlnetlabs.nl> Date: Thu, 04 Dec 2003 16:55:25 +0100 From: Erik Rozendaal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Rozendaal CC: Mark.Andrews@isc.org, "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: Q20: expanding wildcards in the authority section References: <200312041341.hB4Df03f008688@drugs.dv.isc.org> <3FCF4305.7030602@nlnetlabs.nl> In-Reply-To: <3FCF4305.7030602@nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Rozendaal wrote: > But your explanation does make it clearer to me why unexpanded wildcards > were chosen, even though I still slightly prefer expanded wildcards. Actually, I think I've changed my mind and I prefer not expanding wildcards for NSEC records in the authority section. Consider a zone with the following RRs: *.wc. IN NSEC xx TXT NSEC RRSIG *.wc. IN RRSIG ... xx. IN NSEC yy TXT NSEC RRSIG xx. IN RRSIG ... and the query QNAME: foo.wc QTYPE: A Answer with expanded wildcard: *.wc IN NSEC xx. TXT NSEC RRSIG *.wc IN RRSIG ... foo.wc IN NSEC xx. TXT NSEC RRSIG foo.wc IN RRSIG ... In this case the same RRset is included twice: the first time to prove the non-existance of foo.wc (no expansion of wildcard because the wildcard is not used as a match for QNAME) and the second time to show the QTYPE does not exist at the matched wildcard. Of course, only one of these is really necessary but then we need to decide whether to include the expanded or unexpanded version in this particular case. Answer without expanded wildcard: *.wc IN NSEC xx. TXT NSEC RRSIG *.wc IN RRSIG ... In this case the RRset only needs to be included once and there is no (potential) ambiguity. So I'll go with the current draft specification as it is (not expanding wildcards). Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 11:09:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02755 for ; Thu, 4 Dec 2003 11:09:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARvu9-000GSl-Ul for namedroppers-data@psg.com; Thu, 04 Dec 2003 16:00:37 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARvtx-000GRp-WE for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 16:00:26 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB4G0K2w055152; Thu, 4 Dec 2003 17:00:20 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB4G1bXJ028608; Thu, 4 Dec 2003 17:01:37 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB4G1bYV028605; Thu, 4 Dec 2003 17:01:37 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 4 Dec 2003 17:01:37 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Andrew Draper cc: Jakob Schlyter , IETF DNSEXT WG Subject: RE: nsec++ In-Reply-To: <45E39EE2E44FD443AEFAC07728BF3B5054B01D@uk-ismsg02.altera.priv.altera.com> Message-ID: References: <45E39EE2E44FD443AEFAC07728BF3B5054B01D@uk-ismsg02.altera.priv.altera.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Dec 2003, Andrew Draper wrote: > Roy, > > I think the maximum size of my encoding is the same as the one specified > in version 0 of the draft. Use 256 blocks, each 34 octets long, gives > 8704 octets total. > > All I suggest changing is to allow the start value of each block to be > on a multiple of 32 instead of a multiple of 256. So the worst case scenario would not be that different. The 'multiplier' would now be 32 instead of 256, where you'd have a special graph-like algortihm to determine the most optimized presentation. You'd have to calculate all possible encodings to determine which one is the shortest. I don't think RDATA size is really that important to allow for discrete mathematics to determine the shortest representation. The current one (nsec++) satisfies all requirements. Yours adds complexity. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 11:32:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03654 for ; Thu, 4 Dec 2003 11:32:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARwKl-000Hul-17 for namedroppers-data@psg.com; Thu, 04 Dec 2003 16:28:07 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARwKY-000HtX-8t for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 16:27:54 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 4ED831958B for ; Thu, 4 Dec 2003 17:27:53 +0100 (CET) Date: Thu, 4 Dec 2003 17:27:52 +0100 (CET) From: Jakob Schlyter To: IETF DNSEXT WG Subject: nsec++ (-01) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk an updated version of the draft respecifying the rdata format for nsec has been submitted to the drafts editor and can also be found at the following address: http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-01.txt please send comments to namedroppers, jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 11:33:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03692 for ; Thu, 4 Dec 2003 11:33:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARwMI-000HyG-7H for namedroppers-data@psg.com; Thu, 04 Dec 2003 16:29:42 +0000 Received: from [216.148.222.61] (helo=mail19-red-R.bigfish.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARwM4-000Hxw-WD for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 16:29:29 +0000 Received: from mail19-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail19-red-R.bigfish.com (Postfix) with ESMTP id CFC5613934D; Thu, 4 Dec 2003 16:29:28 +0000 (UCT) Received: by mail19-red (MessageSwitch) id 1070555368586254_10948; Thu, 4 Dec 2003 16:29:28 +0000 (UCT) Received: from darwin.altera.com (darwin.altera.com [66.35.227.3]) by mail19-red.bigfish.com (Postfix) with ESMTP id AF2CB13A1FD; Thu, 4 Dec 2003 16:22:44 +0000 (UCT) Received: from sunrise.altera.com (sunrise [137.57.1.1]) by darwin.altera.com (8.11.7p1+Sun/8.11.7) with ESMTP id hB4GHQl25815; Thu, 4 Dec 2003 08:17:27 -0800 (PST) Received: from sj-gw02.altera.priv.altera.com (exchange [137.57.216.60]) by sunrise.altera.com (8.12.9/8.12.9) with ESMTP id hB4GMhZZ013627; Thu, 4 Dec 2003 08:22:43 -0800 (PST) Received: from uk-ismsg02.altera.priv.altera.com ([137.57.183.231]) by sj-gw02.altera.priv.altera.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Dec 2003 08:22:43 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: nsec++ Date: Thu, 4 Dec 2003 16:22:41 -0000 Message-ID: <45E39EE2E44FD443AEFAC07728BF3B50074A11@uk-ismsg02.altera.priv.altera.com> Thread-Topic: nsec++ Thread-Index: AcO6f8VRKzRiKc3NQDK0lUbOq15LagAAJQFw From: "Andrew Draper" To: "Roy Arends" Cc: "Jakob Schlyter" , "IETF DNSEXT WG" X-OriginalArrivalTime: 04 Dec 2003 16:22:43.0619 (UTC) FILETIME=[D86F3F30:01C3BA82] X-BigFish: v X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Roy, The algorithm for calculating the smallest RR is very simple. It's = something like this: next =3D 0; while (there are types with a value >=3D next) { start =3D first active type with a value of next or more start =3D start - (start % 32); // round down to multiple of 32 Create a temporary bitmap containing all types from start to start + = 255 length =3D 32 Trim zero octets off the end of the bitmap, reducing length as you do Look for three consecutive zeros in the bitmap, at byte offsets 1, 5, 9 = etc. If you find one then set the length of the bitmap to the address at = which you found it. Output the bitmap, specifying the start address and the length. next =3D start + length * 8 } I could write it in real C, but I'm sure you get the idea. Of course = the algorithm above could be optimised for processing time. This looks like a trivial piece of code to me, it certainly isn't = discrete mathematics. If small RRDATA size isn't considered important then I'll shut up, but = my experience is that one of the things holding DNSSEC back is that = users think it causes enormous increases in packet size. Putting a bit = of thought into saving some bytes seems worth it to me. Regards, Andy > -----Original Message----- > From: Roy Arends [mailto:roy@logmess.com] > Sent: 04 December 2003 16:02 > To: Andrew Draper > Cc: Jakob Schlyter; IETF DNSEXT WG > Subject: RE: nsec++=20 >=20 >=20 > On Thu, 4 Dec 2003, Andrew Draper wrote: >=20 > > Roy, > > > > I think the maximum size of my encoding is the same as the=20 > one specified > > in version 0 of the draft. Use 256 blocks, each 34 octets=20 > long, gives > > 8704 octets total. > > > > All I suggest changing is to allow the start value of each=20 > block to be > > on a multiple of 32 instead of a multiple of 256. >=20 > So the worst case scenario would not be that different. The=20 > 'multiplier' > would now be 32 instead of 256, where you'd have a special graph-like > algortihm to determine the most optimized presentation. >=20 > You'd have to calculate all possible encodings to determine=20 > which one is > the shortest. >=20 > I don't think RDATA size is really that important to allow=20 > for discrete > mathematics to determine the shortest representation. >=20 > The current one (nsec++) satisfies all requirements. Yours adds > complexity. >=20 > Roy >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 11:43:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03916 for ; Thu, 4 Dec 2003 11:43:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARwWE-000IgF-Ee for namedroppers-data@psg.com; Thu, 04 Dec 2003 16:39:58 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARwW1-000IfU-V4 for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 16:39:46 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B52C513991 for ; Thu, 4 Dec 2003 16:39:45 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: nsec++ In-Reply-To: Message from Miek Gieben of "Thu, 04 Dec 2003 15:31:38 +0100." <20031204143138.GA26856@atoom.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 04 Dec 2003 16:39:45 +0000 Message-Id: <20031204163945.B52C513991@sa.vix.com> X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > I think we don't want to make the NSEC more difficult than it already is > (compared to the NXT definition). > > So I would vote to keep the current NSEC definition as it as and get > used to the fact is takes up a few more bytes, it's all just fun and games until microsoft decides to sign zones containing their private-allocation types (in the 65000 range.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 12:38:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05913 for ; Thu, 4 Dec 2003 12:38:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARxKi-000LoI-HE for namedroppers-data@psg.com; Thu, 04 Dec 2003 17:32:08 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARxKV-000Ln4-Ub for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 17:31:56 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB4HVq2w055567 for ; Thu, 4 Dec 2003 18:31:52 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB4HX9XJ029637 for ; Thu, 4 Dec 2003 18:33:09 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB4HX92N029636 for namedroppers@ops.ietf.org; Thu, 4 Dec 2003 18:33:09 +0100 Date: Thu, 4 Dec 2003 18:33:09 +0100 From: Miek Gieben To: IETF DNSEXT WG Subject: Re: nsec++ Message-ID: <20031204173309.GA29587@atoom.net> Mail-Followup-To: IETF DNSEXT WG References: <20031204143138.GA26856@atoom.net> <20031204163945.B52C513991@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031204163945.B52C513991@sa.vix.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 04 Dec, @17:39, Paul wrote in "Re: nsec++ ..."] > > ... > > I think we don't want to make the NSEC more difficult than it already is > > (compared to the NXT definition). > > > > So I would vote to keep the current NSEC definition as it as and get > > used to the fact is takes up a few more bytes, > > it's all just fun and games until microsoft decides to sign zones containing > their private-allocation types (in the 65000 range.) so with this definition of the NSEC record we will not see an 7 to 10 times increase in zone sizes with DNSSEC? grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 15:41:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13670 for ; Thu, 4 Dec 2003 15:41:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AS0AE-0005LG-KY for namedroppers-data@psg.com; Thu, 04 Dec 2003 20:33:30 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS09u-0005K4-6Q for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 20:33:10 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12929; Thu, 4 Dec 2003 15:32:53 -0500 (EST) Message-Id: <200312042032.PAA12929@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-01.txt Date: Thu, 04 Dec 2003 15:32:53 -0500 X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-01.txt Pages : 9 Date : 2003-12-4 This document defines updates the NSEC resource record RDATA format to cover all type codes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-4154208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154208.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 16:16:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15219 for ; Thu, 4 Dec 2003 16:16:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AS0jp-0007o5-GM for namedroppers-data@psg.com; Thu, 04 Dec 2003 21:10:17 +0000 Received: from [211.30.118.161] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS0jE-0007jM-HM for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 21:09:40 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hB4L9P3f009847; Fri, 5 Dec 2003 08:09:25 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200312042109.hB4L9P3f009847@drugs.dv.isc.org> To: "Andrew Draper" Cc: "Roy Arends" , "Jakob Schlyter" , "IETF DNSEXT WG" From: Mark.Andrews@isc.org Subject: Re: nsec++ In-reply-to: Your message of "Thu, 04 Dec 2003 16:22:41 -0000." <45E39EE2E44FD443AEFAC07728BF3B50074A11@uk-ismsg02.altera.priv.altera.com> Date: Fri, 05 Dec 2003 08:09:25 +1100 X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk If you want to start at 32 bit boundraries you stop the current bitmap if you have a 32 bit subwindow that is all zeros. It takes 4 octets to represent a empty 32 bit subwindow. It takes 2 octets to start a new window. The algorithm would be: Find the first/next active 32 bit window. If the next the next 32 bit window is active include in in the current bitmap otherwise the current bitmap is complete. Repeat adding 32 bit windows until the bitmap is 256 bits long. Repeat until all types are accounted for. Mark > Roy, > > The algorithm for calculating the smallest RR is very simple. It's something > like this: > > next = 0; > while (there are types with a value >= next) > { > start = first active type with a value of next or more > start = start - (start % 32); // round down to multiple of 32 > > Create a temporary bitmap containing all types from start to start + 25 > 5 > length = 32 > > Trim zero octets off the end of the bitmap, reducing length as you do > > Look for three consecutive zeros in the bitmap, at byte offsets 1, 5, 9 > etc. > If you find one then set the length of the bitmap to the address at whi > ch > you found it. > > Output the bitmap, specifying the start address and the length. > next = start + length * 8 > } > > I could write it in real C, but I'm sure you get the idea. Of course the alg > orithm above could be optimised for processing time. > > This looks like a trivial piece of code to me, it certainly isn't discrete ma > thematics. > > If small RRDATA size isn't considered important then I'll shut up, but my exp > erience is that one of the things holding DNSSEC back is that users think it > causes enormous increases in packet size. Putting a bit of thought into savi > ng some bytes seems worth it to me. > > Regards, > Andy > > > > > > -----Original Message----- > > From: Roy Arends [mailto:roy@logmess.com] > > Sent: 04 December 2003 16:02 > > To: Andrew Draper > > Cc: Jakob Schlyter; IETF DNSEXT WG > > Subject: RE: nsec++ > > > > > > On Thu, 4 Dec 2003, Andrew Draper wrote: > > > > > Roy, > > > > > > I think the maximum size of my encoding is the same as the > > one specified > > > in version 0 of the draft. Use 256 blocks, each 34 octets > > long, gives > > > 8704 octets total. > > > > > > All I suggest changing is to allow the start value of each > > block to be > > > on a multiple of 32 instead of a multiple of 256. > > > > So the worst case scenario would not be that different. The > > 'multiplier' > > would now be 32 instead of 256, where you'd have a special graph-like > > algortihm to determine the most optimized presentation. > > > > You'd have to calculate all possible encodings to determine > > which one is > > the shortest. > > > > I don't think RDATA size is really that important to allow > > for discrete > > mathematics to determine the shortest representation. > > > > The current one (nsec++) satisfies all requirements. Yours adds > > complexity. > > > > Roy > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 16:40:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18400 for ; Thu, 4 Dec 2003 16:40:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AS19N-0009Ov-Em for namedroppers-data@psg.com; Thu, 04 Dec 2003 21:36:41 +0000 Received: from [211.30.118.161] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS19A-0009Nx-5s for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 21:36:28 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hB4LaJ3f009916; Fri, 5 Dec 2003 08:36:19 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200312042136.hB4LaJ3f009916@drugs.dv.isc.org> Cc: "Andrew Draper" , "Roy Arends" , "Jakob Schlyter" , "IETF DNSEXT WG" From: Mark.Andrews@isc.org Subject: Re: nsec++ In-reply-to: Your message of "Fri, 05 Dec 2003 08:09:25 +1100." Date: Fri, 05 Dec 2003 08:36:19 +1100 X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > If you want to start at 32 bit boundraries you stop the > current bitmap if you have a 32 bit subwindow that is all > zeros. > > It takes 4 octets to represent a empty 32 bit subwindow. > It takes 2 octets to start a new window. > > The algorithm would be: > Find the first/next active 32 bit window. If the last three octets of this 32 bit window are zero the bitmap is complete, remove trailing zero octets. If the next the next 32 bit window is active include in in the current bitmap otherwise the current bitmap is complete, remove trailing zero octets. If the last three octets of this 32 bit window are zero the current bitmap is complete, remove trailing zero octets. Repeat adding 32 bit windows until the bitmap is 256 bits long. Repeat until all types are accounted for. In otherword start a new bitmap if you save more than the cost of introducing a new bitmap. If the last two octets of the current map are zero it is a break even situation so you include the next 32 bit window in the current map. > > Mark > > > Roy, > > > > The algorithm for calculating the smallest RR is very simple. It's somethi > ng > > like this: > > > > next = 0; > > while (there are types with a value >= next) > > { > > start = first active type with a value of next or more > > start = start - (start % 32); // round down to multiple of 32 > > > > Create a temporary bitmap containing all types from start to start + 25 > > 5 > > length = 32 > > > > Trim zero octets off the end of the bitmap, reducing length as you do > > > > Look for three consecutive zeros in the bitmap, at byte offsets 1, 5, 9 > > etc. > > If you find one then set the length of the bitmap to the address at whi > > ch > > you found it. > > > > Output the bitmap, specifying the start address and the length. > > next = start + length * 8 > > } > > > > I could write it in real C, but I'm sure you get the idea. Of course the a > lg > > orithm above could be optimised for processing time. > > > > This looks like a trivial piece of code to me, it certainly isn't discrete > ma > > thematics. > > > > If small RRDATA size isn't considered important then I'll shut up, but my e > xp > > erience is that one of the things holding DNSSEC back is that users think i > t > > causes enormous increases in packet size. Putting a bit of thought into sa > vi > > ng some bytes seems worth it to me. > > > > Regards, > > Andy > > > > > > > > > > > -----Original Message----- > > > From: Roy Arends [mailto:roy@logmess.com] > > > Sent: 04 December 2003 16:02 > > > To: Andrew Draper > > > Cc: Jakob Schlyter; IETF DNSEXT WG > > > Subject: RE: nsec++ > > > > > > > > > On Thu, 4 Dec 2003, Andrew Draper wrote: > > > > > > > Roy, > > > > > > > > I think the maximum size of my encoding is the same as the > > > one specified > > > > in version 0 of the draft. Use 256 blocks, each 34 octets > > > long, gives > > > > 8704 octets total. > > > > > > > > All I suggest changing is to allow the start value of each > > > block to be > > > > on a multiple of 32 instead of a multiple of 256. > > > > > > So the worst case scenario would not be that different. The > > > 'multiplier' > > > would now be 32 instead of 256, where you'd have a special graph-like > > > algortihm to determine the most optimized presentation. > > > > > > You'd have to calculate all possible encodings to determine > > > which one is > > > the shortest. > > > > > > I don't think RDATA size is really that important to allow > > > for discrete > > > mathematics to determine the shortest representation. > > > > > > The current one (nsec++) satisfies all requirements. Yours adds > > > complexity. > > > > > > Roy > > > > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 16:41:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18436 for ; Thu, 4 Dec 2003 16:41:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AS17g-0009Gs-6n for namedroppers-data@psg.com; Thu, 04 Dec 2003 21:34:56 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS17M-0009GC-5Y for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 21:34:36 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3A1C918C1 for ; Thu, 4 Dec 2003 16:34:34 -0500 (EST) Date: Thu, 04 Dec 2003 16:34:34 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: nsec++ In-Reply-To: <200312042109.hB4L9P3f009847@drugs.dv.isc.org> References: <45E39EE2E44FD443AEFAC07728BF3B50074A11@uk-ismsg02.altera.priv.altera.com> <200312042109.hB4L9P3f009847@drugs.dv.isc.org> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031204213434.3A1C918C1@thrintun.hactrn.net> X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk No offense to Andrew, but my unnecessary complexity meter was reading yellowish green when the WG decided to go with windowed bitmaps, and today's discussion of algorithms by which one might determine the most compact among multiple possible encodings kicks it up into the orange. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 4 18:13:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24367 for ; Thu, 4 Dec 2003 18:13:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AS2ac-000EDG-EH for namedroppers-data@psg.com; Thu, 04 Dec 2003 23:08:54 +0000 Received: from [211.30.118.161] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS2aA-000EB8-Kh for namedroppers@ops.ietf.org; Thu, 04 Dec 2003 23:08:26 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hB4N713f010663; Fri, 5 Dec 2003 10:07:02 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200312042307.hB4N713f010663@drugs.dv.isc.org> To: Rob Austein Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: nsec++ In-reply-to: Your message of "Thu, 04 Dec 2003 16:34:34 CDT." <20031204213434.3A1C918C1@thrintun.hactrn.net> Date: Fri, 05 Dec 2003 10:07:01 +1100 X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > No offense to Andrew, but my unnecessary complexity meter was reading > yellowish green when the WG decided to go with windowed bitmaps, and > today's discussion of algorithms by which one might determine the most > compact among multiple possible encodings kicks it up into the orange. "Choose the most compact" was never going to fly without a differentiator between identically compact results. I do however thing that you can describe a algorithm which will alway produce the mimimal size and same encoding with sliding 256 bit windows. The second description I sent out is not much more difficult to encode / verify than the plain 256 bit window scheme. Mark > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 01:31:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08728 for ; Fri, 5 Dec 2003 01:31:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AS9Kp-0007ht-Hm for namedroppers-data@psg.com; Fri, 05 Dec 2003 06:21:03 +0000 Received: from [216.17.176.210] (helo=mail.acmeps.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS9Kd-0007hN-5H for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 06:20:51 +0000 Received: from acmeps.com (rabbit.acmeps.com [172.20.20.16]) by mail.acmeps.com (Postfix) with ESMTP id 65478A0004 for ; Thu, 4 Dec 2003 23:20:50 -0700 (MST) Message-ID: <3FD023C2.8070206@acmeps.com> Date: Thu, 04 Dec 2003 23:20:50 -0700 From: Michael Milligan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031119193138.1535B1396D@sa.vix.com> In-Reply-To: <20031119193138.1535B1396D@sa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>We actually discussed and rejected the additional processing suggestion >>-- it was present in the original draft of 1886. The argument was pretty >>much the one Robert just gave: we will have to remove the processing >>requirement eventually. It was also not clear that it would be useful in >>most cases. > > > i believed i had shown during the debate over 1886, and i believe i have > shown again here today, that the lifetime of the data will be the same > as the lifetime of its usefulness. this really is not a bad idea, folks. > I agree. This seems to solve the problem nicely and is in the same vein as adding A records to the additional data section when MX records are asked for. Think of it as an optimization. Resolvers only have to know to look for the A records and not start another query. Once all A records go away, there's just an extra bit of code path taken that looks for records that won't be found. And in the case of BIND, the execution of that extra code path can eventually go away like IQUERY did from a configuration standpoint. Regards, Mike -- Michael Milligan -> milli@acmeps.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 04:07:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26979 for ; Fri, 5 Dec 2003 04:07:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASBrF-000EnZ-Gh for namedroppers-data@psg.com; Fri, 05 Dec 2003 09:02:41 +0000 Received: from [193.176.144.164] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASBr2-000Emb-1X for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 09:02:28 +0000 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.10/8.12.10) with ESMTP id hB592OrP095979 for ; Fri, 5 Dec 2003 10:02:24 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200312050902.hB592OrP095979@bartok.sidn.nl> To: namedroppers@ops.ietf.org Subject: Re: List administration In-reply-to: Your message of Wed, 03 Dec 2003 15:28:11 -0500. <6.0.0.22.2.20031203094837.01f68568@localhost> Date: Fri, 05 Dec 2003 10:02:24 +0100 From: Jaap Akkerhuis X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rather than chastising Randy, we should be thanking him for a great job he has been doing. Yes! jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 05:51:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29681 for ; Fri, 5 Dec 2003 05:51:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASDTG-000KJX-Sf for namedroppers-data@psg.com; Fri, 05 Dec 2003 10:46:02 +0000 Received: from [63.161.60.93] (helo=mail4-ny2-R.bigfish.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASDT3-000KIq-7J for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 10:45:49 +0000 Received: from mail4-ny2.bigfish.com (localhost.localdomain [127.0.0.1]) by mail4-ny2-R.bigfish.com (Postfix) with ESMTP id 8DB5296DB4; Fri, 5 Dec 2003 10:45:45 +0000 (UCT) Received: by mail4-ny2 (MessageSwitch) id 1070621145538568_12782; Fri, 5 Dec 2003 10:45:45 +0000 (UCT) Received: from darwin.altera.com (darwin.altera.com [66.35.227.3]) by mail4-ny2.bigfish.com (Postfix) with ESMTP id F3DA4964B7; Fri, 5 Dec 2003 10:45:44 +0000 (UCT) Received: from sunrise.altera.com (sunrise [137.57.1.1]) by darwin.altera.com (8.11.7p1+Sun/8.11.7) with ESMTP id hB5AeTl07191; Fri, 5 Dec 2003 02:40:29 -0800 (PST) Received: from sj-gw02.altera.priv.altera.com (exchange [137.57.216.60]) by sunrise.altera.com (8.12.9/8.12.9) with ESMTP id hB5AjfZZ007891; Fri, 5 Dec 2003 02:45:42 -0800 (PST) Received: from uk-ismsg02.altera.priv.altera.com ([137.57.183.231]) by sj-gw02.altera.priv.altera.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 5 Dec 2003 02:45:42 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: nsec++ Date: Fri, 5 Dec 2003 10:45:39 -0000 Message-ID: <45E39EE2E44FD443AEFAC07728BF3B5054B026@uk-ismsg02.altera.priv.altera.com> Thread-Topic: nsec++ Thread-Index: AcO6rs1+wl8KkrqcQ0W7PHPH8tN3swAbW0xA From: "Andrew Draper" To: Cc: "Roy Arends" , "Jakob Schlyter" , "IETF DNSEXT WG" X-OriginalArrivalTime: 05 Dec 2003 10:45:42.0094 (UTC) FILETIME=[EDE126E0:01C3BB1C] X-BigFish: v X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > If you want to start at 32 bit boundraries you stop the > > current bitmap if you have a 32 bit subwindow that is all > > zeros. > > =09 > > It takes 4 octets to represent a empty 32 bit subwindow. > > It takes 2 octets to start a new window. > >=20 > > The algorithm would be: > >=20 > Find the first/next active 32 bit window. If the last three > octets of this 32 bit window are zero the bitmap is complete, > remove trailing zero octets. If the next the next 32 bit > window is active include in in the current bitmap otherwise > the current bitmap is complete, remove trailing zero octets. > If the last three octets of this 32 bit window are zero the > current bitmap is complete, remove trailing zero octets. > Repeat adding 32 bit windows until the bitmap is 256 bits > long. > =09 > Repeat until all types are accounted for. >=20 > In otherword start a new bitmap if you save more than the > cost of introducing a new bitmap. >=20 > If the last two octets of the current map are zero it is > a break even situation so you include the next 32 bit > window in the current map. This is exactly the algorithm I was intending to describe, both with my = suggested set of MUSTs and with my pseudo-code. Thanks for describing = it in an easier to understand way. Andy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 11:46:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13052 for ; Fri, 5 Dec 2003 11:46:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASIxP-00035z-Uw for namedroppers-data@psg.com; Fri, 05 Dec 2003 16:37:31 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASIxB-00034l-6c for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 16:37:17 +0000 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hB5GZ285037979; Fri, 5 Dec 2003 11:35:04 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.1.1.2.20031205112443.02c20ec0@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 05 Dec 2003 11:36:55 -0500 To: "Andrew Draper" , From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: RE: nsec++ Cc: "IETF DNSEXT WG" In-Reply-To: <45E39EE2E44FD443AEFAC07728BF3B5054B026@uk-ismsg02.altera.p riv.altera.com> References: <45E39EE2E44FD443AEFAC07728BF3B5054B026@uk-ismsg02.altera.priv.altera.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 05:45 2003-12-05, Andrew Draper wrote: > > In otherword start a new bitmap if you save more than the > > cost of introducing a new bitmap. > > > > If the last two octets of the current map are zero it is > > a break even situation so you include the next 32 bit > > window in the current map. > >This is exactly the algorithm I was intending to describe, both with my=20 >suggested set of MUSTs and with my pseudo-code. Thanks for describing it= =20 >in an easier to understand way. > > Andy This algorithm only optimizes for space, it has serious penalty for searching now I add every 64=B4th type and you need to search linearly through 1024 blocs as you do not know before hand the size of any block. Is this tradeoff worth it? Is this whole thread worth the effort when we have many more pressing issues like comment on the protocol document, check if the protocol documents reflect all the documents they are obsoleting/updating correctly ? Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 12:07:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13984 for ; Fri, 5 Dec 2003 12:07:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASJLZ-0006m4-G5 for namedroppers-data@psg.com; Fri, 05 Dec 2003 17:02:29 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASJLN-0006lP-NM for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 17:02:17 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA09517; Fri, 5 Dec 2003 12:59:37 -0500 Date: Fri, 5 Dec 2003 11:53:02 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: ogud@ogud.com, Olaf Kolkman cc: namedroppers@ops.ietf.org Subject: Re: List administration (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At least one person seems to think my view is pretty unique, so if you are concerned about this, perhaps some "me-too"s would help demonstrate that I am not the only person with this concern. I would like to have some confirmation from the Chairs that one of the following has occured: 1) Randy was just exaggerating his threat to configure his servers to delete mail queued for one hour, and that he has been properly chastised for making such threats with respect to IETF list operation. or 2) That Randy has changed the server config back so that he is no longer deleting IETF email, and has been properly chastised for deleting this email in violation of IETF policies, and chastised for making such changes without notification or approval. I think many people would like to have an assurance that namedropper's email is not being deleted before delivery, and that the queue time is at least 3 days. Thanks, --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 13:14:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17251 for ; Fri, 5 Dec 2003 13:14:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASKO3-000GFC-Mw for namedroppers-data@psg.com; Fri, 05 Dec 2003 18:09:07 +0000 Received: from [192.188.192.2] (helo=imail.akc.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASKNp-000GCM-3O for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 18:08:53 +0000 Received: from upstairs [64.253.39.242] by imail.akc.com with ESMTP (SMTPD32-8.02) id AADF46FE013C; Fri, 05 Dec 2003 13:13:51 -0500 Message-ID: <001e01c3bb5a$7f3f2000$6401a8c0@akc.com> From: "Al Costanzo" To: "Dean Anderson" , , "Olaf Kolkman" Cc: References: Subject: Re: List administration (fwd) Date: Fri, 5 Dec 2003 13:06:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear IETF Chairs and members of the this mailing list: I personally think Randy does a damn good job an unlike closed minded indivuals he at listens to ideas. If he has done something I am sure there is a good reason for it. In the years I have been associated with the IETF and this mailing list. I can name at least one person that is fair and open minded and that is Randy. IMHO Randy should not be chastised but applauded for all the work he has done for the IETF. Now these comments from me may come as a suprise to Randy since we have not always seen eye to eye on a few things. But if the IETF chairs want to do something to Randy, how about a pat on the back and a thank you for a job well done! Randy, believe or not. I always considered you helpful to me. Even when you told me I couldn't do something or another. Sincerely, Al Costanzo IETF contributor/member/sitter on the sidelines since 1979 > > At least one person seems to think my view is pretty unique, so if you are > concerned about this, perhaps some "me-too"s would help demonstrate that I > am not the only person with this concern. > > I would like to have some confirmation from the Chairs that one of the > following has occured: > > 1) Randy was just exaggerating his threat to configure his servers to > delete mail queued for one hour, and that he has been properly chastised > for making such threats with respect to IETF list operation. > > or > > 2) That Randy has changed the server config back so that he is no longer > deleting IETF email, and has been properly chastised for deleting this > email in violation of IETF policies, and chastised for making such changes > without notification or approval. > > I think many people would like to have an assurance that namedropper's > email is not being deleted before delivery, and that the queue time is at > least 3 days. > > Thanks, > > --Dean > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 13:32:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17535 for ; Fri, 5 Dec 2003 13:32:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASKbV-000Hpb-KI for namedroppers-data@psg.com; Fri, 05 Dec 2003 18:23:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASKbJ-000Hp8-MH for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 18:22:49 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 7D0D41396B; Fri, 5 Dec 2003 18:22:49 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: nsec++ References: <45E39EE2E44FD443AEFAC07728BF3B5054B026@uk-ismsg02.altera.priv.altera.com> From: Paul Vixie Date: 05 Dec 2003 18:22:49 +0000 In-Reply-To: Message-ID: Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This algorithm only optimizes for space, it has serious > penalty for searching now I add every 64=B4th type and you need to search > linearly through 1024 blocs as you do not know before hand the size of > any block. Is this tradeoff worth it? when i participated in the discussions with michael graff that led to his draft on this topic, these other alternatives were considered and dropped. i now realize that it was foolish of us to not document the roads untaken. > Is this whole thread worth the effort when we have many > more pressing issues like comment on the protocol document, check if the > protocol documents reflect all the documents they are obsoleting/updating > correctly ? the community now embodied by DNSEXT (but previously DNSIND et al) has a rather poor record when it comes to measuring importance. 18 months ago we made the decision not to complicate the NXT format with support for n>128 type codes since it would delay deployment. 16 months later we decided that it wasn't reasonable to go to proposed standard without that support. let's do this: let the debate rage on. let the people who are interested in this topic discuss it. let the draft author judge consensus for now. when it's time to roll out the next -bis docset then the then-current draft will be frozen and incorporated. let's not do this: let leadership mean deciding what (not) to discuss. -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 14:15:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19272 for ; Fri, 5 Dec 2003 14:15:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASLKM-000Oce-9Q for namedroppers-data@psg.com; Fri, 05 Dec 2003 19:09:22 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASLK9-000Obi-K5 for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 19:09:09 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB5J952w063833 for ; Fri, 5 Dec 2003 20:09:05 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p2/8.12.8/Submit) id hB5J95G6063832 for namedroppers@ops.ietf.org; Fri, 5 Dec 2003 20:09:05 +0100 (CET) (envelope-from ted) Message-Id: <200312051909.hB5J95G6063832@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Fri, 5 Dec 2003 20:09:05 +0100 In-Reply-To: "Dean Anderson's message as of Dec 5, 18:10" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: List administration (fwd) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Dean Anderson, on Dec 5, 18:10, in "Re: List administrat ..."] > > At least one person seems to think my view is pretty unique, so if you are > concerned about this, perhaps some "me-too"s would help demonstrate that I > am not the only person with this concern. I'm sorry, but I, and also a number of people I talked with the past week, do NOT share your concern. We all think Randy is doing excellent job on the list administration and appreciate his work. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 14:38:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20273 for ; Fri, 5 Dec 2003 14:38:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASLjS-00026c-Kj for namedroppers-data@psg.com; Fri, 05 Dec 2003 19:35:18 +0000 Received: from [68.162.176.181] (helo=budney.homeunix.net) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ASLjD-0001v4-M3 for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 19:35:07 +0000 Received: (qmail 4239 invoked by uid 500); 5 Dec 2003 19:07:44 -0000 From: lbudney@pobox.com Mail-Followup-To: namedroppers@ops.ietf.org Date: Fri, 5 Dec 2003 14:07:44 -0500 (EST) X-X-Sender: budney@budney.homeunix.net To: "namedroppers@ops.ietf.org" Subject: Re: List administration (fwd) In-Reply-To: <001e01c3bb5a$7f3f2000$6401a8c0@akc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Dec 2003, Al Costanzo wrote: > > IMHO Randy should not be chastised but applauded for all the work he has > done for the IETF. For work he has done, he should be applauded. If he is dropping mails after 1 hour, for that he should be chastised. --Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 16:16:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27037 for ; Fri, 5 Dec 2003 16:16:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASNFI-000FcX-5s for namedroppers-data@psg.com; Fri, 05 Dec 2003 21:12:16 +0000 Received: from [203.143.238.93] (helo=gw.gbch.net) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ASNF5-000Fbx-0W for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 21:12:03 +0000 Received: (qmail 71980 invoked by uid 1001); 6 Dec 2003 07:11:57 +1000 Message-ID: Date: Sat, 6 Dec 2003 07:11:56 +1000 From: Greg Black To: namedroppers@ops.ietf.org Subject: Re: List administration (fwd) Reply-To: namedroppers@ops.ietf.org References: <200312051909.hB5J95G6063832@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312051909.hB5J95G6063832@open.nlnetlabs.nl> User-Agent: Mutt/1.4.1i; gjb-muttsend.sh 1.5 2003-10-01 X-Uptime: 10 days X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-PGP-Key-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-Request-PGP: http://www.gbch.net/keys/4B04B7D6.asc X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 2003-12-05, Ted Lindgreen wrote: > [Quoting Dean Anderson, on Dec 5, 18:10, in "Re: List administrat ..."] > > > > At least one person seems to think my view is pretty unique, so if you are > > concerned about this, perhaps some "me-too"s would help demonstrate that I > > am not the only person with this concern. > > I'm sorry, but I, and also a number of people I talked with the > past week, do NOT share your concern. We all think Randy is doing > excellent job on the list administration and appreciate his work. If Randy is dropping email that cannot be delivered after a mere hour, then we do *not* all think he's doing an excellent job on the list administration -- some of us think that he's doing a really lousy job of it if that allegation is true. Certainly, it is time for some responsible person to assure us that email is not being dropped on the floor as a result of such a decision (by Randy or anybody else). Greg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 16:38:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28089 for ; Fri, 5 Dec 2003 16:38:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASNaE-000HsX-Tk for namedroppers-data@psg.com; Fri, 05 Dec 2003 21:33:54 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASNa2-000HsA-Ef for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 21:33:42 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id hB5LXcW5022380; Fri, 5 Dec 2003 13:33:38 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Dec 2003 13:33:38 -0800 Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113283@mou1wnexm02.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , ogud@ogud.com, Olaf Kolkman Cc: namedroppers@ops.ietf.org Subject: RE: List administration (fwd) Date: Fri, 5 Dec 2003 13:33:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk If the IETF wants to get into this type of discussion it should do what most other standards organizations do and exclusively provide the mailing list facilities itself. Policy and practice for mailing list management may be thus perfectly aligned. Given the astonishing sums paid by ISOC to the secretariat to support the RFC editor function this should be well in scope. I am not a Randy Bush fan. But attacking him for what amounts to parking fines merely cheapens the case against the damage he has caused this group in particular and the IETF in general. This whole discussion should probably be taken to another list, I suggest, "why are we in this handbasket and why do the roadsigns point to Hades?" Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 5 17:53:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00839 for ; Fri, 5 Dec 2003 17:53:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASOlC-00014j-4f for namedroppers-data@psg.com; Fri, 05 Dec 2003 22:49:18 +0000 Received: from [211.30.118.161] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASOkz-00014K-Pt for namedroppers@ops.ietf.org; Fri, 05 Dec 2003 22:49:06 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hB5Mms3f018993; Sat, 6 Dec 2003 09:48:54 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200312052248.hB5Mms3f018993@drugs.dv.isc.org> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: "Andrew Draper" , Mark_Andrews@isc.org, "IETF DNSEXT WG" From: Mark.Andrews@isc.org Subject: Re: nsec++ In-reply-to: Your message of "Fri, 05 Dec 2003 11:36:55 CDT." <6.0.1.1.2.20031205112443.02c20ec0@localhost> Date: Sat, 06 Dec 2003 09:48:54 +1100 X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 05:45 2003-12-05, Andrew Draper wrote: > > > > In otherword start a new bitmap if you save more than the > > > cost of introducing a new bitmap. > > > > > > If the last two octets of the current map are zero it is > > > a break even situation so you include the next 32 bit > > > window in the current map. > > > >This is exactly the algorithm I was intending to describe, both with my > >suggested set of MUSTs and with my pseudo-code. Thanks for describing it > >in an easier to understand way. > > > > Andy > > > This algorithm only optimizes for space, it has serious penalty for > searching now I add every 64´th type and you need to search linearly > through 1024 blocs as you do not know before hand the size > of any block. > Is this tradeoff worth it? Worst case search has gone from 256 to 2048 blocks for a type in 65504-65535. Bitmap size for worst number of blocks is 6144 octets. You still have to perform a linear search as you need to find the right block. I suspect the optimisation however will pay off for the common cases. Zone APEX: 1 block/1 block A NS SOA MX RRSIG NSEC DNSKEY 00 07 62 01 00 00 00 03 80 00 07 62 01 00 00 00 03 80 Typical host: 1 block/1 block A MX RRSIG NSEC 00 06 40 01 00 00 00 03 00 06 40 01 00 00 00 03 Insecure delegation: 1 block/2 blocks A RRSIG NSEC 00 06 20 00 00 00 00 03 00 01 20 02 02 00 03 Secure delegation: 1 block/2 block NS DS RRSIG NSEC 00 06 20 00 00 00 00 13 00 01 20 02 02 00 13 IN-ADDR.ARPA/IP6.ARPA: 1 block/1 block PTR RRSIG NSEC 00 06 00 08 00 00 00 03 00 06 00 08 00 00 00 03 SRV entry: 1 block/1 block SRV RRSIG NSEC 00 06 00 00 00 00 40 03 02 02 40 03 TYPE1234: 2 blocks/2 blocks RRSIG NSEC TYPE1234 00 06 00 00 00 00 00 03 04 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 02 02 00 03 04 c3 00 00 20 TYPE65535: 2 blocks/2 blocks RRSIG NSEC TYPE65535 00 06 00 00 00 00 00 03 ff 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 02 00 03 ff e4 00 00 00 01 > > Is this whole thread worth the effort when we have many > more pressing issues like comment on the protocol document, check > if the protocol documents reflect all the documents they are > obsoleting/updating correctly ? > > Olafur > > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Dec 6 16:53:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21095 for ; Sat, 6 Dec 2003 16:53:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASkEY-000Gbb-Gg for namedroppers-data@psg.com; Sat, 06 Dec 2003 21:45:02 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASkEC-000GXd-UA for namedroppers@ops.ietf.org; Sat, 06 Dec 2003 21:44:41 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id CF6E14E280; Sat, 6 Dec 2003 22:44:39 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6F9E44E099 for ; Sat, 6 Dec 2003 22:44:39 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hB6Lidwp019881 for ; Sat, 6 Dec 2003 22:44:39 +0100 Message-Id: <200312062144.hB6Lidwp019881@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: Re: List administration (fwd) In-Reply-To: Message from "Hallam-Baker, Phillip" of "Fri, 05 Dec 2003 13:33:38 PST." <2A1D4C86842EE14CA9BC80474919782E01113283@mou1wnexm02.vcorp.ad.vrsn.com> Date: Sat, 06 Dec 2003 22:44:39 +0100 From: Olaf Kolkman X-RIPE-Spam-Status: N 0.212270 X-RIPE-Signature: c754c8b23c103ec7f31a165b7be8a42a X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Hallam-Baker, Phillip" writes: * * This whole discussion should probably be taken to another list Thanks Philip, exactly my thinking. The mail-list is prudently managed. I have confirmed that there are no special delivery settings. All recipients are treated the same. (So to use Phillip's metaphore, there was a parking ticket being waved, not handed out). To repeat the list policy: Moderation is based on "subscriber-only with spam filter". Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). If there are problems in delivery, i.e. differences of what is in your mailbox and in the archive, please notify the chairs. We will not troubleshoot individual problems because they could be caused by all kind of problems at the recipient end, however if there are patterns we will follow up. Randy is doing a good job, he is doing it professionally and prudently! This is the last mail on this topic. We have work to do. --Olaf Kolkman DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 7 04:06:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17806 for ; Sun, 7 Dec 2003 04:06:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASulA-0002td-U2 for namedroppers-data@psg.com; Sun, 07 Dec 2003 08:59:24 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ASuky-0002oV-Ko for namedroppers@ops.ietf.org; Sun, 07 Dec 2003 08:59:12 +0000 Received: (qmail 95777 invoked by uid 1016); 7 Dec 2003 08:59:34 -0000 Date: 7 Dec 2003 08:59:34 -0000 Message-ID: <20031207085934.95776.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: List administration References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Chris Thompson writes: > Make that "mail servers in general" rather than just mailing lists, Yup. RFC 1123 says ``the give-up time generally needs to be at least 4-5 days.'' RFC 2821 says the same thing. I used a 7-day timeout in qmail, and I'm glad I did. A few months ago, large chunks of the Internet were unreachable for several days straight; naive 4-day timeouts led to widespread delivery failures. Randy's 1-hour timeout is absurd. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 8 08:21:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08461 for ; Mon, 8 Dec 2003 08:21:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATLAT-000GGz-2G for namedroppers-data@psg.com; Mon, 08 Dec 2003 13:11:17 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATLAF-000GGI-T0 for namedroppers@ops.ietf.org; Mon, 08 Dec 2003 13:11:04 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB8DB02w086134 for ; Mon, 8 Dec 2003 14:11:00 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB8DAx1S021173 for ; Mon, 8 Dec 2003 14:10:59 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB8DAxXw021172 for namedroppers@ops.ietf.org; Mon, 8 Dec 2003 14:10:59 +0100 Date: Mon, 8 Dec 2003 14:10:59 +0100 From: Miek Gieben To: namedroppers Subject: section 3.2 of protocol draft Message-ID: <20031208131059.GB20995@atoom.net> Mail-Followup-To: namedroppers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, I'm rereading the protocol draft again, and I'm wondering about the following paragraph. In section 3.2: Recursive Name Servers 2nd paragraph: A security-aware recursive name server MUST NOT attempt to answer a query by piecing together cached data it received in response to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes. A security-aware recursive name server MUST NOT use NSEC RRs from one negative response to synthesize a response for a different query. A security-aware recursive name server MUST NOT use a previous wildcard expansion to generate a response to a different query. I don't "get" the first sentence. does that really say: "don't use the cache"? If i'm a cache and i've just validated a DNSKEY in response to another query, I cannot use that validated DNSKEY? Further more, if this question is answered negatively (A cache can still be used), i'm wondering why is this put in a protocol draft? Isn't this bordering implementation details? grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 8 09:30:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10529 for ; Mon, 8 Dec 2003 09:30:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATMK7-000P5P-FF for namedroppers-data@psg.com; Mon, 08 Dec 2003 14:25:19 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATMJu-000P4I-ER for namedroppers@ops.ietf.org; Mon, 08 Dec 2003 14:25:06 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hB8EOw18013917 for ; Mon, 8 Dec 2003 09:24:58 -0500 (EST) Message-ID: <012101c3bd97$10f0be30$b9370681@barnacle> From: "Scott Rose" To: "namedroppers" References: <20031208131059.GB20995@atoom.net> Subject: Re: section 3.2 of protocol draft Date: Mon, 8 Dec 2003 09:25:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Miek Gieben" > Hello, > > I'm rereading the protocol draft again, and I'm wondering about the following > paragraph. > > In section 3.2: Recursive Name Servers > 2nd paragraph: > > A security-aware recursive name server MUST NOT attempt to answer a > query by piecing together cached data it received in response to > previous queries that requested different QNAMEs, QTYPEs, or > QCLASSes. A security-aware recursive name server MUST NOT use NSEC > RRs from one negative response to synthesize a response for a > different query. A security-aware recursive name server MUST NOT use > a previous wildcard expansion to generate a response to a different > query. > > I don't "get" the first sentence. does that really say: "don't use the cache"? > If i'm a cache and i've just validated a DNSKEY in response to another query, > I cannot use that validated DNSKEY? > I think the spec will be changed after Q-21 was resolved. See Olaf's previous email (Nov 27) about the proposed change. Not quite - at least that is not what it is supposed to say. The spirit of the "MUST NOT" is that a caching server shouldn't try to format a response out of RRsets from previous responses that were for different combos. It could, however use the previously cached "www.example.com A" RRset to answer another query for "www.example.com A". It shouldn't try to generate any new wildcard expanded responses if it has cached a wildcard RR from a previous query. Mostly because there is a danger it could form an incorrect answer, or that two name servers could generate different answers based on the contents of their individual caches. Actually, this is mostly academic now - Q21 of the DNSSECbis questions was resolved to use "MAY re-use NSEC RRs to format respnoses". So the specs no longer forbids it. Using cached DNSKEYs to verify RRSIGs were always allowed, of course. > Further more, if this question is answered negatively (A cache can still be used), > i'm wondering why is this put in a protocol draft? Isn't this bordering implementation > details? > I agree this is the grey area between protocol and implementation/operation. But the restriction is on what liberty a cahce has in generating responses to queries, so it falls more on protocol (sending responses) than operation. Scott > grtz Miek > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 8 09:48:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11003 for ; Mon, 8 Dec 2003 09:48:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATMcn-0001fX-7G for namedroppers-data@psg.com; Mon, 08 Dec 2003 14:44:37 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATMcZ-0001cw-T2 for namedroppers@ops.ietf.org; Mon, 08 Dec 2003 14:44:24 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB8EiK2w086893 for ; Mon, 8 Dec 2003 15:44:20 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB8EiK1S022652 for ; Mon, 8 Dec 2003 15:44:20 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB8EiKic022651 for namedroppers@ops.ietf.org; Mon, 8 Dec 2003 15:44:20 +0100 Date: Mon, 8 Dec 2003 15:44:19 +0100 From: Miek Gieben To: namedroppers Subject: Re: section 3.2 of protocol draft Message-ID: <20031208144419.GA22600@atoom.net> Mail-Followup-To: namedroppers References: <20031208131059.GB20995@atoom.net> <012101c3bd97$10f0be30$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012101c3bd97$10f0be30$b9370681@barnacle> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 08 Dec, @15:25, Scott wrote in "Re: section 3.2 of protocol dr ..."] > > If i'm a cache and i've just validated a DNSKEY in response to another > query, > > I cannot use that validated DNSKEY? > > > I think the spec will be changed after Q-21 was resolved. See Olaf's > previous email (Nov 27) about the proposed change. I've read that, but that concerns NSEC records ie. negative caching. > Not quite - at least that is not what it is supposed to say. The spirit of > the "MUST NOT" is that a caching server shouldn't try to format a response > out of RRsets from previous responses that were for different QCLASS, QTYPE> combos. It could, however use the previously cached > "www.example.com A" RRset to answer another query for "www.example.com A". Ok, I understand that, but makes the text from 3.2 the following illegal: (i'm not sure of the following 2 replies actually will go to the same nameserver, but suppose they do) got query for nlnetlabs.nl -> cached (and verified!) key for .NL (while following the chain of trust) query for DS of some (other!) nl zone -> reply with DS + SIG, plus add the verified key of NL in packet (and also the sig). The question: can a recursive server add that key? > It shouldn't try to generate any new wildcard expanded responses if it has > cached a wildcard RR from a previous query. Mostly because there is a > danger it could form an incorrect answer, or that two name servers could > generate different answers based on the contents of their individual caches. > > Actually, this is mostly academic now - Q21 of the DNSSECbis questions was > resolved to use "MAY re-use NSEC RRs to format respnoses". So the specs no > longer forbids it. OK, I see, but that is negative caching. > Using cached DNSKEYs to verify RRSIGs were always allowed, of course. Also true, but either I don't understand the exact meaning of 3.2 or you haven't understood the meaning of my email message :) Maybe the example above makes it clearer? > implementation > > details? > > > I agree this is the grey area between protocol and implementation/operation. > But the restriction is on what liberty a cahce has in generating responses > to queries, so it falls more on protocol (sending responses) than operation. ok, then I would like to see where this discussions leads, 'cause the text wasn't entirely clear to me. Maybe something must be added, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 8 10:27:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13851 for ; Mon, 8 Dec 2003 10:27:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATNDv-0006zE-VO for namedroppers-data@psg.com; Mon, 08 Dec 2003 15:22:59 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATNDi-0006yC-LQ for namedroppers@ops.ietf.org; Mon, 08 Dec 2003 15:22:46 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id hB8FMjQ1024032 for ; Mon, 8 Dec 2003 15:22:45 GMT To: namedroppers Subject: Re: section 3.2 of protocol draft In-Reply-To: Message from Miek Gieben of "Mon, 08 Dec 2003 14:10:59 +0100." <20031208131059.GB20995@atoom.net> Date: Mon, 08 Dec 2003 15:22:45 +0000 Message-ID: <24031.1070896965@gromit.rfc1035.com> From: Jim Reid X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Miek" == Miek Gieben writes: >> A security-aware recursive name server MUST NOT attempt >> to answer a query by piecing together cached data it >> received in response to previous queries that requested >> different QNAMEs, QTYPEs, or QCLASSes. A security-aware >> recursive name server MUST NOT use NSEC RRs from one >> negative response to synthesize a response for a different >> query. A security-aware recursive name server MUST NOT use >> a previous wildcard expansion to generate a response to a >> different query. Miek> I don't "get" the first sentence. does that really say: Miek> "don't use the cache"? If i'm a cache and i've just Miek> validated a DNSKEY in response to another query, I cannot Miek> use that validated DNSKEY? No, it doesn't say "don't use the cache". Well, not to this mother-tongue English speaker anyway. It says "don't use cached data to compose or fill out an answer to a query you've not resolved". I think the intention here is to cover things like glue or partial responses from an authoritative server. If the resolving server has previously resolved and validated the glue or other stuff that might be missing from the authoritative server's response, the resolving server MUST NOT add these things to the reply it returns to its end client. That's my interpretation of this bit of the draft. Perhaps the language could be made less opaque? Miek> Further more, if this question is answered negatively (A Miek> cache can still be used), i'm wondering why is this put in a Miek> protocol draft? Isn't this bordering implementation details? Some clarification is needed on when and how cached data can and cannot be used. This is an implementation detail that will be critical to how the protocol gets implemented. :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 8 12:57:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21138 for ; Mon, 8 Dec 2003 12:57:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATPU2-000Ozb-FJ for namedroppers-data@psg.com; Mon, 08 Dec 2003 17:47:46 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATPTp-000Oyu-SQ for namedroppers@ops.ietf.org; Mon, 08 Dec 2003 17:47:33 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hB8HlD18013937 for ; Mon, 8 Dec 2003 12:47:14 -0500 (EST) Message-ID: <02aa01c3bdb3$52813160$b9370681@barnacle> From: "Scott Rose" To: "namedroppers" References: <20031208131059.GB20995@atoom.net> <012101c3bd97$10f0be30$b9370681@barnacle> <20031208144419.GA22600@atoom.net> Subject: Re: section 3.2 of protocol draft Date: Mon, 8 Dec 2003 12:47:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That seems reasonable. It might be a good idea to clarify that test to take different cases into consideration. There is little danger in adding previously cached RR sets into the additional section of another response - I haven't considered all the cases. Or narrowing the restrictions to what (from cache) can and cannot be placed in the answer section of a response. I believe it might be necessary to have stricter conditions on forming the answer section of a response, but be more liberal about using cached RR sets in the other sections. Which I believe your example demonstrated. Scott ----- Original Message ----- From: "Miek Gieben" To: "namedroppers" Sent: Monday, December 08, 2003 9:44 AM Subject: Re: section 3.2 of protocol draft > [On 08 Dec, @15:25, Scott wrote in "Re: section 3.2 of protocol dr ..."] > > > If i'm a cache and i've just validated a DNSKEY in response to another > > query, > > > I cannot use that validated DNSKEY? > > > > > I think the spec will be changed after Q-21 was resolved. See Olaf's > > previous email (Nov 27) about the proposed change. > > I've read that, but that concerns NSEC records ie. negative caching. > > > Not quite - at least that is not what it is supposed to say. The spirit of > > the "MUST NOT" is that a caching server shouldn't try to format a response > > out of RRsets from previous responses that were for different > QCLASS, QTYPE> combos. It could, however use the previously cached > > "www.example.com A" RRset to answer another query for "www.example.com A". > > Ok, I understand that, but makes the text from 3.2 the following illegal: > (i'm not sure of the following 2 replies actually will go to the same > nameserver, but suppose they do) > > got query for nlnetlabs.nl -> cached (and verified!) key for .NL (while > following the chain of trust) > query for DS of some (other!) nl zone -> reply with DS + SIG, plus add the verified > key of NL in packet (and also the sig). > > The question: can a recursive server add that key? > > > It shouldn't try to generate any new wildcard expanded responses if it has > > cached a wildcard RR from a previous query. Mostly because there is a > > danger it could form an incorrect answer, or that two name servers could > > generate different answers based on the contents of their individual caches. > > > > Actually, this is mostly academic now - Q21 of the DNSSECbis questions was > > resolved to use "MAY re-use NSEC RRs to format respnoses". So the specs no > > longer forbids it. > > OK, I see, but that is negative caching. > > > Using cached DNSKEYs to verify RRSIGs were always allowed, of course. > > Also true, but either I don't understand the exact meaning of 3.2 or you > haven't understood the meaning of my email message :) Maybe the example > above makes it clearer? > > > implementation > > > details? > > > > > I agree this is the grey area between protocol and implementation/operation. > > But the restriction is on what liberty a cahce has in generating responses > > to queries, so it falls more on protocol (sending responses) than operation. > > ok, then I would like to see where this discussions leads, 'cause the text > wasn't entirely clear to me. Maybe something must be added, > > grtz Miek > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 8 13:29:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23034 for ; Mon, 8 Dec 2003 13:29:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATQ4n-0004qS-CM for namedroppers-data@psg.com; Mon, 08 Dec 2003 18:25:45 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATQ4a-0004n5-Ix for namedroppers@ops.ietf.org; Mon, 08 Dec 2003 18:25:32 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB8IPN2w088169; Mon, 8 Dec 2003 19:25:24 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB8IPM1S025336; Mon, 8 Dec 2003 19:25:23 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB8IPMr2025335; Mon, 8 Dec 2003 19:25:22 +0100 Date: Mon, 8 Dec 2003 19:25:22 +0100 From: Miek Gieben To: Scott Rose Cc: namedroppers Subject: Re: section 3.2 of protocol draft Message-ID: <20031208182522.GA25320@atoom.net> Mail-Followup-To: Scott Rose , namedroppers References: <20031208131059.GB20995@atoom.net> <012101c3bd97$10f0be30$b9370681@barnacle> <20031208144419.GA22600@atoom.net> <02aa01c3bdb3$52813160$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02aa01c3bdb3$52813160$b9370681@barnacle> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 08 Dec, @18:47, Scott wrote in "Re: section 3.2 of protocol dr ..."] > That seems reasonable. It might be a good idea to clarify that test > to take different cases into consideration. There is little danger in > adding previously cached RR sets into the additional section of another why is this dangerous? Isn't this the reason we have dnssec? If it is validated I can cache it, if I can cache it, I can use it? With DNS this could be potentially dangerous, with DNSSEC I cannot see why (if you only use validated reponses). > response - I haven't considered all the cases. Or narrowing the > restrictions to what (from cache) can and cannot > be placed in the answer section of a response. > > I believe it might be necessary to have stricter conditions on forming the > answer section of a response, but be more liberal about using cached RR sets > in the other sections. Which I believe your example demonstrated. ok, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 04:36:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19552 for ; Tue, 9 Dec 2003 04:36:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATeBH-000D3t-4j for namedroppers-data@psg.com; Tue, 09 Dec 2003 09:29:23 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATeB4-000D2v-2w for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 09:29:10 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 6480D4E760; Tue, 9 Dec 2003 10:29:09 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A783F4E3D0 for ; Tue, 9 Dec 2003 10:29:08 +0100 (CET) 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 hB99T8wp021204 for ; Tue, 9 Dec 2003 10:29:08 +0100 Date: Tue, 9 Dec 2003 10:29:08 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSSEC editors Question list Message-Id: <20031209102908.62c35c73.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.498305 X-RIPE-Signature: cf28518af2ea90edf0e2210964135703 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Update on the state of the DNSSECbis questions/issues list. All questions that where numbered are resolved. There are some open ended discussions on the list once these are resolved the document editors will roll the versions. We will probably do last call on those versions. Details of the questions and resolutions see below and http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02183.html Please send textual nits on the dnssec bis document set to the dnssec editors (dnssec-editors@east.isi.edu) and 'content' to this list. On a related note the records document and 'NSEC++' are intertwined. Please review 'NSEC++' too. The text in that document is intended to be cut-n-pasted into dnssecbis. -- Olaf DNSEXT co-chair ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC This is the list of open questions I posted recently. The following questions are now marked as resolved: > Q18: RRsig TTL violating 2181 > > Default action, based on sense of the room at IETF58, is to permit > the TTL of SIG RRs with same ownername and CLASS to be different and > to have the TTL of the SIG RRs bound to the TTL of the TYPE of the > RR they sign. Resolved: No comments on the list, default action taken as consensus. > Q19: Suppression of duplications > > This issue is about the canonicalization process by the signer and > the verifier. > > Duplicates are specifically forbidden. On the list there have been > several opinions with regards to how to deal with this issue. > > We propose the following text as consensus position: > > Duplicate RR records are not allowed exist according to > [RFC2181]. Implementations MUST therefore treat duplicate RR > records as protocol errors. Signers and verifiers MUST > canonicalize duplicate RR sets by removing duplicate RRs from > the set if the implementation is designed to be liberal in > handling protocol errors. Resolved: No comments on the list, default action taken as consensus. > Q20: Expansion of wild cards in the authority section. > > Default action, based on sense of the room at IETF58, is to not > expand the owner names of e.g. wildcard NSEC RRs. > > There was a little discussion on the list; a question that turned > into support. Resolved: Default action taken as consensus. > Q21: Caching and reuse of NSEC RRs > > Default action, based on sense of the room at IETF58, is to > change the text not to strongly prohibit any reuse of cached > NSEC RRs, but to allow, and not encourage, (MAY language) reuse > to synthesize negative answers for which QNAME, QLASS has an > NSEC RR of same ONAME and CLASS in cache that proves the non > existance of QTYPE. > Resolved: There is consensus on making this requirement less restrictive in the sense mentioned above. Note that there was an issue raised related to this question recently. (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02257.html) That question essentially asks to make the language with respect to cache behaviour even less restrictive. We'll treat this issue independently. > Q22: What should the failure mode be if compressed names are > encountered in RRs other than the "well-known" RRs; Should the > verifier be liberal or fail. (Remember compression is only > allowd for "well known RRs, RFC3597 section 4 and RFC1123) > > The sense of the room at IETF58 that senders should not send RRs > with compressed data and receivers should "not throw a fit". > > Since, in contrast to Q19, the canonicalization for the signer > and the verifier are specified (records section 6.2) so the > question is if the "robustness principle" should be specified at > all. > > If you think that there should be language to specify how to > apply the robustness principle for when RRs other than the "well > known" RRs are compressed than please supply text to go into one > of the DNSSECbis draft. > > Default action will be not to add recomendations about compression > and decompression before sending or after receiving. Resolved, no text was suppied, recomendations on compression and decompression will be added and taken as consensus of the group. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 04:45:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19761 for ; Tue, 9 Dec 2003 04:45:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATeM2-000ERi-8g for namedroppers-data@psg.com; Tue, 09 Dec 2003 09:40:30 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATeLp-000EOL-Pe for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 09:40:17 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB99eD2w092909; Tue, 9 Dec 2003 10:40:14 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB99eDbO003324; Tue, 9 Dec 2003 10:40:13 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hB99eCvK003323; Tue, 9 Dec 2003 10:40:12 +0100 Date: Tue, 9 Dec 2003 10:40:12 +0100 From: Miek Gieben To: Jim Reid Cc: namedroppers Subject: Re: section 3.2 of protocol draft Message-ID: <20031209094012.GA3177@atoom.net> Mail-Followup-To: Jim Reid , namedroppers References: <20031208131059.GB20995@atoom.net> <24031.1070896965@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24031.1070896965@gromit.rfc1035.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 08 Dec, @16:22, Jim wrote in "Re: section 3.2 of protocol dr ..."] > No, it doesn't say "don't use the cache". Well, not to this > mother-tongue English speaker anyway. It says "don't use cached data > to compose or fill out an answer to a query you've not resolved". I > think the intention here is to cover things like glue or partial > responses from an authoritative server. If the resolving server has > previously resolved and validated the glue or other stuff that might > be missing from the authoritative server's response, the resolving > server MUST NOT add these things to the reply it returns to its end > client. That's my interpretation of this bit of the draft. > > Perhaps the language could be made less opaque? Maybe the following is clearer: A security-aware recursive name server MUST NOT attempt to answer a query by piecing together non validated, cached data (i.e. glue) it received in response to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes. A security-aware recursive name server MUST NOT use NSEC RRs from one negative response to synthesize a response for a different query. A security-aware recursive name server MUST NOT use a previous wildcard expansion to generate a response to a different query. grtz Miek -- Serenity now! -- Frank Costanza (Seinfeld) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 07:29:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23879 for ; Tue, 9 Dec 2003 07:29:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATgu5-0007pm-Fx for namedroppers-data@psg.com; Tue, 09 Dec 2003 12:23:49 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATgts-0007nX-Te for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 12:23:37 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id hB9CNZQ1025819 for ; Tue, 9 Dec 2003 12:23:35 GMT To: namedroppers Subject: Re: section 3.2 of protocol draft In-Reply-To: Message from Miek Gieben of "Tue, 09 Dec 2003 10:40:12 +0100." <20031209094012.GA3177@atoom.net> Date: Tue, 09 Dec 2003 12:23:35 +0000 Message-ID: <25818.1070972615@gromit.rfc1035.com> From: Jim Reid X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Miek" == Miek Gieben writes: Miek> A security-aware recursive name server MUST NOT attempt to Miek> answer a query by piecing together non validated, cached Miek> data (i.e. glue) it received in response to previous queries Miek> that requested different QNAMEs, QTYPEs, or QCLASSes. Yes, it is clearer IMO. But I think the security aware server should do that for all cached data, not just non-validated data. Suppose the resolver gets a signed answer that says the next name after a.foo is z.foo. Is it right for the server to infer that no other names exist between a.foo and z.foo for as long it it caches that answer? If it then gets a lookup for b.foo, should it respond with the already cached answer or should it resolve b.foo and return the answer to that to the client? [Suppose the authoritative servers for foo add b.foo while the resolving server is still caching that NXT record for a.foo pointing at z.foo.] There are valid arguments that either of these options is correct (or wrong). A statement of what's the correct behaviour for this scenario would be preferable to leaving this undefined and ambiguous. How about the text below? A security-aware recursive name server MUST NOT synthesise or augment responses, for instance to populate the Additional Section, using cached data from earlier lookups. Cached data MUST NOT be used in a response unless it results from a response to an earlier query that exactly matches the QNAME, QTYPE and QCLASS for the current query. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 08:08:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24749 for ; Tue, 9 Dec 2003 08:08:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AThWU-000Ce7-9r for namedroppers-data@psg.com; Tue, 09 Dec 2003 13:03:30 +0000 Received: from [211.30.118.161] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AThWE-000Cd6-A3 for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 13:03:14 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hB9D383f041928; Wed, 10 Dec 2003 00:03:12 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200312091303.hB9D383f041928@drugs.dv.isc.org> To: Jim Reid , namedroppers From: Mark.Andrews@isc.org Mail-Followup-To: Jim Reid , namedroppers Subject: Re: section 3.2 of protocol draft In-reply-to: Your message of "Tue, 09 Dec 2003 10:40:12 BST." <20031209094012.GA3177@atoom.net> Date: Wed, 10 Dec 2003 00:03:08 +1100 X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [On 08 Dec, @16:22, Jim wrote in "Re: section 3.2 of protocol dr ..."] > > No, it doesn't say "don't use the cache". Well, not to this > > mother-tongue English speaker anyway. It says "don't use cached data > > to compose or fill out an answer to a query you've not resolved". I > > think the intention here is to cover things like glue or partial > > responses from an authoritative server. If the resolving server has > > previously resolved and validated the glue or other stuff that might > > be missing from the authoritative server's response, the resolving > > server MUST NOT add these things to the reply it returns to its end > > client. That's my interpretation of this bit of the draft. > > > > Perhaps the language could be made less opaque? > > Maybe the following is clearer: > > A security-aware recursive name server MUST NOT attempt to answer a query by > piecing together non validated, cached data (i.e. glue) it received in respon > se > to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes. A > security-aware recursive name server MUST NOT use NSEC RRs from one negative > response to synthesize a response for a different query. A security-aware > recursive name server MUST NOT use a previous wildcard expansion to generate > a > response to a different query. Why are we arguing over what it currently says? The current text is overly restrictive. We should be trying to determine firstly what we are going recommend that every server SHOULD do. What they MAY do, what the SHOULD NOT and MUST NOT do. At a minimum negative answers against the same QNAME and QCLASS need to be allowed again "Name Error" to bring the draft into alignment with RFC 2308. "Name Error" is independent of QTYPE. (SHOULD) Also at a minimum negative answers against the same QNAME and QCLASS need to be allowed against "NODATA". This is a extention on RFC 2308. The NSEC bitmap clearly allows a cache to determine which types do not exist when the query was made. All of these would return the same authority section. (SHOULD) Both of these cases allow a internally consistant negative answer to be returned. NXDOMAIN requires the two proofs to be returned * QNAME does not exist * Wildcard does not exist NODATA require one or two proofs to be returned depending apon whether the answer is from a wildcard or not. non-wildcard: * QNAME exists but does not have type wildcard: * QNAME does not exist * wildcard exist but does not have type What get more interesting is should we allow a cache to to take the knowledge that a previous positive answer came from a wildcard and just query for the wildcard. My feeling in this case is NO. You still need to make a query to the server so we don't save anything there. We would potentially save one proof (QNAME does not exist) in the answer, however you combining the two answers could give a internally inconsistant answer. (SHOULD NOT) Following a wildcard CNAME can also produce a internally inconsistant answer if the CNAME refers to the same zone. CNAME chains also have this problem if they go back to a previous zone. I suspect that we just have to live with this one. Another case mention at MN is where the QNAME and QCLASS matches a existing NSEC and the type is not in the bitmap however the NSEC was not learnt via the NSEC ownername. e.g. as one of the proofs in a NXDOMAIN or QNAME does not exist for a wildcard. I think this case can also safely be returned. (MAY) Next comes names that are within a span of a NSEC record. Theoretically it is possible to constuct a response from these provided you also have the answer to the corresponding wildcard (NXDOMAIN, NODATA and positive) answer. (SHOULD NOT, MUST NOT?) > grtz > Miek > -- > Serenity now! > -- Frank Costanza (Seinfeld) > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 10:24:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29986 for ; Tue, 9 Dec 2003 10:24:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATjZF-00020W-Gq for namedroppers-data@psg.com; Tue, 09 Dec 2003 15:14:29 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATjYm-0001xt-9z for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 15:14:00 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id A23F84FC6A; Tue, 9 Dec 2003 16:13:59 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 3FBEA4E479 for ; Tue, 9 Dec 2003 16:13:59 +0100 (CET) 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 hB9FDxwp032624 for ; Tue, 9 Dec 2003 16:13:59 +0100 Date: Tue, 9 Dec 2003 16:13:58 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: NSEC++ (Example code broken) Message-Id: <20031209161358.56fd591f.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.007587 X-RIPE-Signature: b70d843a44f5381fdafc238060441242 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit WRT: draft-ietf-ndsext-nsec-rdata-01. While testing some code; I think the example in section 3 should read: 0x04 'h' 'o' 's' 't' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00 0x00 0x07 0x40 0x01 0x00 0x00 0x00 0x03 0x00 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 Can somebody confirm that? -- Olaf namedropper. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 13:34:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06988 for ; Tue, 9 Dec 2003 13:34:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATmaI-0003BM-Du for namedroppers-data@psg.com; Tue, 09 Dec 2003 18:27:46 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATma5-00035P-S0 for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 18:27:33 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hB9IR018023187 for ; Tue, 9 Dec 2003 13:27:00 -0500 (EST) Message-ID: <00a601c3be82$0a1b40d0$b9370681@barnacle> From: "Scott Rose" To: References: <20031209161358.56fd591f.olaf@ripe.net> Subject: Re: NSEC++ (Example code broken) Date: Tue, 9 Dec 2003 13:27:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I thought it looked okay. I noticed the trailing 0x00 octet after the 0x03 in the example below. Isn't that a trailing null octet in the first window? Is that necessary? Scott ----- Original Message ----- From: "Olaf M. Kolkman" To: Sent: Tuesday, December 09, 2003 10:13 AM Subject: NSEC++ (Example code broken) > > WRT: draft-ietf-ndsext-nsec-rdata-01. > > While testing some code; I think the example in section 3 should read: > > 0x04 'h' 'o' 's' 't' > 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' > 0x03 'c' 'o' 'm' 0x00 > 0x00 0x07 0x40 0x01 0x00 0x00 0x00 0x03 > 0x00 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0x00 0x00 0x00 0x00 0x00 0x20 > > Can somebody confirm that? > > > -- Olaf > namedropper. > > ---------------------------------| Olaf M. Kolkman > ---------------------------------| RIPE NCC > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 15:49:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16151 for ; Tue, 9 Dec 2003 15:49:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATofO-000LqH-Si for namedroppers-data@psg.com; Tue, 09 Dec 2003 20:41:10 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATofC-000Low-7W for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 20:40:58 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 97D794E42C; Tue, 9 Dec 2003 21:40:57 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5E2B84E0D3; Tue, 9 Dec 2003 21:40:57 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hB9Kevwp005775; Tue, 9 Dec 2003 21:40:57 +0100 Message-Id: <200312092040.hB9Kevwp005775@birch.ripe.net> To: "Scott Rose" Cc: namedroppers@ops.ietf.org Subject: Re: NSEC++ (Example code broken) In-reply-to: Your message of Tue, 09 Dec 2003 13:27:01 EST. <00a601c3be82$0a1b40d0$b9370681@barnacle> References: <00a601c3be82$0a1b40d0$b9370681@barnacle> From: Olaf Kolkman X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Tue, 09 Dec 2003 21:40:57 +0100 X-RIPE-Spam-Status: N 0.000446 X-RIPE-Signature: 6576dd35893e8e197e41aef7b4c49dd6 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: * I thought it looked okay. I noticed the trailing 0x00 octet after the 0x03 * in the example below. Isn't that a trailing null octet in the first window? * Is that necessary? * No it is not... I do not understand why I did not catch that in the first place. Hex-diziness I am affraid. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 16:55:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18992 for ; Tue, 9 Dec 2003 16:55:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATpjk-0004UH-VP for namedroppers-data@psg.com; Tue, 09 Dec 2003 21:49:44 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATpjX-0004S9-3v for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 21:49:31 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hB9LnQ2w096914; Tue, 9 Dec 2003 22:49:27 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB9LnQbO014428; Tue, 9 Dec 2003 22:49:26 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hB9LnPGj014425; Tue, 9 Dec 2003 22:49:26 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 9 Dec 2003 22:49:25 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org cc: Jakob Schlyter Subject: Fingerprinting DNS implementations. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, Jakob and I spent the past few weeks hacking up a DNS implementation fingerprint tool (where implementation == anything responding to a query). This mail introduces the methodology of fingerprinting DNS implementations. A nameserver basically responds to a query. Inter-operability is an obvious requirement here, the standard protocol behaviour of different DNS implementations is expected to be the same. Protocol behaviour of a DNS implementation is widely documented in the case of a 'common' query. The DNS protocol is over 20 years old and since its inception, there have been over 40 independant DNS implementations, while some implementations have over 20 versions. The methodology used to identify individual nameserver implementations is based on "borderline" protocol behaviour. The DNS protocol offers a multitude of message bits, response types, opcodes, classes, query types and label types in a fashion that makes some mutually exclusive while some are not used in a query messages at all. Not every implementation offers the full set of features the DNS protocol set currently has. Some implementations offer features outside the protocol set, and there are implementations that do not comform to standards. Also, new features added to - or bugs removed allow for differentiations between versions of an implementation. Methodology We use a serie of "borderline" query-response messages to identify implementations. A serie of query-response messages form a sequence. We call the interpretation of these series to form a conclusion "DNS sequencing". As mentioned, responses to a "borderline" query is used in this method. To be somewhat efficient, a tree can be constructed which consists of queries (nodes) and responses (branches), where the leave nodes identify the implementation. Every path, from the root node (initial query) to a leave node (final query) is essentially a "strain". The strains are used to distinguish between, and as said, ultimatly identify implementations. Parallel to this technique it is possible to identify some brands and their versions by doing a specific query asking for the servers' version. This technique does not satisfy our requirement since this has not been implemented in all brands of nameservers (it is not part of any standard), operators may have obscured the information and there are implementations that try to resolve the query, essentially asking root-servers from a different class for their version. Implementation. Our current software is written as a proof-of-concept. In field tests, false positives were encountered when trying to identify a set of servers residing behind a load-balancing apparatus where the servers itself are of different implementations, or when a specific implementation behaves like a forwarder. We are actively looking for implementations not yet identified by this tool to complement the set of strains. The current set of strains identify the following implementations and their versions: ATLAS BIND 4 BIND 4.8 -- 4.8.3 BIND 4.9.3 -- 4.9.11 BIND 8 BIND 8.1 -- 8.2.1T4B BIND 8.2.1 BIND 8.2.2P3 -- 8.4.1 BIND 8.4.1P1 BIND 9 BIND 9.0.0b5 -- 9.0.1 BIND 9.1.0 -- 9.1.3 BIND 9.2.0a1 -- 9.2.0rc3 BIND 9.2.0rc4 -- 9.2.2P3 BIND 9.2.3rc1 -- 9.4.0a0 eNom DNS Incognito DNS Commander MARADNS Microsoft Windows Server 2003 Server 2000 Server NT4 MyDNS Nominum ANS Nominum CNS NonSequitur DNS NSD Oak DNS Pliant DNS Server Posadis PowerDNS 2.8 -- 2.9.3 2.9.4 -- 2.9.11 QuickDNS Simple DNS plus TinyDNS UltraDNS We are actively looking for volunteers who allow us to identify their running code in some form or configuration of some version of: chives custom-dns dents dnrd dnsmasq gnudip-www ibmdns jeeves lbdns lbnamed ldapdns MacDNS Microsoft Windows Server NT3.51 pdnsd Stanford::DNSserver yaku-ns and/or All other unidentified, unmentioned original code. Thanks, Roy Arends Jakob Schlyter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 17:46:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21437 for ; Tue, 9 Dec 2003 17:46:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATqY2-000AuF-A0 for namedroppers-data@psg.com; Tue, 09 Dec 2003 22:41:42 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATqXq-000AtD-1h for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 22:41:30 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA13491; Tue, 9 Dec 2003 17:37:44 -0500 Date: Tue, 9 Dec 2003 17:37:44 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: Roy Arends cc: namedroppers@ops.ietf.org, Jakob Schlyter Subject: Re: Fingerprinting DNS implementations. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm wondering why you are doing this. This sort of tool could be abused by crackers. I am particularly where is sounds like your are looking for fingerprints for vendors that have obscured their responses in order to prevent fingerprinting. DNS is a critical piece of infrastructure, and fingerprints allow the cracker to use the right attack the first time, without revealing their attack. --Dean On Tue, 9 Dec 2003, Roy Arends wrote: > Hi, > > Jakob and I spent the past few weeks hacking up a DNS implementation > fingerprint tool (where implementation == anything responding to a query). > This mail introduces the methodology of fingerprinting DNS > implementations. > > A nameserver basically responds to a query. Inter-operability is an > obvious requirement here, the standard protocol behaviour of different DNS > implementations is expected to be the same. > > Protocol behaviour of a DNS implementation is widely documented in the > case of a 'common' query. The DNS protocol is over 20 years old and since > its inception, there have been over 40 independant DNS implementations, > while some implementations have over 20 versions. > > The methodology used to identify individual nameserver implementations is > based on "borderline" protocol behaviour. The DNS protocol offers a > multitude of message bits, response types, opcodes, classes, query types > and label types in a fashion that makes some mutually exclusive while some > are not used in a query messages at all. Not every implementation offers > the full set of features the DNS protocol set currently has. Some > implementations offer features outside the protocol set, and there are > implementations that do not comform to standards. > > Also, new features added to - or bugs removed allow for differentiations > between versions of an implementation. > > Methodology > > We use a serie of "borderline" query-response messages to identify > implementations. A serie of query-response messages form a sequence. > We call the interpretation of these series to form a conclusion "DNS > sequencing". > > As mentioned, responses to a "borderline" query is used in this method. > To be somewhat efficient, a tree can be constructed which consists of > queries (nodes) and responses (branches), where the leave nodes identify > the implementation. > > Every path, from the root node (initial query) to a leave node (final > query) is essentially a "strain". The strains are used to distinguish > between, and as said, ultimatly identify implementations. > > Parallel to this technique it is possible to identify some brands and > their versions by doing a specific query asking for the servers' version. > This technique does not satisfy our requirement since this has not been > implemented in all brands of nameservers (it is not part of any standard), > operators may have obscured the information and there are implementations > that try to resolve the query, essentially asking root-servers from a > different class for their version. > > Implementation. > > Our current software is written as a proof-of-concept. In field tests, > false positives were encountered when trying to identify a set of servers > residing behind a load-balancing apparatus where the servers itself are of > different implementations, or when a specific implementation behaves like > a forwarder. > > We are actively looking for implementations not yet identified by this > tool to complement the set of strains. > > The current set of strains identify the following implementations > and their versions: > > ATLAS > BIND 4 > BIND 4.8 -- 4.8.3 > BIND 4.9.3 -- 4.9.11 > BIND 8 > BIND 8.1 -- 8.2.1T4B > BIND 8.2.1 > BIND 8.2.2P3 -- 8.4.1 > BIND 8.4.1P1 > BIND 9 > BIND 9.0.0b5 -- 9.0.1 > BIND 9.1.0 -- 9.1.3 > BIND 9.2.0a1 -- 9.2.0rc3 > BIND 9.2.0rc4 -- 9.2.2P3 > BIND 9.2.3rc1 -- 9.4.0a0 > eNom DNS > Incognito DNS Commander > MARADNS > Microsoft Windows > Server 2003 > Server 2000 > Server NT4 > MyDNS > Nominum ANS > Nominum CNS > NonSequitur DNS > NSD > Oak DNS > Pliant DNS Server > Posadis > PowerDNS > 2.8 -- 2.9.3 > 2.9.4 -- 2.9.11 > QuickDNS > Simple DNS plus > TinyDNS > UltraDNS > > We are actively looking for volunteers who allow us to identify their > running code in some form or configuration of some version of: > > chives > custom-dns > dents > dnrd > dnsmasq > gnudip-www > ibmdns > jeeves > lbdns > lbnamed > ldapdns > MacDNS > Microsoft Windows Server NT3.51 > pdnsd > Stanford::DNSserver > yaku-ns > > and/or > > All other unidentified, unmentioned original code. > > Thanks, > > Roy Arends > Jakob Schlyter > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 18:46:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24668 for ; Tue, 9 Dec 2003 18:46:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATrT1-000JDU-ST for namedroppers-data@psg.com; Tue, 09 Dec 2003 23:40:35 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATrSp-000JCI-60 for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 23:40:23 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id hB9NeEQ1026844; Tue, 9 Dec 2003 23:40:14 GMT To: Dean Anderson cc: Roy Arends , namedroppers@ops.ietf.org, Jakob Schlyter Subject: Re: Fingerprinting DNS implementations. In-Reply-To: Message from Dean Anderson of "Tue, 09 Dec 2003 17:37:44 EST." Date: Tue, 09 Dec 2003 23:40:13 +0000 Message-ID: <26843.1071013213@gromit.rfc1035.com> From: Jim Reid X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Dean" == Dean Anderson writes: Dean> I'm wondering why you are doing this. This sort of tool Dean> could be abused by crackers. So could many other tools. Like compilers. Do you want to ban them too? Dean> I am particularly where is sounds like your are looking for Dean> fingerprints for vendors that have obscured their responses Dean> in order to prevent fingerprinting. Well perhaps those vendors would then spend time fixing security bugs in their code instead of investing in futile efforts to conceal them? Dean> DNS is a critical piece of infrastructure, and fingerprints Dean> allow the cracker to use the right attack the first time, Dean> without revealing their attack. This presumes the crackers and script kiddies have that sort of finesse. If they've got a bunch of attacks to penetrate name servers, they'll more than likely try them all and go with the ones that succeed against their victims. And anyway, if an attack succeeds, it's too late. The damage has already been done. How the choice of attack was made -- if there was a selection! -- is irrelevant. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 18:58:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25100 for ; Tue, 9 Dec 2003 18:58:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATrhf-000M5J-VR for namedroppers-data@psg.com; Tue, 09 Dec 2003 23:55:43 +0000 Received: from [131.111.8.20] (helo=virgo.cus.cam.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATrhS-000M2B-Sp for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 23:55:31 +0000 Received: from cet1 by virgo.cus.cam.ac.uk with local (Exim 4.30) id 1ATrhS-0007TE-9H for namedroppers@ops.ietf.org; Tue, 09 Dec 2003 23:55:30 +0000 Subject: Re: Fingerprinting DNS implementations. To: namedroppers@ops.ietf.org Date: Tue, 9 Dec 2003 23:55:30 +0000 (GMT) In-Reply-To: from "Dean Anderson" at Dec 9, 3 05:37:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dean Anderson writes > I'm wondering why you are doing this. I'm not. I'm wondering why he thinks this is a DNS protocols issue rather than a DNS operations one. Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 9 20:21:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27580 for ; Tue, 9 Dec 2003 20:21:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATstH-0005cN-9p for namedroppers-data@psg.com; Wed, 10 Dec 2003 01:11:47 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATst4-0005Yy-KT for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 01:11:34 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id UAA02473; Tue, 9 Dec 2003 20:08:06 -0500 Date: Tue, 9 Dec 2003 20:08:05 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: Jim Reid cc: Roy Arends , , Jakob Schlyter Subject: Re: Fingerprinting DNS implementations. In-Reply-To: <26843.1071013213@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 9 Dec 2003, Jim Reid wrote: > >>>>> "Dean" == Dean Anderson writes: > > Dean> I'm wondering why you are doing this. This sort of tool > Dean> could be abused by crackers. > > So could many other tools. Like compilers. Do you want to ban them too? Compilers are indispensable. Fingerprinting is not (I think) indispensable. > Dean> I am particularly where is sounds like your are looking for > Dean> fingerprints for vendors that have obscured their responses > Dean> in order to prevent fingerprinting. > > Well perhaps those vendors would then spend time fixing security bugs > in their code instead of investing in futile efforts to conceal them? Much easier said than done. Wait. Clancy! Fire the security bug developers. > Dean> DNS is a critical piece of infrastructure, and fingerprints > Dean> allow the cracker to use the right attack the first time, > Dean> without revealing their attack. > > This presumes the crackers and script kiddies have that sort of > finesse. If they've got a bunch of attacks to penetrate name servers, > they'll more than likely try them all and go with the ones that > succeed against their victims. Well, now they can have that finesse, without even learning about DNS. > And anyway, if an attack succeeds, it's too late. The damage has already > been done. How the choice of attack was made -- if there was a > selection! -- is irrelevant. No, actually, it isn't. The slightest irregularity can trigger discovery. The Debian crack was discovered because of an unexpected kernel Oops. If they crackers had used better fingerprinting, they would have gotten in undetected, and much more damage would have been done. As it was, they got in, but because of their lack of accurate fingerprinting, they were detected (after the fact) but before they could cause great damage. I guess we can't really prevent crackers from getting fingerprinting, if they want to, but it seems smart people are making it easier than it has to be. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 09:28:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12819 for ; Wed, 10 Dec 2003 09:28:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU5CE-0009I3-LV for namedroppers-data@psg.com; Wed, 10 Dec 2003 14:20:10 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU5C1-0009GS-ML for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 14:19:57 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hBAEJm2w008776; Wed, 10 Dec 2003 15:19:51 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hBAEJmGY029283; Wed, 10 Dec 2003 15:19:48 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hBAEJjUT029280; Wed, 10 Dec 2003 15:19:47 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 10 Dec 2003 15:19:45 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Dean Anderson cc: namedroppers@ops.ietf.org, Jakob Schlyter Subject: Re: Fingerprinting DNS implementations. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 9 Dec 2003, Dean Anderson wrote: > I'm wondering why you are doing this. I want to know how the DNS landscape looks like. A popularity contest. Especially if the wg decides to clarify parts of the standards, or standardise additions, I'd like to know the impact on the landscape, therefor I need to know what it looks like. Oh, and for fun as well. > This sort of tool could be abused by crackers. The tool does not discriminate on intend or mindset. > I am particularly where is sounds like your are looking for fingerprints > for vendors that have obscured their responses in order to prevent > fingerprinting. The tool does not discriminate in that area neither. Both implementations that scream their version, including authors, and implementations that do not can be identified. Vendors do not obscure responses. How do you obscure responses ? Create but not send ? Response-Sensorship ? Instead of 'fingerprinting', would you like me to call it 'protocol conformity, indexed by implementation' ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 09:51:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13812 for ; Wed, 10 Dec 2003 09:51:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU5b8-000CsQ-9x for namedroppers-data@psg.com; Wed, 10 Dec 2003 14:45:54 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU5aw-000Co8-62 for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 14:45:42 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hBAEjc2w010215 for ; Wed, 10 Dec 2003 15:45:38 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hBAEjbGY029694 for ; Wed, 10 Dec 2003 15:45:37 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hBAEjb9Z029693 for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 15:45:37 +0100 Date: Wed, 10 Dec 2003 15:45:37 +0100 From: Miek Gieben To: namedroppers Subject: nsec-01, bit 0 Message-ID: <20031210144537.GA29608@atoom.net> Mail-Followup-To: namedroppers Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Bit 0 in the first bitmap in the first window does not encode for any=20 RR. Shouldn't this bit get a status of reserved in the draft? Or doesn't it matter if it's 1 or 0. grtz Miek -- fingerprint =3D E1EB 29B8 8FA2 2923 62B8 0A2B 64B8 F15C 7764 AB4B http://miek.nl/about.html --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/1zGRZLjxXHdkq0sRArA+AJ4kxuLvD3oUwfunVndckOhuqYPqZQCfZ2uQ sC0kCAEYmQb9aQepM/grSq4= =oACr -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 10:08:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15011 for ; Wed, 10 Dec 2003 10:08:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU5sR-000Fac-Tk for namedroppers-data@psg.com; Wed, 10 Dec 2003 15:03:47 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU5sG-000FZs-01 for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 15:03:36 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 60AD54E651; Wed, 10 Dec 2003 16:03:35 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 2F6BD4E61F for ; Wed, 10 Dec 2003 16:03:35 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hBAF3Zwp017642 for ; Wed, 10 Dec 2003 16:03:35 +0100 Message-Id: <200312101503.hBAF3Zwp017642@birch.ripe.net> To: namedroppers Subject: Re: nsec-01, bit 0 In-Reply-To: Message from Miek Gieben of "Wed, 10 Dec 2003 15:45:37 +0100." <20031210144537.GA29608@atoom.net> Date: Wed, 10 Dec 2003 16:03:35 +0100 From: Olaf Kolkman X-RIPE-Spam-Status: N 0.141243 X-RIPE-Signature: 69837d2fecf80db8ec56bfd5ecce0781 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Bit 0 in the first bitmap in the first window does not encode for any=20 * RR. Shouldn't this bit get a status of reserved in the draft? Or doesn't * it matter if it's 1 or 0. This is "Silly State" again :-) (that issue is closed) See http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01851.html --Olaf DNSEXT Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 10:24:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16407 for ; Wed, 10 Dec 2003 10:24:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU65m-000HOJ-Bn for namedroppers-data@psg.com; Wed, 10 Dec 2003 15:17:34 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU65a-000HNu-LR for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 15:17:22 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hBAFHI2w019695; Wed, 10 Dec 2003 16:17:19 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hBAFHEGY030274; Wed, 10 Dec 2003 16:17:14 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hBAFHEfM030273; Wed, 10 Dec 2003 16:17:14 +0100 Date: Wed, 10 Dec 2003 16:17:14 +0100 From: Miek Gieben To: Olaf Kolkman Cc: namedroppers Subject: Re: nsec-01, bit 0 Message-ID: <20031210151714.GA30233@atoom.net> Mail-Followup-To: Olaf Kolkman , namedroppers References: <20031210144537.GA29608@atoom.net> <200312101503.hBAF3Zwp017642@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312101503.hBAF3Zwp017642@birch.ripe.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 10 Dec, @16:03, Olaf wrote in "Re: nsec-01, bit 0 ..."] > > * Bit 0 in the first bitmap in the first window does not encode for any=20 > * RR. Shouldn't this bit get a status of reserved in the draft? Or doesn't > * it matter if it's 1 or 0. > > > This is "Silly State" again :-) (that issue is closed) ah, *duh* grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 10:26:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16495 for ; Wed, 10 Dec 2003 10:26:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU69P-000HtF-I7 for namedroppers-data@psg.com; Wed, 10 Dec 2003 15:21:19 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU69D-000Hsk-MA for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 15:21:07 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hBAFL42w021897; Wed, 10 Dec 2003 16:21:04 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hBAFL3GY030423; Wed, 10 Dec 2003 16:21:03 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hBAFL3rg030420; Wed, 10 Dec 2003 16:21:03 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 10 Dec 2003 16:21:03 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Olaf Kolkman cc: namedroppers Subject: Re: nsec-01, bit 0 In-Reply-To: <200312101503.hBAF3Zwp017642@birch.ripe.net> Message-ID: References: <200312101503.hBAF3Zwp017642@birch.ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 10 Dec 2003, Olaf Kolkman wrote: > > * Bit 0 in the first bitmap in the first window does not encode for any=20 > * RR. Shouldn't this bit get a status of reserved in the draft? Or doesn't > * it matter if it's 1 or 0. > > > This is "Silly State" again :-) (that issue is closed) > > See > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01851.html Nope, Nothing to do with that. In NXT bit 0 was reserved FFU, that future use is no more. Semantically, it would refer to TYPE 0, which is 'an illegal type' according to 2535. The nsec-01 needs to state something about it. (Bit 0 MUST be clear, clear on send, ignore on receive) Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 10:47:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17474 for ; Wed, 10 Dec 2003 10:47:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU6Tx-000Kux-3g for namedroppers-data@psg.com; Wed, 10 Dec 2003 15:42:33 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU6Tl-000KuE-AP for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 15:42:21 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id B01064E71F; Wed, 10 Dec 2003 16:42:20 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 812734E61F; Wed, 10 Dec 2003 16:42:20 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hBAFgJwp029579; Wed, 10 Dec 2003 16:42:19 +0100 Message-Id: <200312101542.hBAFgJwp029579@birch.ripe.net> To: Roy Arends Cc: Olaf Kolkman , namedroppers Subject: Re: nsec-01, bit 0 In-Reply-To: Message from Roy Arends of "Wed, 10 Dec 2003 16:21:03 +0100." Date: Wed, 10 Dec 2003 16:42:19 +0100 From: Olaf Kolkman X-RIPE-Spam-Status: N 0.025824 X-RIPE-Signature: 8150fccf99d16519311156bc3446b6b4 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * * Nope, * (...) * The nsec-01 needs to state something about it. (Bit 0 MUST be clear, clear * on send, ignore on receive) You are correct ("Te kort door de bocht" we say in Dutch). I like the suggested text. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 14:04:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09838 for ; Wed, 10 Dec 2003 14:04:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU9WH-0002TT-Kz for namedroppers-data@psg.com; Wed, 10 Dec 2003 18:57:09 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU9W3-0002Ij-1p for namedroppers@ops.ietf.org; Wed, 10 Dec 2003 18:56:55 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id NAA29558; Wed, 10 Dec 2003 13:53:38 -0500 Date: Wed, 10 Dec 2003 13:53:38 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: Roy Arends cc: namedroppers@ops.ietf.org, Jakob Schlyter Subject: Re: Fingerprinting DNS implementations. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 10 Dec 2003, Roy Arends wrote: > Vendors do not obscure responses. How do you obscure responses ? Create > but not send ? Response-Sensorship ? Nmap fingerprints OS's by TCP signatures, using much the same methods as you described, in principle anyway. There are tools for linux and I think *BSD that will alter the responses so that this fingerprinting fails to identify the true OS. This could get into a sort of war of fingerprinting and obscuring changes, which would seem to be destructive... --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 21:16:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01015 for ; Wed, 10 Dec 2003 21:16:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUGDI-000Pso-3Q for namedroppers-data@psg.com; Thu, 11 Dec 2003 02:06:00 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUGCy-000Ps5-FQ for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 02:05:40 +0000 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 2C9FF1B2284; Wed, 10 Dec 2003 20:05:04 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <83DFCC5E-2B7E-11D8-BAC0-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: Roy Arends , namedroppers@ops.ietf.org, Jakob Schlyter From: Ted Lemon Subject: Re: Fingerprinting DNS implementations. Date: Wed, 10 Dec 2003 20:05:38 -0600 To: Dean Anderson X-Mailer: Apple Mail (2.609) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Dec 10, 2003, at 12:53 PM, Dean Anderson wrote: > This could get into a sort of war of fingerprinting and obscuring > changes, > which would seem to be destructive... Or, it could turn into a war of bug fixing, which would be constructive, and would motivate people to move to less buggy versions of their name server software. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 10 23:15:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04192 for ; Wed, 10 Dec 2003 23:15:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUI6D-0006Tm-52 for namedroppers-data@psg.com; Thu, 11 Dec 2003 04:06:49 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUI5s-0006T5-OT for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 04:06:28 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id XAA10264; Wed, 10 Dec 2003 23:00:21 -0500 Date: Wed, 10 Dec 2003 23:00:21 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: Ted Lemon cc: Roy Arends , , Jakob Schlyter Subject: Re: Fingerprinting DNS implementations. In-Reply-To: <83DFCC5E-2B7E-11D8-BAC0-000A95D9C74C@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 10 Dec 2003, Ted Lemon wrote: > On Dec 10, 2003, at 12:53 PM, Dean Anderson wrote: > > This could get into a sort of war of fingerprinting and obscuring > > changes, > > which would seem to be destructive... > > Or, it could turn into a war of bug fixing, which would be constructive, > and would motivate people to move to less buggy versions of their name > server software. I'm Doubtful. The (linux) fingerprint changes seem (to me anyway--not an expert on the exact changes), gratuitous changes that aren't expected to actually break anything. This is a far cry from fixing bugs. Its just busy work created by the need for a response to fingerprinting. Its also not usaully done in the mainline, but as optional changes, basically making it seem like there are more versions then there are. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 11 03:42:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22384 for ; Thu, 11 Dec 2003 03:42:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUMHn-0003JY-VC for namedroppers-data@psg.com; Thu, 11 Dec 2003 08:35:03 +0000 Received: from [212.214.16.11] (helo=info.dimension.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUMHa-0003I2-SK for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 08:34:51 +0000 Received: from dimension.se ([127.0.0.1]) by info.dimension.se (Netscape Messaging Server 4.15) with ESMTP id HPQ2I000.KUV; Thu, 11 Dec 2003 09:34:48 +0100 Message-ID: <3FD82C27.2050203@dimension.se> Date: Thu, 11 Dec 2003 09:34:47 +0100 From: "Mathias Samuelson" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031119 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lemon CC: Dean Anderson , Roy Arends , namedroppers@ops.ietf.org, Jakob Schlyter Subject: Re: Fingerprinting DNS implementations. References: <83DFCC5E-2B7E-11D8-BAC0-000A95D9C74C@nominum.com> In-Reply-To: <83DFCC5E-2B7E-11D8-BAC0-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Or, it could turn into a war of bug fixing, which would be constructive, > and would motivate people to move to less buggy versions of their name > server software. Just my $0.02. It's, as you all know, surprisingly often the case that the network operators aren't even aware of what version of software they are running. I've heard some people argue that they shouldn't run anything else than whatever version of BIND Sun bundles with Solaris, no matter how many vulnerabilities there's in that software. Obscuring the fact that one is running such software doesn't seem to be a good security measure anyway. So, for what it's worth, I agree with those who are pro what Dean and Jakob is doing. All best Mathias -- Mathias Samuelson Phone: +46 (0)8 5058 3111 Dimension AB You can fetch my GnuPG key (CB6D9D85) with fingerprint B98BB34ADAA91D4F2F47E6363EC2C8BDCB6D9D85 from (e.g.) blackhole.pca.dfn.de. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 11 04:06:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22888 for ; Thu, 11 Dec 2003 04:06:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUMhL-000BzD-2h for namedroppers-data@psg.com; Thu, 11 Dec 2003 09:01:27 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUMh9-000BwT-6z for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 09:01:15 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 954F24EC7A; Thu, 11 Dec 2003 10:01:14 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 66AFB4EC6F for ; Thu, 11 Dec 2003 10:01:14 +0100 (CET) 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 hBB91Ewp022390 for ; Thu, 11 Dec 2003 10:01:14 +0100 Date: Thu, 11 Dec 2003 10:01:13 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Fingerprinting DNS implementations. Message-Id: <20031211100113.7606a672.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.010959 X-RIPE-Signature: 142d25df13f4e80e906c7493f92b5187 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Can we please move the discussion on operational impact of this tool elsewhere; that discussion is clearly off-topic for this list. -- Olaf DNSEXT Co-Chair. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 11 07:10:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26770 for ; Thu, 11 Dec 2003 07:10:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUPYs-000HNf-3e for namedroppers-data@psg.com; Thu, 11 Dec 2003 12:04:54 +0000 Received: from [207.8.214.2] (helo=icicle.pobox.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUPYg-000HMd-77 for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 12:04:42 +0000 Received: from colander (localhost[127.0.0.1]) by icicle.pobox.com (Postfix) with ESMTP id A5BC7A34C2 for ; Thu, 11 Dec 2003 07:04:41 -0500 (EST) Received: from texas.pobox.com (texas.pobox.com[64.49.223.111]) by icicle.pobox.com (Postfix) with ESMTP for ; Thu, 11 Dec 2003 07:04:41 -0500 (EST) Received: from budney.homeunix.net (pool-68-162-176-181.pitt.east.verizon.net [68.162.176.181]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by texas.pobox.com (Postfix) with ESMTP id 92312453A8 for ; Thu, 11 Dec 2003 07:04:39 -0500 (EST) Date: Thu, 11 Dec 2003 07:04:47 -0500 (EST) From: lbudney@pobox.com X-X-Sender: budney@budney.homeunix.net To: "namedroppers@ops.ietf.org" Subject: Re: Fingerprinting DNS implementations. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: * X-Spam-Status: No, hits=1.1 required=5.0 tests=BAYES_01,NO_REAL_NAME, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL,RCVD_IN_SORBS,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 10 Dec 2003, Dean Anderson wrote: > > The (linux) fingerprint changes...Its just busy work created by the need > for a response to fingerprinting. It's just busywork, full stop. There is no "need for a response to fingerprinting". --Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 11 10:31:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06505 for ; Thu, 11 Dec 2003 10:31:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUSd0-000D48-5K for namedroppers-data@psg.com; Thu, 11 Dec 2003 15:21:22 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUScm-000D3B-Jc for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 15:21:08 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D7D964E68D; Thu, 11 Dec 2003 16:21:07 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 9D22D4E677 for ; Thu, 11 Dec 2003 16:21:07 +0100 (CET) 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 hBBFL7wp023568 for ; Thu, 11 Dec 2003 16:21:07 +0100 Date: Thu, 11 Dec 2003 16:21:07 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: nsec++ Message-Id: <20031211162107.513534eb.olaf@ripe.net> In-Reply-To: References: <45E39EE2E44FD443AEFAC07728BF3B5054B026@uk-ismsg02.altera.priv.altera.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.214945 X-RIPE-Signature: ee5033924067c0fce56db9dd3c75d54e X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul wrote: > let's not do this: let leadership mean deciding what (not) to discuss. Well eh... leadership... who me ? ;-) Given that I have not seen major support on the list in favour of 'more compression', few people worried about additional comlexity and we really need to get this done I propose to keep the document with the specification as is and go for last call early next week. If you have editorial issues please mail them to Jakob ASAP, maybe we can do another document roll. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 11 14:26:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15846 for ; Thu, 11 Dec 2003 14:26:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUWJZ-000FBr-F3 for namedroppers-data@psg.com; Thu, 11 Dec 2003 19:17:33 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUWJ3-000F7Z-QK for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 19:17:01 +0000 Received: from [130.105.36.66] ([130.105.36.66]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id OAA19045; Thu, 11 Dec 2003 14:12:44 -0500 Date: Thu, 11 Dec 2003 14:12:45 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus To: Mathias Samuelson cc: Ted Lemon , Roy Arends , , Jakob Schlyter Subject: Re: Fingerprinting DNS implementations. In-Reply-To: <3FD82C27.2050203@dimension.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY,RCVD_IN_SORBS,RCVD_IN_SORBS_ZOMBIE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 11 Dec 2003, Mathias Samuelson wrote: > I've heard some people argue that they shouldn't run > anything else than whatever version of BIND Sun bundles with Solaris, no > matter how many vulnerabilities there's in that software. Sun (like most vendors) won't provide software support if you aren't running what they bundled. But they do provide their own updates. You have to take those updates. But I don't run Bind at all for security reasons. > Obscuring the fact that one is running such software doesn't seem to be > a good security measure anyway. Certainly, in the more mature area of OS fingerprinting, quite a lot of people disagree. Hiding this kind of information is the first thing security consultants recommend. Security by obscurity is a valid and effective form of security. Call a bank, and ask them what kind of alarm system they have. Even the manuals for Airport security systems are restricted. This is security by obsurity. Everything has weaknesses. Every software has an exploit. Thinking otherwise is unrealistic. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 11 15:18:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20137 for ; Thu, 11 Dec 2003 15:18:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUX2G-000LEG-1S for namedroppers-data@psg.com; Thu, 11 Dec 2003 20:03:44 +0000 Received: from [209.102.208.18] (helo=altair.ipal.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUX23-000LDB-3l for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 20:03:31 +0000 Received: by altair.ipal.net (Postfix, from userid 600) id 7E28D7C1; Thu, 11 Dec 2003 14:03:24 -0600 (CST) Date: Thu, 11 Dec 2003 14:03:23 -0600 From: Phil Howard To: namedroppers@ops.ietf.org Subject: Re: Fingerprinting DNS implementations. Message-ID: <20031211200323.GA2287@altair.ipal.net> References: <20031211100113.7606a672.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031211100113.7606a672.olaf@ripe.net> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Dec 11, 2003 at 10:01:13AM +0100, Olaf M. Kolkman wrote: | Can we please move the discussion on operational impact of this tool | elsewhere; that discussion is clearly off-topic for this list. | | | -- Olaf | DNSEXT Co-Chair. Right. It shouldn't be here. Can someone suggest a software-neutral mailing list or other forum for DNS server operational discussions? -- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | ----------------------------------------------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 11 15:40:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21952 for ; Thu, 11 Dec 2003 15:40:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUXUX-000Oi0-Qd for namedroppers-data@psg.com; Thu, 11 Dec 2003 20:32:57 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AUXUH-000Oge-BR for namedroppers@ops.ietf.org; Thu, 11 Dec 2003 20:32:41 +0000 Received: (qmail 31218 invoked by uid 1016); 11 Dec 2003 20:32:55 -0000 Date: 11 Dec 2003 20:32:55 -0000 Message-ID: <20031211203255.31217.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Fingerprinting DNS implementations. References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I posted fingerprint data a year ago: http://cr.yp.to/surveys/dns1.html Chris Thompson writes: > I'm wondering why he thinks this is a DNS protocols issue > rather than a DNS operations one. The IETF often creates interoperability problems by extending protocols in a way that breaks existing software. Today's ``borderline'' packets could be tomorrow's protocol extensions; it's important to document how those packets are handled. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 11 19:18:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04488 for ; Thu, 11 Dec 2003 19:18:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUauw-000Pjp-Cc for namedroppers-data@psg.com; Fri, 12 Dec 2003 00:12:26 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUauj-000PjK-Om for namedroppers@ops.ietf.org; Fri, 12 Dec 2003 00:12:14 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id hBC0C9Q1001452; Fri, 12 Dec 2003 00:12:09 GMT To: Phil Howard cc: namedroppers@ops.ietf.org Subject: Re: Fingerprinting DNS implementations. In-Reply-To: Message from Phil Howard of "Thu, 11 Dec 2003 14:03:23 CST." <20031211200323.GA2287@altair.ipal.net> Date: Fri, 12 Dec 2003 00:12:09 +0000 Message-ID: <1451.1071187929@gromit.rfc1035.com> From: Jim Reid X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Phil" == Phil Howard writes: Phil> Can someone suggest a software-neutral mailing list or other Phil> forum for DNS server operational discussions? The IETF dnsop WG's mailing list would be an obvious choice. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 15 04:34:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01126 for ; Mon, 15 Dec 2003 04:34:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AVotx-000Lnp-O2 for namedroppers-data@psg.com; Mon, 15 Dec 2003 09:20:29 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AVotl-000LnI-8d for namedroppers@ops.ietf.org; Mon, 15 Dec 2003 09:20:17 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 992DA4EDA1; Mon, 15 Dec 2003 10:20:16 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 63A6D4EDC2 for ; Mon, 15 Dec 2003 10:20:16 +0100 (CET) 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 hBF9KGwp013583 for ; Mon, 15 Dec 2003 10:20:16 +0100 Date: Mon, 15 Dec 2003 10:20:16 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Q22: mistake made. Message-Id: <20031215102016.2b7acf10.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.028860 X-RIPE-Signature: 51f67b77638d688e783abb80d11739fc X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In both http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02181.html http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02183.html I wrote: > Default action will be not to add recomendations about compression > and decompression before sending or after receiving. In the wrapup http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02263.html I wrote: > Resolved, no text was suppied, recomendations on compression and > decompression will be added and taken as consensus of the group. I missed the negation in that sentence. As a logical concequence of the process followed it should have read: > Resolved, no text was suppied. The concensus of the group is that > text with recomendations on compression and decompression will not be > added. Sorry for the confusion. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 15 13:38:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19568 for ; Mon, 15 Dec 2003 13:38:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AVxU4-000FAH-Qx for namedroppers-data@psg.com; Mon, 15 Dec 2003 18:30:20 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AVxTp-000F8Q-F9 for namedroppers@ops.ietf.org; Mon, 15 Dec 2003 18:30:05 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2003 10:32:54 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBFIU3BN020943 for ; Mon, 15 Dec 2003 10:30:03 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-232.cisco.com [10.82.240.232]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AER18275; Mon, 15 Dec 2003 13:30:01 -0500 (EST) Message-Id: <4.3.2.7.2.20031215114705.01ffbe28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Dec 2003 13:29:59 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: LLMNR Issue 52: LLMNR-25 review (Ralph Droms) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk See "RD>" for my comments on the responses to issue 52. - Ralph [BA] 1. LLMNR does indeed use the same packet format as DNS for both requests and responses. This should be clarified. RD> OK; changes below look OK. 2. Names are used in LLMNR the same way that they are used in DNS, and have the same structure. The matching rules are also identical, including use of wildcards. RD> Practically speaking, because of text in section 2.2 like: Responders MUST NOT respond to LLMNR queries for names they are not authoritative for. I think the LLMNR names could be characterized as simple character strings, and that LLMNR name comparisons could be characterized as a simple equality check (with application of DNS case-folding rules). LLMNR also does not change how hosts determine their names or how they handle DHCP options 12 and 15. Some hosts accept DHCP assignment of names, others do not. RD> I wasn't thinking so much of DHCP specifically, I just used the DHCP options as examples of how a host might be configured with various names that would be used in the synthesis of LLMNR names. In terms of the examples, it is not possible to encode a query for "foo" or "foo.example.com" or "foo.example" using the DNS packet format; only queries for "foo.", "foo.example.com." or "foo.example." are possible. An LLMNR responder will only respond to a query if it is authoritative for that name. Whether the responder is configured to respond to queries for "foo." or "foo.example.com." is implementation dependent. RD> OK, so before I read your response to issue 56, I wrote the following text as a suggestion for a new section to be added to section 2. The idea is to give a clear example of what RRs an LLMNR responder might own, and where those RRs might be synthesized from. 2.1 Resource record model and naming Each LLMNR responder conceptually maintains a set of records for which it is authoritative in response to LLMNR queries. These records are similar to 'nodes', as defined in DNS (RFC 1034). Each record has a name that acts as a key for the record, and owns one or more resource records (RRs). The RRs are typed like DNS RRs. The records for which an LLMNR is authoritative may be constructed from information configured in the responder, or may be explicitly configured. For example, a Windows 2000 host configured through the "System Properties" control panel to have computer name "host1" and to be a member of the "example.com" domain, and with IPv4 address 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: host1. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 host1.example.com. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 1.1.1.10.in-addr.arpa. IN PTR host1. IN PTR host1.example.com. 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.inv6.arpa IN PTR host1. IN PTR host1.example.com An LLMNR responder might be further manually configured with the name of a local mail server with an MX RR included in the "host1" and "host1.example.com" records. An LLMNR responder is only authoritative for records that are directly related to the responder itself. Names in LLMNR are treated as a character string, with no internal structure. Thus, the LLMNR name host1 is completely unrelated to host1.example.com. Comparisons between LLMNR names are simple equality tests, with case-folding according to the rules in DNS (RFC ???). 3. The term "authoritative" is used to refer to whether a host responds to a query for a name. The term "owned" is used to refer to whether an RR is present on the responder. These are different things, so the same term cannot be used. The term "has" is used synonymously with "owned" and so the term "owned" can be substituted to improve clarity. RD> Thanks for the clarification... Proposed fixes: RD> The fixes all look OK, except where noted... In Section 1, change: "This document discusses Link Local Multicast Name Resolution (LLMNR), which operates on a separate port from the Domain Name System (DNS), with a distinct resolver cache, but does not change the format of DNS packets. LLMNR supports all current and future DNS formats, types and classes." To: "This document discusses Link Local Multicast Name Resolution (LLMNR), which utilizes the DNS packet format for both requests and responses, and supports all current and future DNS formats, types and classes. LLMNR operates on a separate port from the Domain Name System (DNS), with a distinct resolver cache." Add to Section 2: "This document does not specify how names are chosen or configured. This may occur via any mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]." RD> Perhaps also mention local synthesis and explicit configuration? "including synthesis from local configuration information such as the host name and default domain, configuration information obtained through DHCPv4 [RFC2131} or DHCPv6 [RFC3315], or explicit manual configuration." Add to Section 2.1: "An LLMNR query is composed in exactly the same manner and with the same packet format as a DNS query as specified in [RFC1035]." Add to Section 2.2: "A response to an LLMNR query is composed in exactly the same manner and with the same packet format as a response to a DNS query as specified in [RFC1035]." Throughout the document: Change "has" to "owns" where the term refers to RRs. Add the following definition to the terminology section: "Owner A host is said to be the owner of a Resource Record (RR) if it is configured to respond to an LLMNR query for that RR." Proposed resolution: Accept -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 15 15:10:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24436 for ; Mon, 15 Dec 2003 15:10:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AVyul-000OOH-SH for namedroppers-data@psg.com; Mon, 15 Dec 2003 20:01:59 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AVyuZ-000OMy-Uo for namedroppers@ops.ietf.org; Mon, 15 Dec 2003 20:01:47 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBFK1gZ2016934 for ; Mon, 15 Dec 2003 12:01:46 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-232.cisco.com [10.82.240.232]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AER28261; Mon, 15 Dec 2003 15:01:41 -0500 (EST) Message-Id: <4.3.2.7.2.20031215150031.00b66b58@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Dec 2003 15:01:38 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: LLMNR Issue 52: Miscellaneous NITs (Part 1) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I agree with all of the fixes made in response to issues 53. There doesn't seem to be an explicit response or change to this comment in issue 53: Section 4, fifth paragraph: I think the host should perform the uniqueness test when the interface is connected to a link (in addition to the other events in the bullet list). - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 15 15:32:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26414 for ; Mon, 15 Dec 2003 15:32:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AVzKl-0000lo-1B for namedroppers-data@psg.com; Mon, 15 Dec 2003 20:28:51 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AVzKY-0000ke-IM for namedroppers@ops.ietf.org; Mon, 15 Dec 2003 20:28:38 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25907; Mon, 15 Dec 2003 15:28:36 -0500 (EST) Message-Id: <200312152028.PAA25907@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-26.txt Date: Mon, 15 Dec 2003 15:28:35 -0500 X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-26.txt Pages : 23 Date : 2003-12-15 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-26.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-26.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-26.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-15150205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-26.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-26.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-15150205.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 15 16:14:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00179 for ; Mon, 15 Dec 2003 16:14:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AVzx1-0005K0-IV for namedroppers-data@psg.com; Mon, 15 Dec 2003 21:08:23 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AVzwZ-0005Hs-2C for namedroppers@ops.ietf.org; Mon, 15 Dec 2003 21:07:55 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Dec 2003 13:11:05 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBFL7qAt011552 for ; Mon, 15 Dec 2003 13:07:53 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-685.cisco.com [10.82.242.173]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AER34932; Mon, 15 Dec 2003 16:07:51 -0500 (EST) Message-Id: <4.3.2.7.2.20031215160153.01ffbe28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Dec 2003 16:07:48 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: LLMNR Issue 56: Miscellaneous NITs (Part 2) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm OK with all of the responses except the changes to section 2.6 (noting that the comments about names, RRs and host configuration was also addresses in issue 52). I'm still not clear about the retransmission strategy described in section 2.6. Does this text describe it correctly? 2.6 Retransmission, collection of responses and transmission jitter An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine when to retransmit an LLMNR query and how long to collect responses to an LLMNR query. If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Because an LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT for each transmission. It is suggested that the computation of LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries sent on the same interface. For example, the algorithms described in RFC 2988 [RFC2988] (including exponential backoff) to compute an RTO, which is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). Recommended values are an initial RTO of 1 second, a minimum RTO of 200ms, and a maximum RTO of 20 seconds. In order to avoid synchronization, the transmission of each LLMNR query and response MUST be delayed by a time randomly selected from the interval 0 to 200 ms. - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 16 11:44:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22914 for ; Tue, 16 Dec 2003 11:44:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AWIAc-0006sp-4A for namedroppers-data@psg.com; Tue, 16 Dec 2003 16:35:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWIAP-0006pe-AX for namedroppers@ops.ietf.org; Tue, 16 Dec 2003 16:35:25 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hBGGVw84085988 for ; Tue, 16 Dec 2003 11:31:58 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id hBGGVwrt085987 for namedroppers@ops.ietf.org; Tue, 16 Dec 2003 11:31:58 -0500 (EST) Received: from [192.109.206.50] (helo=mailrelay.sony.de) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWCcM-0002MJ-O6 for namedroppers@ops.ietf.org; Tue, 16 Dec 2003 10:39:54 +0000 Received: from DEATCSSTRMSX03.wins.fb.sony.de (thanks for all the fish) by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id LAA20727 for ; Tue, 16 Dec 2003 11:39:53 +0100 Received: by deatcsstrmsx03.wins.fb.sony.de with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Dec 2003 11:39:53 +0100 Message-ID: <46C6A213F79E1D4DA73AB018C2CF61580271E3C4@deatcsstrmsx03.wins.fb.sony.de> From: "Loebbert, Johannes" To: "'namedroppers@ops.ietf.org'" Subject: draft-ietf-dnsext-mdns-26.txt Date: Tue, 16 Dec 2003 11:39:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C3C0.F01D1200" X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] ------_=_NextPart_001_01C3C3C0.F01D1200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I'm member of a Bluetooth SIG working group, which defines IP over Bluetooth. Since this Bluetooth profile mandates LLMNR it would be = great, if you could give me some information, when the RFC will be finished and fundamental parameters like the port number will be fixed. =20 Thanks, Johannes L=F6bbert =20 ------------------------------------------------------ Johannes L=F6bbert European Technology Center Sony International (Europe) GmbH Hedelfingerstra=DFe 61 D-70327 Stuttgart phone: +49 (0) 711 / 5858-537 fax: +49 (0) 711 / 5858-740 ------------------------------------------------------ =20 ------_=_NextPart_001_01C3C3C0.F01D1200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 all,
 
I'm = member of a=20 Bluetooth SIG working group, which defines IP over Bluetooth. Since = this=20 Bluetooth profile mandates LLMNR it would be great, if you could give = me some=20 information, when the RFC will be finished and fundamental parameters = like the=20 port number will be fixed.
 
Thanks,
Johannes=20 L=F6bbert
 
------------------------------------------------------
Johannes=20 L=F6bbert
European Technology Center
Sony International = (Europe)=20 GmbH
Hedelfingerstra=DFe 61
D-70327 Stuttgart
phone: +49 (0) = 711 /=20 5858-537
fax: +49 (0) 711 /=20 5858-740
------------------------------------------------------
 
------_=_NextPart_001_01C3C3C0.F01D1200-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 16 14:57:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29499 for ; Tue, 16 Dec 2003 14:57:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AWLCq-000Bin-7p for namedroppers-data@psg.com; Tue, 16 Dec 2003 19:50:08 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AWLCb-000BhP-7h for namedroppers@ops.ietf.org; Tue, 16 Dec 2003 19:49:53 +0000 Received: (qmail 25807 invoked from network); 16 Dec 2003 19:48:20 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 16 Dec 2003 19:48:20 -0000 Message-ID: <3FDF61E0.2020706@necom830.hpcl.titech.ac.jp> Date: Wed, 17 Dec 2003 04:49:52 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "Loebbert, Johannes" CC: "'namedroppers@ops.ietf.org'" Subject: Re: draft-ietf-dnsext-mdns-26.txt References: <46C6A213F79E1D4DA73AB018C2CF61580271E3C4@deatcsstrmsx03.wins.fb.sony.de> In-Reply-To: <46C6A213F79E1D4DA73AB018C2CF61580271E3C4@deatcsstrmsx03.wins.fb.sony.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Johannes; > Hi all, Hi. > I'm member of a Bluetooth SIG working group, which defines IP over > Bluetooth. Since this Bluetooth profile mandates LLMNR it would be great, Mandate LLMNR for IP over Bluetooth? Since not even DNS is mandated for IP over something and not all the IP based devices are expected to use DNS, mandating LLMNR is overkill. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 16 16:09:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05123 for ; Tue, 16 Dec 2003 16:09:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWMKb-000Kcy-Vt for namedroppers-data@psg.com; Tue, 16 Dec 2003 21:02:13 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWMJj-000KXb-8i for namedroppers@ops.ietf.org; Tue, 16 Dec 2003 21:01:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03994; Tue, 16 Dec 2003 16:01:16 -0500 (EST) Message-Id: <200312162101.QAA03994@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-06.txt Date: Tue, 16 Dec 2003 16:01:16 -0500 X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Legacy Resolver Compatibility for Delegation Signer Author(s) : S. Weiler Filename : draft-ietf-dnsext-dnssec-2535typecode-change-06.txt Pages : 5 Date : 2003-12-16 As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-2535typecode-change-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-16154016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-2535typecode-change-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-16154016.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 17 12:00:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20349 for ; Wed, 17 Dec 2003 12:00:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWer6-0000ut-92 for namedroppers-data@psg.com; Wed, 17 Dec 2003 16:49:00 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWeqt-0000u1-Ep for namedroppers@ops.ietf.org; Wed, 17 Dec 2003 16:48:47 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7578B18E4 for ; Wed, 17 Dec 2003 11:48:46 -0500 (EST) Date: Wed, 17 Dec 2003 11:48:46 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: New versions of DNSSECbis docs posted User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031217164846.7578B18E4@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I just sent new revisions of the DNSSECbis docs off to the Internet-Drafts administrator, they should pop out shortly. I've also placed copies of the new drafts at http://www.hactrn.net/ietf/dns/dnssec-editors/ along with htmlwdiff (thanks, fenner!) output showing changes since the previous versions. Please review. Please review. Please review. We believe that we've integrated the WG's answers to all of the outstanding questions. Please check to see if we got them right. This version of the docs also includes the new NSEC++ format (more precisely, the NSEC++ du jour format, but the editors and WG chairs concluded that this is close enough to stable that it makes sense for the DNSSECbis docs to start tracking the new NSEC stuff). This set of drafts didn't get quite as much internal proofreading by the editing team as we usually try to do, because we wanted to get this set out in time for you all to have something to read in the corner of those boring holiday parties. We may have missed some nits in the process (in fact, I know we did, I already found one, sigh), but no doubt this group can help us find more. As always, please send minor comments to dnssec-editors@east.isi.edu, substantive issues to namedroppers. Thanks! --Rob (on behalf of your friendly neighborhood DNSSEC editors) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 17 12:25:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21397 for ; Wed, 17 Dec 2003 12:25:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWfKg-0004um-7W for namedroppers-data@psg.com; Wed, 17 Dec 2003 17:19:34 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWfKU-0004tt-4N for namedroppers@ops.ietf.org; Wed, 17 Dec 2003 17:19:22 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 939A018E9 for ; Wed, 17 Dec 2003 12:19:21 -0500 (EST) Date: Wed, 17 Dec 2003 12:19:21 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: nsec++: type code zero again User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031217171921.939A018E9@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Minor issue with the new text for handling of type code zero in NSEC++. draft-ietf-dnsext-nsec-rdata-02.txt (which may not have popped out of the I-D queue yet) says: Since bit 0 in window block 0 refers to the non-existing RR type 0, it MUST be set to 0. After verification, the validator SHOULD ignore the value of bit 0 in window block 0. The SHOULD here seems wrong to me, I think it ought to be MUST, for the usual Robustness Principle reason. Since the reason that I happened to notice this is that I was integrating the NSEC++ text into draft-ietf-dnssec-records-06 at the time, and since I hadn't seen any namedroppers discussion that looked like direction from the WG on this point, I went with what made sense to me and put MUST into the new -records text on this point. Final answer on this point is of course up to the WG, but I had to put something into -records and it seemed silly to include text that the WG had not yet discussed and that I was pretty sure was wrong. So the point of this message is twofold: a) to ask the WG to decide what the right answer is on this point; b) to warn the WG that the current NSEC++ and DNSSECbis drafts disagree on this point, so that nobody will be surprised. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 17 12:42:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22185 for ; Wed, 17 Dec 2003 12:42:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWfcC-0006gj-JM for namedroppers-data@psg.com; Wed, 17 Dec 2003 17:37:40 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWfbj-0006d3-Lu for namedroppers@ops.ietf.org; Wed, 17 Dec 2003 17:37:11 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 0D93556849; Wed, 17 Dec 2003 09:37:10 -0800 (PST) Message-Id: <6.0.1.1.2.20031217123638.024f7640@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 17 Dec 2003 12:37:26 -0500 To: Rob Austein , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: nsec++: type code zero again In-Reply-To: <20031217171921.939A018E9@thrintun.hactrn.net> References: <20031217171921.939A018E9@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk MUST is more correct than SHOULD. The counter example is (What does it mean to not ignore the bit?) At 12:19 PM 12/17/2003, Rob Austein wrote: >Minor issue with the new text for handling of type code zero in >NSEC++. draft-ietf-dnsext-nsec-rdata-02.txt (which may not have >popped out of the I-D queue yet) says: > > Since bit 0 in window block 0 refers to the non-existing RR type 0, > it MUST be set to 0. After verification, the validator SHOULD ignore > the value of bit 0 in window block 0. > >The SHOULD here seems wrong to me, I think it ought to be MUST, for >the usual Robustness Principle reason. > >Since the reason that I happened to notice this is that I was >integrating the NSEC++ text into draft-ietf-dnssec-records-06 at the >time, and since I hadn't seen any namedroppers discussion that looked >like direction from the WG on this point, I went with what made sense >to me and put MUST into the new -records text on this point. Final >answer on this point is of course up to the WG, but I had to put >something into -records and it seemed silly to include text that the >WG had not yet discussed and that I was pretty sure was wrong. > >So the point of this message is twofold: > >a) to ask the WG to decide what the right answer is on this point; > >b) to warn the WG that the current NSEC++ and DNSSECbis drafts > disagree on this point, so that nobody will be surprised. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 17 15:27:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01893 for ; Wed, 17 Dec 2003 15:27:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWiBX-000OwU-Gd for namedroppers-data@psg.com; Wed, 17 Dec 2003 20:22:19 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWiBL-000OvK-Ib for namedroppers@ops.ietf.org; Wed, 17 Dec 2003 20:22:07 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBHKdbq18063 for ; Wed, 17 Dec 2003 12:39:37 -0800 Date: Wed, 17 Dec 2003 12:39:37 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 58: DNS server usage of LLMNR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 58: DNS server usage of LLMNR Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: December 13, 2003 Reference: Document: LLMNR-26 Comment type: T Priority: S Section: 2.2 Rationale/Explanation of issue: DNS servers are prohibited from responding to LLMNR queries except with RRs they own. However, DNS servers are not prohibited from sending LLMNR queries in order to resolve DNS queries. This seems like a very bad idea. Add the following sentence to Section 2.2: "DNS servers also MUST NOT send LLMNR queries in order to resolve DNS queries." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 17 15:28:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01939 for ; Wed, 17 Dec 2003 15:28:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWiAN-000Op8-Hs for namedroppers-data@psg.com; Wed, 17 Dec 2003 20:21:07 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWiA9-000Oo9-8p for namedroppers@ops.ietf.org; Wed, 17 Dec 2003 20:20:53 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBHKcN817990 for ; Wed, 17 Dec 2003 12:38:23 -0800 Date: Wed, 17 Dec 2003 12:38:23 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 55: Sender Checks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk LLMNR Issue 55: Sender checks Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: December 3, 2003 Reference: Document: LLMNR-25 Comment type: T Priority: S Section: 2-2.8 Rationale/Explanation of issue: Section 2 states: [4] Upon the reception of the response, the sender performs the checks described in Section 2.5. If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response. It is not clear what sender checks this paragraph is referring to. Possibilities include material in sections 2.3, 2.5, 2.8 and 3.1. Section 2.3 does include some sender checks. For example: "If the sender of a TCP query receives a response not using TCP, the response MUST be silently discarded." There is also discussion of handling of ICMP "time exceeded" messages. Section 2.5 does not specify checks to be made by senders on reception of a response. For example, there are recommendations on setting of TTL/hop count by senders, but no TTL check specified for receivers. Since the sender MUST set the TTL/Hop Count field to 1, it is not possible for a receiver to see a TTL/Hop Count field of 2 or larger. Yet no sender action is specified upon reception of such a packet. Within Section 2.5, the following paragraph is present: "A sender SHOULD prefer RRs including reachable addresses where RRs involving both reachable and unreachable addresses are returned in response to a query." I do not believe that this sentence implies a reachability test be done on received RRs. Section 2.8 provides guidelines for sender processing of the authority and additional section of responses. Section 3.1 talks about responder responsibilities, but not sender checks. It includes the sentence: "Routable addresses MUST be included first in the response, if available. This encourages use of routable address(es) for establishment of new connections." [Ralph Droms] Section 2.5, third paragraph: what is an "unreachable address"; did you intend "unroutable address"? [BA] Proposed fixes: In Section 2, change: "[4] Upon the reception of the response, the sender performs the checks described in Section 2.5. If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response." to: "[4] Upon reception of the response, the sender processes it." In Section 2.5, delete: "A sender SHOULD prefer RRs including reachable addresses where RRs involving both reachable and unreachable addresses are returned in response to a query." In Section 2.1, add: "Since the responder may order the RRs in the response so as to indicate preference, the sender SHOULD preserve ordering in the response to the querying application." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 17 15:28:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02002 for ; Wed, 17 Dec 2003 15:28:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWiD1-000P3n-HL for namedroppers-data@psg.com; Wed, 17 Dec 2003 20:23:51 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWiCo-000P36-QE for namedroppers@ops.ietf.org; Wed, 17 Dec 2003 20:23:38 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBHKf9l18146 for ; Wed, 17 Dec 2003 12:41:09 -0800 Date: Wed, 17 Dec 2003 12:41:09 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 59: Miscellaneous Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk LLMNR Issue 59: Miscellaneous Issues Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: December 17, 2003 Reference: Document: LLMNR-27 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The draft could benefit from addition of a section gathering in one place all the requirements relating to the use of the DNS packet format for LLMNR. For example, use of the TR bit is not defined and neither are the AD and CD bits (which I assume are set to zero). In Section 2.2, change: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone root." To: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone appex except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone appex." In Section 2.2, change: "Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." To: "Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." Add the following paragraph to Section 2.2: "Upon configuring an IP address responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has. However, in general whether RRs are manually or automatically created is an implementation decision." Change Section 2.7 from: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 0 is recommended in highly dynamic environments (such as mobile ad-hoc networks). In less dynamic environments, LLMNR traffic can be reduced by setting the TTL to a higher value. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 30 seconds is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc networks), the TTL value may need to be reduced. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 17 15:38:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02554 for ; Wed, 17 Dec 2003 15:38:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWiMb-0000aF-9h for namedroppers-data@psg.com; Wed, 17 Dec 2003 20:33:45 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWiMO-0000ZK-JJ for namedroppers@ops.ietf.org; Wed, 17 Dec 2003 20:33:32 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02210; Wed, 17 Dec 2003 15:33:29 -0500 (EST) Message-Id: <200312172033.PAA02210@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-02.txt Date: Wed, 17 Dec 2003 15:33:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-02.txt Pages : 9 Date : 2003-12-17 This document defines updates the NSEC resource record RDATA format to cover all type codes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-17151834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-17151834.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 18 02:07:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03040 for ; Thu, 18 Dec 2003 02:07:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWs5T-000GbT-KF for namedroppers-data@psg.com; Thu, 18 Dec 2003 06:56:43 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWs5G-000Gap-G2 for namedroppers@ops.ietf.org; Thu, 18 Dec 2003 06:56:30 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 254444EE71; Thu, 18 Dec 2003 07:54:25 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DBD824EC7A for ; Thu, 18 Dec 2003 07:54:24 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hBI6sOdH023644 for ; Thu, 18 Dec 2003 07:54:24 +0100 Message-Id: <200312180654.hBI6sOdH023644@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: WGLC on DNSSEC bis document set Date: Thu, 18 Dec 2003 07:54:24 +0100 From: Olaf Kolkman X-RIPE-Spam-Status: N 0.494764 X-RIPE-Signature: 3c3bec6459de0d0795ccd4854691f807 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Working Group Colleagues, This is a working group last call for the DNSSEC bis specification. The document set consists out of 3 documents that are lined up for the standards track: draft-ietf-dnsext-dnssec-intro-08 draft-ietf-dnsext-dnssec-records-06 draft-ietf-dnsext-dnssec-protocol-04 these documents update and replace the different RFCs related to DNSSEC this working group has produced over the last 5 years. We would like to urge you to review and comment on the document set. This specification has significant impact on the DNS and it is important that the specifications are unambiguous and implementable. Please provide statements of support or non-supports. We would like a clear technical motivation on why you support this document set, why you have issues with it or why you consent with the content; is the specification consistent, understandable, implementable, testable, &c, &c. The working group last call will conclude Jan 15 2004, we hope that that provides the WG with sufficient time to read the document set. We would like to acknowledge: Roy Arends, Rob Austein, Matt Larson, Dan Massey and Scott Rose for putting in the enourmous effort to get the spec WGLC ready in 2003! --------------------- WGLC Details -------------------------- If new issues are brought up that cause significant changes to the text a new WGLC will be issued. Minor issues will be processed based on working group consensus on the individual issues; there will be no WGLC if there are only minor issues that are solved easily and timely. Please bring technical issues to the list. Please try to use the format for bringing up issues as described in our monthly posting (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02045.html). Also split issues in separate mails this will make them stand out and easier to discuss. Editorial nits can be mailed directly to the editors: dnssec-editors@east.isi.edu. The specification has been written by an editors team that was tasked with documenting the protocol as specified in RFC's generated by this group and Internet Drafts that have been passed on by the working group to the IESG. For completeness we would like to mention that the dnssec-editors communication has been archived at: http://www.east.isi.edu/projects/DNSSEC The editing process has been documented in e.g. http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00165.html As mentioned in an announcement list the document set follows the text of the last DNSSEC document that still needs to be finalized draft-ietf-dnsext-nsec-rdata-02.txt. Whatever will be decided on that document will be reflected in this document set. Happy reading, spend your holidays well. --Olaf Kolkman Olafur Gudmundsson DNSEXT Chairs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 18 15:38:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16087 for ; Thu, 18 Dec 2003 15:38:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX4m6-000Do8-Q9 for namedroppers-data@psg.com; Thu, 18 Dec 2003 20:29:34 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX4lj-000DiA-O1 for namedroppers@ops.ietf.org; Thu, 18 Dec 2003 20:29:11 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14805; Thu, 18 Dec 2003 15:29:09 -0500 (EST) Message-Id: <200312182029.PAA14805@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-27.txt Date: Thu, 18 Dec 2003 15:29:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-27.txt Pages : 23 Date : 2003-12-18 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-27.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-27.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-27.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-18142532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-27.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142532.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 18 15:38:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16136 for ; Thu, 18 Dec 2003 15:38:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX4mX-000DrB-5X for namedroppers-data@psg.com; Thu, 18 Dec 2003 20:30:01 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX4lt-000Dj4-L4 for namedroppers@ops.ietf.org; Thu, 18 Dec 2003 20:29:21 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14835; Thu, 18 Dec 2003 15:29:19 -0500 (EST) Message-Id: <200312182029.PAA14835@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-06.txt Date: Thu, 18 Dec 2003 15:29:19 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Resource Records for DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-records-06.txt Pages : 37 Date : 2003-12-18 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existance (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-records-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-18142550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142550.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 18 15:39:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16185 for ; Thu, 18 Dec 2003 15:39:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX4n2-000DwM-1E for namedroppers-data@psg.com; Thu, 18 Dec 2003 20:30:32 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX4le-000DhX-7d for namedroppers@ops.ietf.org; Thu, 18 Dec 2003 20:29:06 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14769; Thu, 18 Dec 2003 15:28:59 -0500 (EST) Message-Id: <200312182028.PAA14769@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-08.txt Date: Thu, 18 Dec 2003 15:28:59 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, R. Austein, D. Massey, M. Larson, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-08.txt Pages : 26 Date : 2003-12-18 The Domain Name System Security Extensions (DNSSEC) adds data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-18142510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142510.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 18 15:39:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16207 for ; Thu, 18 Dec 2003 15:39:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX4oD-000EAK-BA for namedroppers-data@psg.com; Thu, 18 Dec 2003 20:31:45 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX4lo-000Dib-Vy for namedroppers@ops.ietf.org; Thu, 18 Dec 2003 20:29:17 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14821; Thu, 18 Dec 2003 15:29:14 -0500 (EST) Message-Id: <200312182029.PAA14821@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-04.txt Date: Thu, 18 Dec 2003 15:29:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-protocol-04.txt Pages : 55 Date : 2003-12-18 This document is part of a family of documents which describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-protocol-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-18142541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142541.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 18 15:40:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16301 for ; Thu, 18 Dec 2003 15:40:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX4mJ-000DpQ-PX for namedroppers-data@psg.com; Thu, 18 Dec 2003 20:29:47 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX4lf-000Dhc-81 for namedroppers@ops.ietf.org; Thu, 18 Dec 2003 20:29:07 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14785; Thu, 18 Dec 2003 15:29:04 -0500 (EST) Message-Id: <200312182029.PAA14785@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-12.txt Date: Thu, 18 Dec 2003 15:29:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : KEY RR Secure Entry Point Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-12.txt Pages : 10 Date : 2003-12-18 With the Delegation Signer (DS) resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record (RR) set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what keys are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-keyrr-key-signing-flag-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-18142523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142523.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From hhkinfo@mail.com Thu Dec 18 19:23:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01133 for ; Thu, 18 Dec 2003 19:23:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX8Q9-0002Vh-00 for dnsext-archive@ietf.org; Thu, 18 Dec 2003 19:23:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX8Q5-0002VO-00 for dnsext-archive@ietf.org; Thu, 18 Dec 2003 19:23:08 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AX8Pz-0002Ul-00; Thu, 18 Dec 2003 19:22:59 -0500 Received: from adsl-64-218-142-244.dsl.rcsntx.swbell.net ([64.218.142.244] helo=ietf.org) by manatick with smtp (Exim 4.24) id 1AX8Pm-0007LG-Gi; Thu, 18 Dec 2003 19:22:47 -0500 From: "Temas Patrulhados" To: disman-archive@ietf.org Subject: Lindenberg: Emprego rural versus assentamentos ref.: rlg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Thu, 18 Dec 2003 19:22:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES autolearn=no version=2.60

xvu ConstruNews deseja a todos um feliz Natal!
EnEspañol - InEnglish - Subscrever - Remover

Série Temas Patrulhados

Lindenberg: Emprego rural versus assentamentos

"Por que os agrorreformistas só falam em assentamentos e nunca na criação de empregos na área rural?"

* Patrulhamento

Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", onde denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, opiniões e livros "politicamente incorretos", não afinados com as assim denominadas "causas sociais": os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Agrorreformistas

Em artigo "Emprego rural versus assentamentos", da Série Temas Patrulhados, Lindenberg pergunta:

- Por que os agrorreformistas só falam em assentamentos e nunca na criação de empregos na área rural?

- Por que não reivindicam financiamentos ou outros estímulos à agroindústria ou a empresas rurais que empregam grande número de trabalhadores?

- Por que não propõem modificações na legislação trabalhista para o campo de modo a permitir que os fazendeiros reconstruam as antigas colônias com casas razoáveis e terrenos destinados ao plantio de hortaliças, criação de porcos e galinhas etc.?

* Viés socialista

A resposta do autor é simples:

- Trata-se do velho viés marxista, a mentalidade socialista, denominador comum a todos os agrorreformistas! Na mentalidade marxista, o patrão é sempre visto como um explorador e o empregado como um semiescravo, humilhado e indefeso! Para pessoas de mentalidade esquerdista, o contraste entre o casario pobre de uma colônia e o casarão senhorial do fazendeiro, lembra feudalismo, desigualdade social gritante, injustiças de toda espécie. Xico Graziano, ex-presidente do Incra, confirma essa obsessão niveladora ao atribuir o desinteresse dos agrorreformistas pela qualidade e pelo custo da política de assentamentos "a uma razão de fundo ideológico, pois o pensamento agrarista tradicional sempre se interessou em penalizar o latifúndio, desapropriando-o".

* Sonho aliciante

Haverá um sonho mais aliciante e semelhante ao velho utopismo socialista, do que um país onde todos têm sua terra para plantar, financiamentos com juros subsidiados, onde não existem patrões ou fiscais de qualquer espécie?, pergunta Lindenberg em seu artigo. E responde: Diante desse sonho utópico, o único recurso que nos resta é o apelo constante ao bom senso e à experiência acumulada durante séculos. De um modo muito empírico, quase a título exemplificativo, poder-se-ia alinhar algumas considerações atinentes à problemática:

- A condição empregatícia de si não tem absolutamente nada de humilhante ou de exploratório. As mais altas autoridades do país - o presidente, os ministros, magistrados do Supremo - são empregados. São igualmente empregados os professores, os oficiais superiores, os altos executivos que governam os grandes conglomerados econômicos e as multinacionais.

- O importante para o trabalhador rural não é ser o dono da terra, como também para o morador de uma casa não é ser dono do imóvel. O importante é ganhar bem, poder progredir, sentir-se seguro no emprego, estar em condições de formar um pecúlio. Dono de um capital, o empregado pode decidir se compra a terra ou a casa, ou se investe num negócio ou se compra ações. Ele se tornou um minicapitalista.

- Aliás, diga-se de passagem, o Brasil só terá se tornado um país verdadeiramente capitalista na medida em que boa parte de sua população seja proprietária de minicapitais. A esse respeito convém lembrar o exemplo dado pelos imigrantes japoneses. Considerados os agricultores mais bem sucedidos que já aportaram em nossas terras, eles sempre preferiram arrendar a comprar as várzeas nas quais plantaram suas hortas e isso com um sucesso absoluto.

- Que haja uma significativa diminuição do desemprego e do êxodo rural constitui um anseio nacional. Que os homens do campo, pequenos proprietários, assentados, bóias-frias consigam elevar seus padrões de vida a níveis aceitáveis constitui, igualmente uma meta a ser atingida. Esses objetivos não são, por conseguinte um monopólio dos agrorreformistas e, muito menos, um apanágio das esquerdas. No modo de solucionar essas carências é que se situam as diferenças.

* Outros temas

Outros temas abordados no artigo: Monteiro Lobato, a saúva e o sítio; condições para o éxito das pequenas propriedades; causas do enfraquecimento dos "liames feudais" entre fazendeiros e empregados; os descontentes e o "canto de sereia" dos agrorreformistas; o crescimento espetacular dos Tigres Asiáticos; os dois paradigmas básicos para o Brasil rural; e como evitar, no Brasil, o triunfo da utopia e da revolução social. Para receber gratuitamente o texto completo deste artigo, clique em: Lindenberg:DesejoReceberGratuitamenteEsteArtigo

LINKS DE OPINIÃO:

Entre aqueles que enviarem sua valiosa opinião a respeito do texto acima, até 31 de dezembro, usando qualquer um dos links seguintes, serão sorteados 10 exemplares impressos do livro "Os católicos e a economia de mercado". Os favorecidos serão comunicados por e-mail e deverão enviar o endereço postal para receberem os exemplares do livro, por Correio).

Lindenberg:Concordo (pode simplesmente enviar seu voto virtual, e acrescentar seu comentário caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirE-Book (para adquirir o livro, em formato Word, que será enviado por e-mail; clicando neste link receberá número de conta bancária para efetuar transferência; preço promocional do e-book, até 31 de dezembro: R$ 5,50)

Lindenberg:DesejoAdquirirLivroEmPortugal (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora em Portugal; preço: E 19,45)

Lindenberg:DesejoAdquirirLivroNoBrasil (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora no Brasil, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais Correio)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores

GratuitamenteProximosArtigos

GratuitamenteTodosOsArtigos

LINK DE REMOÇÃO

ConstruNews:Remover

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 From owner-namedroppers@ops.ietf.org Thu Dec 18 19:41:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02102 for ; Thu, 18 Dec 2003 19:41:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX8bi-000N9m-Cl for namedroppers-data@psg.com; Fri, 19 Dec 2003 00:35:06 +0000 Received: from [128.9.144.145] (helo=gamma.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX8bV-000N7g-0B for namedroppers@ops.ietf.org; Fri, 19 Dec 2003 00:34:53 +0000 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hBJ0Yfs23165; Thu, 18 Dec 2003 16:34:41 -0800 (PST) Message-Id: <200312190034.hBJ0Yfs23165@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3658 Delegation Signer (DS) Resource Record (RR) Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 18 Dec 2003 16:34:41 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3658 Title: Delegation Signer (DS) Resource Record (RR) Author(s): O. Gudmundsson Status: Standards Track Date: December 2003 Mailbox: ds-rfc@ogud.com Pages: 19 Characters: 42120 Updates: 3090, 3008, 2535, 1035 I-D Tag: draft-ietf-dnsext-delegation-signer-15.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3658.txt The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031218163308.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3658 --OtherAccess Content-Type: Message/External-body; name="rfc3658.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031218163308.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 19 11:33:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15076 for ; Fri, 19 Dec 2003 11:33:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXNR9-000Ldj-7o for namedroppers-data@psg.com; Fri, 19 Dec 2003 16:25:11 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXNQv-000LbR-OL for namedroppers@ops.ietf.org; Fri, 19 Dec 2003 16:24:57 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id hBJGOs7M002581 for ; Fri, 19 Dec 2003 17:24:54 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) with ESMTP id hBJGP0PK017285 for ; Fri, 19 Dec 2003 17:25:00 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-5) id hBJGP0D8017284 for namedroppers@ops.ietf.org; Fri, 19 Dec 2003 17:25:00 +0100 Date: Fri, 19 Dec 2003 17:25:00 +0100 From: Miek Gieben To: namedroppers Subject: DNSSEC workshop Message-ID: <20031219162500.GA17265@atoom.net> Mail-Followup-To: namedroppers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Namedroppers, The RIPE NCC will be hosting a DNSSEC workshop organized by ISC and NLnetLabs. The tests will focus on interoperability between BIND and NSD. Other DNSSEC aware tools and code can be tested if available. There is a set of volunteers that will participate in the workshop but there are still a few seats (3 to 4) left for people who want to join. Please let us know if you want to participate. There is a preference for people who bring alternative DNSSEC implementations, but otherwise it is first come first served. Please do arrange travel until you had confirmation. A report of the workshop will be posted to this list. The workshop will be at the RIPE NCC offices in Amsterdam, the Netherlands, Jan 20-22, 2004 (the week before the RIPE meeting) grtz Miek -- fingerprint = E1EB 29B8 8FA2 2923 62B8 0A2B 64B8 F15C 7764 AB4B http://miek.nl/about.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 21 02:28:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17219 for ; Sun, 21 Dec 2003 02:28:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXxqC-0009sP-HK for namedroppers-data@psg.com; Sun, 21 Dec 2003 07:17:28 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXxpz-0009ra-Ik for namedroppers@ops.ietf.org; Sun, 21 Dec 2003 07:17:15 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 20 Dec 2003 23:17:41 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 20 Dec 2003 23:17:11 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 20 Dec 2003 23:16:54 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 20 Dec 2003 23:16:53 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 20 Dec 2003 23:17:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR Issue 58: DNS server usage of LLMNR Date: Sat, 20 Dec 2003 23:17:25 -0800 Message-ID: Thread-Topic: LLMNR Issue 58: DNS server usage of LLMNR Thread-Index: AcPE3YkBik6yNVLrTPyl1oEJU0IobACs3kQg From: "Christian Huitema" To: "Bernard Aboba" , X-OriginalArrivalTime: 21 Dec 2003 07:17:10.0173 (UTC) FILETIME=[72CD84D0:01C3C792] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > DNS servers are prohibited from responding to LLMNR queries except with > RRs they own. However, DNS servers are not prohibited from sending > LLMNR queries in order to resolve DNS queries. This seems like a very bad > idea. >=20 > Add the following sentence to Section 2.2: >=20 > "DNS servers also MUST NOT send LLMNR queries in order to resolve DNS > queries." I am not sure this is such a "very bad idea". Take the example of an IPv6 home network. The ISP explicitly delegates an IPv6 prefix to the home router. The router advertises this prefix. Hosts configure addresses from this prefix. Since there is explicit prefix delegation to the router, we may expect the router to also receive delegation of the reverse lookup tree. In these conditions, it makes a lot of sense to use LLMNR to fulfill a DNS PTR request. If you look at it, the chain of trust is exactly the same as what we have today in IPv4, when a router fulfills a PTR request using whatever name the host asserted in a DHCP request. This is just one scenario. I am convinced there may be others. "MUST NOT" is way too strong. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 21 03:36:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18497 for ; Sun, 21 Dec 2003 03:36:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXywp-000FTi-TI for namedroppers-data@psg.com; Sun, 21 Dec 2003 08:28:23 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AXywT-000FQZ-Et for namedroppers@ops.ietf.org; Sun, 21 Dec 2003 08:28:01 +0000 Received: (qmail 45232 invoked from network); 21 Dec 2003 08:27:51 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 21 Dec 2003 08:27:51 -0000 Message-ID: <3FE55999.6030608@necom830.hpcl.titech.ac.jp> Date: Sun, 21 Dec 2003 17:28:09 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Bernard Aboba , namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 58: DNS server usage of LLMNR References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian; >>DNS servers are prohibited from responding to LLMNR queries except > > with > >>RRs they own. However, DNS servers are not prohibited from sending >>LLMNR queries in order to resolve DNS queries. This seems like a very > > bad > >>idea. >> >>Add the following sentence to Section 2.2: >> >>"DNS servers also MUST NOT send LLMNR queries in order to resolve DNS >>queries." > > > I am not sure this is such a "very bad idea". Take the example of an > IPv6 home network. The ISP explicitly delegates an IPv6 prefix to the > home router. The router advertises this prefix. Hosts configure > addresses from this prefix. Since there is explicit prefix delegation to > the router, we may expect the router to also receive delegation of the > reverse lookup tree. Wrong. We expect that there are multiple nameservers of a zone at multiple locations. We may expect that a router of a link corresponding to a PTR act as the primary nameserver of a zone containg the PTR. However, in this case, DHCP is the way for the router maintain information of the reverse zone. LLMNR MUST NOT be queried from DNS servers. > This is just one scenario. I am convinced there may be others. Your senario merely is an example that stateless autoconfiguration and LLMNR is useless to the Internet. Unlike stateless autoconfiguration, however, LLMNR may be useful to an isolated IP network with a single link (with no routers). Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 21 10:57:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27745 for ; Sun, 21 Dec 2003 10:57:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AY5pk-0003iM-E5 for namedroppers-data@psg.com; Sun, 21 Dec 2003 15:49:32 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AY5ob-0003fH-Ut for namedroppers@ops.ietf.org; Sun, 21 Dec 2003 15:48:22 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBLG5TW24986; Sun, 21 Dec 2003 08:05:30 -0800 Date: Sun, 21 Dec 2003 08:05:29 -0800 (PST) From: Bernard Aboba To: Christian Huitema cc: namedroppers@ops.ietf.org Subject: RE: LLMNR Issue 58: DNS server usage of LLMNR In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I am not sure this is such a "very bad idea". Take the example of an > IPv6 home network. The ISP explicitly delegates an IPv6 prefix to the > home router. The router advertises this prefix. Hosts configure > addresses from this prefix. Since there is explicit prefix delegation to > the router, we may expect the router to also receive delegation of the > reverse lookup tree. In these conditions, it makes a lot of sense to use > LLMNR to fulfill a DNS PTR request. If you look at it, the chain of > trust is exactly the same as what we have today in IPv4, when a router > fulfills a PTR request using whatever name the host asserted in a DHCP > request. The drafts currently discusses two scenarios: a. Today with IPv4, home gateways typically act as both a DHCPv4 server and DNS server, supporting dynamic DNS (via DHCP). This allows them to answer both A and PTR queries for the names of hosts on the local network. Such routers typically answer AAAA queries for local hosts they don't know with RCODE=3 or, for hosts they do know, but for which there is no AAAA RR, with RCODE=0 and no RRs. This causes the querying host to send an LLMNR query for the AAAA RR or corresponding PTR. b. If the router supports IPv6, as well as acting as a DNS server, and supports DHCPv6Lite, then it would also be able to support dynamic DNS (via DHCPv6lite) and could answer AAAA and PTR queries without need of LLMNR. Given that both a) and b) scenarios already work, I'm looking to come up with a scenario in which DNS server usage of LLMNR queries helps. One possible scenario would be where only some of the local IPv6 hosts are LLMNR capable and support DHCPv6lite. Hosts that do not support DHCPv6lite might not be able to register their AAAA and corresponding PTR RRs with the DNS server authoritative for the names of local hosts (e.g. the router). Other hosts might support DHCPv6 lite, but might not be able to act as either an LLMNR sender or responder. In such a situation, an LLMNR-incapable host might send a DNS query for a AAAA or PTR RR of a host that didn't support DHCPv6lite, but could act as an LLMNR responder. The DNS server would respond with RCODE=3, at which point the querier would have no recourse, since it doesn't support LLMNR. However, if the DNS server sent an LLMNR query for the name, it would get an answer which it could relay back to the querier. Is this a likely scenario? It seems quite likely to me that we will have hosts that support DHCPv6lite but not LLMNR, but I'm not sure about hosts that support LLMNR but not DHCPv6lite. You need to posit both types of hosts for scenario c) to apply. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 21 15:30:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04419 for ; Sun, 21 Dec 2003 15:30:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYA6p-0005gZ-Bh for namedroppers-data@psg.com; Sun, 21 Dec 2003 20:23:27 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AYA6d-0005fW-5Y for namedroppers@ops.ietf.org; Sun, 21 Dec 2003 20:23:15 +0000 Received: (qmail 47420 invoked from network); 21 Dec 2003 20:23:14 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 21 Dec 2003 20:23:14 -0000 Message-ID: <3FE6013C.5030804@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Dec 2003 05:23:24 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: Christian Huitema , namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 58: DNS server usage of LLMNR References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba; > One possible scenario would be where only some of the local IPv6 hosts are > LLMNR capable and support DHCPv6lite. Hosts that do not support DHCPv6lite > might not be able to register their AAAA and corresponding PTR RRs with > the DNS server authoritative for the names of local hosts (e.g. the router). > Other hosts might support DHCPv6 lite, but might not be able to act as > either an LLMNR sender or responder. > > In such a situation, an LLMNR-incapable host might send a DNS query for a > AAAA or PTR RR of a host that didn't support DHCPv6lite, but could act as > an LLMNR responder. The DNS server would respond with RCODE=3, at which > point the querier would have no recourse, since it doesn't support LLMNR. > However, if the DNS server sent an LLMNR query for the name, it would get > an answer which it could relay back to the querier. Your hidden assumption is that all the related hosts are on a single link or that all the hosts on a link belong to a local forward domain served by nameservers, all of which is on the link. Otherwise, we have no idea on where to ask the forward query, even if you say LLMNR. Given so much confusion on usefulness of LLMNR and an attempt to mandate LLMNR for IP over BT, I'd like to suggest to abandone LLMNR entirely, or, at least, add explicite explanation stating its narrow scope, such as: LLMNR is expected to be useful for nodes on an isolated IP network with a single link, but not beyond that. LLMNR MUST NOT be used by nodes connected to the Internet nor an isolated IP network with multiple links. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 21 16:36:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06466 for ; Sun, 21 Dec 2003 16:36:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYBBf-000DAq-BI for namedroppers-data@psg.com; Sun, 21 Dec 2003 21:32:31 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYBBS-000D9b-2o for namedroppers@ops.ietf.org; Sun, 21 Dec 2003 21:32:18 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBLLnMV12465; Sun, 21 Dec 2003 13:49:22 -0800 Date: Sun, 21 Dec 2003 13:49:22 -0800 (PST) From: Bernard Aboba To: Masataka Ohta cc: Christian Huitema , namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 58: DNS server usage of LLMNR In-Reply-To: <3FE6013C.5030804@necom830.hpcl.titech.ac.jp> Message-ID: References: <3FE6013C.5030804@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > LLMNR is expected to be useful for nodes on an isolated > IP network with a single link, but not beyond that. LLMNR > MUST NOT be used by nodes connected to the Internet nor > an isolated IP network with multiple links. Since LLMNR queries and responses are sent on the local link with TTL=1, they will not propagate beyond the local link. Therefore I would agree that Link Local Name Resolution Protocol (LLMNR) should be restricted to link local usage. However, I do not think that the rest of this recommendation can be put into practice. Whether the network is "isolated" or "connected to the Internet" is very hard to determine. A host may be able to reach some Internet prefixes, and not be able to reach others. Similarly, the radius of the network may also be hard to determine. Furthermore, I would argue that the disction between "isolated" and "connected" networks is not really relevant to deciding whether to use a secondary name resolution protocol. Issues that are relevant are: a. whether the primary protocol (DNS) can provide an answer or not. b. whether the rules governing usage of the secondary protocol are conservative enough to avoid unnecessary use of a secondary protocol when the primary protocol could be used successfully. LLMNR use is restricted to situations in which DNS servers are not configured, where DNS servers do not respond or where DNS responds with RCODE=3 or RCODE=0 and no RRs. However, the host is not obliged to dig deeper to understand *why* these situations occur, because there may be no easy way for a host to determine *why* a DNS server did not respond to a query, or *why* the host was not configured with a DNS server. The only real issue is whether, based on these criteria, it is appropriate for a host to conclude that it is unlikely to successfully resolve the name using the primary name resolution protocol (DNS). Whether that conclusion is justified depends in part on resolver behavior. Hosts implementing RFC 1536 are advised to support DNS resolver failover, to measure DNS RTTs, and to avoid unnecessary RCODE=3 errors. All of these fixes make it more likely that a DNS server, if available, will respond to the query so that LLMNR is not needed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 21 16:54:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06929 for ; Sun, 21 Dec 2003 16:54:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYBU6-000FNH-EU for namedroppers-data@psg.com; Sun, 21 Dec 2003 21:51:34 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AYBTu-000FIF-B2 for namedroppers@ops.ietf.org; Sun, 21 Dec 2003 21:51:22 +0000 Received: (qmail 47658 invoked from network); 21 Dec 2003 21:51:23 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 21 Dec 2003 21:51:23 -0000 Message-ID: <3FE615E3.7020202@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Dec 2003 06:51:31 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: Christian Huitema , namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 58: DNS server usage of LLMNR References: <3FE6013C.5030804@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba; >> LLMNR is expected to be useful for nodes on an isolated >> IP network with a single link, but not beyond that. LLMNR >> MUST NOT be used by nodes connected to the Internet nor >> an isolated IP network with multiple links. > Whether the network is "isolated" or "connected to the Internet" is > very hard to determine. A host may be able to reach some Internet > prefixes, and not be able to reach others. Similarly, the radius of the > network may also be hard to determine. It is trivially easy for an administrator of the network. > LLMNR use is restricted to situations in which DNS servers are not > configured, where DNS servers do not respond or where > DNS responds with RCODE=3 or RCODE=0 and no RRs. The problem is that, LLMNR is still not useful unless the network is an isolated single link that LLMNR should never be attempted otherwise. > However, the host is not obliged to dig deeper to understand *why* these > situations occur, Agreed, but it is not my point. Given the difficulty you mentioned, I think it is also necessary to request that LLMNR functionality is, by default, turned off. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 22 09:56:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18795 for ; Mon, 22 Dec 2003 09:56:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYRAu-00044n-3C for namedroppers-data@psg.com; Mon, 22 Dec 2003 14:36:48 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYRAI-0003y6-Ju for namedroppers@ops.ietf.org; Mon, 22 Dec 2003 14:36:10 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8A5844E4DE; Mon, 22 Dec 2003 14:17:30 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5CF9F4E1BE for ; Mon, 22 Dec 2003 14:17:30 +0100 (CET) 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 hBMDHUdH025330 for ; Mon, 22 Dec 2003 14:17:30 +0100 Date: Mon, 22 Dec 2003 14:17:30 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: WGLC for draft-ietf-dnsext-nsec-rdata-03.txt Message-Id: <20031222141730.50f9de82.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.095843 X-RIPE-Signature: e481a41dc83588a84c52714903fd5dd2 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Working Group Colleagues, This is a working group last call for draft-ietf-dnsext-nsec-rdata-03.txt. This document introduces a new format for the type bit map so that it can cover the full range of typecodes without the need of being extended. The document does not change the semantics of the NSEC RR (as they where inherited from the NXT RR). This is to become a standard track RFC, the specification as documented herein will end up in the DNSSEC bis document set. To be able to forward this document we, the chairs, will need your comments of support and statements concerning the ability to implement this spec. The WGLC concludes January 15, at the same time as the DNSSEC bis document set. If the WG remains silent the default action will be to forward the document. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 22 09:56:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18812 for ; Mon, 22 Dec 2003 09:56:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYRBL-00046b-BF for namedroppers-data@psg.com; Mon, 22 Dec 2003 14:37:15 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYQcc-00009D-8g for namedroppers@ops.ietf.org; Mon, 22 Dec 2003 14:01:22 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBM86ie15424 for ; Mon, 22 Dec 2003 00:06:45 -0800 Date: Mon, 22 Dec 2003 00:06:44 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 60: Uniqueness check on linkup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 60: Uniqueness check on linkup Submitter name: Ralph Droms Submitter email address: rdroms@cisco.com Date first submitted: December 3, 2003 Reference: Document: LLMNR-27 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: Section 4, fifth paragraph: I think the host should perform the uniqueness test when the interface is connected to a link (in addition to the other events in the bullet list). [BA] I think this is probably correct, since while the host was disconnected, another host might have checked for uniqueness of the name, and not gotten a response. As a result, once the host connects to the network, it needs to do a uniquenss check. In order to avoid an impact on roaming latency, it probably makes sense for this check to be done optimistically -- the host does not respond to LLMNR queries until it verifies uniqueness of the name, but it should be able to do other things, such as initiate TCP connections, etc. As a result, the LLMNR name uniqueness test is not in the critical path for roaming. Proposed fix is as follows: In Section 4, add to the list of events on which uniqueness checking is triggered: "- detects that an interface is connected and is usable (e.g. an IEEE 802 hardware link-state change indicating that a cable was attached or that an association has occurred with a wireless base station and that any required authentication has completed)" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 22 14:53:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02718 for ; Mon, 22 Dec 2003 14:53:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYVzy-000HiV-6x for namedroppers-data@psg.com; Mon, 22 Dec 2003 19:45:50 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYVzl-000Hh4-Tj for namedroppers@ops.ietf.org; Mon, 22 Dec 2003 19:45:38 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Mon, 22 Dec 2003 14:45:36 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: question about dnssec-protocol-04 Date: Mon, 22 Dec 2003 14:45:36 -0500 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312221445.36740.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit draft-ietf-dnsext-dnssec-protocol-04, section 2.3 has the following paragraph: An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRsets at any particular owner name. That is, the signing process MUST NOT create (or RRSIG) RRs for owner names nodes which were not the owner name of any RRset before the zone was signed. [There is an editing nit here, too: s/MUST NOT create (or/MUST NOT create NSEC (or/, I think.] I feel sure that I have just forgotten the discussion about this, but why does this restriction exist? What harm would NSEC records of this sort cause? It is true that I cannot think of any useful reason to do this, but forbidding such NSEC records should have some real problem associated with it. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 22 15:21:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05530 for ; Mon, 22 Dec 2003 15:21:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYWUT-000M2t-Ub for namedroppers-data@psg.com; Mon, 22 Dec 2003 20:17:21 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYWUH-000M1i-QY for namedroppers@ops.ietf.org; Mon, 22 Dec 2003 20:17:09 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CFA6C18B7 for ; Mon, 22 Dec 2003 15:17:08 -0500 (EST) Date: Mon, 22 Dec 2003 15:17:08 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: question about dnssec-protocol-04 In-Reply-To: <200312221445.36740.davidb@verisignlabs.com> References: <200312221445.36740.davidb@verisignlabs.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031222201708.CFA6C18B7@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 22 Dec 2003 14:45:36 -0500, David Blacka wrote: > > draft-ietf-dnsext-dnssec-protocol-04, section 2.3 has the following > paragraph: > > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRsets at any particular owner name. That is, the signing process > MUST NOT create (or RRSIG) RRs for owner names nodes which were not > the owner name of any RRset before the zone was signed. > > [There is an editing nit here, too: s/MUST NOT create (or/MUST NOT create > NSEC (or/, I think.] > > I feel sure that I have just forgotten the discussion about this, but why > does this restriction exist? What harm would NSEC records of this sort > cause? > > It is true that I cannot think of any useful reason to do this, but > forbidding such NSEC records should have some real problem associated with > it. Empty non-terminals. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 22 15:35:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06427 for ; Mon, 22 Dec 2003 15:35:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYWj6-000O7N-7R for namedroppers-data@psg.com; Mon, 22 Dec 2003 20:32:28 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYWij-000O5T-CC for namedroppers@ops.ietf.org; Mon, 22 Dec 2003 20:32:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05996; Mon, 22 Dec 2003 15:32:02 -0500 (EST) Message-Id: <200312222032.PAA05996@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-03.txt Date: Mon, 22 Dec 2003 15:32:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-03.txt Pages : 9 Date : 2003-12-22 This document defines updates the NSEC resource record RDATA format to cover all type codes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-22143255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-22143255.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 22 15:46:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07483 for ; Mon, 22 Dec 2003 15:46:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYWtm-0000JY-0K for namedroppers-data@psg.com; Mon, 22 Dec 2003 20:43:30 +0000 Received: from [211.30.120.24] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYWtO-0000F5-8T for namedroppers@ops.ietf.org; Mon, 22 Dec 2003 20:43:16 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hBMKf9Dl010358; Tue, 23 Dec 2003 07:42:59 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200312222042.hBMKf9Dl010358@drugs.dv.isc.org> To: David Blacka Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: question about dnssec-protocol-04 In-reply-to: Your message of "Mon, 22 Dec 2003 14:45:36 CDT." <200312221445.36740.davidb@verisignlabs.com> Date: Tue, 23 Dec 2003 07:41:09 +1100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > draft-ietf-dnsext-dnssec-protocol-04, section 2.3 has the following > paragraph: > > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRsets at any particular owner name. That is, the signing process > MUST NOT create (or RRSIG) RRs for owner names nodes which were not > the owner name of any RRset before the zone was signed. > > [There is an editing nit here, too: s/MUST NOT create (or/MUST NOT create > NSEC (or/, I think.] > > I feel sure that I have just forgotten the discussion about this, but why > does this restriction exist? What harm would NSEC records of this sort > cause? A signed zone should return the same answers as a unsigned zone modulo DNSSEC records. > It is true that I cannot think of any useful reason to do this, but > forbidding such NSEC records should have some real problem associated with > it. Without the rule it also means that a UPDATE client needs to know to delete NSEC when the last regular record is deleted. This introduces race conditions between the client and the server which don't exist if the server is left to manage the creation and deletion of NSEC. > -- > David Blacka > Sr. Engineer Verisign Applied Research > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From hbepress@mail.com Tue Dec 30 05:24:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18324 for ; Tue, 30 Dec 2003 05:24:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbH2v-0000gw-00 for dnsext-archive@ietf.org; Tue, 30 Dec 2003 05:24:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbH1H-0000b7-00 for dnsext-archive@ietf.org; Tue, 30 Dec 2003 05:22:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AbGzL-0000TG-00; Tue, 30 Dec 2003 05:20:35 -0500 Received: from [61.236.238.72] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1AbGzJ-00068n-Ts; Tue, 30 Dec 2003 05:20:35 -0500 From: "O pequeno Lucas:" To: disman-request@ietf.org Subject: Um exemplo para o Brasil ref.: lot X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Tue, 30 Dec 2003 05:20:35 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.1 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_20_30,HTML_FONT_BIG,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.0 AWL AWL: Auto-whitelist adjustment

sxs Feliz Ano Novo para você e família! Atenciosamente, Ferreira Passos, Atualidade Brasileira. Lucas:EnCastellano Lucas:InEnglish ProximosEnvios:SoloEnCastellano NextMessages:OnlyInEnglish

Dez. 29, 2003: Atualidade Brasileira, Rio de Janeiro.

O pequeno Lucas: um exemplo para o Brasil

Deu seu último suspiro segurando com suas mãozinhas um Menino Jesus e uma Medalha Milagrosa, e partiu para celebrar seu primeiro Natal no Céu

Lucas da Rocha Silva nasceu em São Paulo, no bairro industrial de Itaquera, zona leste da cidade, em 28 de novembro de 1994. Foi ele crescendo normalmente, como todas as crianças de sua idade, quando, na madrugada de 1o. de novembro de 2000, próximo a completar 6 anos, acordou com fortes dores na tíbia de sua perninha esquerda. Começava a trilhar uma dolorosa e inesperada via crucis que a Providencia, em seus misteriosos desígnios, lhe tinha reservado, e que ele aceitaria de maneira exemplar, até seu falecimento em 15 de dezembro de 2003.

Um exame de raios-x indicou uma fratura no local da dor, o que levou os médicos a engessarem sua perna por um mês. Mas a dor ia aumentando. O pequeno pegava então o seu tercinho, dizendo que rezaria Ave-Marias "até a dor passar". Conseguia assim adormecer, mas, no dia seguinte, seu drama recomeçava.

Em março de 2001, uma biopsia feita no Hospital Santa Marcelina indicou um tumor na tíbia. Passou a ser atendido no Instituto de Oncologia Pediátrica, do Hospital São Paulo, onde foi submetido pouco depois a um implante de ossos, para tentar deter o avanço do tumor; mas este se expandiu para o joelho, e depois para o fêmur, obrigando a mais duas cirurgias, a última das quais, em abril de 2003, lhe amputou a perninha esquerda.

O pequeno Lucas foi aceitando todos esses sofrimentos com admirável espírito cristão, como vindos da vontade de Deus, sem jamais se deixar abater, nem reclamar pelas dores ou pelo seu infortúnio. Disto são testemunhas seu pai, Carlos Alberto Gil da Silva, 39; sua mãe, da. Maria Aparecida da Rocha Silva, 36; seu irmão Klayton, 14; seu melhor amiguinho, Luizinho; seus familiares; médicos; professores; coleguinhas; vizinhos, e todos quantos o conheceram.

Desde a primeira cirurgia, precisou acordar três vezes por semana às 5.30 hs. da manhã, para ir ao Hospital e ser examinado pela sua médica, além de submeter-se a sessões de quimioterapia, radioterapia, e outros exames. Lá, enquanto aguardava o atendimento, costumava, com sua conversa alegre e animada, e participando de jogos, estimular outras crianças com doenças similares, que compreensivelmente se encontravam abatidas e tristes. Ainda com sua perninha amputada, ele deu um jeito de continuar a jogar bola e andar de bicicleta. Às vezes, quando o atendimento atrasava e o relógio estava perto do meio-dia, procurava sua médica e lhe dizia: "Por favor, me chama logo, tia, que preciso ir à escola". Seu senso do dever fez com que, até o final, continuasse a ir à escola, onde obteve sempre notas acima de 8.

O esforço de seus médicos, e as cirurgias, não impediram que, a partir de abril de 2003, o implacável tumor se alastrasse por seu debilitado organismo, passando do fêmur aos pulmões, e daí, ao maxilar e ao pescoço; o que foi multiplicando seus sofrimentos, pois agora sentia dificuldades para falar, se alimentar e mesmo respirar.

Em setembro de 2003, enquanto Lucas aguardava para efetuar um dos intermináveis exames e tratamentos, uma alma caridosa lhe deu de presente uma Medalha de Nossa Senhora das Graças, a Medalha Milagrosa, que passou a usar continuamente, com piedade sincera, até os últimos instantes de sua breve vida terrena, que já se aproximavam. Também ganhou um livrinho com a historia de Nossa Senhora de Fátima e dos três pastorinhos videntes, e ficou assim sabendo que um deles, Jacinta, falecera sendo ainda uma criança. Todas as noites, o pequeno Lucas pedia à sua mãe para ler algumas páginas desse livrinho; depois, rezava a Oração ao Anjo da Guarda e adormecia.

Algumas semanas antes do Natal, Lucas ganhou também um pequeno Menino Jesus na manjedoura, que recebeu com devoção e alegria, dizendo serenamente a seus pais que este Natal ele o passaria no Céu junto com seu avô paterno, que falecera alguns meses antes. De fato, seu corpo já não mais agüentava a quimioterapia e a radioterapia, que foram suspensas em novembro de 2003. Então seus pais convocaram os familiares e amigos para, na igreja de Dom Bosco, perto de seu lar, anunciar-lhes que os médicos já nada mais podiam fazer: seu filho agora estava inteiramente nas mãos de Deus e de Nossa Senhora. O menino, perto do altar, ouviu tudo com o rosto sereno, ao mesmo tempo decidido e resignado, com a mesma cristã serenidade e resignação que tivera desde o começo de sua doença, sem jamais reclamar de sua situação ou de suas enormes dores.

Na noite de 13 de dezembro, Lucas teve um agravamento de seus problemas respiratórios, devendo ser levado com urgência ao Instituto de Oncologia Pediátrica. Em sua escrivaninha, ele deixava, em perfeita ordem, "santinhos" de Maria Auxiliadora, Dom Bosco, Santa Madre Paulina, Beato Frei Galvão, Sta. Rita de Cássia, São Benedito, Santo Expedito e a Novena de Nossa Senhora das Graças, sua devoção preferida.

Só levou consigo ao Hospital, como seus mais valiosos tesouros, a Medalha Milagrosa e o pequeno Menino Jesus. Em 14 de dezembro, domingo, recebeu de mãos de seu Pároco a Unção dos Enfermos. No dia seguinte, de manhã, cada vez com maiores dificuldades para respirar, entrou em agonia. Sempre lúcido, continuava segurando com suas mãozinhas a Medalha Milagrosa e o Menino Jesus. Percebendo que as forças o abandonavam, conseguiu sussurrar com dificuldade: "Mãe, me ajude a segurar o Menino Jesus..." Pouco depois, dava seu último suspiro.

O Menino Jesus, sem dúvida, retribuiu o afeto dessa alma inocente, levando-o consigo para passar o primeiro Natal no Céu.

Para Deus não existem heróis anônimos; mais ainda, Ele muitas vezes nos dá a possibilidade de conhecer essas vidas, para nossa edificação, e para nos ajudar, com seus exemplos, a enfrentar as enormes dificuldades do dia-a-dia. O pequeno Lucas foi um herói, apesar de ter só 9 anos: por sua fé, e pela inteira aceitação do misterioso e luminoso caminho da dor que a Providencia lhe preparou, trilhando os passos do Divino Mestre. O pequeno Lucas é, neste sentido, um grande exemplo para o Brasil.

Gonçalo Guimarães, autor deste artigo, é jornalista.

LINKS:

Para enviar uma mensagem aos pais e irmão do pequeno Lucas, clique em:

FamiliaDoLucas:MinhaMensagem

Para enviar ao autor do artigo sua valiosa opinião, clique aqui: ArtigoSobreLucas:MinhaOpiniao

Para receber gratuitamente, por e-mail, duas fotos de Lucas (uma com 6 anos, e outra, com 9, poucos dias antes de falecer), clique aqui:

DesejoReceberFotosDeLucas

Para ser retirado de nosso Address Book, clique em:

RetirarDoAddresBook

Nota: este artigo pode ser reproduzido parcial ou totalmente, de preferência, citando a fonte: Atualidade Brasileira.