From owner-namedroppers@ops.ietf.org Fri Nov 1 01:13:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29585 for ; Fri, 1 Nov 2002 01:13:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187Ulw-000IT4-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 21:55:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 187Ulu-000ISs-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 21:55:06 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 187Ulu-000KQB-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 21:55:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021031200717.E6EE4137F11@shell.nominum.com> To: namedroppers@ops.ietf.org Subject: Re: draft-reid-ipv6ok-00.txt From: Andreas.Gustafsson@nominum.com (Andreas Gustafsson) Date: Thu, 31 Oct 2002 12:07:17 -0800 (PST) X-Spam-Status: No, hits=-3.8 required=5.0 tests=RESENT_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] I don't see the point of draft-reid-ipv6ok-00. The draft seems to be based on the assumption that inclusion of AAAA records in a DNS response as a result of additional section processing would cause truncation and fallback to TCP, but that is not the case - see RFC2181 section 9: The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room. This includes the results of additional section processing. In such cases the entire RRSet that will not fit in the response should be omitted, and the reply sent as is, with the TC bit clear. Also, the draft seems to prohibit a server from returning AAAA records as part of the response to an QTYPE=ANY query by a non-ipv6ok-aware resolver (though I'm not sure if this is intentional or not). This would be a non-backwards-compatible change to the semantics of an ANY query. It would also make ANY queries much less useful for troubleshooting purposes (which is about the only thing they currently are useful for). Finally, it makes little sense to single out AAAA records to be omitted from the response to an ANY query out of size concerns while including much larger records such as KEY and SIG. -- 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 Fri Nov 1 06:10:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03385 for ; Fri, 1 Nov 2002 06:10:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187ZX1-000CLP-00 for namedroppers-data@psg.com; Fri, 01 Nov 2002 03:00:03 -0800 Received: from randy by psg.com with local (Exim 3.36 #2) id 187ZWz-000CL9-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 03:00:01 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Fri, 01 Nov 2002 03:00:01 -0800 X-Spam-Status: No, hits=-0.2 required=5.0 tests=SPAM_PHRASE_02_03,SUBJECT_IS_LIST version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. 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.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- 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 Nov 1 08:57:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07134 for ; Fri, 1 Nov 2002 08:57:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187c9T-000MlQ-00 for namedroppers-data@psg.com; Fri, 01 Nov 2002 05:47:55 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 187c9R-000MlE-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 05:47:53 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id C6E9F137F02; Fri, 1 Nov 2002 05:47:52 -0800 (PST) To: Kevin Darcy Cc: namedroppers@ops.ietf.org Subject: Re: Comment on draft-reid-ipv6ok-00.txt In-Reply-To: Message from Kevin Darcy of "Thu, 31 Oct 2002 11:11:08 EST." <3DC1561C.34CDA4C1@daimlerchrysler.com> Date: Fri, 01 Nov 2002 05:47:52 -0800 Message-ID: <41098.1036158472@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Kevin" == Kevin Darcy writes: Kevin> Why allocate a bit in the EDNS0 extended flags, which Kevin> you'll probably never be able to de-allocate/re-allocate? Because it's the best (or least-worst) way to indicate a resolver is AAAA aware. Kevin> Use an OPTION record instead. For an option which is Kevin> basically just boolean, it only takes up 4 octets (2 for Kevin> the option code and 2 for the length field); hardly enough Kevin> to break the bank, and when the option is no longer needed, Kevin> it can simply be phased out. Presumably you mean an OPT pseudo-RR as defined in RFC2671? Well the prime reason for not going down that road was that it would probably mean extra traffic and more latency. Clients are likely to be doing EDNS0 probes to negotiate bigger UDP payloads, especially when they can reasonably anticipate receiving a bigger payload because of AAAA or SIG records or whatever. So since there can only be one OPT RR per request/response, your suggestion would require another request/response to send some OPT record to indicate AAAA-awareness. That would have to be repeated for each DNS transaction. Unless the server kept state of course. But that would get ugly very quickly: suppose a client had two resolvers, one of which was AAAA-aware and another that wasn't. The second reason for using an EDNS0 bit was because they are available. And the precedent has already been set in RFC3225: using one of those bits to indicate DNSSEC-awareness. In fact much of the draft was shamelessly plagiarised from RFC3225. -- 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 Nov 1 09:03:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07576 for ; Fri, 1 Nov 2002 09:03:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187cIr-000NNC-00 for namedroppers-data@psg.com; Fri, 01 Nov 2002 05:57:37 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 187cIp-000NN0-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 05:57:35 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id A17A1137F02; Fri, 1 Nov 2002 05:57:34 -0800 (PST) To: "Eric A. Hall" Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-reid-ipv6ok-00.txt In-Reply-To: Message from "Eric A. Hall" of "Thu, 31 Oct 2002 10:11:03 CST." <3DC15617.7040506@ehsco.com> Date: Fri, 01 Nov 2002 05:57:34 -0800 Message-ID: <41164.1036159054@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Eric" == Eric A Hall writes: Eric> There isn't a lot of discussion on what the flag is supposed Eric> to cause to happen. Does it mean that whenever a server Eric> would normally return an A RR (either as answer or Eric> additional-data) that it should also return any available Eric> AAAA RRs for all of those names? If the bit was set, yes. Eric> What if the size of the answer will overload the EDNS Eric> message? That will put us back into the original problem Eric> case. Should the server not return the AAAA data, should the Eric> server give a truncated response using the existing rules, Eric> or what. Good point. We can fix that in the next version. Eric> On a broader note, include-AAAA-for-every-A implicitly Eric> updates several specifications which prescribe Eric> additional-data behavior. Even if this doesn't result in any Eric> significant problems, it may still be necessary to itemize Eric> (at the least) or discuss (at the worst) the impact of this Eric> change to those specifications. OTOH, if the intention is Eric> architecture -- facilitating standardized usage but not Eric> updating the default behavior for any existing Eric> specifications -- then that should be stated somewhere Eric> explicitly as well. Good point. We'll address that too. Eric> | More explicitly, IPv6-aware nameservers MUST NOT insert Eric> | AAAA RRs in a response unless the IO bit was set on the Eric> I request. Eric> Should be "MUST NOT insert [unsolicited] AAAA RRs" if I Eric> understand the model correctly. Yeah, though the next sentence in the draft does clarify this, albeit not clearly enough. -- 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 Nov 1 15:33:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03100 for ; Fri, 1 Nov 2002 15:33:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187iCY-0000hJ-00 for namedroppers-data@psg.com; Fri, 01 Nov 2002 12:15:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 187iCE-0000gu-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 12:15:10 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 187iCD-000GQV-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 12:15:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Date: Fri, 1 Nov 2002 10:49:28 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed changes to draft-ietf-dnsext-mdns-12.txt X-Spam-Status: No, hits=-3.1 required=5.0 tests=BALANCE_FOR_LONG_20K,RESENT_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Proposed Changes to draft-ietf-dnsext-mdns-12.txt Bernard Aboba Issue 12.1: LLMNR port usage Requester: Bernard Aboba Date: October 25, 2002 Section: 2, 2.2, 6.3, 7 Rationale for change: LLMNR currently operates on the same port as Apple's "Rendezvous" name resolution protocol. However, since these protocols are not compatible, this is inappropriate. The protocols also use the same multicast address for IPv4, but this is not an issue. Proposal: In section 2, change: "LLMNR queries are sent to and received on port 5353 using a LINKLOCAL address..." To: "LLMNR queries are sent to and received on port TBD using a LINKLOCAL address..." In section 2.2, change: "A responder listens on port 5353 on the LINKLOCAL address" To: "A responder listens on port TBD on the LINKLOCAL address" In section 6.3, change: "LLMNR operates on a separate port (5353) from DNS" To: "LLMNR operates on a separate port from DNS" In section 7, change: "Since it uses a port (5353) and link scope multicast IPv4 address (224.0.0.251) previously allocated for use with LLMNR, no additional IANA allocations are required." To: "LLMNR requires allocation of a port. LLMNR utilizes a link scope multicast IPv4 address (224.0.0.251) that has been previously allocated." Proposed resolution: accept ---------------------------------------------- Issue 12-2: Terminology Requester: Markku Savela Date: July 26, 2002 Section: 1.2 Rationale for change: 1.2. Terminology Responder A host that listens to (but not necessarily responds to) a LLMNR query is called "responder". Sender A host that sends an LLMNR query. The same host may be configured as a "sender", but not a "responder" and vice versa, i.e. as a "responder", but not a "sender". ----------------- I thought the idea was that each host knows it's own name and address and is an authority on those. Thus each host must be a 'responder'. But, if it cannot be 'sender' at same time, it cannot query any other names. And if host is a 'sender', it cannot listen and respond to queries that match its name? To me it seems that the most common and useful configuration would exactly be combined 'sender' + 'responder', which seems to be ruled out by above! Proposed change [From Dave Thaler]: Change: "Responder A host that listens to (but not necessarily responds to) a LLMNR query is called "responder". Sender A host that sends an LLMNR query. The same host may be configured as a "sender", but not a "responder" and vice versa, i.e. as a "responder", but not a "sender". " To: "Responder A host that listens to LLMNR queries, and responds to those for which it is authoritative is called "responder". Sender A host that sends an LLMNR query. Typically a host is configured as both a sender and a responder, but a host may be configured as a "sender", but not a "responder" or a "responder" but not a "sender". " Proposed resolution: Accept ---------------------------------------------- Issue 12-3: Dual stack implementation issues Requester: Markku Savela Date: July 26, 2002 Section: 2 Rationale for change: In [this section] I see again some confusion. Any DNS server either over IPv6 or over IPv4 can serve BOTH IPv6 and IPv4 queries. It does not matter whether this server was obtained through DHCPv4 or DCHPv6 (or by any other means). The corollary to this is that enabling both IPv4 and IPv6 LLMNR on the same link, means that you just have two "nameservers" to choose, and a host (sender) should be able send query to either one (regardless of the query type: A, AAAA or PTR). However, if it is expected that there are IPv4-only or IPv6-only hosts on the link, then it should send query to both "servers"? Does it send them in parallel or after one timeouts? Proposed change: [From Bernard Aboba] In section 2, change: "network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of IPv4 hosts on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of IPv6 hosts on the local network." To: "network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution over IPv4 on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution over IPv6 on the local network. Hosts supporting both IPv4 and IPv6 may send LLMNR queries over both IPv4 and IPv6 either in serial or in parallel, according to the implementation." Proposed resolution: Accept ---------------------------------------------------- Issue 12-4: Sending of NXRRSET Requester: Markku Savela Date: July 26, 2002 Section: 2.5 Rationale for change: "Since the responder MUST NOT respond to queries for names it is not authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR query with an NXRRSET. However, for other queries, such a response is possible; for example, if the host has a AAAA RR, but no MX RR, and an MX RR query is received." Perhaps, better or additional example would be "AAAA" and "A" (instead of "AAAA" and "MX"): e.g. "if the host has a AAAA RR, but no A RR, and an A RR query is received" (or vice versa). Proposed change: [From Levon Esibov] Change: "Since the responder MUST NOT respond to queries for names it is not authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR query with an NXRRSET. However, if the host has a AAAA RR, but no MX RR, and an MX RR query is received, the host would respond as follows: RCODE: NOERROR Answer: Authority: SOA for zone. Additional: Empty." To: "While the responder MUST NOT respond to queries for names it is not authoritative for, a responder MAY respond to a query for the name it is authoritative for, even if the type of query does not match a RR owned by the responder, with RCODE set to NXRRSET. For example, if the host has a AAAA RR, but no A RR, and an A RR query is received, the host would respond with RCODE set to NXRRSET." Proposed resolution: Accept ---------------------------------------------------- Issue 12-5: Concatenation of Responses Requester: Markku Savela Date: July 26, 2002 Section: 2.5 Rationale for change: The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When this occurs, the responses MAY first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would, ordinarily. Concatenated? Isn't receiving multiple replies an indication of a conflict? Two hosts on the link use same name? At least for A and AAAA queries? Proposed resolution: No change It is possible that there may be RRs owned by multiple responders, and therefore receiving multiple replies is not always evidence of a conflict. ---------------------------------------------------- Issue 12-6: LLMNR configuration Requester: Markku Savela Date: July 26, 2002 Section: 3.1 Rationale for change: LLMNR usage can be configured manually or automatically. On interfaces where no manual or automatic DNS configuration has been performed for a given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that protocol. Again the same confusion. DNS is not configured for single interface. When a host finds a DNS server address, it will apply to ALL interfaces. Thus, the logical conclusion is: if host has "real" DNS server address, then NONE of the interfaces can have LLNMR. Or, you have to accept the fact that in such situation you have both GLOBAL DNS and LLNMR applying to the same interface and specify sensible rules to deal with situation. [NOTE: I do realise there are such beasts as split DNS servers or intranet local servers, but handling these require some new "namespace" concepts that are not present in "standard traditional" DNS semantics and resolver stubs.] Proposed change: [From Dave Thaler] Change: "LLMNR usage can be configured manually or automatically. On interfaces where no manual or automatic DNS configuration has been performed for a given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that protocol. For IPv6, the stateless DNS discovery mechanisms described in "IPv6 Stateless DNS Discovery" [DNSDisc] or "Using DHCPv6 for DNS Configuration in Hosts" [DHCPv6DNS] can be used to discover whether LLMNR should be enabled or disabled on a per-interface basis." To: "LLMNR usage can be configured manually or automatically on a per interface basis. On an interface where no manual or automatic DNS configuration has been performed, LLMNR SHOULD be enabled." Proposed Resolution: Accept ---------------------------------------------------- Issue 12-7: Dual stack LLMNR configuration Requester: Markku Savela Date: July 26, 2002 Section: 3.1 Rationale for change: Note that it is possible for LLMNR to be enabled for use with IPv6 at the same time it is disabled for IPv4, and vice versa. Yes, but this just means that you have "LLMNR" over IPv4 or IPv6. You can still use either to query A or AAAA. Proposed change: [From Dave Thaler] Change: "Note that it is possible for LLMNR to be enabled for use with IPv6 at the same time it is disabled for IPv4, and vice versa. For example, a home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for DNS configuration [DHCPv6DNS] or stateless DNS discovery [DNSDisc]. In such a circumstance, IPv6 hosts will not be configured with a DNS server. Where DHCPv6 is not supported, the DNS proxy within the home gateway will not be able to dynamically register names learned via DHCPv6. As a result, unless the DNS proxy supports client dynamic update, it will not be able to respond to AAAA RR queries for local names sent over IPv4 or IPv6, preventing IPv6 hosts from resolving the names of other IPv6 hosts on the local link. In this situation, LLMNR enables resolution of dynamic names, and it will be enabled for use with IPv6, even though it is disabled for use with IPv4." To: "Note that it is possible for LLMNR to be enabled for use over IPv6 at the same time it is disabled over IPv4, or vice versa. For example, a home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for DNS configuration [DHCPv6DNS]. In such a circumstance, IPv6-only hosts will not be configured with a DNS server. Where DHCPv6 is not supported, the DNS proxy within the home gateway will not be able to dynamically register names learned via DHCPv6. As a result, unless the DNS proxy supports client dynamic update, it will not be able to respond to AAAA RR queries for local names sent over IPv4 or IPv6, preventing hosts from resolving the names of other IPv6-only hosts on the local link. In this situation, LLMNR enables resolution of dynamic names, and it will be enabled for use over IPv6, even though it is disabled for use over IPv4." Proposed resolution: Accept ---------------------------------------------------- Issue 12-8: Conflict resolution Requester: Markku Savela Date: July 26, 2002 Section: 5 Rationale for change: Where a host is configured to respond to LLMNR queries on more than one interface, the host MUST verify resource record uniqueness on each interface for each UNIQUE resource record that could be used on that interface. LLMNR is "LINK LOCAL MULTICAST NAME RESOLUTION". I think all text about synchronizing the names across links should be removed. Each link should have it's own independent LLMNR cache. Proposed change: [From Dave Thaler] In Section 5, Change: "Where a host is configured to respond to LLMNR queries on more than one interface, the host MUST verify resource record uniqueness on each interface for each UNIQUE resource record that could be used on that interface." To: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache. For each interface, the host MUST verify resource record uniqueness for each UNIQUE resource record in that interface's cache." In Section 6.3, change: "In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for LLMNR. The use of separate caches is most effective when LLMNR is used as a name resolution mechanism of last resort, since the this minimizes the opportunities for poisoning the LLMNR cache, and decreases reliance on it." To: "In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for LLMNR on each interface. The use of separate caches is most effective when LLMNR is used as a name resolution mechanism of last resort, since the this minimizes the opportunities for poisoning the LLMNR cache, and decreases reliance on it." Proposed Resolution: Accept ------------------------------------------------- Issue 12-9: Another conflict resolution issue Requester: Markku Savela Date: July 26, 2002 Section: 5, 2.1 Rationale for change: - multiple hosts may respond to a query for a SRV type record - multiple hosts may respond to a query for an A type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A type record for a hostname. When querying a name and getting multiple replies, how does host know whether name was "hostname" or "cluster name"? Each "...for an A type..." in above should be replaced with text "...for an A or AAAA type..." Proposed change: [From Bernard Aboba] In Section 5, Change: " - multiple hosts may respond to a query for a SRV type record - multiple hosts may respond to a query for an A type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A type record for a hostname." To: " - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a hostname." In Section 2.1, Change: "If the LLMNR query is not resolved during a limited amount of time (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. The default value for LLMNR_TIMEOUT is 1 second." To: ""If the LLMNR query is not resolved during a limited amount of time (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. The default value for LLMNR_TIMEOUT is 1 second. Since a sender cannot know beforehand whether it will receive no response, one response, or more than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the query answered after the first response is received." Proposed Resolution: Accept ------------------------------------------------- Issue 12-11: Confusion on dual stack behavior Requester: Markku Savela Date: July 26, 2002 Section: 1 Rationale for change: I may have other comments later, but first this: the introduction contains a paragraph: Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server for IPv4, while remaining unconfigured with a DNS server suitable for use with IPv6. ... I think this contains a fundamental misunderstanding how a nameresolving on the dual stack host works. If a dual stack host has even one DNS server address (either IPv4 or IPv6), it can be used for both IPv4 (A) and IPv6 (AAAA) queries. It makes no difference how this DNS server address was obtained (/etc/resolv.conf, DHCP, DHCPv6 or whatever). Proposed Change: [From Bernard Aboba]: Change: "Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server for IPv4, while remaining unconfigured with a DNS server suitable for use with IPv6." To: "While IPv4 and IPv6 utilize distinct configuration mechanisms, dual stack hosts share configuration, so that if a dual stack host has been configured with the address of a DNS server over IPv4, both A and AAAA queries will be sent to that server over IPv4." Proposed Resolution: Accept ------------------------------------------------- Issue 12-12: LLMNR Usage issues Requester: Markku Savela Date: July 26, 2002 Section: 6.2 Rationale for change: Having read and commented on , I think we might need a "Scoped name resolution reference model" or something, that specifies the framework for handling overlapping situations. - we have "traditional" global DNS - we have this new Link Local Name resolution - we may hava site local name resolution The includes some text about not having global DNS and LLMNR active at same time. This assumption requires highly special conditions (a closed meeting room without any outside network connections, permanently isolated network segments). In normal practise I would claim most useful ad hoc networks (bluetooth, wlan..) will also have occational access to the global internet and thus global DNS. There is a need to accept situation where a node can - has neither LLMNR nor global DNS - has LLMNR (on at least one link) - has global DNS - has both LLMNR and global DNS and node can transition between these states unpredictably. Then add possible site local DNS into this soup... It should be noted that LLMNR is somewhat different "taxonomically" from global DNS. LLMNR is P2P, global DNS is peer-to-server. One could consider P2P on site-local level (SLMNR?) or peer-to-server. Howabout global P2P name resolution, based on global multicast (yeah, does not scale? Unless you have IPSEC protected multicast group, and only limited membership :-) The reference model should tell how to behave in enviroment that has multiple enclosing name resolutions: - which order are queries sent (global -> site - > local or local -> site - > global, or something else?) - are gueries sent in parallel or one at time - how are conflicts handled (at least each level must have own cache, and each LLMNR must be cached separately per interface) [you can use from IPv6 scoped addressing architecture as cache id, for example] - if there are multiple LLMNR interfaces, how are queries handled? (send queries in parallel to all?) - can LLMNR contain only link local addresses in A and AAAA? Should name already tell the scope? Eg. only "*.local" names are resolved with LLMNR? "*.site"? Or can, any name "foo.bar.com" or address appear in any of the levels and you just get what is first found based on the search order? - what happens when some name resolution level becomes reachable or unreachable? Proposed Change: [From Bernard Aboba] In Section 1, change: "The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. These include scenarios in which hosts are not configured with the address of a DNS server. Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server for IPv4, while remaining unconfigured with a DNS server suitable for use with IPv6. Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] and [DNSDisc] are not yet widely deployed, such "partially configuration" may be common in the short term. However, in the long term, IPv6 DNS configuration will become more common so that LLMNR will typically be restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers are configured." To: "The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. These include scenarios in which hosts are not configured with the address of a DNS server, or where configured DNS servers do not reply to a query. Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server over IPv4, while remaining unconfigured with a DNS server suitable for use over IPv6. In these situations, a dual stack host will send AAAA queries to the configured DNS server over IPv4. However, an IPv6-only host will not be able to resolve names. Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] and [DNSDisc] are not yet widely deployed, and not all DNS servers support IPv6, "partial configuration" may be common in the short term, and LLMNR may prove useful in enabling linklocal name resolution over IPv6. However, in the long term, IPv6 DNS configuration, and DNS support over IPv6 will become more common so that LLMNR usage will typically be restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers are configured, and situations in which DNS servers do not respond to queries." In Section 2, change: "Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of IPv4 hosts on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of IPv6 hosts on the local network. This should be adequate as long as home gateways implementing DNS configuration also support dynamic DNS in some form. If the home gateway only supports DNS discovery [DNSDisc] but not DHCPv6 DNS configuration [DHCPv6DNS] or dynamic client update, then resolution of the names of IPv6 hosts on the local link will not be possible. Since IPv6 DNS discovery will configure the DNS server address, LLMNR will not be enabled by default. Yet without gateway support for client dynamic update or DHCPv6, dynamic DNS will not be enabled." To: "Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of hosts over IPv4 on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of hosts over IPv6 on the local network. This should be adequate as long as home gateways implementing DNS configuration also support dynamic DNS in some form." In Section 3.1.1, change: "It is possible that DNS servers and/or DNS configuration mechanisms will go in and out of service. In these circumstances, it is possible for hosts within an administrative domain to be inconsistent in their DNS configuration. For example, where DHCP is used for configuring DNS servers, one or more DHCP servers can go down. As a result, hosts configured prior to the outage will be configured with a DNS server, while hosts configured after the outage will use LLMNR. When the DHCP server comes back online, it is desirable that unconfigured hosts obtain their configuration from it. Alternatively, it is possible for the DNS configuration mechanism to continue functioning while the configured DNS servers fail. In this circumstance, it may be desirable for administrators to be able to reconfigure hosts to utilize alternative DNS servers. In order to minimize inconsistencies, the following practices are recommended: Periodic retry Unless unconfigured hosts periodically retry configuration, an outage in the DNS configuration mechanism will result in hosts continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents an unnecessary degradation in capabilities. As a result, it is recommended that hosts without a configured DNS server periodically attempt to obtain DNS configuration. The recommended default retry interval is 30 seconds. DNS failover For security reasons, by default LLMNR is not enabled for the resolution of FQDNs where a DNS server has been configured. This implies that where a DNS server has been configured, LLMNR will not be used by default for resolution of FQDNs, even in the event that all configured DNS servers fail. In this circumstance, it may desirable for hosts to retry DNS configuration, so as to discover alternative DNS servers, if they are available. If the configuration mechanism does not respond, hosts MAY enable LLMNR. However, if the configuration mechanism merely configures non- functioning DNS servers, this is not sufficient reason to enable default LLMNR usage, without an explicit indication that LLMNR usage is desired." To: "It is possible that DNS servers and/or DNS configuration mechanisms will go in and out of service. In these circumstances, it is possible for hosts within an administrative domain to be inconsistent in their DNS configuration. For example, where DHCP is used for configuring DNS servers, one or more DHCP servers can go down. As a result, hosts configured prior to the outage will be configured with a DNS server, while hosts configured after the outage will not. Alternatively, it is possible for the DNS configuration mechanism to continue functioning while configured DNS servers fail. In order to minimize inconsistencies, the following practices are recommended: Periodic retry Unless unconfigured hosts periodically retry configuration, an outage in the DNS configuration mechanism will result in hosts continuing to prefer LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents an unnecessary degradation in capabilities. As a result, it is recommended that hosts without a configured DNS server periodically attempt to obtain DNS configuration. DNS failover By default, LLMNR queries are not sent unless configured DNS servers have not responded. However, where all configured DNS servers fail, LLMNR queries will be sent." In Section 6, change: "LLMNR is by nature a peer to peer name resolution protocol, for use in situations when a DNS server is not configured. It is therefore inherently more vulnerable than DNS, since existing DNS security mechanisms are difficult to apply to LLMNR and an attacker only needs to be misconfigured to answer an LLMNR query with incorrect information." To: "LLMNR is by nature a peer to peer name resolution protocol. It is therefore inherently more vulnerable than DNS, since existing DNS security mechanisms are difficult to apply to LLMNR and an attacker only needs to be misconfigured to answer an LLMNR query with incorrect information." In Section 6.2, change: "As noted in Section 3.1, LLMNR is intended for usage in scenarios where a DNS server is not configured. If an interface has been configured for a given protocol via any automatic configuration mechanism which is able to supply DNS configuration information, then LLMNR SHOULD NOT be used on that interface for that protocol unless it has been explicitly enabled, whether via that mechanism or any other. This ensures that upgraded hosts do not change their default behavior, without requiring the source of the configuration information to be simultaneously updated. This implies that on the interface, the host will neither listen on the LINKLOCAL multicast address, nor will it send queries to that address. Violation of this guideline can significantly increases security vulnerabilities. For example, if an LLMNR query were to be sent whenever a DNS server did not respond in a timely way, then an attacker could execute a denial of service attack on the DNS server(s) and then poison the LLMNR cache by responding to the resulting LLMNR queries with incorrect information. The vulnerability would be even greater if LLMNR is given higher priority than DNS among the enabled name resolution mechanisms. In such a configuration, a denial of service attack on the DNS server would not be necessary in order to poison the LLMNR cache, since LLMNR queries would be sent even when the DNS server is available. In addition, the LLMNR cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is best thought of as a name resolution mechanism of last resort, useful only in situations where a DNS server is not configured. Where resilience against DNS server failure is desired, configuration of additional DNS servers or DNS server clustering is recommended; LLMNR is not an appropriate "failsafe" mechanism." To: "As noted in Section 3.1, LLMNR is intended for usage in scenarios where a DNS server is not configured or DNS servers do not respond to queries. If an interface has been configured via any automatic configuration mechanism which is able to supply DNS configuration information, then LLMNR MUST NOT be used as the primary name resolution mechanism on that interface, although it MAY be used as a secondary mechanism when DNS servers do not respond to queries. Note: enabling LLMNR for use in situations where a DNS server has been configured will result in upgraded hosts changing their default behavior without a simultaneous update to configuration information. Where this is considered undesirable, LLMNR SHOULD NOT be enabled by default, so that hosts will neither listen on the LINKLOCAL multicast address, nor will it send queries to that address. Use of LLMNR as a secondary name resolution mechanism increases security vulnerabilities. For example, if an LLMNR query wis sent whenever a DNS server does not respond in a timely way, then an attacker can execute a denial of service attack on the DNS server(s) and then poison the LLMNR cache by responding to the resulting LLMNR queries with incorrect information. The vulnerability is more serious if LLMNR is given higher priority than DNS among the enabled name resolution mechanisms. In such a configuration, a denial of service attack on the DNS server would not be necessary in order to poison the LLMNR cache, since LLMNR queries would be sent even when the DNS server is available. In addition, the LLMNR cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is best thought of as a secondary name resolution mechanism." Proposed Resolution: Discuss ------------------------------------------------- -- 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 Nov 1 18:15:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08048 for ; Fri, 1 Nov 2002 18:15:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187krO-000FR6-00 for namedroppers-data@psg.com; Fri, 01 Nov 2002 15:05:50 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #2) id 187krM-000FQi-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 15:05:48 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id gA1N5Pk05277 for ; Fri, 1 Nov 2002 18:05:25 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAeuaGtk; Fri, 1 Nov 02 18:05:25 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002110118054307647 for ; Fri, 01 Nov 2002 18:05:43 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gA1N5c418497 for ; Fri, 1 Nov 2002 18:05:38 -0500 (EST) Message-ID: <3DC30889.8B9DFA30@daimlerchrysler.com> Date: Fri, 01 Nov 2002 18:04:41 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Comment on draft-reid-ipv6ok-00.txt References: <41098.1036158472@shell.nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Reid wrote: > >>>>> "Kevin" == Kevin Darcy writes: > > Kevin> Why allocate a bit in the EDNS0 extended flags, which > Kevin> you'll probably never be able to de-allocate/re-allocate? > > Because it's the best (or least-worst) way to indicate a resolver is > AAAA aware. > > Kevin> Use an OPTION record instead. For an option which is > Kevin> basically just boolean, it only takes up 4 octets (2 for > Kevin> the option code and 2 for the length field); hardly enough > Kevin> to break the bank, and when the option is no longer needed, > Kevin> it can simply be phased out. > > Presumably you mean an OPT pseudo-RR as defined in RFC2671? Well the > prime reason for not going down that road was that it would probably > mean extra traffic and more latency. Clients are likely to be doing > EDNS0 probes to negotiate bigger UDP payloads, especially when they > can reasonably anticipate receiving a bigger payload because of AAAA > or SIG records or whatever. So since there can only be one OPT RR per > request/response, your suggestion would require another request/response > to send some OPT record to indicate AAAA-awareness. That would have to > be repeated for each DNS transaction. Unless the server kept state of > course. But that would get ugly very quickly: suppose a client had two > resolvers, one of which was AAAA-aware and another that wasn't. Actually, I meant OPTION records in the "variable" part of the original request's OPT pseudo-RR. See section 4.4 of RFC 2671. There would be no need for a subsequent request/response transaction. > The second reason for using an EDNS0 bit was because they are available. Well, they're available until they're all used up. AFAIK, there are 65536 available OPTION-CODEs but less than 16 bits (= 16 independent boolean options) available, because some have already been reserved or spoken for, in the extended flags. Which is going to be exhausted sooner? The set of protocol elements which deserve an extended flag is supposed to be a "small collection which we expect to be so popular that it would be a waste of wire space to encode them as {attribute, value} pairs" (quoting EDNS0 Section 4.2). I don't know that the protocol element you propose meets that very high requirement. > And the precedent has already been set in RFC3225: using one of those > bits to indicate DNSSEC-awareness. In fact much of the draft was > shamelessly plagiarised from RFC3225. I don't necessarily agree that RFC 3225 should be using extended-flags bits either, although the justification for that is probably stronger. - 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 Fri Nov 1 18:15:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08065 for ; Fri, 1 Nov 2002 18:15:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187ktq-000FdE-00 for namedroppers-data@psg.com; Fri, 01 Nov 2002 15:08:22 -0800 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #2) id 187kto-000Fd1-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 15:08:20 -0800 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gA1N8Fw21304 for ; Fri, 1 Nov 2002 15:08:15 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 1 Nov 2002 15:08:11 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gA1N8Bi29715 for ; Fri, 1 Nov 2002 15:08:11 -0800 (PST) Date: Fri, 1 Nov 2002 15:08:10 -0800 Mime-Version: 1.0 (Apple Message framework v546) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: when to use LLMNR From: Joshua Graessley To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've read through the latest LLMNR draft and a few things are unclear to me. In section 3, Usage Model, an implicit search order for unqualified names is given. This search order suggests appending the "current domain" and then querying for the unqualified name: > [1] Request the name with the current domain appended. > [2] Request just the name. It goes on to say: > The same host MAY use LLMNR queries for the resolution of unqualified > host names, and conventional DNS queries for resolution of other DNS > names.". How does one discern the difference between an unqualified name and a top level domain name? If someone wants to query for "com", should that be sent using conventional DNS or LLMNR? Are we changing the semantics of the APIs to require all top level domains to be specified as a fully qualified name (i.e. "com." instead of "com")? What is a "current domain". It is possible for a host to have multiple interfaces with separate configurations. Is the "current domain" a list of domains to be searched when an unqualified name is specified? This list can come from DHCP or be manually entered. If DHCPv4 and DHCPv6 are in use, there could be conflicts? This is a little off topic, but the point is that a user may not have a lot of control over the domain names appended to unqualified names. At the very least, there are a lot of sources of a "current domain" or current domains. It seems like the needs of multi-homed hosts are not fully covered by this draft. In section 3.1, "LLMNR configuration", the draft states: > LLMNR usage can be configured manually or automatically. On > interfaces where no manual or automatic DNS configuration has been > performed for a given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled > for that protocol. What does it mean to only enable LLMNR on an interface where no manual or automatic DNS configuration has been performed? DNS settings are not per-interface. When an API such as getaddrinfo is used, the client does not specify an interface. If a multi-homed host is connected to a configured network and an unconfigured network, it seems the desired behavior is nearly impossible to attain. In section 6.2, Usage Restrictions: > As noted in Section 3.1, LLMNR is intended for usage in scenarios where > a DNS server is not configured. If an interface has been configured > for > a given protocol via any automatic configuration mechanism which is > able > to supply DNS configuration information, then LLMNR SHOULD NOT be used > on that interface for that protocol unless it has been explicitly > enabled, whether via that mechanism or any other. This ensures that > upgraded hosts do not change their default behavior, without requiring > the source of the configuration information to be simultaneously > updated. This implies that on the interface, the host will neither > listen on the LINKLOCAL multicast address, nor will it send queries to > that address. If a multi-homed host is connected to a configured network and an unconfigured network, it may want to perform LLMNR to find hosts on the unconfigured network. This conflicts with the security concerns that suggest LLMNR should not be used. It is unclear if LLMNR could be used in this case, but only for unqualified names. If LLMNR is supposed to be used only for unqualified names, how does one resolve conflicts between an unqualified name resolved via LLMNR and the fully qualified name created by appending the "current domain". This limits, in very difficult to guess ways, the names that could be used with LLMNR on the unconfigured link. Example: My laptop has a wireless interface and an ethernet jack. I may have my ethernet jack connected to a network with a global IPv4 address and a DNS server both of which I received from a DHCP server. The DHCP server also told me that my current domain is "graessley.net". My wireless interface may be used only to connect to an 802.11 printer nearby. My printer may have a LLMNR name of "printer". Since I have a configured DNS server and a current domain, my resolver library will probably query "printer.graessley.net" before trying "printer". This makes it impossible to find my printer by name. It is unclear what names I could use for the printer. Any host that connects wirelessly to my printer may search any number of other domains if the host is also connected to another network. What am I overlooking? -josh -- 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 Nov 1 18:22:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08171 for ; Fri, 1 Nov 2002 18:22:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187l2b-000GXc-00 for namedroppers-data@psg.com; Fri, 01 Nov 2002 15:17:25 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 187l2Z-000GXQ-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 15:17:23 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA28487; Fri, 1 Nov 2002 18:17:22 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA28050; Fri, 1 Nov 2002 18:17:21 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id SAA02895; Fri, 1 Nov 2002 18:17:20 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA26091; Fri, 1 Nov 2002 18:17:20 -0500 (EST) To: Joshua Graessley Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: when to use LLMNR References: Date: 01 Nov 2002 18:17:20 -0500 In-Reply-To: Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-12.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Joshua Graessley writes: > How does one discern the difference between an unqualified name and a Qualified names end with a ".", i.e. "com." or "org." or "." (for the root). Unqualified names do NOT end with a . Note, however, this this is irrelevant. LLMNR is just another naming service, different from DNS as much as NIS/YP is diferent from DNS, which is just as different as /etc/hosts. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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 Nov 1 21:19:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12994 for ; Fri, 1 Nov 2002 21:19:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187ni5-0006Mp-00 for namedroppers-data@psg.com; Fri, 01 Nov 2002 18:08:25 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 187ni0-0006Md-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 18:08:20 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 187ni0-000PSq-00 for namedroppers@ops.ietf.org; Fri, 01 Nov 2002 18:08:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 1 Nov 2002 17:04:17 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Revised mDNS-12 changes X-Spam-Status: No, hits=-3.1 required=5.0 tests=BALANCE_FOR_LONG_20K,RESENT_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for the feedback on the proposed changes. Here is a reivsed change list, based on that feedback. Additional comments welcome. Proposed Changes to draft-ietf-dnsext-mdns-12.txt Bernard Aboba Issue 12.1: LLMNR port usage Requester: Bernard Aboba Date: October 25, 2002 Section: 2, 2.2, 6.3, 7 Rationale for change: LLMNR currently operates on the same port as Apple's "Rendezvous" name resolution protocol. However, since these protocols are not compatible, this is inappropriate. The protocols also use the same multicast address for IPv4, but this is not an issue. Proposal: In section 2, change: "LLMNR queries are sent to and received on port 5353 using a LINKLOCAL address..." To: "LLMNR queries are sent to and received on port TBD using a LINKLOCAL address..." In section 2.2, change: "A responder listens on port 5353 on the LINKLOCAL address" To: "A responder listens on port TBD on the LINKLOCAL address" In section 6.3, change: "LLMNR operates on a separate port (5353) from DNS" To: "LLMNR operates on a separate port from DNS" In section 7, change: "Since it uses a port (5353) and link scope multicast IPv4 address (224.0.0.251) previously allocated for use with LLMNR, no additional IANA allocations are required." To: "LLMNR requires allocation of a port. LLMNR utilizes a link scope multicast IPv4 address (224.0.0.251) that has been previously allocated to LLMNR by IANA." Proposed resolution: accept ---------------------------------------------- Issue 12-2: Terminology Requester: Markku Savela Date: July 26, 2002 Section: 1.2 Rationale for change: 1.2. Terminology Responder A host that listens to (but not necessarily responds to) a LLMNR query is called "responder". Sender A host that sends an LLMNR query. The same host may be configured as a "sender", but not a "responder" and vice versa, i.e. as a "responder", but not a "sender". ----------------- I thought the idea was that each host knows it's own name and address and is an authority on those. Thus each host must be a 'responder'. But, if it cannot be 'sender' at same time, it cannot query any other names. And if host is a 'sender', it cannot listen and respond to queries that match its name? To me it seems that the most common and useful configuration would exactly be combined 'sender' + 'responder', which seems to be ruled out by above! Proposed change [From Dave Thaler]: Change: "Responder A host that listens to (but not necessarily responds to) a LLMNR query is called "responder". Sender A host that sends an LLMNR query. The same host may be configured as a "sender", but not a "responder" and vice versa, i.e. as a "responder", but not a "sender". " To: "Responder A host that listens to LLMNR queries, and responds to those for which it is authoritative is called "responder". Sender A host that sends an LLMNR query. Typically a host is configured as both a sender and a responder, but a host may be configured as a "sender", but not a "responder" or a "responder" but not a "sender". " Proposed resolution: Accept ---------------------------------------------- Issue 12-3: Dual stack implementation issues Requester: Markku Savela Date: July 26, 2002 Section: 2 Rationale for change: In [this section] I see again some confusion. Any DNS server either over IPv6 or over IPv4 can serve BOTH IPv6 and IPv4 queries. It does not matter whether this server was obtained through DHCPv4 or DCHPv6 (or by any other means). The corollary to this is that enabling both IPv4 and IPv6 LLMNR on the same link, means that you just have two "nameservers" to choose, and a host (sender) should be able send query to either one (regardless of the query type: A, AAAA or PTR). However, if it is expected that there are IPv4-only or IPv6-only hosts on the link, then it should send query to both "servers"? Does it send them in parallel or after one timeouts? Proposed change: [From Bernard Aboba] In section 2, change: "network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of IPv4 hosts on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of IPv6 hosts on the local network." To: "network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. Home gateways can acquire A records by supporting DNS dynamic update, either by supporting dynamic client update of A RRs on the DNS proxy, or by supporting DHCPv4-based dynamic DNS update within the DNS proxy and DHCPv4 server implemented on the home gateway. This allows the home gateway to provide resolution of the names of IPv4 hosts on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway acquiring AAAA records, either by supporting dynamic client update of AAA RRs on the DNS proxy, or by supporting DHCPv6-based DNS update between a DNS proxy and DHCPv6 server implemented within the home gateway. This allows the home gateway to provide resolution of the names of IPv6 hosts on the local network. Hosts supporting both IPv4 and IPv6 may send LLMNR queries over both IPv4 and IPv6 either in serial or in parallel, according to the implementation." Proposed resolution: Accept ---------------------------------------------------- Issue 12-4: Sending of NXRRSET Requester: Markku Savela Date: July 26, 2002 Section: 2.5 Rationale for change: "Since the responder MUST NOT respond to queries for names it is not authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR query with an NXRRSET. However, for other queries, such a response is possible; for example, if the host has a AAAA RR, but no MX RR, and an MX RR query is received." Perhaps, better or additional example would be "AAAA" and "A" (instead of "AAAA" and "MX"): e.g. "if the host has a AAAA RR, but no A RR, and an A RR query is received" (or vice versa). Proposed change: [From Levon Esibov] Change: "Since the responder MUST NOT respond to queries for names it is not authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR query with an NXRRSET. However, if the host has a AAAA RR, but no MX RR, and an MX RR query is received, the host would respond as follows: RCODE: NOERROR Answer: Authority: SOA for zone. Additional: Empty." To: "While the responder MUST NOT respond to queries for names it is not authoritative for, a responder MAY respond to a query for the name it is authoritative for, even if the type of query does not match a RR owned by the responder, with RCODE set to NXRRSET. For example, if the host has a AAAA RR, but no A RR, and an A RR query is received, the host would respond with RCODE set to NXRRSET." Proposed resolution: Accept ---------------------------------------------------- Issue 12-5: Concatenation of Responses Requester: Markku Savela Date: July 26, 2002 Section: 2.5 Rationale for change: The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When this occurs, the responses MAY first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would, ordinarily. Concatenated? Isn't receiving multiple replies an indication of a conflict? Two hosts on the link use same name? At least for A and AAAA queries? Proposed resolution: No change It is possible that there may be RRs owned by multiple responders, and therefore receiving multiple replies is not always evidence of a conflict. ---------------------------------------------------- Issue 12-6: LLMNR configuration Requester: Markku Savela Date: July 26, 2002 Section: 3.1 Rationale for change: LLMNR usage can be configured manually or automatically. On interfaces where no manual or automatic DNS configuration has been performed for a given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that protocol. Again the same confusion. DNS is not configured for single interface. When a host finds a DNS server address, it will apply to ALL interfaces. Thus, the logical conclusion is: if host has "real" DNS server address, then NONE of the interfaces can have LLNMR. Or, you have to accept the fact that in such situation you have both GLOBAL DNS and LLNMR applying to the same interface and specify sensible rules to deal with situation. [NOTE: I do realise there are such beasts as split DNS servers or intranet local servers, but handling these require some new "namespace" concepts that are not present in "standard traditional" DNS semantics and resolver stubs.] Proposed change: [From Dave Thaler] Change: "LLMNR usage can be configured manually or automatically. On interfaces where no manual or automatic DNS configuration has been performed for a given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that protocol. For IPv6, the stateless DNS discovery mechanisms described in "IPv6 Stateless DNS Discovery" [DNSDisc] or "Using DHCPv6 for DNS Configuration in Hosts" [DHCPv6DNS] can be used to discover whether LLMNR should be enabled or disabled on a per-interface basis." To: "LLMNR usage can be configured manually or automatically on a per interface basis. By default, LLMNR SHOULD be enabled as a secondary name resolution mechanism, available for use when no manual or automatic DNS configuration has been performed, when configured DNS servers do not respond, or when they respond to a query with NXRRSET." Proposed Resolution: Accept ---------------------------------------------------- Issue 12-7: Dual stack LLMNR configuration Requester: Markku Savela Date: July 26, 2002 Section: 3.1 Rationale for change: Note that it is possible for LLMNR to be enabled for use with IPv6 at the same time it is disabled for IPv4, and vice versa. Yes, but this just means that you have "LLMNR" over IPv4 or IPv6. You can still use either to query A or AAAA. Proposed change: [From Dave Thaler] Change: "Note that it is possible for LLMNR to be enabled for use with IPv6 at the same time it is disabled for IPv4, and vice versa. For example, a home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for DNS configuration [DHCPv6DNS] or stateless DNS discovery [DNSDisc]. In such a circumstance, IPv6 hosts will not be configured with a DNS server. Where DHCPv6 is not supported, the DNS proxy within the home gateway will not be able to dynamically register names learned via DHCPv6. As a result, unless the DNS proxy supports client dynamic update, it will not be able to respond to AAAA RR queries for local names sent over IPv4 or IPv6, preventing IPv6 hosts from resolving the names of other IPv6 hosts on the local link. In this situation, LLMNR enables resolution of dynamic names, and it will be enabled for use with IPv6, even though it is disabled for use with IPv4." To: "A home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for DNS configuration [DHCPv6DNS]. In such a circumstance, IPv6-only hosts will not be configured with a DNS server. Where the DNS proxy does not support dynamic client update over IPv6 or DHCPv6-based dynamic update of the DNS proxy, the home gateway will not be able to dynamically register the names of IPv6 hosts. As a result, the DNS proxy will not be able to respond to AAAA RR queries sent over IPv4 or IPv6. This prevents hosts from resolving the names of IPv6-only hosts on the local link. In this situation, LLMNR over IPv6 can be used for resolution of dynamic names." Proposed resolution: Accept ---------------------------------------------------- Issue 12-8: Conflict resolution Requester: Markku Savela Date: July 26, 2002 Section: 5 Rationale for change: Where a host is configured to respond to LLMNR queries on more than one interface, the host MUST verify resource record uniqueness on each interface for each UNIQUE resource record that could be used on that interface. LLMNR is "LINK LOCAL MULTICAST NAME RESOLUTION". I think all text about synchronizing the names across links should be removed. Each link should have it's own independent LLMNR cache. Proposed change: [From Dave Thaler] In Section 5, Change: "Where a host is configured to respond to LLMNR queries on more than one interface, the host MUST verify resource record uniqueness on each interface for each UNIQUE resource record that could be used on that interface." To: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache. For each UNIQUE resource record in a given interface's cache, the host MUST verify resource record uniqueness on that interface." In Section 6.3, change: "In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for LLMNR. The use of separate caches is most effective when LLMNR is used as a name resolution mechanism of last resort, since the this minimizes the opportunities for poisoning the LLMNR cache, and decreases reliance on it." To: "In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for LLMNR on each interface. The use of separate caches is most effective when LLMNR is used as a name resolution mechanism of last resort, since the this minimizes the opportunities for poisoning the LLMNR cache, and decreases reliance on it." Proposed Resolution: Accept ------------------------------------------------- Issue 12-9: Another conflict resolution issue Requester: Markku Savela Date: July 26, 2002 Section: 5, 2.1 Rationale for change: - multiple hosts may respond to a query for a SRV type record - multiple hosts may respond to a query for an A type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A type record for a hostname. When querying a name and getting multiple replies, how does host know whether name was "hostname" or "cluster name"? Each "...for an A type..." in above should be replaced with text "...for an A or AAAA type..." Proposed change: [From Bernard Aboba] In Section 5, Change: " - multiple hosts may respond to a query for a SRV type record - multiple hosts may respond to a query for an A type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A type record for a hostname." To: " - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a hostname." In Section 2.1, Change: "If the LLMNR query is not resolved during a limited amount of time (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. The default value for LLMNR_TIMEOUT is 1 second." To: ""If the LLMNR query is not resolved during a limited amount of time (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. The default value for LLMNR_TIMEOUT is 1 second. Since a sender cannot know beforehand whether it will receive no response, one response, or more than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the query answered after the first response is received." Proposed Resolution: Accept ------------------------------------------------- Issue 12-11: Confusion on dual stack behavior Requester: Markku Savela Date: July 26, 2002 Section: 1 Rationale for change: I may have other comments later, but first this: the introduction contains a paragraph: Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server for IPv4, while remaining unconfigured with a DNS server suitable for use with IPv6. ... I think this contains a fundamental misunderstanding how a nameresolving on the dual stack host works. If a dual stack host has even one DNS server address (either IPv4 or IPv6), it can be used for both IPv4 (A) and IPv6 (AAAA) queries. It makes no difference how this DNS server address was obtained (/etc/resolv.conf, DHCP, DHCPv6 or whatever). Proposed Change: [From Bernard Aboba]: Change: "Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server for IPv4, while remaining unconfigured with a DNS server suitable for use with IPv6." To: "While IPv4 and IPv6 utilize distinct configuration mechanisms, dual stack hosts share configuration, so that if a dual stack host has been configured with the address of a DNS server over IPv4, both A and AAAA queries will be sent to that server over IPv4." Proposed Resolution: Accept ------------------------------------------------- Issue 12-12: LLMNR Usage issues Requester: Markku Savela Date: July 26, 2002 Section: 6.2 Rationale for change: Having read and commented on , I think we might need a "Scoped name resolution reference model" or something, that specifies the framework for handling overlapping situations. - we have "traditional" global DNS - we have this new Link Local Name resolution - we may hava site local name resolution The includes some text about not having global DNS and LLMNR active at same time. This assumption requires highly special conditions (a closed meeting room without any outside network connections, permanently isolated network segments). In normal practise I would claim most useful ad hoc networks (bluetooth, wlan..) will also have occational access to the global internet and thus global DNS. There is a need to accept situation where a node can - has neither LLMNR nor global DNS - has LLMNR (on at least one link) - has global DNS - has both LLMNR and global DNS and node can transition between these states unpredictably. Then add possible site local DNS into this soup... It should be noted that LLMNR is somewhat different "taxonomically" from global DNS. LLMNR is P2P, global DNS is peer-to-server. One could consider P2P on site-local level (SLMNR?) or peer-to-server. Howabout global P2P name resolution, based on global multicast (yeah, does not scale? Unless you have IPSEC protected multicast group, and only limited membership :-) The reference model should tell how to behave in enviroment that has multiple enclosing name resolutions: - which order are queries sent (global -> site - > local or local -> site - > global, or something else?) - are gueries sent in parallel or one at time - how are conflicts handled (at least each level must have own cache, and each LLMNR must be cached separately per interface) [you can use from IPv6 scoped addressing architecture as cache id, for example] - if there are multiple LLMNR interfaces, how are queries handled? (send queries in parallel to all?) - can LLMNR contain only link local addresses in A and AAAA? Should name already tell the scope? Eg. only "*.local" names are resolved with LLMNR? "*.site"? Or can, any name "foo.bar.com" or address appear in any of the levels and you just get what is first found based on the search order? - what happens when some name resolution level becomes reachable or unreachable? Proposed Change: [From Bernard Aboba] In Section 1, change: "The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. These include scenarios in which hosts are not configured with the address of a DNS server. Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server for IPv4, while remaining unconfigured with a DNS server suitable for use with IPv6. Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] and [DNSDisc] are not yet widely deployed, such "partially configuration" may be common in the short term. However, in the long term, IPv6 DNS configuration will become more common so that LLMNR will typically be restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers are configured." To: "The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. These include scenarios in which hosts are not configured with the address of a DNS server, where configured DNS servers do not reply to a query, or where they respond with RCODE set to NXRRSET. Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server over IPv4, while remaining unconfigured with a DNS server suitable for use over IPv6. In these situations, a dual stack host will send AAAA queries to the configured DNS server over IPv4. However, an IPv6-only host will not be able to resolve names. Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] and [DNSDisc] are not yet widely deployed, and not all DNS servers support IPv6, "partial configuration" may be common in the short term, and LLMNR may prove useful in enabling linklocal name resolution over IPv6. However, in the long term, IPv6 DNS configuration, and DNS support over IPv6 will become more common so that LLMNR usage will typically be restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers are configured, and situations in which DNS servers do not respond to queries." In Section 2, change: "Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of IPv4 hosts on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of IPv6 hosts on the local network. This should be adequate as long as home gateways implementing DNS configuration also support dynamic DNS in some form. If the home gateway only supports DNS discovery [DNSDisc] but not DHCPv6 DNS configuration [DHCPv6DNS] or dynamic client update, then resolution of the names of IPv6 hosts on the local link will not be possible. Since IPv6 DNS discovery will configure the DNS server address, LLMNR will not be enabled by default. Yet without gateway support for client dynamic update or DHCPv6, dynamic DNS will not be enabled." To: "Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of hosts over IPv4 on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of hosts over IPv6 on the local network. This should be adequate as long as home gateways implementing DNS configuration also support dynamic DNS in some form." In Section 3.1.1, change: "It is possible that DNS servers and/or DNS configuration mechanisms will go in and out of service. In these circumstances, it is possible for hosts within an administrative domain to be inconsistent in their DNS configuration. For example, where DHCP is used for configuring DNS servers, one or more DHCP servers can go down. As a result, hosts configured prior to the outage will be configured with a DNS server, while hosts configured after the outage will use LLMNR. When the DHCP server comes back online, it is desirable that unconfigured hosts obtain their configuration from it. Alternatively, it is possible for the DNS configuration mechanism to continue functioning while the configured DNS servers fail. In this circumstance, it may be desirable for administrators to be able to reconfigure hosts to utilize alternative DNS servers. In order to minimize inconsistencies, the following practices are recommended: Periodic retry Unless unconfigured hosts periodically retry configuration, an outage in the DNS configuration mechanism will result in hosts continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents an unnecessary degradation in capabilities. As a result, it is recommended that hosts without a configured DNS server periodically attempt to obtain DNS configuration. The recommended default retry interval is 30 seconds. DNS failover For security reasons, by default LLMNR is not enabled for the resolution of FQDNs where a DNS server has been configured. This implies that where a DNS server has been configured, LLMNR will not be used by default for resolution of FQDNs, even in the event that all configured DNS servers fail. In this circumstance, it may desirable for hosts to retry DNS configuration, so as to discover alternative DNS servers, if they are available. If the configuration mechanism does not respond, hosts MAY enable LLMNR. However, if the configuration mechanism merely configures non- functioning DNS servers, this is not sufficient reason to enable default LLMNR usage, without an explicit indication that LLMNR usage is desired." To: "It is possible that DNS servers and/or DNS configuration mechanisms will go in and out of service. In these circumstances, it is possible for hosts within an administrative domain to be inconsistent in their DNS configuration. For example, where DHCP is used for configuring DNS servers, one or more DHCP servers can go down. As a result, hosts configured prior to the outage will be configured with a DNS server, while hosts configured after the outage will not. Alternatively, it is possible for the DNS configuration mechanism to continue functioning while configured DNS servers fail. In order to minimize inconsistencies, the following practices are recommended: Periodic retry Unless unconfigured hosts periodically retry configuration, an outage in the DNS configuration mechanism will result in hosts continuing to prefer LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents an unnecessary degradation in capabilities. As a result, it is recommended that hosts without a configured DNS server periodically attempt to obtain DNS configuration. A default retry interval of two (2) minutes is recommended. DNS failover By default, LLMNR queries are not sent unless configured DNS servers have not responded. However, where all configured DNS servers fail, LLMNR queries will be sent." In Section 6, change: "LLMNR is by nature a peer to peer name resolution protocol, for use in situations when a DNS server is not configured. It is therefore inherently more vulnerable than DNS, since existing DNS security mechanisms are difficult to apply to LLMNR and an attacker only needs to be misconfigured to answer an LLMNR query with incorrect information." To: "LLMNR is by nature a peer to peer name resolution protocol. It is therefore inherently more vulnerable than DNS, since existing DNS security mechanisms are difficult to apply to LLMNR and an attacker only needs to be misconfigured to answer an LLMNR query with incorrect information." In Section 6.2, change: "As noted in Section 3.1, LLMNR is intended for usage in scenarios where a DNS server is not configured. If an interface has been configured for a given protocol via any automatic configuration mechanism which is able to supply DNS configuration information, then LLMNR SHOULD NOT be used on that interface for that protocol unless it has been explicitly enabled, whether via that mechanism or any other. This ensures that upgraded hosts do not change their default behavior, without requiring the source of the configuration information to be simultaneously updated. This implies that on the interface, the host will neither listen on the LINKLOCAL multicast address, nor will it send queries to that address. Violation of this guideline can significantly increases security vulnerabilities. For example, if an LLMNR query were to be sent whenever a DNS server did not respond in a timely way, then an attacker could execute a denial of service attack on the DNS server(s) and then poison the LLMNR cache by responding to the resulting LLMNR queries with incorrect information. The vulnerability would be even greater if LLMNR is given higher priority than DNS among the enabled name resolution mechanisms. In such a configuration, a denial of service attack on the DNS server would not be necessary in order to poison the LLMNR cache, since LLMNR queries would be sent even when the DNS server is available. In addition, the LLMNR cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is best thought of as a name resolution mechanism of last resort, useful only in situations where a DNS server is not configured. Where resilience against DNS server failure is desired, configuration of additional DNS servers or DNS server clustering is recommended; LLMNR is not an appropriate "failsafe" mechanism." To: "As noted in Section 3.1, LLMNR is intended for usage in scenarios where a DNS server is not configured or DNS servers do not respond to queries. If an interface has been configured via any automatic configuration mechanism which is able to supply DNS configuration information, then LLMNR MUST NOT be used as the primary name resolution mechanism on that interface, although it MAY be used as a secondary mechanism when DNS servers do not respond to queries. Note: enabling LLMNR for use in situations where a DNS server has been configured will result in upgraded hosts changing their default behavior without a simultaneous update to configuration information. Where this is considered undesirable, LLMNR SHOULD NOT be enabled by default, so that hosts will neither listen on the LINKLOCAL multicast address, nor will it send queries to that address. Use of LLMNR as a secondary name resolution mechanism increases security vulnerabilities. For example, if an LLMNR query wis sent whenever a DNS server does not respond in a timely way, then an attacker can execute a denial of service attack on the DNS server(s) and then poison the LLMNR cache by responding to the resulting LLMNR queries with incorrect information. The vulnerability is more serious if LLMNR is given higher priority than DNS among the enabled name resolution mechanisms. In such a configuration, a denial of service attack on the DNS server would not be necessary in order to poison the LLMNR cache, since LLMNR queries would be sent even when the DNS server is available. In addition, the LLMNR cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is best thought of as a secondary name resolution mechanism." Proposed Resolution: Discuss ------------------------------------------------- -- 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 Nov 3 17:35:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16205 for ; Sun, 3 Nov 2002 17:35:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188T0Q-0003Dx-00 for namedroppers-data@psg.com; Sun, 03 Nov 2002 14:14:06 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 188T0N-0003DY-00 for namedroppers@ops.ietf.org; Sun, 03 Nov 2002 14:14:04 -0800 Received: from [128.177.194.164] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 00610137F03 for ; Sun, 3 Nov 2002 14:13:33 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sun, 03 Nov 2002 14:15:45 -0800 Subject: and to require that a requestor MUST NOT mark a responder as non-EDNS-aware if it receives a S2671 problem (was Re: Re: Comment on draft-reid-ipv6ok-00.txt) From: David Conrad To: namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-8.0 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_LOCALPART_EQ_REAL,USER_AGENT, USER_AGENT_ENTOURAGE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11/1/02 3:04 PM, "Kevin Darcy" wrote: > I don't necessarily agree that RFC 3225 should be using extended-flags bits > either, although the justification for that is probably stronger. Actually, there is an issue here, applicable to both 3225 as well as draft-reid-ipv6ok. The use of a bit in the EDNS0 header can cause difficulties because the EDNS0 negotiation mechanism specified in RFC2671 is not reliable and may cause authoritative servers to occasionally be falsely identified as not supporting EDNS0. While this unreliability may be relatively harmless to other uses of EDNS0 such as the support for larger UDP packets, such a mis-identification can be fatal to DNSSEC resolution. There are two sources of EDNS0 negotiation failure to be considered. The first is due to the following definition in RFC2671: 5.3. Responders who do not understand these protocol extensions are expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. Therefore use of extensions should be "probed" such that a responder who isn't known to support them be allowed a retry with no extensions if it responds with such an RCODE. If a responder's capability level is cached by a requestor, a new probe should be sent periodically to test for changes to responder capability. It is entirely possible that an authoritative server will occasionally send a response with an RCODE of NOTIMPL, FORMERR, or SERVFAIL for a reason other than lack of EDNS0 support. For example, a SERVFAIL response might be returned by a server under excessive load or in the process of reloading a zone. When querying a forwarder rather than an authoritative server, SERVFAIL responses are particularly common since they can be caused by any kind of resolution failure. The second source of EDNS0 negotiation failure is the fact that practical EDNS0 aware resolvers, e.g., BIND 9, implement "EDNS blackhole detection" in order to deal with broken authoritative servers that silently drop EDNS0 queries rather than returning one of the three RCODEs above. This EDNS blackhole detection causes servers to be classified as not supporting EDNS0 after they have failed to respond to a number of EDNS0 queries, even though this failure to respond could in fact be caused by mere excessive server load or network packet loss. In accordance with section 5.3 of 2671, the resolver will cache the incorrect indication that the server does not support EDNS0. Therefore, a single EDNS0 mis-negotiation will not only cause a single query to fail, but also all subsequent queries involving the same name server until the EDNS0 information times out. When DNSSEC validation fails due to EDNS0 mis-negotiation, it may be very hard to diagnose the true cause of the failure. From the perspective of the client, it will be seen as a SERVFAIL response, indistinguishable from any number of other DNSSEC related and non-DNSSEC-related resolution errors. From the perspective of the DNSSEC aware resolver, the responses received from the server mistakenly identified as not supporting EDNS0 will be indistinguishable from correct responses in an insecure subdomain of a secure domain, and the DNSSEC validation will only fail when the resolver fails to obtain the DS nonexistence proof necessary to prove that the subdomain is indeed insecure. In practice, end users may see it as a significant number of random but persistent resolution failures in domains where DNSSEC is enabled. In the case of 3225, the original proposal for a DNSSEC negotiation mechanism that evolved into the RFC did not suffer from this problem as it used the AD bit in the request header to indicate DNSSEC support rather than relying on the unreliable EDNS0 negotiation mechanism. Reverting to that older mechanism would solve 3225's problem (albeit there are concerns with respect to broken servers copying the flag bits incorrectly). A more general solution, although only for the first source of failures, could be for EDNS-aware servers to send back some indication, e.g., an OPT RR, that they support EDNS in the SERVFAIL (et al) response to a request containing an OPT RR and to require that a requestor MUST NOT mark a responder as non-EDNS-aware if it receives a SERVFAIL (et al) response containing this indication. As for the second source of failures, it can be argued that BINDv9 has gone too far out of its way to support broken implementations and that servers that black hole EDNS queries instead of sending back some error response are too stupid to live. Thoughts? Rgds, -drc ------ End of Forwarded Message -- 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 Nov 3 18:10:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16673 for ; Sun, 3 Nov 2002 18:10:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188Tl9-0005IR-00 for namedroppers-data@psg.com; Sun, 03 Nov 2002 15:02:23 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 188Tl7-0005GH-00 for namedroppers@ops.ietf.org; Sun, 03 Nov 2002 15:02:21 -0800 Received: from [128.177.194.164] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id F3380137F03 for ; Sun, 3 Nov 2002 15:01:50 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sun, 03 Nov 2002 15:04:04 -0800 Subject: Oops. From: David Conrad To: namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-4.5 required=5.0 tests=INVALID_MSGID,IN_REP_TO,SPAM_PHRASE_00_01, TO_LOCALPART_EQ_REAL,USER_AGENT,USER_AGENT_ENTOURAGE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The subject of that last message should've been: 2671 problem (was Re: Re: Comment on draft-reid-ipv6ok-00.txt) Apologies. On 11/3/02 2:15 PM, "David Conrad" wrote: >[a long message] -- 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 Nov 4 01:51:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24821 for ; Mon, 4 Nov 2002 01:51:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188auN-000LKo-00 for namedroppers-data@psg.com; Sun, 03 Nov 2002 22:40:23 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #2) id 188auJ-000LKP-00 for namedroppers@ops.ietf.org; Sun, 03 Nov 2002 22:40:19 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 18F5A18C8 for ; Mon, 4 Nov 2002 01:40:18 -0500 (EST) Date: Mon, 04 Nov 2002 01:40:18 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: new version of draft-ietf-dnsext-dns-threats User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: multipart/mixed; boundary="Multipart_Mon_Nov__4_01:40:18_2002-1" Message-Id: <20021104064018.18F5A18C8@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.1 required=5.0 tests=PATCH_UNIFIED_DIFF,SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Multipart_Mon_Nov__4_01:40:18_2002-1 Content-Type: text/plain; charset=US-ASCII A new version of draft-ietf-dnsext-dns-threats is in the I-D queue to replace the expired version. Not a lot of change from the expired version (less than I had intended, ran out of time). For the record: my co-author had no input on these changes, they were all done by me, writing in haste to capture what I could of several recent discussions, so please don't blame Derek for any errors or omissions. Diff of the non-cosmetic stuff attached, for those who have read the previous versions. --Multipart_Mon_Nov__4_01:40:18_2002-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="diff" Content-Transfer-Encoding: 7bit --- draft-ietf-dnsext-dns-threats-01.txt Mon Nov 4 01:30:00 2002 +++ draft-ietf-dnsext-dns-threats-02.txt Mon Nov 4 01:30:00 2002 @@ -361,6 +361,39 @@ if we cannot conceive of a plausible scenario involving this attack today. This implies that some mitigation of this risk is required. + Note that it's necessary to prove the non-existance of applicable + wildcard RRs as part of the authenticated denial mechanism, and that, + in a zone that is more than one label deep, such a proof may require + proving the non-existance of multiple discrete sets of wildcard RRs. + +2.7. Wildcards + + Much discussion has taken place over whether and how to provide data + integrity and data origin authentication for "wildcard" DNS names. + Conceptually, RRs with wildcard names are patterns for synthesizing + RRs on the fly according to the matching rules described in section + 4.3.2 of RFC 1034. While the rules that control the behavior of + wildcard names have a few quirks that can make them a trap for the + unwary zone administrator, it's clear that a number of sites make + heavy use of wildcard RRs, particularly wildcard MX RRs. + + In order to provide the desired services for wildcard RRs, we need to + prove two things: + + - We need to prove the existance of the wildcard RR itself (that is, + we need to prove that the synthesis rule exists), and + + - We need to prove the non-existance of any RRs which, if they + existed, would make the wildcard RR irrelevant according to the + synthesis rules the way in which wildcards are used (that is, we + need to prove that the synthesis rule is applicable). + + Note that this makes the wildcard proof mechanism dependent upon the + authenticated denial mechanism described in the previous section. + + DNSSEC does include mechanisms by which it is possible to furnish + wildcard proofs along the lines described above. + 3. Weaknesses of DNSSEC DNSSEC has some problems of its own: @@ -414,6 +447,20 @@ generating signatures whose validity period does not match what the signer intended. + - The mechanism for wildcard proofs in DNSSEC is fairly painful. At + various times there have been questions as to whether the proof + mechanism is completely airtight and whether it would be worthwhile + to optimize the wildcard proof mechanism for the common case in + which wildcards do not exist, but the main problem is just the + inherent complexity of the wildcard mechanism itself. This + complexity probably makes the code for generating and checking + wildcard proofs somewhat fragile, but since the alternative of + giving up wildcards entirely is not practical due to widespread + use, we are going to have to live with wildcards, and the question + just becomes one of whether or not the proposed optimizations would + make DNSSEC's wildcard proof mechanisms more or less fragile. + + 4. Other issues [Odds and ends that don't yet fit anywhere else, to be revised...] @@ -465,12 +512,37 @@ to multiple entities, each of whom may require different kinds of access. For example, Alice may need to be able to add new nodes to the zone or change existing nodes, but not remove them; Bob may need - to be able to remove zones but not add them; Charlie may need to be + to be able to remove zones but not add them; Carol may need to be able to add, remove, or modify nodes, but only A records. NOTE: Scaling properties of the key management problem here is a particular concern that needs more study. +4.3. Securing DNS Zone Replication + + As discussed in previous sections, DNSSEC per se attempts to provide + data integrity and data origin authentication services on top of the + normal DNS query protocol. Using the terminology discussed in [SEC- + CONS], DNSSEC provides "object security" for the normal DNS query + protocol. For purposes of replicating entire DNS zones, however, + DNSSEC does not provide object security, because zones include + unsigned NS RRs and glue at delegation points. Use of TSIG to + protect zone transfer (AXFR or IXFR) operations provides "channel + security", but still does not provide object security for complete + zones, so the trust relationships involved in zone transfer are still + very much a hop-by-hop matter of name server operators trusting other + name server operators, rather than an end-to-end matter of name + server operators trusting zone administrators. + + Zone object security was not an explicit design goal of DNSSEC, so + failure to provide this service should not be a surprise. + Nevertheless, there are some zone replication scenarios for which + this would be a very useful additional service, so this seems like a + useful area for future work. In theory it should not be difficult to + zone object security as a backwards compatible enhancement to the + existing DNSSEC model, but the DNSEXT WG has not yet discussed either + the desirability of or the requirements for such an enhancement. + 5. Conclusion Based on the above analysis, the DNSSEC extensions do appear to solve @@ -488,12 +560,18 @@ Acknowledgments - This note is based both previous published works by others and on on - a number of discussions both public and private over a period of many + This note is based both previous published works by others and on a + number of discussions both public and private over a period of many years, but particular thanks go to Steve Bellovin, Dan Bernstein, - Randy Bush, Olafur Gudmundsson, Allison Mankin, Paul Vixie, and our - libel lawyers at the firm of Dewey, Chetham, & Howe, none of whom are - responsible for what the authors did with their ideas. + Randy Bush, Olafur Gudmundsson, Allison Mankin, Paul Vixie, and any + other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups + whose names and contributions the authors have forgotten, none of + whom are responsible for what the authors did with their ideas. + + The authors would also like to thank Paul Mockapetris and Xunhua + Wang, both of whom sent useful information to the authors, about + which the authors have, as yet, done absolutely nothing. We were + listening, really, we just ran out of time before the draft deadline. References @@ -548,6 +626,11 @@ [DNSSEC-ZONE-STATUS] Lewis, E., "DNS Security Extension Clarification on Zone Status" RFC 3090, March 2001. + [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture + Board, "Guidelines for Writing RFC Text on Security + Considerations", work in progress (draft-iab-sec-cons-01.txt), + October 2002. + Author's addresses: Derek Atkins --Multipart_Mon_Nov__4_01:40:18_2002-1-- -- 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 Nov 4 03:52:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06805 for ; Mon, 4 Nov 2002 03:52:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188ctu-000Oaw-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 00:48:02 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #2) id 188cts-000OaS-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 00:48:00 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15846; Mon, 4 Nov 2002 00:47:24 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gA48lNL20203; Mon, 4 Nov 2002 09:47:23 +0100 (MET) Date: Sun, 3 Nov 2002 19:52:43 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Proposed changes to draft-ietf-dnsext-mdns-12.txt To: Bernard Aboba Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 12-12: LLMNR Usage issues > Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] > and [DNSDisc] are not yet widely deployed, and not all DNS servers > support IPv6, "partial configuration" may be common in the short > term, and LLMNR may prove useful in enabling linklocal name resolution > over IPv6. However, in the long term, IPv6 DNS configuration, and DNS support > over IPv6 will become more common so that LLMNR usage will typically be > restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers are > configured, and situations in which DNS servers do not respond to queries." The above doesn't speculate about a future where names to global addresses can be resolved using DNS, but names to link-local addresses can only be resolved using LLMNR. The high-order question is whether the LLMNR spec should speculate about this future or not. 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 Mon Nov 4 03:59:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07047 for ; Mon, 4 Nov 2002 03:59:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188ctQ-000Oai-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 00:47:32 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 188ctO-000OaR-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 00:47:30 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17017; Mon, 4 Nov 2002 01:47:25 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gA48lOL20207; Mon, 4 Nov 2002 09:47:24 +0100 (MET) Date: Sun, 3 Nov 2002 19:59:10 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: when to use LLMNR To: Derek Atkins Cc: Joshua Graessley , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Note, however, this this is irrelevant. LLMNR is just another > naming service, different from DNS as much as NIS/YP is diferent > from DNS, which is just as different as /etc/hosts. Actually, IMHO *more* different than NIS/YP and /etc/hosts. For different naming services there is typically an administrator who is trying to prevent inconsistencies between the answers from the the different naming services. In some cases one naming service might contain a subset of another, but I don't know of a case where one naming service explicitly contains inconsistent information for the same name as another naming service. With LLMNR the operational use might cause inconsistent information by design, where www. can be effectively advertised by anybody using LLMNR and be different than the "managed" name service information for that name. 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 Mon Nov 4 05:43:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08609 for ; Mon, 4 Nov 2002 05:43:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188ecM-00017g-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 02:38:02 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #2) id 188ecC-00017E-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 02:37:57 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id gA4AbcB28950 for ; Mon, 4 Nov 2002 17:37:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id gA48eJ024081; Mon, 4 Nov 2002 15:41:40 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: ahh, the dreaded opt-in discussion again In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 2002 15:40:19 +0700 Message-ID: <24079.1036399219@munnari.OZ.AU> X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 25 Oct 2002 16:09:47 -0400 From: Edward Lewis Message-ID: I have been "not reading" this list for the past few weeks, just catching up, sorry for the late reply. | Debate: do we just live with this because "who in their right mind | would use BOTH wildcards AND opt-in in the SAME zone?" Yes. Or perhaps more appropriately, no-one sane is going to care whether wildcard names exist or not, in an op-in zone. If I can create any new name I like anyway (make it appear that the name exists), whether or not there would have been a wildcard is irrelevant. | Opt-in is beginning to seem more like a Quality of Service of DNS. | QOS for bandwidth has problems - as Randy Bush said at a DARPA PI | meeting panel last January, QoS means dropping packets in favor of | other packets. The problem is that dropping packets is not what | providers are there for. (I may have part of this wrong, the essence | is that QoS in bandwidth services runs counter to the aim of the | service.) That's the kind of nice sounding platitude that turns out to be completely wrong when you look at it more closely. Kind of like "Doctors are to save lives, not take them", which is all very fine in a perfect world, but given 5 patients, all about to die without immediate attention, and 3 doctors, then either the doctors attempt to look after all 5, in which case probably many of them die, or they look after the 3 with the best chances - choosing the other 2 to be sacrificed. Of course service providers are there to drop packets, that's their job, they just prefer not to tell people that, because it doesn't sound good. But the alternative in that case is to queue packets (or provide unlimited bandwidth, and that as an option isn't very likely). Queueing packets is just fine for a very short time, after that, packets are supposed to be dropped, and the ISP is supposed to do that. That's what TCP wants, it is how it detects congestion, it is what real time applications want (where delivery late is a waste if time), etc. QoS is just an attempt to give the service providers some kind of information to allow them to decide which packets to drop, rather than picking at random (kind of like the doctors selecting the patients with the best chances to survive). kre -- 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 Nov 4 05:53:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08785 for ; Mon, 4 Nov 2002 05:53:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188ekW-0001Or-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 02:46:28 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #2) id 188ekS-0001NP-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 02:46:25 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id gA4Ai9B04053; Mon, 4 Nov 2002 17:44:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id gA4Acs024493; Mon, 4 Nov 2002 17:39:03 +0700 (ICT) From: Robert Elz To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: Bob Halley , namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. In-Reply-To: <5.1.1.6.2.20021029113010.018fe478@localhost> References: <5.1.1.6.2.20021029113010.018fe478@localhost> <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 04 Nov 2002 17:38:54 +0700 Message-ID: <24491.1036406334@munnari.OZ.AU> X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA08785 Date: Tue, 29 Oct 2002 11:42:00 -0500 From: Message-ID: <5.1.1.6.2.20021029113010.018fe478@localhost> | Take following example | *.foo | c.b.foo. | | There is no RR at name b.foo. | does the wildcard match a.b.foo or does the presence in of b.foo in c.b.foo | terminate the wild card matching rule ? The latter, no match. This isn't even slightly unclear. 1034 refers to names (labels actually) only, and whether they exist or not, not to whether there's any data attached to them. The only way this can be confusing is if you somehow allow yourself to believe that a name can't exist without data attached to it. There is nothing in the DNS specs that would lead to that conclusion (though it is true that there's no way to generate a leaf label without attached data). kre -- 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 Nov 4 08:56:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13036 for ; Mon, 4 Nov 2002 08:56:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188hYA-0006RY-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 05:45:54 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #2) id 188hY8-0006RM-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 05:45:52 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gA4CgYS31655; Mon, 4 Nov 2002 04:42:34 -0800 Date: Mon, 4 Nov 2002 04:42:33 -0800 (PST) From: Bernard Aboba To: Erik Nordmark cc: namedroppers@ops.ietf.org Subject: Re: Proposed changes to draft-ietf-dnsext-mdns-12.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] > > and [DNSDisc] are not yet widely deployed, and not all DNS servers > > support IPv6, "partial configuration" may be common in the short > > term, and LLMNR may prove useful in enabling linklocal name resolution > > over IPv6. However, in the long term, IPv6 DNS configuration, and DNS support > > over IPv6 will become more common so that LLMNR usage will typically be > > restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers are > > configured, and situations in which DNS servers do not respond to queries." > > The above doesn't speculate about a future where names to global > addresses can be resolved using DNS, but names to link-local > addresses can only be resolved using LLMNR. > The high-order question is whether the LLMNR spec should speculate > about this future or not. Currently, the draft doesn't state what addresses an LLMNR responder will include in its A/AAAA RR query response. Are you suggesting that it should respond *only* with a linklocal address? BTW, a version of the draft with all changes applied is available here: http://www.drizzle.com/~aboba/dnsext/draft-ietf-dnsext-mdns-13.txt -- 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 Nov 4 09:23:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14081 for ; Mon, 4 Nov 2002 09:23:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188i1j-0007JR-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 06:16:27 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 188i1h-0007J7-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 06:16:25 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA4EGOYm032927; Mon, 4 Nov 2002 09:16:24 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA09761; Mon, 4 Nov 2002 09:16:19 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <200210251824.g9PIOAV03759@guam.araneus.fi> References: <200210251824.g9PIOAV03759@guam.araneus.fi> Date: Mon, 4 Nov 2002 09:15:04 -0500 To: gson@nominum.com (Andreas Gustafsson), Edward Lewis From: Edward Lewis Subject: Re: Handling of Unknown DNS RR Types Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.6 required=5.0 tests=FROM_AND_TO_SAME_6,IN_REP_TO,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:24 -0700 10/25/02, Andreas Gustafsson wrote: >Yes, this is deliberate and stems from the fact that the >interoperability issues of compression and DNSSEC canonicalization are >fundamentally different. Thanks for the explanation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 4 09:24:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14096 for ; Mon, 4 Nov 2002 09:24:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188i1f-0007J5-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 06:16:23 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 188i1b-0007It-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 06:16:21 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA4EGIYm032924; Mon, 4 Nov 2002 09:16:18 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA09756; Mon, 4 Nov 2002 09:16:15 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <5.1.1.6.2.20021028143526.01bbee40@localhost> References: <5.1.1.6.2.20021028143526.01bbee40@localhost> Date: Mon, 4 Nov 2002 09:15:04 -0500 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , Olaf Kolkman , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: DS and cache transparency. Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Status: No, hits=-6.1 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA14096 At 14:37 -0500 10/28/02, Ólafur Guðmundsson wrote: >At 14:12 2002-10-28, Olaf Kolkman wrote: > >> >> > My question is did we ever consciously decide to live with the >> >> > architectural constraints or is there still work to do on defining the >> >> > label magic? >> >> >> >> I'd rather live with the constraints and avoid the label voodoo. >> >>Perfect... >> >>Should the 'only DNSSEC in line of sight" constrain be made explicit >>in the DS draft? > >This is applies not just to DS but all DNSSEC Records and should >be mentioned in the DNSSEC-bis protocol document. Well, only the DS RR is the problem, but it condemns the other DNSSEC RR's as well. Because it may happen that a cache with a resolver that is unaware of the implications of the DS RR just might get asked to retrieve a DS RR for an aware resolver, I'm afraid that such a constraint is needed. (I hate constraints.) Because a resolver seeking a DS RR has to be smart enough to ask the parent and not the child zone, only aware resolvers should ever have to go look for a DS RR. And without the DS RR's available, the other records become useless. I hope this comment is in-line with the discussion. I'm not completely sure I grok the intent, but I think this is what is being asked here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 4 09:56:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15184 for ; Mon, 4 Nov 2002 09:56:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188iUL-0008Cm-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 06:46:01 -0800 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=msa) by psg.com with esmtp (Exim 3.36 #2) id 188iUI-0008CX-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 06:45:58 -0800 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA12218; Mon, 4 Nov 2002 16:45:40 +0200 Date: Mon, 4 Nov 2002 16:45:40 +0200 Message-Id: <200211041445.QAA12218@burp.tkv.asdf.org> From: Markku Savela To: aboba@internaut.com CC: namedroppers@ops.ietf.org In-reply-to: (message from Bernard Aboba on Mon, 4 Nov 2002 04:42:33 -0800 (PST)) Subject: What about PTR queries in draft-ietf-dnsext-mdns-12.txt? References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-6.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I assume that if you end up doing a address (fe80::1) to name query for IPv6, you end up sending a query to IPv6 multicast address generated from the hash of "1.0.0. ... 0.0.8.e.f.ip6.int" and because the hash is taken from the first label, this will be MD5 from "1"? (basicly only 16 different hashes are possible). IPv4 side you have for example "1.2.254.169.in-addr.arpa". Am I right assuming the "resolvers" on nodes have to deal also with these for link local name resolution? -- 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 Nov 4 10:45:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18745 for ; Mon, 4 Nov 2002 10:45:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188jKK-000GAg-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 07:39:44 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 188jI7-000G6b-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 07:37:27 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA4FaGYm038619; Mon, 4 Nov 2002 10:36:16 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA26719; Mon, 4 Nov 2002 10:36:13 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <24491.1036406334@munnari.OZ.AU> References: <5.1.1.6.2.20021029113010.018fe478@localhost> <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> <24491.1036406334@munnari.OZ.AU> Date: Mon, 4 Nov 2002 10:31:35 -0500 To: Robert Elz From: Edward Lewis Subject: Re: DNSSEC wildcard optimization. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't mean to argue with Robert, but I'd like a clarification. At 17:38 +0700 11/4/02, Robert Elz wrote: >The latter, no match. This isn't even slightly unclear. 1034 refers >to names (labels actually) only, and whether they exist or not, not to >whether there's any data attached to them. Could you give a document citation saying this? If it is there, it would be useful. For some reason, I haven't found it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 4 15:34:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05143 for ; Mon, 4 Nov 2002 15:34:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188nic-0001gb-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 12:21:06 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 188niZ-0001gO-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 12:21:03 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gA4KKdBM089734; Tue, 5 Nov 2002 07:20:41 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> To: Edward Lewis Cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , Olaf Kolkman , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DS and cache transparency. In-reply-to: Your message of "Mon, 04 Nov 2002 09:15:04 CDT." Date: Tue, 05 Nov 2002 07:20:39 +1100 X-Spam-Status: No, hits=-6.1 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 14:37 -0500 10/28/02, Ólafur Guðmundsson wrote: > >At 14:12 2002-10-28, Olaf Kolkman wrote: > > > >> >> > My question is did we ever consciously decide to live with the > >> >> > architectural constraints or is there still work to do on defining > the > >> >> > label magic? > >> >> > >> >> I'd rather live with the constraints and avoid the label voodoo. > >> > >>Perfect... > >> > >>Should the 'only DNSSEC in line of sight" constrain be made explicit > >>in the DS draft? > > > >This is applies not just to DS but all DNSSEC Records and should > >be mentioned in the DNSSEC-bis protocol document. > > Well, only the DS RR is the problem, but it condemns the other DNSSEC > RR's as well. Because it may happen that a cache with a resolver > that is unaware of the implications of the DS RR just might get asked > to retrieve a DS RR for an aware resolver, I'm afraid that such a > constraint is needed. (I hate constraints.) > > Because a resolver seeking a DS RR has to be smart enough to ask the > parent and not the child zone, only aware resolvers should ever have > to go look for a DS RR. And without the DS RR's available, the other > records become useless. > > I hope this comment is in-line with the discussion. I'm not > completely sure I grok the intent, but I think this is what is being > asked here. Getting only DS aware servers in the line of site is the small part of the problem. The main problem however is that you can't stop a non DS aware cache being asked about DS. You need to give back a answer to such a cache that will not result in it treating the server as lame. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > > -- > 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 Mon Nov 4 17:32:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11240 for ; Mon, 4 Nov 2002 17:32:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188pba-0007TG-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 14:21:58 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 188pbW-0007T4-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 14:21:54 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA4MLnYm054106; Mon, 4 Nov 2002 17:21:49 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA03247; Mon, 4 Nov 2002 17:21:46 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> References: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> Date: Mon, 4 Nov 2002 17:19:52 -0500 To: Mark.Andrews@isc.org, Edward Lewis From: Edward Lewis Subject: Re: DS and cache transparency. Cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , Olaf Kolkman , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.9 required=5.0 tests=FROM_AND_TO_SAME_6,IN_REP_TO,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:20 +1100 11/5/02, Mark.Andrews@isc.org wrote: > ... You need to give back a > answer to such a cache that will not result in it treating > the server as lame. I agree, but I stopped short of saying that because it's not a foregone conclusion that this will happen - I think. The code in one snapshot is susceptible to this because of how the code works, but my understanding is that this can be fixed. You're right, the problem is that a non-DS aware resolver will ask the child and not the parent, which leads to the problem. If nothing else, the resolver will get the wrong impression from the child, up to the possiblity that the child is lame. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 4 19:57:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17054 for ; Mon, 4 Nov 2002 19:57:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188ruZ-000G3m-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 16:49:43 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 188ruW-000G3T-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 16:49:40 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA08496; Mon, 4 Nov 2002 19:49:33 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA09188; Mon, 4 Nov 2002 19:47:11 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA06830; Mon, 4 Nov 2002 19:44:00 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id TAA04374; Mon, 4 Nov 2002 19:44:00 -0500 (EST) To: Edward Lewis Cc: Mark.Andrews@isc.org, =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= , Olaf Kolkman , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DS and cache transparency. References: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> Date: 04 Nov 2002 19:44:00 -0500 In-Reply-To: Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-10.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY,USER_AGENT,X_OSIRU_OPEN_RELAY version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Well, we can do the obvious "be liberal in what you accept" and if the child gets a request for its own DS it can recurse, response with the DS, and perhaps log the 'broken cache'. -derek Edward Lewis writes: > At 7:20 +1100 11/5/02, Mark.Andrews@isc.org wrote: > > ... You need to give back a > > answer to such a cache that will not result in it treating > > the server as lame. > > I agree, but I stopped short of saying that because it's not a > foregone conclusion that this will happen - I think. The code in one > snapshot is susceptible to this because of how the code works, but my > understanding is that this can be fixed. > > You're right, the problem is that a non-DS aware resolver will ask the > child and not the parent, which leads to the problem. If nothing > else, the resolver will get the wrong impression from the child, up to > the possiblity that the child is lame. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > > -- > 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: -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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 Tue Nov 5 01:58:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25984 for ; Tue, 5 Nov 2002 01:58:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188xTB-000E33-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 22:45:49 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #2) id 188xT9-000E2q-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 22:45:47 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 82EDD18E3 for ; Tue, 5 Nov 2002 01:45:46 -0500 (EST) Date: Tue, 05 Nov 2002 01:45:46 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: and to require that a requestor MUST NOT mark a responder as non-EDNS-aware if it receives a S2671 problem (was Re: Re: Comment on draft-reid-ipv6ok-00.txt) In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021105064546.82EDD18E3@thrintun.hactrn.net> X-Spam-Status: No, hits=-5.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, SUBJ_HAS_SPACES,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sun, 03 Nov 2002 14:15:45 -0800, David R. Conrad wrote: > ... > A more general solution, although only for the first source of failures, > could be for EDNS-aware servers to send back some indication, e.g., an OPT > RR, that they support EDNS in the SERVFAIL (et al) response to a request > containing an OPT RR and to require that a requestor MUST NOT mark a > responder as non-EDNS-aware if it receives a SERVFAIL (et al) response > containing this indication. This sounds like a reasonable approach. > As for the second source of failures, it can be argued that BINDv9 has gone > too far out of its way to support broken implementations and that servers > that black hole EDNS queries instead of sending back some error response > are too stupid to live. I'm inclined to agree with this argument. Resolvers making and caching guesses based on incomplete information seems to lead to interoperability problems sooner or later, as shown both by your example and by the otherwise unrelated issue of how queries for DS RRs interact with deployed lame server detection code. -- 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 Nov 5 01:58:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25998 for ; Tue, 5 Nov 2002 01:58:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188xPI-000Dra-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 22:41:48 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 188xPG-000DrO-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 22:41:46 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gA56faa1021126; Tue, 5 Nov 2002 07:41:36 +0100 Message-Id: <200211050641.gA56faa1021126@birch.ripe.net> To: Edward Lewis cc: Mark.Andrews@isc.org, =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , Olaf Kolkman , namedroppers@ops.ietf.org Subject: Re: DS and cache transparency. In-reply-to: Your message of Mon, 04 Nov 2002 17:19:52 EST. References: From: Olaf Kolkman X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Tue, 05 Nov 2002 07:41:35 +0100 X-RIPE-Spam-Status: NONE ; -1002 X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * You're right, the problem is that a non-DS aware resolver will ask * the child and not the parent, which leads to the problem. If nothing * else, the resolver will get the wrong impression from the child, up * to the possiblity that the child is lame. I think it's safe to conclude that we do not want to 'fix' this problem with a namespace hack so that the parent becomes authoritive for DS RRs. (e.g. by adding a null byte to the first label as somebody (Derek???) suggested) That was my initial question after all :-) --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 Nov 5 02:11:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05951 for ; Tue, 5 Nov 2002 02:11:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188xaQ-000Elu-00 for namedroppers-data@psg.com; Mon, 04 Nov 2002 22:53:18 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 188xaN-000ElV-00 for namedroppers@ops.ietf.org; Mon, 04 Nov 2002 22:53:16 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gA56qnBM000912; Tue, 5 Nov 2002 17:52:49 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211050652.gA56qnBM000912@drugs.dv.isc.org> To: Olaf Kolkman Cc: Edward Lewis , Mark_Andrews@isc.org, =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DS and cache transparency. In-reply-to: Your message of "Tue, 05 Nov 2002 07:41:35 BST." <200211050641.gA56faa1021126@birch.ripe.net> Date: Tue, 05 Nov 2002 17:52:49 +1100 X-Spam-Status: No, hits=-5.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > * You're right, the problem is that a non-DS aware resolver will ask > * the child and not the parent, which leads to the problem. If nothing > * else, the resolver will get the wrong impression from the child, up > * to the possiblity that the child is lame. > > > I think it's safe to conclude that we do not want to 'fix' this > problem with a namespace hack so that the parent becomes authoritive > for DS RRs. (e.g. by adding a null byte to the first label as somebody > (Derek???) suggested) > > That was my initial question after all :-) > > --Olaf I think that was the feeling of everyone that responded. Mark -- 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 Nov 5 06:21:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12144 for ; Tue, 5 Nov 2002 06:21:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1891XR-0001g6-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 03:06:29 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 1891XP-0001ft-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 03:06:27 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09904; Tue, 5 Nov 2002 06:03:57 -0500 (EST) Message-Id: <200211051103.GAA09904@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-rfc1886bis-01.txt Date: Tue, 05 Nov 2002 06:03:57 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * 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 Extensions to support IP version 6 Author(s) : S. Thomson, C. Huitema et al. Filename : draft-ietf-dnsext-rfc1886bis-01.txt Pages : 7 Date : 2002-11-4 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This document updates RFC 1886 [5]. Changes mainly consist in replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152 [6]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-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-rfc1886bis-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-rfc1886bis-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: <2002-11-4171105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc1886bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc1886bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171105.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 Nov 5 06:21:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12170 for ; Tue, 5 Nov 2002 06:21:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1891Xb-0001gi-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 03:06:39 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 1891XY-0001gM-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 03:06:36 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09929; Tue, 5 Nov 2002 06:04:06 -0500 (EST) Message-Id: <200211051104.GAA09929@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-02.txt Date: Tue, 05 Nov 2002 06:04:06 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * 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 et al. Filename : draft-ietf-dnsext-dnssec-records-02.txt Pages : 32 Date : 2002-11-4 This document is part of a family of documents that describe 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 KEY, DS, SIG, and NXT resource records. The purpose and format of each resource record is descibed 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-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-dnssec-records-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-dnssec-records-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: <2002-11-4171126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171126.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 Nov 5 06:21:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12196 for ; Tue, 5 Nov 2002 06:21:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1891XM-0001fq-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 03:06:24 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 1891XK-0001fd-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 03:06:22 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09890; Tue, 5 Nov 2002 06:03:52 -0500 (EST) Message-Id: <200211051103.GAA09890@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-delegation-signer-11.txt Date: Tue, 05 Nov 2002 06:03:52 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * 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 : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-11.txt Pages : 14 Date : 2002-11-4 The delegation signer (DS) resource record 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 the implications of this record on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC1035, RFC2535, RFC3008 and RFC3090. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-11.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-delegation-signer-11.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-delegation-signer-11.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: <2002-11-4171055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171055.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 Nov 5 06:22:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12281 for ; Tue, 5 Nov 2002 06:22:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1891XW-0001gK-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 03:06:34 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 1891XU-0001g8-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 03:06:32 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09916; Tue, 5 Nov 2002 06:04:02 -0500 (EST) Message-Id: <200211051104.GAA09916@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-02.txt Date: Tue, 05 Nov 2002 06:04:02 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * 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 Key-Signing Key (KSK) Flag Author(s) : O. Kolkman, J. Schlyter Filename : draft-ietf-dnsext-keyrr-key-signing-flag-02.txt Pages : 8 Date : 2002-11-4 With the DS record [1] the concept of key-signing and zone-signing keys has been introduced. Key-signing keys are the keys that sign the keyset only. In general, key-signing keys are the keys that are pointed to by DS records and are the first keys to be used when following a chain of trust into the zone. The key-signing keys only sign the KEY RRset at the apex of a zone, zone- signing keys sign all other data in a zone. We propose a flag to distinguish the key- signing key from other keys in the KEY RR set during DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-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-keyrr-key-signing-flag-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-keyrr-key-signing-flag-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: <2002-11-4171115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171115.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 Nov 5 08:51:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18508 for ; Tue, 5 Nov 2002 08:51:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1893s1-0009dX-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 05:35:53 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #2) id 1893rz-0009aO-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 05:35:51 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21668; Tue, 5 Nov 2002 05:35:20 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gA5DZJL09163; Tue, 5 Nov 2002 14:35:19 +0100 (MET) Date: Tue, 5 Nov 2002 14:32:21 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Proposed changes to draft-ietf-dnsext-mdns-12.txt To: Bernard Aboba Cc: Erik Nordmark , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Currently, the draft doesn't state what addresses an LLMNR responder will > include in its A/AAAA RR query response. Are you suggesting that it should > respond *only* with a linklocal address? I'm suggesting that we don't know the answer to that question yet. And the draft, by saying that the appicability is likely to be limited to adhoc networks, says that we do know the answer to the question. So leaving the applicability a bit more open-ended might be useful. Note that ideally we'd use global addresses for all application use, since limited scope addresses can cause problems for applications. But the thing I don't know is whether this will always be sufficient or whether there will be cases where it makes sense to use LLMNR to get a link-local address back even in cases when the network is connected to the Internet. 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 Tue Nov 5 10:15:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22683 for ; Tue, 5 Nov 2002 10:15:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1895H7-000Eux-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 07:05:53 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 1895H5-000Eul-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 07:05:52 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 90FC237A037 for ; Tue, 5 Nov 2002 15:05:51 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: and to require that a requestor MUST NOT mark a responder as non-EDNS-aware if it receives a S2671 problem (was Re: Re: Comment on draft-reid-ipv6ok-00.txt) In-Reply-To: Message from Rob Austein of "Tue, 05 Nov 2002 01:45:46 EST." <20021105064546.82EDD18E3@thrintun.hactrn.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 05 Nov 2002 15:05:51 +0000 Message-Id: <20021105150551.90FC237A037@as.vix.com> X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > A more general solution, although only for the first source of failures, > > could be for EDNS-aware servers to send back some indication, e.g., an OPT > > RR, that they support EDNS in the SERVFAIL (et al) response to a request > > containing an OPT RR and to require that a requestor MUST NOT mark a > > responder as non-EDNS-aware if it receives a SERVFAIL (et al) response > > containing this indication. > > This sounds like a reasonable approach. to me, as well. unless there are objections, i will incorporate this into EDNS1. > > As for the second source of failures, it can be argued that BINDv9 > > has gone too far out of its way to support broken implementations > > and that servers that black hole EDNS queries instead of sending > > back some error response are too stupid to live. > > I'm inclined to agree with this argument. Resolvers making and > caching guesses based on incomplete information seems to lead to > interoperability problems sooner or later, as shown both by your > example and by the otherwise unrelated issue of how queries for DS RRs > interact with deployed lame server detection code. also agreed. -- 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 Nov 5 10:33:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24113 for ; Tue, 5 Nov 2002 10:33:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1895cJ-000GF4-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 07:27:47 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1895cG-000GEL-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 07:27:46 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA5FRaYm067318; Tue, 5 Nov 2002 10:27:36 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA15475; Tue, 5 Nov 2002 10:27:35 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200211050652.gA56qnBM000912@drugs.dv.isc.org> References: <200211050652.gA56qnBM000912@drugs.dv.isc.org> Date: Tue, 5 Nov 2002 09:55:31 -0500 To: Mark.Andrews@isc.org, Olaf Kolkman From: Edward Lewis Subject: Re: DS and cache transparency. Cc: Edward Lewis , Mark_Andrews@isc.org, =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:52 +1100 11/5/02, Mark.Andrews@isc.org wrote: > I think that was the feeling of everyone that responded. me too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 5 10:37:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24344 for ; Tue, 5 Nov 2002 10:37:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1895cI-000GEz-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 07:27:46 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1895cE-000GEF-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 07:27:43 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA5FRbYm067323; Tue, 5 Nov 2002 10:27:37 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA15479; Tue, 5 Nov 2002 10:27:36 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> Date: Tue, 5 Nov 2002 10:02:49 -0500 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: damage - was Re: DS and cache transparency. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-8.0 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk First - see my response to Mark... At 19:44 -0500 11/4/02, Derek Atkins wrote: >Well, we can do the obvious "be liberal in what you accept" and if the >child gets a request for its own DS it can recurse, response with the >DS, and perhaps log the 'broken cache'. This doesn't apply here. Let me whiteboard it: resolver ------> old cache -------> authoritative server The liberal in what you accept policy would protect the resolver. But the entity at risk here is the old cache. The problem is that if the authoritative server answers as the BIND 7/22 snapshot[0] does, it is possible that a cetain sequence of queries by the resolver will "break" the old cache. The old cache will mark (all of) the authoritative server(s) as lame for "the" zone. Others then asking the old cache for data from that same zone will be told that the zone can't be found. [0] For those wanting to giggle at BIND, keep in mind that this is a snapshot, meaning it contains experimental code. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 5 12:27:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00518 for ; Tue, 5 Nov 2002 12:27:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1897Ir-000Ntt-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 09:15:49 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 1897Ip-000Ns4-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 09:15:47 -0800 Received: from [128.177.194.103] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 285E9137F04; Tue, 5 Nov 2002 09:15:17 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 05 Nov 2002 09:17:30 -0800 Subject: Re: and to require that a requestor MUST NOT mark a responder as non-EDNS-aware if it receives a S2671 problem (was Re: Re: Comment on draft-reid-ipv6ok-00.txt) From: David Conrad To: Paul Vixie , namedroppers Message-ID: In-Reply-To: <20021105150551.90FC237A037@as.vix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-4.6 required=5.0 tests=INVALID_MSGID,IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_ENTOURAGE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On 11/5/02 7:05 AM, "Paul Vixie" wrote: > to me, as well. unless there are objections, i will incorporate this into > EDNS1. Fine, as long as there is no objection to having an RFC that fixes EDNS0 too. Rgds, -drc -- 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 Nov 5 14:32:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07608 for ; Tue, 5 Nov 2002 14:32:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1899G3-0007lF-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 11:21:03 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 1899G1-0007l3-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 11:21:01 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 38AAF37A1C4; Tue, 5 Nov 2002 19:21:01 +0000 (GMT) From: Paul Vixie To: David Conrad Cc: namedroppers Subject: Re: and to require that a requestor MUST NOT mark a responder as non-EDNS-aware if it receives a S2671 problem (was Re: Re: Comment on draft-reid-ipv6ok-00.txt) In-Reply-To: Message from David Conrad of "Tue, 05 Nov 2002 09:17:30 PST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 05 Nov 2002 19:21:01 +0000 Message-Id: <20021105192101.38AAF37A1C4@as.vix.com> X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > to me, as well. unless there are objections, i will incorporate this into > > EDNS1. > > Fine, as long as there is no objection to having an RFC that fixes EDNS0 > too. i don't see any point in updating/fixing/rereleasing EDNS0. the implementation work folks would do to get such a fix into the field is equal in magnitude to the work they would have to do to get EDNS1 into the field. let's press forward. -- 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 Nov 5 14:55:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09106 for ; Tue, 5 Nov 2002 14:55:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1899eG-0009mM-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 11:46:04 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 1899eE-0009lc-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 11:46:02 -0800 Received: from [128.177.195.153] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8EF4C137F06; Tue, 5 Nov 2002 11:45:31 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 05 Nov 2002 11:47:45 -0800 Subject: 2671 problem (was a ridiculously long subject) From: David Conrad To: Paul Vixie Cc: namedroppers Message-ID: In-Reply-To: <20021105192101.38AAF37A1C4@as.vix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-8.1 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_ENTOURAGE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, On 11/5/02 11:21 AM, "Paul Vixie" wrote: >> Fine, as long as there is no objection to having an RFC that fixes EDNS0 >> too. > i don't see any point in updating/fixing/rereleasing EDNS0. I see a point because I'd like to see DNSSEC deployed in my lifetime. This bug will also have an impact on IPv6 deployment given IPv6 requires EDNS0. > the > implementation work folks would do to get such a fix into the > field is equal in magnitude to the work they would have to do to > get EDNS1 into the field. let's press forward. I do not believe there is consensus on EDNS1 (to put it mildly). I do not want to get bogged down in yet more IETF sludge. Can't we just fix the known problem I identified and, for once, not try to add a raft of other "features"? Rgds, -drc -- 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 Nov 5 17:22:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20390 for ; Tue, 5 Nov 2002 17:22:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189Bu1-000LtI-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 14:10:29 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #2) id 189Btz-000LsX-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 14:10:27 -0800 Received: from guam.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id gA5MAPt06628; Tue, 5 Nov 2002 14:10:25 -0800 (PST) Received: (from gson@localhost) by guam.araneus.fi (8.11.6/8.11.6) id gA5M9md06127; Tue, 5 Nov 2002 14:09:48 -0800 (PST) Date: Tue, 5 Nov 2002 14:09:48 -0800 (PST) Message-Id: <200211052209.gA5M9md06127@guam.araneus.fi> To: Paul Vixie Cc: namedroppers Subject: Re: 2671 problem (was a ridiculously long subject) In-Reply-To: <20021105192101.38AAF37A1C4@as.vix.com> References: <20021105192101.38AAF37A1C4@as.vix.com> X-Mailer: VM 7.07 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-10.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie wrote: > i don't see any point in updating/fixing/rereleasing EDNS0. the > implementation work folks would do to get such a fix into the > field is equal in magnitude to the work they would have to do to > get EDNS1 into the field. let's press forward. Speaking as an implementer, I strongly disagree with this statement. The changes needed to fix EDNS0 are trivial, while implementing EDNS1 would require major changes to recursive servers in particular, if it is implementable at all. The job of a DNS implementer is already extraordinarily difficult due both to the loose specification of the DNS in STD0013 and to the numerous extensions to the DNS protocol that have appeared over the last few years. One major difficulty in implementing a full resolver is defining a complete and correct algorithm for classifying and interpreting a DNS response, since each section of a DNS response can contain a bewildering jumble of records: The answer section can already contain CNAMEs, DNAMEs, synthetic CNAMEs, answers, SIGs of answers, SIGs of the CNAMEs and SIGs of DNAMEs in no particular order. The authority section can contain NSes, SOAs, NXTs proving the nonexistence of a type, NXTs proving the nonexistence of a name, NXTs proving the nonexistence of a wildcard, SIGs of the SOAs, and SIGs of the NXTs, DSes, and SIGs of DSes. Sorting all this out in a way that correctly handles the general case is already an extremely difficult task, and having to also deal with multiple answers in response to the multiple questions of EDNS1 would make it even worse if not completely impossible. The DNS protocol has numerous corner cases that the draft does not even begin to consider. For example, what if one of the multiple queries is a CNAME query? Should the CNAME be followed (as the non-CNAME query requires) or not (as the CNAME query requires)? What happens if one of the queries is for type DS, which has special lookup rules? If one or more of the query types does not exist, will the response have a DNSSEC nonexistence proof in the authority section? My suggestion is to fix EDNS0 and kill EDNS1. -- 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 Tue Nov 5 18:16:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24045 for ; Tue, 5 Nov 2002 18:16:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189Cp2-0001AC-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 15:09:24 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 189CoX-00017s-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 15:08:53 -0800 Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05679 for ; Tue, 5 Nov 2002 16:08:52 -0700 (MST) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5400LI0LMSHC@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 16:08:52 -0700 (MST) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H54000YWLMRXY@mail.sun.net> for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 16:08:52 -0700 (MST) Date: Tue, 05 Nov 2002 15:07:53 -0800 From: Alain Durand Subject: reverse tree DNS for IPv6... To: namedroppers@ops.ietf.org Message-id: <3DC84F49.2060900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT As highlighted in the DNSop wg in draft-durand-ngtrans-dns-issues-00.txt & draft-durand-ngtrans-dns-issues-01.txt (this draft needs to be rename draft-ietf-dnsop-ipv6-dns-isssues-..) a current IPv4 practise of end-user ISPs is to pre-populate the reverse tree DNS with records like dsl-customer-374.pop-12.isp.net Due to the size of Ipv6 adddres space, this practise is no more possible. Several solutions have been proposed so far, but all of them have serious drawbacks: - do not populate the reverse tree at all - only populate for some hosts - use wildcard DNS records - dynamically generate DNS records This is a new proposal that should not get in the way of DNSsec but would require some changes in the stub resolver library routines, getnameinfo and getaddrinfo. I would like to get feedback from the DNSext wg before I present this to DNSop. - Alain. ps: as this was first discussed with a few people last week at ARIN, it was too late to publish an Internet Draft, so here is an outline of the proposal. Note: this is a similar idea as described in RFC1101 DNS operational requirements: For each /64 network, in the delegated /64 reverse zone: a record: 0.0.0.0.0.0.0.0 IN PTR networkname and in the direct zone networkname IN AAAA xxxxxxxxxxx:0.0.0.0.0.0.0.0 SHOULD be in place. Stub resolver library changes: getaddrinfo(): - if a PTR exist for the IPv6 address, returns it. - else - split the IPv6 address into a /64 $prefix and an Interface ID $interfaceID (note $interfaceID is a pure hex string) - append Interface ID all zeros to $prefix to form $networkAddr - lookup a PTR for $networkAddr into $networkName - if it exists, return the string $InterfaceID "+" $networkName - else return non existant getnameinfo(): - only for AAAA lookups: - lookup AAAA for $name - if exist, retuns it - if not exist AND $name matches the syntax $interfaceID "+" non empty valid DNS name then: - check $interfaceID is a 64 bit long hex string - look AAAA for the RHS to $netAddr - if non existant, return error - if lower 64 bits non empty, return error - append $interfaceID to $netAddr into $Addr - return $Addr - else return non existant -- 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 Nov 6 00:14:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11055 for ; Wed, 6 Nov 2002 00:14:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189ILd-0006y0-00 for namedroppers-data@psg.com; Tue, 05 Nov 2002 21:03:25 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 189ILb-0006xo-00 for namedroppers@ops.ietf.org; Tue, 05 Nov 2002 21:03:23 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 68C9237A1C4 for ; Wed, 6 Nov 2002 05:03:22 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: 2671 problem (was a ridiculously long subject) In-Reply-To: Message from David Conrad of "Tue, 05 Nov 2002 11:47:45 PST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 06 Nov 2002 05:03:22 +0000 Message-Id: <20021106050322.68C9237A1C4@as.vix.com> X-Spam-Status: No, hits=-5.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_LOCALPART_EQ_REAL version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I do not believe there is consensus on EDNS1 (to put it mildly). the current EDNS1 proposal is just multiple queries. there was one dissenter who agreed that multiple queries was a good thing but disagreed that it solved the problem then under discussion. (you might be thinking of the previous EDNS1 proposal, but all of the controversial swill from that was pushed into EDNS2.) > I do not want to get bogged down in yet more IETF sludge. > > Can't we just fix the known problem I identified and, for once, not > try to add a raft of other "features"? yes. the simplest thing would be to fix this when EDNS0 goes from proposed to draft. -- 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 Nov 6 06:42:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13467 for ; Wed, 6 Nov 2002 06:42:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189ONh-0009Lh-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 03:29:57 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 189ONc-0009L7-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 03:29:53 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11792; Wed, 6 Nov 2002 06:27:21 -0500 (EST) Message-Id: <200211061127.GAA11792@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-dhcid-rr-06.txt Date: Wed, 06 Nov 2002 06:27:21 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * 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 : A DNS RR for encoding DHCP information (DHCID RR) Author(s) : M. Stapp, T. Lemon, A. Gustafsson Filename : draft-ietf-dnsext-dhcid-rr-06.txt Pages : 10 Date : 2002-11-5 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-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-dhcid-rr-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-dhcid-rr-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: <2002-11-5192744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5192744.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 Nov 6 07:11:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14567 for ; Wed, 6 Nov 2002 07:11:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189Owx-000BsV-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 04:06:23 -0800 Received: from 64-186-170-147-cust.nextweb.net ([64.186.170.147] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #2) id 189Owv-000BsJ-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 04:06:21 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 189G4U-0004VE-00; Tue, 05 Nov 2002 18:37:34 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Conrad Cc: Paul Vixie , namedroppers Subject: Re: 2671 problem (was a ridiculously long subject) References: <20021105192101.38AAF37A1C4@as.vix.com> Message-Id: Date: Tue, 05 Nov 2002 18:37:34 -0800 X-Spam-Status: No, hits=-4.1 required=5.0 tests=DATE_IN_PAST_06_12,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Fine, as long as there is no objection to having an RFC that fixes EDNS0 >>> too. >> i don't see any point in updating/fixing/rereleasing EDNS0. > > I see a point because I'd like to see DNSSEC deployed in my lifetime. This > bug will also have an impact on IPv6 deployment given IPv6 requires EDNS0. > >> the >> implementation work folks would do to get such a fix into the >> field is equal in magnitude to the work they would have to do to >> get EDNS1 into the field. let's press forward. > > I do not believe there is consensus on EDNS1 (to put it mildly). I do not > want to get bogged down in yet more IETF sludge. > > Can't we just fix the known problem I identified and, for once, not try to > add a raft of other "features"? i can dig it -- 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 Nov 6 08:07:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16172 for ; Wed, 6 Nov 2002 08:07:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189Pkl-000FM7-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 04:57:51 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #2) id 189Pkj-000FLu-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 04:57:49 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id gA6Cvgm26065; Wed, 6 Nov 2002 19:57:42 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id gA6CuE020781; Wed, 6 Nov 2002 19:56:15 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. In-Reply-To: References: <5.1.1.6.2.20021029113010.018fe478@localhost> <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> <24491.1036406334@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 2002 19:56:14 +0700 Message-ID: <20779.1036587374@munnari.OZ.AU> X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 4 Nov 2002 10:31:35 -0500 From: Edward Lewis Message-ID: | Could you give a document citation saying this? If it is there, it | would be useful. For some reason, I haven't found it. 1034 4.3.2 c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a the "*" label exists. The "ie" explains exactly what matters. That step is the only place where the wildcard is consulted. "label does not exist" is it. kre -- 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 Nov 6 10:21:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25950 for ; Wed, 6 Nov 2002 10:21:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189Rm3-000P69-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 07:07:19 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 189Rm0-000P5v-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 07:07:16 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA6F68Ym097283; Wed, 6 Nov 2002 10:06:08 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA02715; Wed, 6 Nov 2002 10:06:06 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20779.1036587374@munnari.OZ.AU> References: <5.1.1.6.2.20021029113010.018fe478@localhost> <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> <24491.1036406334@munnari.OZ.AU> <20779.1036587374@munnari.OZ.AU> Date: Wed, 6 Nov 2002 10:06:18 -0500 To: Robert Elz , Edward Lewis From: Edward Lewis Subject: Re: DNSSEC wildcard optimization. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-10.7 required=5.0 tests=GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I love it when specification writers hide details in parenthesized expressions. It just adds so much to a coder's quality of life. So I suppose that the below passage is saying: if QNAME is a.b.c.d.e and the zone has z.x.c.d.e (but nothing with abcde nor bcde and no data at cde): looking at the tree: 1st iteration | 2nd iteration | 3rd iteration search result | search result | search result e abcde branch to d | bcde br to d | cde br to d | | | d abcde branch to c | bcde br to c | cde br to c | | | c abcde no branch | bcde no branch | cde exact match----\ |\ | | | x y | | v | | | | z w a.b.c.d.e - a shorter match is possible (?-guessing) b.c.d.e - a shorter match is possible (?-ditto) c.d.e - an exact match exists, but no data sets match (QTYPE is not a member of the set of types at cde = the empty set.) I think the problem here is lack of clarity in "a match is impossible" until you break it down pictorially. At 19:56 +0700 11/6/02, Robert Elz wrote: > Date: Mon, 4 Nov 2002 10:31:35 -0500 > From: Edward Lewis > Message-ID: > > | Could you give a document citation saying this? If it is there, it > | would be useful. For some reason, I haven't found it. > >1034 4.3.2 > > c. If at some label, a match is impossible (i.e., the > corresponding label does not exist), look to see if a > the "*" label exists. > >The "ie" explains exactly what matters. That step is the only place >where the wildcard is consulted. "label does not exist" is it. > >kre -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 6 13:05:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04709 for ; Wed, 6 Nov 2002 13:05:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189UMU-000Cqs-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 09:53:06 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 189UMR-000Cof-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 09:53:03 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 36803137F02; Wed, 6 Nov 2002 09:52:33 -0800 (PST) To: Kevin Darcy Cc: namedroppers@ops.ietf.org Subject: Re: Comment on draft-reid-ipv6ok-00.txt In-Reply-To: Message from Kevin Darcy of "Fri, 01 Nov 2002 18:04:41 EST." <3DC30889.8B9DFA30@daimlerchrysler.com> Date: Wed, 06 Nov 2002 09:52:33 -0800 Message-ID: <63368.1036605153@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Kevin" == Kevin Darcy writes: >> Presumably you mean an OPT pseudo-RR as defined in RFC2671? Kevin> Actually, I meant OPTION records in the "variable" part of Kevin> the original request's OPT pseudo-RR. Of course you did. The caffeine hadn't kicked in when I sent that reply. Apologies. -- 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 Nov 6 16:31:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13224 for ; Wed, 6 Nov 2002 16:31:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189XFK-0003vn-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 12:57:54 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 189XFI-0003vb-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 12:57:52 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA27333; Wed, 6 Nov 2002 15:57:50 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA17125; Wed, 6 Nov 2002 15:57:50 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA20236; Wed, 6 Nov 2002 15:57:49 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id PAA08969; Wed, 6 Nov 2002 15:57:49 -0500 (EST) To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: damage - was Re: DS and cache transparency. References: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> Date: 06 Nov 2002 15:57:49 -0500 In-Reply-To: Message-ID: Lines: 52 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-10.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,USER_AGENT, X_OSIRU_OPEN_RELAY version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Let me alter your whiteboard drawing: resolver --> old-cache --> auth-server(child) --> auth-server(parent) If the auth-server(child) received a query for "IN DS" it can recurse the query to its parent and send the response back to the old-cache. In other words, as far as the old-cache is concerned, the auth-server(child) _IS_ responding with data. The "resolver" need never know the difference, and the old-cache will never mark auth-server(child) as lame. How does this not work (except for the fact that it breaks the authority abstraction, but there is no reason a child cannot 'cache' the DS from its parent as any over resolver/cache would). -derek Edward Lewis writes: > First - see my response to Mark... > > At 19:44 -0500 11/4/02, Derek Atkins wrote: > >Well, we can do the obvious "be liberal in what you accept" and if the > >child gets a request for its own DS it can recurse, response with the > >DS, and perhaps log the 'broken cache'. > > This doesn't apply here. Let me whiteboard it: > > > resolver ------> old cache -------> authoritative server > > The liberal in what you accept policy would protect the resolver. But > the entity at risk here is the old cache. The problem is that if the > authoritative server answers as the BIND 7/22 snapshot[0] does, it is > possible that a cetain sequence of queries by the resolver will > "break" the old cache. The old cache will mark (all of) the > authoritative server(s) as lame for "the" zone. Others then asking > the old cache for data from that same zone will be told that the zone > can't be found. > > [0] For those wanting to giggle at BIND, keep in mind that this is a > snapshot, meaning it contains experimental code. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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 Nov 6 16:39:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13674 for ; Wed, 6 Nov 2002 16:39:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189XgK-0006dY-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 13:25:48 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 189XgI-0006dL-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 13:25:46 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA6LPdYm011056; Wed, 6 Nov 2002 16:25:39 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA06038; Wed, 6 Nov 2002 16:25:38 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> Date: Wed, 6 Nov 2002 16:07:48 -0500 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: Re: damage - was Re: DS and cache transparency. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-12.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:57 -0500 11/6/02, Derek Atkins wrote: >Let me alter your whiteboard drawing: > > resolver --> old-cache --> auth-server(child) --> auth-server(parent) > >If the auth-server(child) received a query for "IN DS" it can recurse >the query to its parent and send the response back to the old-cache. True, but we've (or I've) left out part of the story. >In other words, as far as the old-cache is concerned, the >auth-server(child) _IS_ responding with data. The "resolver" need >never know the difference, and the old-cache will never mark >auth-server(child) as lame. The discussion on this kind of brokenness has assumed that the auth-servers are running in nonrecursive mode. Recursive ones did not have a problem during the workshop. >How does this not work (except for the fact that it breaks the >authority abstraction, but there is no reason a child cannot 'cache' >the DS from its parent as any over resolver/cache would). I'm sorry, I can't parse the above paragraph. Are you asking why, with a recursive child auth-server, is there a problem? There ain't any. If you turn recursion off, like any good auth-server operator should (;)), you'll have a problem - IF we stick with the failed-experimental code that kicked this all off in August. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 6 16:46:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13989 for ; Wed, 6 Nov 2002 16:46:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189XoS-0007Y0-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 13:34:12 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 189XoP-0007XA-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 13:34:09 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA15989; Wed, 6 Nov 2002 16:34:08 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA24512; Wed, 6 Nov 2002 16:30:54 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA19556; Wed, 6 Nov 2002 16:30:54 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA09048; Wed, 6 Nov 2002 16:30:54 -0500 (EST) To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: damage - was Re: DS and cache transparency. References: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> Date: 06 Nov 2002 16:30:54 -0500 In-Reply-To: Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-12.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > Are you asking why, with a recursive child auth-server, is there a > problem? There ain't any. If you turn recursion off, like any good > auth-server operator should (;)), you'll have a problem - IF we stick > with the failed-experimental code that kicked this all off in August. Basically, yes, that's what I was asking. Change the code so that an auth server will _ALWAYS_ recurse for _its own_ DS record? We're already adding special-case code for DS, why not add yet another special case? -derek > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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 Nov 6 17:16:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15167 for ; Wed, 6 Nov 2002 17:16:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189YJ8-000Amd-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 14:05:54 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 189YJ4-000AmR-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 14:05:50 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA6M5mYm012434; Wed, 6 Nov 2002 17:05:48 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA12204; Wed, 6 Nov 2002 17:05:48 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <200211042020.gA4KKdBM089734@drugs.dv.isc.org> Date: Wed, 6 Nov 2002 16:53:55 -0500 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: Re: damage - was Re: DS and cache transparency. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:30 -0500 11/6/02, Derek Atkins wrote: >Basically, yes, that's what I was asking. Change the code so that an >auth server will _ALWAYS_ recurse for _its own_ DS record? We're >already adding special-case code for DS, why not add yet another >special case? It's possible that the server may not have a route to the parent. (Even if just temporarily.) I wouldn't want a query to it to hang in that case. In addition - I believe[0] that the DS draft proposes a different solution that what failed in August. [0] The editor told me it does. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 6 17:58:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16237 for ; Wed, 6 Nov 2002 17:58:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189Z1l-000FIe-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 14:52:01 -0800 Received: from adsl-67-119-98-58.dsl.snfc21.pacbell.net ([67.119.98.58] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #2) id 189Z1i-000FGL-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 14:51:58 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id gA6MmHZs012493; Wed, 6 Nov 2002 14:48:17 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id gA6MmGKX012490; Wed, 6 Nov 2002 14:48:17 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Wed, 6 Nov 2002 14:48:16 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Derek Atkins cc: Edward Lewis , Subject: Re: damage - was Re: DS and cache transparency. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 6 Nov 2002, Derek Atkins wrote: > Edward Lewis writes: > > > Are you asking why, with a recursive child auth-server, is there a > > problem? There ain't any. If you turn recursion off, like any good > > auth-server operator should (;)), you'll have a problem - IF we stick > > with the failed-experimental code that kicked this all off in August. > > Basically, yes, that's what I was asking. Change the code so that an > auth server will _ALWAYS_ recurse for _its own_ DS record? We're > already adding special-case code for DS, why not add yet another > special case? You've got to be kidding. Having an authoritative-only server perform recursion is not a special case. It's an authoritative-only server. By definition, it doesn't do recursion. There's no requirement that it even knows how to do recursion or what its parent zone is. Note that this also causes other problems, since even if the server did the recursion, it would respond with AA=0, since it's not authoritative data, which would confuse the requestor, who was asking what it thought was the authoritive server. Brian -- 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 Nov 6 18:57:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17498 for ; Wed, 6 Nov 2002 18:57:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189ZvG-000LOU-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 15:49:22 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 189ZvD-000LOH-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 15:49:20 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gA6Nmw3L002915; Thu, 7 Nov 2002 10:48:58 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211062348.gA6Nmw3L002915@drugs.dv.isc.org> To: Edward Lewis Cc: Derek Atkins , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: damage - was Re: DS and cache transparency. In-reply-to: Your message of "Wed, 06 Nov 2002 16:53:55 CDT." Date: Thu, 07 Nov 2002 10:48:58 +1100 X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 16:30 -0500 11/6/02, Derek Atkins wrote: > >Basically, yes, that's what I was asking. Change the code so that an > >auth server will _ALWAYS_ recurse for _its own_ DS record? We're > >already adding special-case code for DS, why not add yet another > >special case? > > It's possible that the server may not have a route to the parent. > (Even if just temporarily.) I wouldn't want a query to it to hang in > that case. > > In addition - I believe[0] that the DS draft proposes a different > solution that what failed in August. I don't believe it solves the case where the a grandparent zone is being served by the child zone. You won't get a referral down to the parent zone. > [0] The editor told me it does. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > > -- > 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 Nov 6 20:37:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19349 for ; Wed, 6 Nov 2002 20:37:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189bVE-0006sa-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 17:30:36 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 189bVB-0006sF-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 17:30:33 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gA71URw24213; Wed, 6 Nov 2002 17:30:27 -0800 (PST) From: Bill Manning Message-Id: <200211070130.gA71URw24213@boreas.isi.edu> Subject: Re: damage - was Re: DS and cache transparency. In-Reply-To: from Brian Wellington at "Nov 6, 2 02:48:16 pm" To: Brian.Wellington@nominum.com (Brian Wellington) Date: Wed, 6 Nov 2002 17:30:27 -0800 (PST) Cc: derek@ihtfp.com, edlewis@arin.net, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.6 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > Basically, yes, that's what I was asking. Change the code so that an % > auth server will _ALWAYS_ recurse for _its own_ DS record? We're % > already adding special-case code for DS, why not add yet another % > special case? % % You've got to be kidding. % % Having an authoritative-only server perform recursion is not a special % case. It's an authoritative-only server. By definition, it doesn't do % recursion. There's no requirement that it even knows how to do recursion % or what its parent zone is. % % Note that this also causes other problems, since even if the server did % the recursion, it would respond with AA=0, since it's not authoritative % data, which would confuse the requestor, who was asking what it thought % was the authoritive server. % % Brian sorry for the clueless post, but isn't authority based on zone, not server. -- --bill -- 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 Nov 6 20:43:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19486 for ; Wed, 6 Nov 2002 20:43:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189bd7-0007aN-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 17:38:45 -0800 Received: from adsl-67-119-98-58.dsl.snfc21.pacbell.net ([67.119.98.58] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #2) id 189bd5-0007YI-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 17:38:43 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id gA71YsZs013087; Wed, 6 Nov 2002 17:34:54 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id gA71YsCM013084; Wed, 6 Nov 2002 17:34:54 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Wed, 6 Nov 2002 17:34:53 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Bill Manning cc: derek@ihtfp.com, , Subject: Re: damage - was Re: DS and cache transparency. In-Reply-To: <200211070130.gA71URw24213@boreas.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 6 Nov 2002, Bill Manning wrote: > % > Basically, yes, that's what I was asking. Change the code so that an > % > auth server will _ALWAYS_ recurse for _its own_ DS record? We're > % > already adding special-case code for DS, why not add yet another > % > special case? > % > % You've got to be kidding. > % > % Having an authoritative-only server perform recursion is not a special > % case. It's an authoritative-only server. By definition, it doesn't do > % recursion. There's no requirement that it even knows how to do recursion > % or what its parent zone is. > % > % Note that this also causes other problems, since even if the server did > % the recursion, it would respond with AA=0, since it's not authoritative > % data, which would confuse the requestor, who was asking what it thought > % was the authoritive server. > % > % Brian > > sorry for the clueless post, but isn't authority > based on zone, not server. Yes, but it's very common for a server to be authoritative for one or more zones and not support recursion at all. Presumably a server that acts as both an authority and a recursive server could do this, but would hit the second problem described above. Brian -- 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 Nov 6 23:57:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23509 for ; Wed, 6 Nov 2002 23:57:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189eaY-00038c-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 20:48:18 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 189eaX-000383-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 20:48:17 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 7DB1F37A037 for ; Thu, 7 Nov 2002 04:48:14 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: damage - was Re: DS and cache transparency. In-Reply-To: Message from Brian Wellington of "Wed, 06 Nov 2002 14:48:16 PST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 07 Nov 2002 04:48:14 +0000 Message-Id: <20021107044814.7DB1F37A037@as.vix.com> X-Spam-Status: No, hits=-6.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Having an authoritative-only server perform recursion is not a special > case. It's an authoritative-only server. By definition, it doesn't do > recursion. There's no requirement that it even knows how to do recursion > or what its parent zone is. not only that. authority and recursion by the same server instance is ill defined in the 1034/1035 docs. (if you are authoritative for vix.com and there's a zone cut at lh.vix.com and someone asks you for xx.lh.vix.com do you send a referral or do the recursion?) ideally, a subsequent version of bind9 will become strictly modal -- recursive, or authoritative, but never both. unfortunately, historical configs would become incompatible, so it's unlikely to happen as soon as i'd like. -- 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 Nov 7 02:40:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06185 for ; Thu, 7 Nov 2002 02:40:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189hCj-000NFw-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 23:35:53 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #2) id 189hCe-000NFh-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 23:35:48 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id gA77ZWm13524; Thu, 7 Nov 2002 14:35:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id gA77Xs024084; Thu, 7 Nov 2002 14:33:55 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. In-Reply-To: References: <5.1.1.6.2.20021029113010.018fe478@localhost> <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> <24491.1036406334@munnari.OZ.AU> <20779.1036587374@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 2002 14:33:54 +0700 Message-ID: <24082.1036654434@munnari.OZ.AU> X-Spam-Status: No, hits=-5.2 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_03_05 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 6 Nov 2002 10:06:18 -0500 From: Edward Lewis Message-ID: | I love it when specification writers hide details in parenthesized | expressions. It just adds so much to a coder's quality of life. Yes. Saying that 103[45] aren't perfect isn't news... But nor were lots of RFCs of that vintage. | So I suppose that the below passage is saying: Sorry, I can't interpret your explanation, something has gotten lost somewhere. But the algorithm is simple. You have a DNS name tree, and a QNAME. Start at the rhs of the QNAME, and the root of the tree. Match the rightmost label in the QNAME against the sub-domains of the root. Each time you get a match (equality) you remove (figuratively) the label you just found and move down the tree to its node. If that leaves an empty QNAME, then you return whatever (appropriate) data exists at the node you're at (just moved to) (ie: success). (If you're not auth for the node, and not recursive, then "appropriate" would be a referral). When you don't get a match (ie: there is no sub-domain of the current node in the tree that is exactly the same (after case independence is allowed for of course) as the label you have from QNAME), what you do depends upon your auth status for the zone containing the node in question. If you aren't auth, then you send a referral (or if you're being recursive, you make a query). If you are auth, then you look and see if the current node in the tree (and no others) has a '*' sub-domain in the zone (ie: a wildcard exists). If it does, then you use whatever data (RRs) exist for the wildcard as the answer for the (whole) QNAME from the query. If there's no wildcard directly under the current node, then you NXDOMAIN. Note: this explanation assumes a slightly different data structure than the one assumed by 1034, but the effect is the same I believe. | I think the problem here is lack of clarity in "a match is | impossible" until you break it down pictorially. It just means "there is no label equal to the one being sought". kre -- 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 Nov 7 02:46:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06293 for ; Thu, 7 Nov 2002 02:46:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189hBM-000N6L-00 for namedroppers-data@psg.com; Wed, 06 Nov 2002 23:34:28 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 189hBJ-000MxH-00 for namedroppers@ops.ietf.org; Wed, 06 Nov 2002 23:34:25 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id gA77WxJc020886; Thu, 7 Nov 2002 08:32:59 +0100 Date: Thu, 7 Nov 2002 09:32:59 +0100 From: "Olaf M. Kolkman" To: Edward Lewis Cc: kre@munnari.OZ.AU, edlewis@arin.net, namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. Message-Id: <20021107093259.4f3cdd55.olaf@ripe.net> In-Reply-To: References: <5.1.1.6.2.20021029113010.018fe478@localhost> <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> <24491.1036406334@munnari.OZ.AU> <20779.1036587374@munnari.OZ.AU> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: NONE ; -1004 X-Spam-Status: No, hits=-7.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI, in Apendix A.1.2. of version 01 of the draft (still in the drafts queue but available on: http://www.ripe.net/disi/Notes/draft-olaf-dnsext-dnssec-wildcard-optimization-01.html=anchor17) I have added an example of the denial of wildcard proof as, I think, it is supposed to be given. As it is bind 9.3s20020722 returns a few answers to many. I hope that the argumentation is clear enough, and correct. --Olaf PS. In version 01 we have tried to clarify servers MAY choose to not use the optimizations but that resolvers MUST understand the optimisation. Besides we have changed the typecode from SIG to NOWILD, which had as a consequence that the optimization takes place when the bit is set to 1 iso 0. Finally DDNS considerations where added. PSS. Roy and Johan did not have a change to look at the document before the deadline, all errors that sneaked in after 00 are to blame on me. :-) --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- 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 Nov 7 06:37:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12134 for ; Thu, 7 Nov 2002 06:37:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189kke-000I5u-00 for namedroppers-data@psg.com; Thu, 07 Nov 2002 03:23:08 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 189kkb-000I58-00 for namedroppers@ops.ietf.org; Thu, 07 Nov 2002 03:23:06 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10059; Thu, 7 Nov 2002 06:20:34 -0500 (EST) Message-Id: <200211071120.GAA10059@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-opt-in-04.txt Date: Thu, 07 Nov 2002 06:20:34 -0500 X-Spam-Status: No, hits=3.4 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,OPT_IN,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: *** 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 Opt-in Author(s) : R. Arends, M. Kosters, D. Blacka Filename : draft-ietf-dnsext-dnssec-opt-in-04.txt Pages : 21 Date : 2002-11-6 In RFC 2535, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an 'Opt-In' model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-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-opt-in-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-opt-in-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: <2002-11-6173823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6173823.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 Nov 7 10:07:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27147 for ; Thu, 7 Nov 2002 10:07:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189o6G-000C3B-00 for namedroppers-data@psg.com; Thu, 07 Nov 2002 06:57:40 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 189o6E-000C1U-00 for namedroppers@ops.ietf.org; Thu, 07 Nov 2002 06:57:38 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA7EvXYm024867; Thu, 7 Nov 2002 09:57:33 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA20510; Thu, 7 Nov 2002 09:57:31 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200211062348.gA6Nmw3L002915@drugs.dv.isc.org> References: <200211062348.gA6Nmw3L002915@drugs.dv.isc.org> Date: Thu, 7 Nov 2002 09:57:40 -0500 To: Mark.Andrews@isc.org, Edward Lewis From: Edward Lewis Subject: Re: damage - was Re: DS and cache transparency. Cc: Derek Atkins , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.6 required=5.0 tests=FROM_AND_TO_SAME_6,IN_REP_TO,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:48 +1100 11/7/02, Mark.Andrews@isc.org wrote: > I don't believe it solves the case where the a grandparent zone > is being served by the child zone. You won't get a referral > down to the parent zone. Hmm, an interesting case. You're saying that: server: zone "d.e" { type master; ....} zone "b.c.d.e" { type master; ....} query {b.c.d.e, DS RR, IN} Since the authority is c.d.e for the query answer, yeah, this is scary. What if c.d.e is run on an server not aware of the DS RR? That server will then refer back to this one, and the cycle begins anew. Even if this server sees no DS for c.d.e., this server cannot claim that there is no DS for b.c.d.e. because it just might be that c.d.e. is "privately signed" - keys distributed to resolvers - and has a DS for b.c.d.e. Ugly. U-g-l-y. Ugly. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 7 10:50:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28884 for ; Thu, 7 Nov 2002 10:50:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189ojA-000FkB-00 for namedroppers-data@psg.com; Thu, 07 Nov 2002 07:37:52 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 189oj8-000Fjy-00 for namedroppers@ops.ietf.org; Thu, 07 Nov 2002 07:37:50 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id gA7FWqg05938; Thu, 7 Nov 2002 10:32:52 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 7 Nov 2002 10:32:52 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Mark.Andrews@isc.org cc: DNSEXT mailing list Subject: Re: damage - was Re: DS and cache transparency. In-Reply-To: <200211062348.gA6Nmw3L002915@drugs.dv.isc.org> Message-ID: <20021107094606.S5738-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 7 Nov 2002 Mark.Andrews@isc.org wrote: > > > At 16:30 -0500 11/6/02, Derek Atkins wrote: > > >Basically, yes, that's what I was asking. Change the code so that an > > >auth server will _ALWAYS_ recurse for _its own_ DS record? We're > > >already adding special-case code for DS, why not add yet another > > >special case? > > > > It's possible that the server may not have a route to the parent. > > (Even if just temporarily.) I wouldn't want a query to it to hang in > > that case. > > > > In addition - I believe[0] that the DS draft proposes a different > > solution that what failed in August. > > I don't believe it solves the case where the a grandparent zone > is being served by the child zone. You won't get a referral > down to the parent zone. Another special case. Real nasty, at first look I thought this was an irrelevant case as we could safely ignore the fact that server is authorative for the grand parent. But that makes it impossible for the DS aware resolver to find the correct zone. There two possible solutions come to mind: - have this server hand out a delegation for the parent - stick with what we have in the document return a no data answer (RCODE:NOERROR, Auth: SOA + NXT The first one is identical to the 103x behavior for lookup of data in the parent zone. BUT this may cause a non-DS aware resolver to mark the server as lame for the child. In the second case the server operates in an identical manner for DS and all other types that do not exist at the apex. BUT in this case resolver may never find the parent zone, as the server does not hand out the delegation as it would if the query was for a name it is not authorative for. I think in this case we need to put logic into the resolver to discover the zone cut, and ask explicitly for NS for one label shorter than the name on the child zone. If the NS set returned does not include the server queried parent resides on a different server. (YUCK). OR do we need a EDNS0 option to inform the server the resolver is DS aware and please put the NS for the parent in the answer? Are there any more special cases that need to be considered ? 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 Thu Nov 7 13:07:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04605 for ; Thu, 7 Nov 2002 13:07:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189qk4-00027s-00 for namedroppers-data@psg.com; Thu, 07 Nov 2002 09:46:56 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 189qk1-00027g-00 for namedroppers@ops.ietf.org; Thu, 07 Nov 2002 09:46:54 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id gA7HkcJc020077; Thu, 7 Nov 2002 18:46:38 +0100 Date: Thu, 7 Nov 2002 18:46:38 +0100 From: "Olaf M. Kolkman" To: Olafur Gudmundsson Cc: Mark.Andrews@isc.org, namedroppers@ops.ietf.org Subject: Re: damage - was Re: DS and cache transparency. Message-Id: <20021107184638.3607c17f.olaf@ripe.net> In-Reply-To: <20021107094606.S5738-100000@hlid.dc.ogud.com> References: <200211062348.gA6Nmw3L002915@drugs.dv.isc.org> <20021107094606.S5738-100000@hlid.dc.ogud.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: NONE ; -1012 X-Spam-Status: No, hits=-11.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > OR do we need a EDNS0 option to inform the server the resolver is > DS aware and please put the NS for the parent in the answer? But we allready have a DNSSEC aware bit... (Forget RFC2535 compatibility, RFC2535 DNSSEC has a small install base and people doing that are on top of developments.) --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- 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 Nov 7 15:39:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10995 for ; Thu, 7 Nov 2002 15:39:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189t3B-000HiB-00 for namedroppers-data@psg.com; Thu, 07 Nov 2002 12:14:49 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 189t36-000HhP-00; Thu, 07 Nov 2002 12:14:44 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; Subject: Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 X-Spam-Status: No, hits=0.9 required=5.0 tests=SPAM_PHRASE_01_02,TO_HAS_SPACES,TO_MALFORMED version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- 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 Nov 7 15:55:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11917 for ; Thu, 7 Nov 2002 15:55:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189tWu-000LAp-00 for namedroppers-data@psg.com; Thu, 07 Nov 2002 12:45:32 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 189tWp-000L9B-00 for namedroppers@ops.ietf.org; Thu, 07 Nov 2002 12:45:28 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA7KjLYm036137; Thu, 7 Nov 2002 15:45:21 -0500 (EST) Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA13896; Thu, 7 Nov 2002 15:45:19 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20021107094606.S5738-100000@hlid.dc.ogud.com> References: <20021107094606.S5738-100000@hlid.dc.ogud.com> Date: Thu, 7 Nov 2002 15:45:34 -0500 To: Olafur Gudmundsson , Mark.Andrews@isc.org From: Edward Lewis Subject: Re: damage - was Re: DS and cache transparency. Cc: DNSEXT mailing list Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-11.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:32 -0500 11/7/02, Olafur Gudmundsson wrote: >On Thu, 7 Nov 2002 Mark.Andrews@isc.org wrote: >> I don't believe it solves the case where the a grandparent zone >> is being served by the child zone. You won't get a referral >> down to the parent zone. > >Another special case. Real nasty, at first look I thought this was ... >There two possible solutions come to mind: > - have this server hand out a delegation for the parent > - stick with what we have in the document return > a no data answer (RCODE:NOERROR, Auth: SOA + NXT #1 won't work and #2 may give the wrong answer. Unfortunately I can't dwell on this now - other issues are pressing - but there's one idea I've been urged to mention. At the August workshop, I made the comment that the DS is a significant departure from other types. Because of this, addressing the odd-ball cases that are created may require fairly drastic changes - such as a new RCODE (IDONTKNOW) or some treatment in the OPT RR. I've had some thoughts about "now it takes qname+qtype to determine the auth zone" and "what degrees of freedom" are available, but I can't spend time on it right now. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 8 07:49:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16937 for ; Fri, 8 Nov 2002 07:49:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18A8KS-0003DF-00 for namedroppers-data@psg.com; Fri, 08 Nov 2002 04:33:40 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18A8KO-0003Ce-00 for namedroppers@ops.ietf.org; Fri, 08 Nov 2002 04:33:36 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14720; Fri, 8 Nov 2002 07:31:04 -0500 (EST) Message-Id: <200211081231.HAA14720@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-dns-threats-02.txt Date: Fri, 08 Nov 2002 07:31:04 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * 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 : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-02.txt Pages : 14 Date : 2002-11-7 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-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-dns-threats-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-dns-threats-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: <2002-11-7155329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7155329.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 Fri Nov 8 07:49:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16952 for ; Fri, 8 Nov 2002 07:49:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18A8Le-0003Ti-00 for namedroppers-data@psg.com; Fri, 08 Nov 2002 04:34:54 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18A8La-0003Sj-00 for namedroppers@ops.ietf.org; Fri, 08 Nov 2002 04:34:50 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14986; Fri, 8 Nov 2002 07:32:18 -0500 (EST) Message-Id: <200211081232.HAA14986@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-olaf-dnsext-dnssec-wildcard-optimization-01.txt Date: Fri, 08 Nov 2002 07:32:17 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNSSEC Wildcard optimization Author(s) : O. Kolkman et al. Filename : draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt Pages : 13 Date : 2002-11-7 Secure denial of the existence of wildcards may lead to a large number of NXT RRs and associated SIG RRs in DNS responses, even in the common case when wildcards are not present in the zone. This optimization uses one bit from the NXT type array to signal that there is no closer wildcard in the zone for a given query name. This reduces the packet size and the need for executing slow, and complicated, code paths in common queries. In cases where there are no wildcard RRs in the zone (i.e. te root zone) only one NXT RR and corresponding SIG is needed for denial of existence of the wildcard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-olaf-dnsext-dnssec-wildcard-optimization-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-olaf-dnsext-dnssec-wildcard-optimization-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-olaf-dnsext-dnssec-wildcard-optimization-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: <2002-11-7155613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7155613.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 Fri Nov 8 17:11:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18805 for ; Fri, 8 Nov 2002 17:11:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AH4K-000GRI-00 for namedroppers-data@psg.com; Fri, 08 Nov 2002 13:53:36 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18AH4H-000GR0-00 for namedroppers@ops.ietf.org; Fri, 08 Nov 2002 13:53:33 -0800 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gA8LrRD10041; Fri, 8 Nov 2002 16:53:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021108163725.01ee4078@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 08 Nov 2002 16:52:42 -0500 To: "Olaf M. Kolkman" From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: How to measure savings ? (Was Re: DNSSEC wildcard optimization.) Cc: namedroppers@ops.ietf.org In-Reply-To: <20021107093259.4f3cdd55.olaf@ripe.net> References: <5.1.1.6.2.20021029113010.018fe478@localhost> <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> <24491.1036406334@munnari.OZ.AU> <20779.1036587374@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:32 2002-11-07, Olaf M. Kolkman wrote: >FYI, in Apendix A.1.2. of version 01 of the draft (still in the drafts >queue but available on: >http://www.ripe.net/disi/Notes/draft-olaf-dnsext-dnssec-wildcard-optimization-01.html=anchor17) > >I have added an example of the denial of wildcard proof as, I think, >it is supposed to be given. As it is bind 9.3s20020722 returns a few >answers to many. I hope that the argumentation is clear enough, and >correct. > > >--Olaf > >PS. In version 01 we have tried to clarify servers MAY choose to not >use the optimizations but that resolvers MUST understand the >optimisation. Besides we have changed the typecode from SIG to >NOWILD, which had as a consequence that the optimization takes place >when the bit is set to 1 iso 0. Finally DDNS considerations where >added. > >PSS. Roy and Johan did not have a change to look at the document before >the deadline, all errors that sneaked in after 00 are to blame on me. :-) After reading this much improved version I realized there are three possible paths forward from standards perspective: 1. Do nothing and require wildcard proof in all cases 2. Adopt something like this draft that always minimizes the number of records sent. 3. Adopt a simpler approach, in which the NXT signals if a wild card EXISTS in the zone. In this case full wild card proof is needed for all answers for the zone even if no wild card matches or if the wild card only matches a small part of the zone. The ONLY reason for adopting #2 or #3 is if the savings on the wire are going to be significant. In order to answer that we need some idea about how widespread the use of wild cards is and coverage inside the zone. (I have no idea how to derive this information). If the feeling is that wild cards are not frequent and when present they cover most of the zone (eg *. is more common than *..) then approach #3 may effectively yield the same savings (on the wire) as #2. 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 Sat Nov 9 01:26:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03271 for ; Sat, 9 Nov 2002 01:26:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AOpk-000GK0-00 for namedroppers-data@psg.com; Fri, 08 Nov 2002 22:11:04 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18AOph-000GHw-00 for namedroppers@ops.ietf.org; Fri, 08 Nov 2002 22:11:02 -0800 Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id gA96ATJc022480; Sat, 9 Nov 2002 07:10:29 +0100 Date: Sat, 9 Nov 2002 07:10:29 +0100 From: "Olaf M. Kolkman" To: Ólafur Guðmundsson Cc: namedroppers@ops.ietf.org Subject: Re: How to measure savings ? (Was Re: DNSSEC wildcard optimization.) Message-Id: <20021109071029.4fd8e69b.olaf@ripe.net> In-Reply-To: <5.1.1.6.2.20021108163725.01ee4078@localhost> References: <5.1.1.6.2.20021029113010.018fe478@localhost> <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> <24491.1036406334@munnari.OZ.AU> <20779.1036587374@munnari.OZ.AU> <5.1.1.6.2.20021108163725.01ee4078@localhost> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: NONE ; -1012 X-Spam-Status: No, hits=-11.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Note that scheme #3 can be adopted without major changes to the current draft (that is, with a clarification here and there). The flag as it is defined now basically is a message from the zone owner to the resolver saying 'you can stop further denial of wildcard proof'. If it is on a resolver does not have to do further denial of existence proof, if it is off you have to fall back to 2535 style proof. If do not want to make things difficult for dynamic zones with wildards than toggling the bit for the whole zone as soon as a wildcard appears or disappears will work. In other words, from resolver perspective nothing needs to change to implement #3, from server side perspective it needs to be made more explicit that toggling the bit zone-wide is an option too. --Olaf > After reading this much improved version I realized there are > three possible paths forward from standards perspective: > 1. Do nothing and require wildcard proof in all cases > 2. Adopt something like this draft that always minimizes the > number of records sent. > 3. Adopt a simpler approach, in which the NXT signals if a wild > card EXISTS in the zone. In this case full wild card > proof is needed for all answers for the zone even > if no wild card matches or if the wild card only matches > a small part of the zone. > > The ONLY reason for adopting #2 or #3 is if the savings on the wire are > going to be significant. In order to answer that we need some idea about > how widespread the use of wild cards is and coverage inside the > zone. (I have no idea how to derive this information). > > If the feeling is that wild cards are not frequent and when present they > cover most of the zone (eg *. is more common than *..) > then approach #3 may effectively yield the same savings (on the wire) as > #2. > > Olafur > --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- 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 Nov 10 10:38:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18376 for ; Sun, 10 Nov 2002 10:38:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ats0-0001hl-00 for namedroppers-data@psg.com; Sun, 10 Nov 2002 07:19:28 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Atrz-0001hZ-00 for namedroppers@ops.ietf.org; Sun, 10 Nov 2002 07:19:27 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Atrz-0003fR-00 for namedroppers@ops.ietf.org; Sun, 10 Nov 2002 07:19:27 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "Mohammad Awad" To: namedroppers@ops.ietf.org Subject: in-addr.arpa Date: Sun, 10 Nov 2002 11:37:24 +0200 X-Spam-Status: No, hits=0.9 required=5.0 tests=FORGED_HOTMAIL_RCVD,FROM_ENDS_IN_NUMS,RESENT_TO, SPAM_PHRASE_00_01 version=2.41 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 mis-posts. so fix subscription addresses! ] where can I find details about all types of quries that is applicable to the in-addr.arpa ? -- 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 Nov 10 11:38:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19073 for ; Sun, 10 Nov 2002 11:38:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Auw0-0004Rw-00 for namedroppers-data@psg.com; Sun, 10 Nov 2002 08:27:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Auvy-0004Rk-00 for namedroppers@ops.ietf.org; Sun, 10 Nov 2002 08:27:38 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Auvy-0005MD-00; Sun, 10 Nov 2002 08:27:38 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Mohammad Awad" Cc: namedroppers@ops.ietf.org Subject: Re: in-addr.arpa References: Message-Id: Date: Sun, 10 Nov 2002 08:27:38 -0800 X-Spam-Status: No, hits=-2.8 required=5.0 tests=REFERENCES,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > where can I find details about all types of quries that is > applicable to the in-addr.arpa ? the name of the domain is orthogonal to the RRs within it. so this is not a protocol issue, and hence not a topic for this working group. that aside, operationally, from the normal uses of the in-addr.arpa zone, at least SOA, NS, KEY, DS, SIG, and PTR would be expected. and i have probably forgotten some. 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 Sun Nov 10 12:10:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19776 for ; Sun, 10 Nov 2002 12:10:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AvS3-0005tX-00 for namedroppers-data@psg.com; Sun, 10 Nov 2002 09:00:47 -0800 Received: from libra.cus.cam.ac.uk ([131.111.8.19] ident=cusexim) by psg.com with esmtp (Exim 3.36 #2) id 18AvRz-0005tI-00; Sun, 10 Nov 2002 09:00:43 -0800 Received: from cet1 by libra.cus.cam.ac.uk with local (Exim 4.10) id 18AvRv-0004lS-00; Sun, 10 Nov 2002 17:00:39 +0000 Subject: Re: in-addr.arpa To: randy@psg.com (Randy Bush) Date: Sun, 10 Nov 2002 17:00:39 +0000 (GMT) Cc: maa1074@hotmail.com, namedroppers@ops.ietf.org In-Reply-To: from "Randy Bush" at Nov 10, 2 08:27:38 am 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=-6.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit randy@psg.com (Randy Bush) writes: > > > where can I find details about all types of quries that is > > applicable to the in-addr.arpa ? > > the name of the domain is orthogonal to the RRs within it. so this > is not a protocol issue, and hence not a topic for this working > group. > > that aside, operationally, from the normal uses of the in-addr.arpa > zone, at least SOA, NS, KEY, DS, SIG, and PTR would be expected. > and i have probably forgotten some. CNAMEs, to implement classless delegation a la RFC 2317 ? 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 Mon Nov 11 05:22:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14834 for ; Mon, 11 Nov 2002 05:22:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BBVs-000HWm-00 for namedroppers-data@psg.com; Mon, 11 Nov 2002 02:09:48 -0800 Received: from munnari.oz.au ([128.250.1.21]) by psg.com with esmtp (Exim 3.36 #2) id 18BBVp-000HWa-00 for namedroppers@ops.ietf.org; Mon, 11 Nov 2002 02:09:46 -0800 Received: from delta.cs.mu.OZ.AU (delta.cs.mu.OZ.AU [128.250.1.44]) by munnari.OZ.AU (8.11.6/8.11.6) with ESMTP id gABA9MO03654; Mon, 11 Nov 2002 21:09:22 +1100 (EST) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id gABA3W213848; Mon, 11 Nov 2002 17:03:32 +0700 (ICT) From: Robert Elz To: namedroppers@ops.ietf.org cc: Mohammad Awad Subject: Re: in-addr.arpa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Nov 2002 21:03:32 +1100 Message-ID: <13846.1037009012@munnari.OZ.AU> X-Spam-Status: No, hits=-6.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sun, 10 Nov 2002 17:00:39 +0000 (GMT) From: Chris Thompson Message-ID: | > that aside, operationally, from the normal uses of the in-addr.arpa | > zone, at least SOA, NS, KEY, DS, SIG, and PTR would be expected. | > and i have probably forgotten some. | | CNAMEs, to implement classless delegation a la RFC 2317 ? TXT is common as well, and RP should be there, and A records for rfc1101 if anyone still does that. Of course, also AXFR and IXFR. But the real answer was in the first part of Randy's mail - any RR at all, so see 1034, 1035, and all that has followed. in-addr.arpa domains are no different than any others, except as relates to the expected frequency of RR's sought there. This all assumes that "types of queries" means "types of RR's that might be queried", if read literally though, there's only one type of query that exists in the DNS (opcode 0) now that IQUERY has been discarded (finally) so that's the one and only query type that you should be seeing. The server can also get NOTIFY and UPDATE packets, but they don't really count as queries. kre -- 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 Nov 11 08:02:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16761 for ; Mon, 11 Nov 2002 08:02:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BE7N-000Jrq-00 for namedroppers-data@psg.com; Mon, 11 Nov 2002 04:56:41 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18BE7L-000Jrd-00 for namedroppers@ops.ietf.org; Mon, 11 Nov 2002 04:56:39 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18BE7K-000AgF-00; Mon, 11 Nov 2002 04:56:38 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: namedroppers@ops.ietf.org Subject: Re: in-addr.arpa References: <13846.1037009012@munnari.OZ.AU> Message-Id: Date: Mon, 11 Nov 2002 04:56:38 -0800 X-Spam-Status: No, hits=-5.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > TXT is common as well, and RP should be there, and A records for rfc1101 > if anyone still does that. Of course, also AXFR and IXFR. somehow i missed AXFR and IXFR resource records 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 Mon Nov 11 22:24:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10383 for ; Mon, 11 Nov 2002 22:24:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BRQf-000DVV-00 for namedroppers-data@psg.com; Mon, 11 Nov 2002 19:09:29 -0800 Received: from munnari.oz.au ([128.250.1.21]) by psg.com with esmtp (Exim 3.36 #2) id 18BRQd-000DVH-00; Mon, 11 Nov 2002 19:09:27 -0800 Received: from delta.cs.mu.OZ.AU (delta.cs.mu.OZ.AU [128.250.1.44]) by munnari.OZ.AU (8.11.6/8.11.6) with ESMTP id gAC39MO09665; Tue, 12 Nov 2002 14:09:22 +1100 (EST) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id gAC37D216997; Tue, 12 Nov 2002 10:07:14 +0700 (ICT) From: Robert Elz To: Randy Bush cc: namedroppers@ops.ietf.org Subject: Re: in-addr.arpa In-Reply-To: References: <13846.1037009012@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 2002 14:07:13 +1100 Message-ID: <16995.1037070433@munnari.OZ.AU> X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 11 Nov 2002 04:56:38 -0800 From: Randy Bush Message-ID: | > TXT is common as well, and RP should be there, and A records for rfc1101 | > if anyone still does that. Of course, also AXFR and IXFR. | | somehow i missed AXFR and IXFR resource records He asked for query types, not RR's. kre -- 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 Nov 13 04:12:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25627 for ; Wed, 13 Nov 2002 04:12:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BtIH-00042O-00 for namedroppers-data@psg.com; Wed, 13 Nov 2002 00:54:41 -0800 Received: from tyo201.gate.nec.co.jp ([210.143.35.51]) by psg.com with esmtp (Exim 3.36 #2) id 18BtIF-000429-00 for namedroppers@ops.ietf.org; Wed, 13 Nov 2002 00:54:39 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id gAD8sal09242 for ; Wed, 13 Nov 2002 17:54:36 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id gAD8sZD18213 for ; Wed, 13 Nov 2002 17:54:35 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id gAD8sVd10857 for ; Wed, 13 Nov 2002 17:54:33 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.6/3.7W) with ESMTP id gAD8sUb13263; Wed, 13 Nov 2002 17:54:30 +0900 (JST) Received: from potsdam.lab5.netlab.nec.co.jp (potsdam.lab5.netlab.nec.co.jp [10.17.226.96]) by dns03.netlab.nec.co.jp (8.11.6/3.7W) with ESMTP id gAD8sTj25894; Wed, 13 Nov 2002 17:54:29 +0900 (JST) Received: from localhost (localhost.lab5.netlab.nec.co.jp [127.0.0.1]) by potsdam.lab5.netlab.nec.co.jp (8.9.3/3.7W20020312HK) with ESMTP id RAA19704; Wed, 13 Nov 2002 17:54:28 +0900 (JST) To: namedroppers@ops.ietf.org Cc: kitamura@da.jp.nec.com Subject: Domain Name Auto-Registration for Plugged-in IPv6 Nodes From: kitamura@da.jp.nec.com Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-Id: <20021113175428D.kitamura@netlab.nec.co.jp> Date: Wed, 13 Nov 2002 17:54:28 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 56 X-Spam-Status: No, hits=-4.8 required=5.0 tests=DEAR_SOMEBODY,DOMAIN_SUBJECT,NO_REAL_NAME, QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA25627 Dear All, How to deal with an item ("Domain Name Auto-Registration for Plugged-in IPv6 Nodes" ) has not clarified yet. So, I'd like to clarify it at the next Atlanta meeting. I talked with Olafur on this issue. I got comments and suggestions from him. The followings is a part of his mail. From: Ólafur Guðmundsson Subject: Re: Agenda items for DNSEXT at IETF-45 in Atlanta > I think the best thing is to advance this document as an informational > or experimental RFC at this point. We have agreed with this point. > I have no problem issuing a working group last call for this as experimental, > or multiple ones if my AD tell me to. > > Please send a message to namedroppers asking for explicit input on > how to publish this new protocol. I will give you a slot in Atlanta > to summarize input and request explicit WG action. Well then: My explicit inputs are: I think the goal of my proposal is to be published as an Informational RFC. My proposal is tightly related with DNSEXT WG activities and it must be reviewed by DNSEXT folks. So, I'd like to ask to move my I-D to a WG I-D and do a last call. I believe this procedure must be a natural and simple way. As above mail shows, I got a slot in the Atlanta meeting. Please let us know your comments. As far as I have heard until now. There were no objections on ideas themselves. Many people understood importance of this proposal and showed their understandings. Thank you. Regards, Hiroshi -- 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 Nov 14 10:08:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21248 for ; Thu, 14 Nov 2002 10:08:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CLNN-0008Kt-00 for namedroppers-data@psg.com; Thu, 14 Nov 2002 06:53:49 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18CLNL-0008Kd-00 for namedroppers@ops.ietf.org; Thu, 14 Nov 2002 06:53:47 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id gAEEqvG36398; Thu, 14 Nov 2002 09:52:58 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 14 Nov 2002 09:52:57 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list cc: agenda@ietf.org Subject: IETF-55 DNSEXT Agenda Message-ID: <20021114095141.S36354-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=2.2 required=5.0 tests=OPT_IN,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk IETF-55 DNSEXT WG agenda Tuesday 2002/11/19 13:00-14:00 Salon II Chairs: Randy Bush randy@psg.com Olafur Gudmundsson ogud@ogud.com Agenda Bashing 3 min Working group document status: 2 min completed WG Last Call, status: Restrict KEY RFC Editors queue Obsolete IQuery RFC Editors queue DNSSEC Roadmap RFC Editors queue GSSAPI Passed IESG, Needs resolution on conflict with TSIG RFC. AD secure IESG discussing AXFR-clarify Advanced to IESG Unkown Types Advanced to IESG DS IETF last call waiting for resolution on one issue Discover Pending minor changes by author, next stop IESG in WG last call: RFC1886-bis (AAAA) for Draft Standard DNSSEC Opt-In TKEY Renwal GSSAPI TISG vs TSIG TKEY issue Olafur Gudmundsson 7 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-05.txt Opt-in - changes David Blacka 5 min Opt-in - issues and discussion Rob Austein 15 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-04.txt DS status Olafur Gudmundsson 5 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-11.txt AAAA-bis Vladimir Ksinant 3 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-01.txt http://www.6wind.com/RFC1886/testRFC1886.html DNSSEC-bis Documents Scott Rose 5 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-03.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-02.txt Wild card optimation Olaf Kolkman 7 min http://www.ietf.org/internet-drafts/draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt Key Signing Flag Olaf Kolkman 5 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-02.txt Donamin name Auto-Registration for Plugged-in IPv6 Nodes Hiroshi Kitamura 3 min http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt -- 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 Nov 14 10:09:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21273 for ; Thu, 14 Nov 2002 10:09:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CLUC-0008b2-00 for namedroppers-data@psg.com; Thu, 14 Nov 2002 07:00:52 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18CLU9-0008ak-00 for namedroppers@ops.ietf.org; Thu, 14 Nov 2002 07:00:49 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gAEExxD36410; Thu, 14 Nov 2002 09:59:59 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021113120447.020537c8@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 13 Nov 2002 12:10:29 -0500 To: Erik Nordmark From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: Unknown types support Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=2.6 required=5.0 tests=DATE_IN_PAST_12_24,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The DNSEXT working group has concluded a last call on this document and there is consensus on advancing it as Proposed Standard. Authors have updated the document based on comments from the last call. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unkown-rrs-04.txt This document updates RFC1035. The actions in this document are: - require that resolvers and servers handle unknown types transparently, this will allow more rapid deployment of new types in the future. - Outlaw name compression in RDATA part of new types, this is done to allow DNSSEC to validate new unknown types, preserve case and assist IDN in the future. - Defines a standard presentation format for unknown types. This document does not clarify the name compression rules from STD0013 separate document is needed to address that issue. 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 Thu Nov 14 10:10:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21314 for ; Thu, 14 Nov 2002 10:10:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CLUA-0008aw-00 for namedroppers-data@psg.com; Thu, 14 Nov 2002 07:00:50 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18CLU8-0008aa-00 for namedroppers@ops.ietf.org; Thu, 14 Nov 2002 07:00:48 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gAEExxD36413 for ; Thu, 14 Nov 2002 09:59:59 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021113121657.01be1e20@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 13 Nov 2002 12:33:40 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: Opcode-discover-00 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.9 required=5.0 tests=DATE_IN_PAST_12_24,SPAM_PHRASE_01_02 version=2.41 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This working group last call has concluded. This work meets the technical criteria to be to be published as EXPERIMENTAL. Authors are requested to make the following changes before the document is advanced to the IESG. 0. Number all sections that have titles. 1. In the last paragraph before IANA consideration: Add a comment that a responder to DISCOVER, in some cases is not a traditional DNS server, it could be a special purpose software. 2. References section needs to be broken into two "Normative References" and "Informational References", please fill out references fully. Olafur >This starts a 2 week last call for this document, the document is >slated to be published as EXPERIMENTAL. > >http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-00.txt > >This document specifies a new opcode that is used to discover DNS servers >within the multicast scope of the address sent to. > >The authors main focus is to get a IANA assigned opcode for experimentation, >does this document provide enough technical details for the framework to be >experimented with. > >This working group last call completes on August 30'th 2002. > > 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 Thu Nov 14 10:10:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21333 for ; Thu, 14 Nov 2002 10:10:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CLUF-0008bP-00 for namedroppers-data@psg.com; Thu, 14 Nov 2002 07:00:55 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18CLUC-0008ay-00 for namedroppers@ops.ietf.org; Thu, 14 Nov 2002 07:00:52 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gAEExwD36407; Thu, 14 Nov 2002 09:59:58 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021113115011.016d7490@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 13 Nov 2002 11:54:43 -0500 To: Erik Nordmark From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: AXFR clarify Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=-0.9 required=5.0 tests=DATE_IN_PAST_12_24,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA21333 Erik, DNSEXT has completed it's review of this document and requests that it be advanced to Proposed standard. This document updates RFC1035, actually it fills in a under specified section. Unfortunately the current version has expired, until author can post a identical new version here is the last version http://users.starpower.net/ogud/draft-ietf-dnsext-axfr-clarify-04.txt thanks Olafur >X-Sender: (Unverified) >X-Mailer: QUALCOMM Windows Eudora Version 5.1 >Date: Fri, 01 Mar 2002 01:57:16 -0500 >To: namedroppers@ops.ietf.org >From: Ólafur Gudmundsson/DNSEXT co-chair >Subject: DNSEXT WGLC Summary: AXFR-02.txt >Sender: owner-namedroppers@ops.ietf.org > > >This last call concluded a long time ago, it is this chairs fault for >not posting the consensus sooner, Sorry everyone. > >The working group rough consensus is to advance the document with minor >changes as outlined below. >There has been strong objection from certain well respected member of >the working group. >The main objections can be summarized in two major points: > >1. He objects to the restriction that all data go in answer section, >he wants section agnostic rules. > >There is no technical reason why one is better or worse than the other. >All implementations but ONE, put all AXFR data in ANSWER section, thus >that is less disruptive to formalize. > >2. He objects to the restriction that AXFR MUST contain exactly the >data that the master server loaded from zone file. >Most early implementations did not comply with this rule, but some >did, the old implementation that became the de-facto standard for DNS >allowed data to leak between zones. >This has certain beneficial behavior for delegations if data from >children is better than parent, but has the following drawbacks > a. AXFR of the same version of a zone from two servers may > differ. > b. IXFR updates may fail due to preconditions not being true, > this was not explained in IXFR document. > c. Dynamic Update may fail due to preconditions (not explained > in Dynamic Update RFC). > d. Diagnosing problem is harder as answers differ between > Authorative servers. > >Since the AXFR last call concluded the working group had extensive >discussion on similar issue: if DNSSEC servers could drop expired >signatures. >The working group expressed a strong and clear consensus on this >issue: >Authorative Servers MUST not change or discard any zone data, even if >the server can determine data is wrong/bad. > >This counters objection #2. > >The Author has made all changes to the document that are needed, but >the document has expired, Andreas please resubmit before deadline. > 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 Thu Nov 14 13:57:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26970 for ; Thu, 14 Nov 2002 13:57:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CP62-000Hmt-00 for namedroppers-data@psg.com; Thu, 14 Nov 2002 10:52:10 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18CP5j-000Hm8-00 for namedroppers@ops.ietf.org; Thu, 14 Nov 2002 10:51:51 -0800 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gAEIp1D36797 for ; Thu, 14 Nov 2002 13:51:01 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021114134710.0158ffa8@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 14 Nov 2002 13:50:50 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC: TKEY Renewal Mode-02 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is the beginning of a 3 week working group last call. This last call ends on December 6'th. This document updates RFC2930 to allow atomic updating of TKEY secrets. This document defines a new mode for each algorithm supported, and how the "key rollover" takes place. This document is on standards track and is available via following URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-02.txt 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 Thu Nov 14 14:00:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27051 for ; Thu, 14 Nov 2002 14:00:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CP5l-000HmV-00 for namedroppers-data@psg.com; Thu, 14 Nov 2002 10:51:53 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18CP5j-000Hm6-00 for namedroppers@ops.ietf.org; Thu, 14 Nov 2002 10:51:51 -0800 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gAEIp0D36791 for ; Thu, 14 Nov 2002 13:51:00 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021114114119.0167f7e8@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 14 Nov 2002 11:56:13 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC: DNSSEC Opt-in Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=2.2 required=5.0 tests=OPT_IN,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is the beginning of a 3 week working group last call. This last call ends on December 6'th. This document updates RFC2535 to allow NXT chain to omit insecure delegations. This document covers the implications this has on servers and resolvers. This document is on standards track and is available via following URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-04.txt 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 Thu Nov 14 14:02:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27148 for ; Thu, 14 Nov 2002 14:02:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CP5u-000Hmi-00 for namedroppers-data@psg.com; Thu, 14 Nov 2002 10:52:02 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18CP5j-000Hm7-00 for namedroppers@ops.ietf.org; Thu, 14 Nov 2002 10:51:51 -0800 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gAEIp1D36794 for ; Thu, 14 Nov 2002 13:51:01 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021114115616.02177250@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 14 Nov 2002 13:43:18 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC: RFC1886bis-01 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is the beginning of a 3 week working group last call. This last call ends on December 6'th. This document replaces RFC1886 with minimal changes incorporated from interoperabilty testing and RFC3152 (ip6.arpa. delegation) This document is on standards track and is to be advanced to Draft Standard it and supporting interoperabilty test report and is available via following URLs: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-01.txt http://www.6wind.com/RFC1886/testRFC1886.html 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 Nov 15 17:32:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22017 for ; Fri, 15 Nov 2002 17:32:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CojX-000FIz-00 for namedroppers-data@psg.com; Fri, 15 Nov 2002 14:14:39 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18CojV-000FIm-00 for namedroppers@ops.ietf.org; Fri, 15 Nov 2002 14:14:37 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAFMEaYm037645 for ; Fri, 15 Nov 2002 17:14:36 -0500 (EST) Received: from [192.168.1.70] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA16227 for ; Fri, 15 Nov 2002 17:14:36 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Fri, 15 Nov 2002 17:14:35 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Fwd: Re: damage - was Re: DS and cache transparency. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.3 required=5.0 tests=FWD_MSG,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This seems to have not made it to the list/it's not in the archives... >Date: Fri, 8 Nov 2002 08:35:01 +0100 >From: "Olaf M. Kolkman" >To: Edward Lewis >Cc: namedroppers@ops.ietf.org >Subject: Re: damage - was Re: DS and cache transparency. >Organization: RIPE NCC >X-RIPE-Spam-Status: NONE ; -1004 >Status: > > >Ed wrote, in somewhat different context: > >> Ugly. U-g-l-y. Ugly. > > >This is just a thought, it relates to the subject and qualifies as >Ugly U-g-l-y. Ugly. It is only to be considered if we find the >'damaging' corner cases important enough to be solved and introduce >yet new delays. While most probably not The Solution(TM), it may >inspire to better solutions. > > >It seems that most DS corner-cases are caused by the fact that a >resolver ends up at the child and does not know how to get to the >parent. Besides, 'classic' resolvers may mark servers as lame because >the DS is not served from servers that are, in the eyes of the classic >resolver, authoritative for the namespace. > >A way out of this is to have the DS on both sides of the zone cut but >in two incarnations indicated by a flag. In normal cases you would >(should) get an authoritative DS RR from the parent with the hash of >the child's key. If for some reason the server authoritative for the >child zone is queried for the DS it hands out a DS in the second >incarnation, that DS's rdata contains the name of the parent >zone. Resolvers that get this DS incarnation back will know where to >go for the 'real answer' directly. > > > Incarnation flag > | > V > >foo.example. 3600 IN DS 1 42495 1 1 0123abc(....) > >foo.example. 3600 IN DS 2 example. > > >This scheme may also be useful in situations where the parent's NS and >the child's DS RRs have expired from the cache and you want to get to >the DS without traversing the namespace from the root in the hope >that the parent passes you a new DS RR. > >In the Mark's example of the server authoritative for grand-parent and >child zone, a resolver would get the 2nd incarnation that would point >you to the parent. The resolver could go out to the parent and query >for the DS directly. > > > >--Olaf > > > > >--------------------------------------------| Olaf M. Kolkman > | www.ripe.net/disi > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 17 09:15:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18725 for ; Sun, 17 Nov 2002 09:15:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DQ0u-000Myv-00 for namedroppers-data@psg.com; Sun, 17 Nov 2002 06:03:04 -0800 Received: from funnel.cisco.com ([161.44.168.79]) by psg.com with esmtp (Exim 3.36 #2) id 18DQ0s-000MyW-00 for namedroppers@ops.ietf.org; Sun, 17 Nov 2002 06:03:02 -0800 Received: from rdroms-w2k.cisco.com (rtp-vpn1-128.cisco.com [10.82.224.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA11711 for ; Sun, 17 Nov 2002 09:02:30 -0500 (EST) Message-Id: <4.3.2.7.2.20021117085210.00b8caa8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Nov 2002 08:53:13 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: Fwd: [dhcwg] update on dhcp/dns drafts' progress Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.2 required=5.0 tests=FWD_MSG,SATISFACTION,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The dnsext WG will also be interested in these revised drafts... - Ralph >Date: Fri, 15 Nov 2002 14:34:17 -0500 >To: dhcwg@ietf.org >From: Mark Stapp >Subject: [dhcwg] update on dhcp/dns drafts' progress > >Folks, > >The advance summaries that several authors have sent about their drafts >have been pretty useful, and Ralph has prodded me to produce something >similar about the dhcp/dns drafts. The current versions are: > >http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-05.txt >http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-06.txt > >History > >The ddns-resolution and fqdn-option drafts last-called in October last >year. The related dhcid rr draft also last-called, after some last-minute >procedural hijinks almost caused it to be lost. I responded to some >post-last-call comments from Thomas Narten in November. It seemed by the >March 2002 ietf that the various working-group chairs and ads were in >synch. By the summer, I was concerned that we hadn't heard from the iesg, >and I asked Ralph to try to help me understand what was going on. In July, >a significant issue was raised. Ralph, Olafur, and I agreed that we should >address it, and I published revisions to the ddns-resolution and dhcid-rr >drafts. > >The Issue > >The evolution of the dhcid-rr draft led to a situation in which details >about the data within the dhcid-rr were present in two different drafts. >History is to blame here, as usual. Years ago, there was a very simple >dhcid-rr specification. It said, basically, "This RR holds binary data. If >you want to know how to generate this data, go look in the dhc wg's >ddns-resolution draft." > >The dnsext folks were not satisfied with this approach, and over time more >and more details about the dhcid rr data leaked from the ddns-resolution >draft into the dhcid-rr draft. By the summer, that had led to parallel >language in the two specifications. The wg chairs were concerned that that >would lead to implementation problems. > >The Current Drafts > >The current versions of the drafts have moved all of the specification of >the dhcid rr data into the dhcid-rr draft. The use of the dhcid-rr by >updaters remains in the ddns-resolution draft. > >The dhcid rr includes a 16-bit value specifying the source of the >client-identity information. The original proposal for the RR proposed >that this value would take on one of three values: the value zero if the >identifier was the client's MAC address, the value 0xffff was reserved, >and any other value would be the option number of the dhcp option that >supplied the identifier (like the client-id option number). There was >concern that this relied on non-overlapping v4 and v6 option >number-spaces. The current draft specifies that this field holds an >IANA-managed number. Four values are allocated initially: zero for the MAC >address, one for the dhcpv4 client-id option, two for the dhcpv6 duid, and >0xffff is reserved. > >There is a slot at the end of the Atlanta agenda for discussion about >these drafts, if that's necessary. > >-- Mark > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- 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 Nov 19 15:35:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15831 for ; Tue, 19 Nov 2002 15:35:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EEnk-000LFC-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 12:16:52 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100] ident=firewall-user) by psg.com with esmtp (Exim 3.36 #2) id 18EEnh-000LDl-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 12:16:49 -0800 Received: by sentry.gw.tislabs.com; id PAA23851; Tue, 19 Nov 2002 15:16:55 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma023829; Tue, 19 Nov 02 15:16:13 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id gAJKG4b27704 for ; Tue, 19 Nov 2002 15:16:05 -0500 (EST) Date: Tue, 19 Nov 2002 15:16:04 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: Clear path requirement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Over the past several months we've seen several problems that stem from legacy resolvers thinking that children, not parents, are authoritative for DS. In particular, having non-DS-aware resolvers/caches/proxies in the path from querier to authoritative server can block DS records entirely, even if those boxes otherwise handle unknown RR types. Further details are being discussed on dnssec@cafax.se. So here are the questions: is it reasonable to mandate a "clear path" between resolver and authoritative server, meaning a path with only DS-aware (not just 2535-aware) resolvers/caches/proxies? Is it acceptable to have DNSSEC RRs dropped until everything along the path is upgraded, or is that a deployment showstopper? Or do so few of these boxes pass unknown RR types that this is nothing new -- we're already stuck with upgrading everything just to get KEY/SIG/NXT? I think a clear path requirement is too onerous and will slow deployment. In particular, while a zone that wants to be signed can probably remove any legacy caches that sit in front of its authoritative servers, users wishing to validate results may not be able to remove or upgrade the (often embedded) hardware at their ISP (or hotel). Assuming that there are enough of these boxes that handle unknown RR types but don't understand DS, I think we should try to make the protocol work through them. The exact technical solution can be debated -- I'd like to see if we can get rough consensus on the need to avoid a clear path requirement. -- Sam -- 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 Nov 19 17:00:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18406 for ; Tue, 19 Nov 2002 17:00:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EGKa-000ISn-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 13:54:52 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #2) id 18EGKV-000ISU-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 13:54:47 -0800 Received: from nominum.com (dra-chi.ietf55.ops.ietf.org [204.42.72.120]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gAJLmY227301; Tue, 19 Nov 2002 15:48:34 -0600 (CST) Date: Tue, 19 Nov 2002 16:54:52 -0500 Subject: Re: Clear path requirement Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: namedroppers@ops.ietf.org To: Sam Weiler From: Ted Lemon In-Reply-To: Message-Id: <888CB056-FC09-11D6-ACAE-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think it's reasonable to require that there be no DS-unaware resolvers in the path to a secure zone. The reason is that in general, one can almost always bypass broken resolvers in embedded devices - for example, I never use the resolver in my airport base station, even though in terms of topology it is between me and the outside world. My experience as a frequent roamer is that outside of corporate networks, it is rarely the case that anyone prevents you from bypassing a resolver. Inside of corporate networks, arguing that the resolver is causing a security problem can, over time, result in the problem being fixed. Because early adopters tend to be highly motivated, I think that this requirement will have a good effect. BTW, I do not intend to strongly advocate this position - I am just interjecting with some personal experience and the possibly incorrect conclusion I draw from it. Your milage may vary. -- 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 Nov 19 17:02:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18517 for ; Tue, 19 Nov 2002 17:02:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EGIf-000I3N-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 13:52:53 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18EGId-000Hyt-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 13:52:51 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id E025537A1C4 for ; Tue, 19 Nov 2002 21:52:50 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Clear path requirement In-Reply-To: Message from Sam Weiler of "Tue, 19 Nov 2002 15:16:04 EST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 19 Nov 2002 21:52:50 +0000 Message-Id: <20021119215250.E025537A1C4@as.vix.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk quite a lot of the ipv4 edge consists of gateway boxes (nat, etc) which were poorly programmed, have unspecified features, and whose manufacturers are out of business. if we decide on a dnssec design which requires that these devices be replaced/upgraded before dnssec will work "at these edges" then we won't see deployment at badly served edges until some later time when dnssec functionality becomes compelling (i don't know what that will look like but whatever it is, i don't expect it to occur soon.) the boxes in question often rewrite dns messages as they pass through, and their weaknesses give rise to a strong defense of the "end to end" argument and may even form some motivation for ipv6 deployment in the hope that ipv6 firewalls will somehow be smarter than ipv4 firewalls were, since NAT won't be a consideration. my take on this: a clear-path requirement would slow dnssec deployment, if dnssec deployment otherwise became possible. -- 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 Nov 19 17:35:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19239 for ; Tue, 19 Nov 2002 17:35:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EGiP-000Ojb-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 14:19:29 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #2) id 18EGiL-000OjL-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 14:19:26 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA13501; Tue, 19 Nov 2002 17:19:20 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA03379; Tue, 19 Nov 2002 17:15:29 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id RAA26127; Tue, 19 Nov 2002 17:09:54 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA13797; Tue, 19 Nov 2002 17:09:54 -0500 (EST) To: Ted Lemon Cc: Sam Weiler , namedroppers@ops.ietf.org Subject: Re: Clear path requirement References: <888CB056-FC09-11D6-ACAE-00039317663C@nominum.com> From: Derek Atkins Date: 19 Nov 2002 17:09:54 -0500 In-Reply-To: <888CB056-FC09-11D6-ACAE-00039317663C@nominum.com> Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ted Lemon writes: > I think it's reasonable to require that there be no DS-unaware > resolvers in the path to a secure zone. The reason is that in > general, one can almost always bypass broken resolvers in embedded > devices - for example, I never use the resolver in my airport base > station, even though in terms of topology it is between me and the > outside world. > > My experience as a frequent roamer is that outside of corporate > networks, it is rarely the case that anyone prevents you from > bypassing a resolver. Inside of corporate networks, arguing that the > resolver is causing a security problem can, over time, result in the > problem being fixed. Because early adopters tend to be highly > motivated, I think that this requirement will have a good effect. Interesting -- I've been stuck behind "transparent" proxy caches that intercept DNS messages, even when the dest IP is a server I know. Indeed, the service in the hotel rooms here at the IETF have this "feature"... > BTW, I do not intend to strongly advocate this position - I am just > interjecting with some personal experience and the possibly incorrect > conclusion I draw from it. Your milage may vary. I also believe that requiring all these edge devices to be upgraded in order to get DNSSec to work will be a major impediment to deployment. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- 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 Nov 19 18:06:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20076 for ; Tue, 19 Nov 2002 18:06:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EHFd-0007a6-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 14:53:49 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18EHFb-0007ZH-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 14:53:47 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18EHFZ-0002Fi-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 17:53:45 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <84DD35E3DD87D5489AC42A59926DABE90888E8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Proposal for TSIG update Thread-Index: AcKPdCk2gFkuZ9OZQHeyAF9l/6s7hQ== Subject: Proposal for TSIG update Date: Mon, 18 Nov 2002 18:34:17 -0800 From: "Levon Esibov" To: X-Spam-Status: No, hits=0.6 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA20076 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] I'd like to ask namedroppers to support a proposal to update TSIG (RFC 2845) as described below: Currently section 4.2 reads: "The server MUST not generate a signed response to an unsigned request.". In my opinion this restriction unnecessarily prevents TKEY mechanism from signing the last response (i.e. as soon as shared secret key becomes available) in the exchange of queries/responses that establish shared security key, which would be the right thing to do for the TKEY protocol. I propose that TSIG-bis allows TKEY to sign the last response as soon as shared secret key is established (even if the query was not signed). Comments? Thanks, Levon. -- 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 Nov 19 18:07:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20130 for ; Tue, 19 Nov 2002 18:07:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EHNB-0009TP-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 15:01:37 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #2) id 18EHN9-0009TD-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 15:01:35 -0800 Received: from nominum.com (dra-chi.ietf55.ops.ietf.org [204.42.72.120]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gAJMtA227676; Tue, 19 Nov 2002 16:55:10 -0600 (CST) Date: Tue, 19 Nov 2002 18:01:22 -0500 Subject: Re: Clear path requirement Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: namedroppers@ops.ietf.org, Sam Weiler To: Derek Atkins From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Interesting -- I've been stuck behind "transparent" proxy caches > that intercept DNS messages, even when the dest IP is a server I > know. Indeed, the service in the hotel rooms here at the IETF > have this "feature"... Yes, indeed, this is the one exception of which I am aware, and I have also run into it at other hotels. I am glad that the fact that I use DNS correctly means that I can't get through this box - I find it alarming that a device such as this might silently corrupt my network transactions. Anything that can be done to make it so that Joe Average simply loses when trying to connect through such boxes is a good thing. It gives the service provider a financial incentive to fix the problem - it means they have to pay for backcharges, reduces their income, and runs up the phone bill on their 800-number. It is not in Joe Average's interest to connect through a device that arbitrarily modifies the contents of DNS packets - no good can come of it. -- 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 Nov 19 18:55:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21014 for ; Tue, 19 Nov 2002 18:55:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EIA8-000MRO-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 15:52:12 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18EIA6-000MQi-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 15:52:10 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18EIA4-0002Tj-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 18:52:08 -0500 Message-Id: <5.1.1.6.2.20021119143305.02dd6838@mail.amaranth.net> In-Reply-To: <20021119190230.7319.qmail@cr.yp.to> References: <96C102324EF9D411A49500306E06C8D1020200B6@eketsv02.cubis.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Tue, 19 Nov 2002 14:52:57 -0500 To: namedroppers@ops.ietf.org From: Daniel Senie Subject: Re: axfr-clarify on the move again Cc: iesg@ietf.org X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Without regard to the specific issue, but rather in response to the attack tone the author has taken (on this and other occasions), I bring up some points to clarify where we are at. Though the author below is hostile in his remarks, the broader question is whether he (or those he accuses) are representing, misrepresenting or following the IETF procedures. Regardless, I have limited the scope of this mailing to IESG and DNSEXT, since the rest of the IETF community need not be a party to this. At 02:02 PM 11/19/2002, D. J. Bernstein wrote: >Reckhard, Tobias writes: > > The latter page says, "This Internet-Draft was not published as an RFC." > >Right. The BIND company is trying to get this ``clarification'' >published as a ``Proposed Standard'' RFC. > >These decisions are supposed to be made by working-group consensus, then >reviewed by the IESG. The DNSEXT chairs have sent this document to the >IESG, claiming that the document has DNSEXT consensus. ROUGH consensus. [RFC 2418, Section 3 introduction] >In fact, at the last DNSEXT meeting, the working group decided _against_ >publishing this document. Working group sessions are places to accelerate discussion and try to reach consensus on ideas which should then be brought back to the mailing list to ensure the wider audience has the opportunity to participate. [RFC 2418, Section 3.2] > (``Too BIND-specific,'' the minutes say.) The >only discussions since then have been secret discussions between the >BIND company and the DNSEXT chairs. (The chairs let slip on 2002.08.19 >that they were acting on the basis of behind-the-scenes discussions.) > >In legitimate standards organizations, there's no way for anyone to >misrepresent the will of the group. All actions are confirmed by votes. If you dislike the procedures, leave. If you think the procedures have not been followed, follow the proper motions for that. >In contrast, in the IETF, chairs have tremendous power to promote their >favorite documents. They can declare ``consensus'' whenever they want. >A tremendous burden is then placed on people who object, even if those >people are the majority of the working group! Since you've chosen to represent your view as the being the "majority" of the working group, I would insist you qualify that by quantifying how many people are in the working group, and how you came to believe you had a majority behind you. -- 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 Nov 19 18:56:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21029 for ; Tue, 19 Nov 2002 18:56:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EI4x-000Ksd-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 15:46:51 -0800 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18EI4u-000Krq-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 15:46:49 -0800 Received: from tecotoo.www.gis.net ([67.30.179.94]) by mx03.gis.net; Tue, 19 Nov 2002 18:46:43 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id pa029239 for ; Tue, 19 Nov 2002 18:45:12 -0500 Message-Id: <4.3.1.2.20021119184300.038bde30@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Nov 2002 18:44:57 -0500 To: "Levon Esibov" , From: Danny Mayer Subject: Re: Proposal for TSIG update In-Reply-To: <84DD35E3DD87D5489AC42A59926DABE90888E8@WIN-MSG-10.wingroup .windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:34 PM 11/18/02, Levon Esibov wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > >I'd like to ask namedroppers to support a proposal to update TSIG (RFC >2845) as described below: > >Currently section 4.2 reads: "The server MUST not generate a signed >response to an unsigned request.". In my opinion this restriction >unnecessarily prevents TKEY mechanism from signing the last response >(i.e. as soon as shared secret key becomes available) in the exchange of >queries/responses that establish shared security key, which would be the >right thing to do for the TKEY protocol. > >I propose that TSIG-bis allows TKEY to sign the last response as soon as >shared secret key is established (even if the query was not signed). > >Comments? Has there been any discussion of this at the IETF meeting? If so, what feedback did you get? What were the pros and cons? Danny >Thanks, >Levon. > > > >-- >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 Nov 19 18:56:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21045 for ; Tue, 19 Nov 2002 18:56:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EI91-000MAI-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 15:51:03 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18EI8z-000MA5-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 15:51:01 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A4D0B37A2AB for ; Tue, 19 Nov 2002 23:51:00 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal for TSIG update In-Reply-To: Message from "Levon Esibov" of "Mon, 18 Nov 2002 18:34:17 PST." <84DD35E3DD87D5489AC42A59926DABE90888E8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 19 Nov 2002 23:51:00 +0000 Message-Id: <20021119235100.A4D0B37A2AB@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I propose that TSIG-bis allows TKEY to sign the last response as soon as > shared secret key is established (even if the query was not signed). > > Comments? sounds right to me. -- 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 Nov 19 19:12:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21369 for ; Tue, 19 Nov 2002 19:12:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EIOP-000Psq-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 16:06:57 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18EION-000PsX-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 16:06:56 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18EIOM-0002XA-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 19:06:54 -0500 Message-ID: <004e01c29014$cc60d940$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-reply-to: <20021119204308.52994.qmail@cr.yp.to> From: "Jeroen Massar" To: "'D. J. Bernstein'" , Cc: , , Subject: RE: axfr-clarify on the move again Date: Tue, 19 Nov 2002 22:44:11 +0100 X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA21369 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] D. J. Bernstein wrote: > (1) NS records for which the parent node is in the zone, > (2) A records that those NS records point to, > (3) AAAA records that those NS records point to, or > (4) A6 records that those NS records point to. > What happens if the IETF adds another address type beyond A/AAAA/A6? > Answer: a zone administrator who adds a record of that type causes a > complete zone-transfer failure with older versions of BIND 9. This is > even worse than the situation in http://cr.yp.to/djbdns/newtypes.html, > because it kills the whole zone transfer, not just the new records. > Nobody would fall for > it if the document imposed rules relating to silly > experiments like A6. Lots of snipps, just to remind you that A6 has been moved to experimental and that you won't find it in 99.9999% of current actively deployed systems. Check http://cr.yp.to/djbdns/killa6.html which you wrote some time ago :) Greets, Jeroen -- 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 Nov 19 20:53:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24234 for ; Tue, 19 Nov 2002 20:53:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EJsJ-000OaS-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 17:41:55 -0800 Received: from adsl-67-119-98-58.dsl.snfc21.pacbell.net ([67.119.98.58] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #2) id 18EJsH-000OJ9-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 17:41:53 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id gAK1f7Xx014396; Tue, 19 Nov 2002 17:41:07 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id gAK1f61X014393; Tue, 19 Nov 2002 17:41:06 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Tue, 19 Nov 2002 17:41:06 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Levon Esibov cc: namedroppers@ops.ietf.org Subject: Re: Proposal for TSIG update In-Reply-To: <84DD35E3DD87D5489AC42A59926DABE90888E8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 18 Nov 2002, Levon Esibov wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > I'd like to ask namedroppers to support a proposal to update TSIG (RFC > 2845) as described below: > > Currently section 4.2 reads: "The server MUST not generate a signed > response to an unsigned request.". In my opinion this restriction > unnecessarily prevents TKEY mechanism from signing the last response > (i.e. as soon as shared secret key becomes available) in the exchange of > queries/responses that establish shared security key, which would be the > right thing to do for the TKEY protocol. > > I propose that TSIG-bis allows TKEY to sign the last response as soon as > shared secret key is established (even if the query was not signed). > > Comments? As I said last time this came up, I think this unnecessarily complicates the protocol, and the only reason to do this would be so that the GSS-TSIG draft becomes standards compliant. I believe GSS-TSIG should be fixed, as this has no benefit for other TKEY methods. Are there any other reasons for a TSIG-bis? I haven't seen any. Brian -- 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 Nov 19 21:23:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27358 for ; Tue, 19 Nov 2002 21:23:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EKLQ-0006SM-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 18:12:00 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18EKLN-0006S9-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 18:11:57 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAK2BsYm030252 for ; Tue, 19 Nov 2002 21:11:54 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id VAA16098; Tue, 19 Nov 2002 21:11:52 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 19 Nov 2002 21:11:49 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wildcard optimization and b/w incompatibility Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.5 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm not sure, but I think this paragraph is wrong: # The fact that resolvers that obtain an answer with a NXT RR's NOWILD # set to 1 do not receive additional proof for the non-existence of # wildcards is incompatible with RFC2535. This is at the end of section 2.2, "resolver side" processing discussion. After hearing Olaf's presentation I was thinking about whether or not this proposal indeed lacks backwards compatibility. For "old" = not optimizing and "new" = optimizing, we need to look at four cases. 1) New signer, old server. 2) New resolver, old server. 3) Old signer, new server. 4) Old resolver, new server. 1 - a problem only if the server checks the NXT type bit map on load, axfr, ixfr, or dynamic update. 2 - not a problem, the resolver will "fall back" to having to handle the whole proof. 3 - no a problem, the server will always have to provide the full response. 4 - this is a two step problem. Old resolvers don't look for the wildcard NXT anyway, as we didn't notice the omission until the August workshop. If there is an old resolver that did anticipate this, a problem would arise only if the resolver was "lazy" in my words. By this I mean - if a resolver is "missing" some expected data, it should go ask for it, not be lazy and give up. Question to the implementers - are there implementation-level problems with the first and last case? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 19 23:03:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15724 for ; Tue, 19 Nov 2002 23:03:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ELwk-0008Xt-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 19:54:38 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #2) id 18ELwj-0008Xg-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 19:54:37 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 24EC152A5; Wed, 20 Nov 2002 04:54:35 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 323F71DF6; Wed, 20 Nov 2002 04:54:31 +0100 (MET) Date: Tue, 19 Nov 2002 22:54:33 -0500 (EST) From: Jakob Schlyter To: Derek Atkins Cc: Ted Lemon , Sam Weiler , Subject: Re: Clear path requirement In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 19 Nov 2002, Derek Atkins wrote: > Interesting -- I've been stuck behind "transparent" proxy caches > that intercept DNS messages, even when the dest IP is a server I > know. Indeed, the service in the hotel rooms here at the IETF > have this "feature"... the "transparent" proxy caches play well with other DNSSEC RR types such as SIG, KEY and NXT ? what about support for EDNS0 ? 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 Nov 20 00:40:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18074 for ; Wed, 20 Nov 2002 00:40:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ENVR-0009Jf-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 21:34:33 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18ENVO-0009JR-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 21:34:30 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gAK5YOV17060; Tue, 19 Nov 2002 21:34:24 -0800 (PST) Date: Tue, 19 Nov 2002 21:34:24 -0800 (PST) Message-Id: <200211200534.gAK5YOV17060@guava.araneus.fi> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: axfr-clarify on the move again From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [I'm responding to a message which was CC:d to namedroppers@ops.ietf.org, iesg@ietf.org, and ietf@ietf.org, but which I have not yet seen appear on namedroppers. I'm omitting ietf@ietf.org from the list of recipients since this discussion really doesn't belong there.] Dan Berstein wrote: > > I don't understand your point about axfr-clarify-01 under the "What is > > allowed in a zone?" heading. I think you removed too much context. > > Suppose there's a delegation from the heaven.af.mil zone: > > heaven.af.mil SOA ... > heaven.af.mil NS ... > moon.heaven.af.mil NS ... > full.moon.heaven.af.mil ... > > There are (at least) two zones here: > > * the heaven.af.mil zone, which is authoritative for the > heaven.af.mil records, and > > * the moon.heaven.af.mil zone, which is authoritative for > moon.heaven.af.mil and (presumably) full.moon.heaven.af.mil. > > In the words of RFC 1034, section 4.2: ``After all cuts are made, each > group of connected name space is a separate zone. The zone is said to be > authoritative for all names in the connected region.'' > > Is a zone completely described by its authoritative records? No. A zone > can---and sometimes must---include records copied from other zones. For > example, the heaven.af.mil server needs to know the moon.heaven.af.mil > NS record. That record isn't part of the authoritative heaven.af.mil > data; it's part of the authoritative moon.heaven.af.mil data. No argument there. > axfr-clarify-01 prohibits zone-transfer servers providing records ``from > the authoritative data of zones other than the one being transferred.'' > For example, it prohibits the heaven.af.mil server from providing the > moon.heaven.af.mil NS record. No, it does not. It says that when transferring the heaven.af.mil zone, the master server MUST provide the moon.heaven.af.mil NS records that are present as non-authoritative data copied into the the heaven.af.mil.zone. What it prohibits is sending the authoritative moon.heaven.af.mil NS records in the moon.heaven.af.mil zone instead of, or in addition to, the non-authorative ones in the parent just because the server happens to be authoritative for both zones. > Now, that isn't what the BIND company meant to say. What they really > want is to force everybody else to imitate a stupid mistake in BIND 9. > Namely, BIND 9 (on both the server side and the client side) reportedly > rejects non-authoritative records that are not > > (1) NS records for which the parent node is in the zone, > (2) A records that those NS records point to, > (3) AAAA records that those NS records point to, or > (4) A6 records that those NS records point to. > > For example, if the full.moon.heaven.af.mil record is included in the > heaven.af.mil zone, BIND 9 might or might not reject it, depending on > exactly what the record types and contents are. That's completely false. BIND 9 does not reject such records, and never has. > So the BIND company gave us the ridiculous axfr-clarify-01 rule. When I > pointed out how dumb that rule was, they replaced it with a horribly > unclear rule in axfr-clarify-02: > > An RR is associated with a zone by being loaded from the master file > of that zone at the primary master server, or by some other, > equivalent method for configuring zone data. ... The transfer MUST > NOT include any RRs that are not associated with the zone, such as > RRs associated with zones other than the one being transferred. > > My questions about the meaning of that rule remain unanswered. > > > I wouldn't read it as prohibiting a single configuration file; the term > > "master file for that zone" in the djbdns context just means data.cdb, > > That's certainly how the software is supposed to work, and it seems to > be a reasonable interpretation of ``associated'': the records for > moon.heaven.af.mil and full.moon.heaven.af.mil are associated with two > zones, heaven.af.mil and moon.heaven.af.mil. > > However, the axfr-clarify-02 rule then contradicts itself: > > MUST NOT include > any RRs that are not > associated with the zone ----- Sounds okay so far: the > moon.heaven.af.mil NS record > such as RRs associated with is associated with heaven.af.mil. > zones other than > the one being transferred. ----- Wait a minute! The record is > also associated with > moon.heaven.af.mil! In the draft's terminology, a record is associated with exactly one zone. What you describe can be seen as there being two identical moon.heaven.af.mil records, one associated with the parent zone and one with the child zone, both configured using a single, shared line in the data.cdb file. The draft says the transfer includes the parent copy, not the child copy, but in this case the distinction does not matter since they are are identical; what matters is that the server behaves as if the parent copy was transferred (even if only one record is actually stored). The case of full.moon.heaven.af.mil is similar. It is not the intent of the draft to outlaw this or any other configuration mechanism for primary master servers. Being the primary master, it defines the contents of the zones, and is free to do that in whichever way it likes, including ways which enforce consistency between parent and child at the delegation point or even ones that define parents as containing the union of their children. The draft is mainly concerned with the case where the server is a *slave* for one or both of the zones involved (and may also act as a master to downstream slaves). In those cases, the contents of the zones being slaved have been defined by someone else, and they should be respected by the slave server and should be transmitted verbatim to downstream slaves, and that includes non-authoritative parts for which the slave server has conflicting authoritative data in a child zone. > Is the moon.heaven.af.mil NS record allowed, or is it prohibited? What > about the record for full.moon.heaven.af.mil? How do we figure this out > from axfr-clarify-02? If your server defines the moon.heaven.af.mil zone as containing those records in its non-authoritative (glue) data, then yes, transferring them is allowed (and required). > The axfr-clarify-02 language presumes, incorrectly, that a record cannot > be ``associated'' with two zones simultaneously. To make sense of this, > you have to switch from the DNS standards' consistent-database model to > BIND 9's fractured-database model: > > * Under RFC 1034, the Domain Name System has a single node named > full.moon.heaven.af.mil. The records at that node are copied to > any place that they're needed. If a copy isn't exact, the copying > mechanism has failed and should be fixed. RFC1034 talks about copying "NS and glue RRs" to the parent, not entire nodes. > * According to BIND 9, the Domain Name System has two separate nodes > for ``full.heaven.af.mil in the heaven.af.mil zone'' and > ``full.heaven.af.mil in the moon.heaven.af.mil zone.'' According to > BIND 9, those nodes are allowed to be different, and everybody else > has to change their software to keep track of the difference. The vast majority of all delegations in the DNS are between physically separate parent and child servers. This means that even if you like to think that there is a single conceptual "node" at the delegation point, there are in fact two separate physical nodes, one at the parent server and one at the child server. In a correctly configured delegation these nodes will have identical NS records, but in practice they are often differences. In terms of records other than NS, the nodes are completely different - for example, the child has an SOA record but the parent does not, and various DNSSEC related records will be present in one but not the other or even differently in both. In reality, the DNS *is* a fractured database. Since the nodes are separate when the zones are on separate servers, it makes sense for them to also be separate when they zones happen to be on the same server. RFC1035 goes as far as saying that the "suggested data structure" for a name server has "Separate data structures for each of the zones held by the name server". BIND 4 and BIND 8 failed to follow this suggestion and stored their data in a single tree sharing a node between parent and child, and while this did work in most cases, problems quickly became apparent as the IETF DNS standards evolved. For example, the incremental zone transfer (RFC1995) protocol makes the implicit assumption that the zone data do not spontaneously change, but with a shared node, that's exactly what will happen to glue data in the parent as changes are made in the child. When a downstream IXFR slave receives a combination of AXFRs and IXFRs from multiple masters, such spontaneous changes will cause the IXFR protocol to get out of sync. The DNSSEC protocol (RFC2065) even specifically requires that the parent and child store different NXT records at the delegation point, which is impossible to do if the node is shared. A server using the data structures of BIND 4 or BIND 8 simply will not meet the requirements of these protocols, and this was one of the reasons why BIND 9 was written in the first place. This is a case of BIND being changed because of the standards, not of the standards being changed because of BIND. -- 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 Nov 20 02:22:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08486 for ; Wed, 20 Nov 2002 02:22:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EP33-0006He-00 for namedroppers-data@psg.com; Tue, 19 Nov 2002 23:13:21 -0800 Received: from adsl-67-119-98-58.dsl.snfc21.pacbell.net ([67.119.98.58] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #2) id 18EP31-0006Gb-00 for namedroppers@ops.ietf.org; Tue, 19 Nov 2002 23:13:19 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id gAK7CpXx018328; Tue, 19 Nov 2002 23:12:51 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id gAK7CoY2018325; Tue, 19 Nov 2002 23:12:50 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Tue, 19 Nov 2002 23:12:50 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: wildcard optimization and b/w incompatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 19 Nov 2002, Edward Lewis wrote: > I'm not sure, but I think this paragraph is wrong: > > # The fact that resolvers that obtain an answer with a NXT RR's NOWILD > # set to 1 do not receive additional proof for the non-existence of > # wildcards is incompatible with RFC2535. > > This is at the end of section 2.2, "resolver side" processing discussion. > > After hearing Olaf's presentation I was thinking about whether or not > this proposal indeed lacks backwards compatibility. > > For "old" = not optimizing and "new" = optimizing, we need to look > at four cases. > > 1) New signer, old server. > 2) New resolver, old server. > 3) Old signer, new server. > 4) Old resolver, new server. > > 1 - a problem only if the server checks the NXT type bit map on load, > axfr, ixfr, or dynamic update. > > 2 - not a problem, the resolver will "fall back" to having to handle > the whole proof. > > 3 - no a problem, the server will always have to provide the full response. > > 4 - this is a two step problem. Old resolvers don't look for the > wildcard NXT anyway, as we didn't notice the omission until the > August workshop. If there is an old resolver that did anticipate > this, a problem would arise only if the resolver was "lazy" in my > words. By this I mean - if a resolver is "missing" some expected > data, it should go ask for it, not be lazy and give up. Maybe you didn't notice the omission, but it's been known for years. The lack of wildcard DNSSEC support has been documented in the BIND 9 README file since the file was written, well before 9.0.0 was released. > Question to the implementers - are there implementation-level > problems with the first and last case? The first case is irrelevant, as no servers do that. The last case will affect servers that support wildcard proof, of which there is at least one. No dnssec capable server that I'm aware of will look for missing NXT records, as this would be extremely complicated and would likely lead to deadlocks. There is a backwards compatibility issue. Brian -- 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 Nov 20 06:27:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16422 for ; Wed, 20 Nov 2002 06:27:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ESqO-000Dwo-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 03:16:32 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 18ESqM-000Dwc-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 03:16:30 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gAKBGSw11626 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 03:16:29 -0800 (PST) From: Bill Manning Message-Id: <200211201116.gAKBGSw11626@boreas.isi.edu> Subject: I do not agree To: namedroppers@ops.ietf.org Date: Wed, 20 Nov 2002 03:16:28 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.5 required=5.0 tests=SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_05_08 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit to djb's terms of acceptance, I know he reads this list. So Professor Bernstein, if you have the time, I'd appreciate an answer to my two questions below. A private reply will suffice. ----- Forwarded message from The qsecretary program ----- From MAILER-DAEMON@ISI.EDU Wed Nov 20 03:06:54 2002 Message-Id: <200211201106.gAKB6kL07253@tnt.isi.edu> Date: 20 Nov 2002 11:06:44 -0000 From: "The qsecretary program" To: bmanning@ISI.EDU Subject: qsecretary notice X-AntiVirus: scanned by AMaViS 0.2.1 Hi. This is D. J. Bernstein's automated mail-handling program. I've received a message from you. The top of your message is shown below. Professor Bernstein receives many interesting messages. Unfortunately, he also receives a torrent of unsolicited commercial mail, unsolicited job applications, unsolicited mailing-list subscriptions, forged mailing-list subscriptions, etc. Professor Bernstein has asked me to reject all bulk mail messages. But I'm a rather primitive computer program, and I'm not sure whether your message is bulk mail. If you reply to this notice, you are (1) acknowledging that Professor Bernstein does not want to receive bulk mail; (2) confirming that your message is not part of a bulk mailing; and (3) agreeing to pay Professor Bernstein $250 if your message is part of a bulk mailing. I won't look at the contents of your reply. A simple OK is fine, as long as it's sent to the address shown above. You don't have to include a second copy of your message. If you do not reply to this notice, your message will eventually be returned to you, and Professor Bernstein will not see it. I realize that this confirmation process is inconvenient. I'm sorry for the hassle. I hope that IM2000, Professor Bernstein's new Internet mail architecture, succeeds in eliminating these problems. In the meantime, we're all suffering because of a few inconsiderate people. Sincerely, The qsecretary program P.S. Professor Bernstein has asked me to convey his own apologies to you if you're someone he knows. I'm sure he'll tell me to accept subsequent messages from you without confirmation. If you're replying to a message that Professor Bernstein sent you, the problem is probably that the return address in your message isn't the same as the address that Professor Bernstein has on file. I'll let Professor Bernstein know that he should add your new address. P.P.S. If you're a legitimate mailing-list manager, and you've received what appears to be a subscription request from djb@cr.yp.to: That request is a forgery. Professor Bernstein uses different addresses for his mailing-list subscriptions. Please remove djb@cr.yp.to from your mailing list. Do not reply to this message. Note that high-quality mailing-list software confirms each subscription request with a secure cryptographic authenticator; supports tracing by returning a complete copy of each request, including Received fields; and supports filtering by adding a Mailing-List field to every outgoing message, including confirmation notices. If your software does not have these features, upgrade! --- Below this line is the top of your message. Received: (qmail 68333 invoked from network); 20 Nov 2002 11:07:06 -0000 Received: from boreas.isi.edu (128.9.160.161) by stoneport.math.uic.edu with SMTP; 20 Nov 2002 11:07:06 -0000 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gAKB6h106073; Wed, 20 Nov 2002 03:06:43 -0800 (PST) From: Bill Manning Message-Id: <200211201106.gAKB6h106073@boreas.isi.edu> Subject: survey sez.... In-Reply-To: <20021120033827.34516.qmail@cr.yp.to> from "D. J. Bernstein" at "Nov 20, 2 03:38:27 am" To: djb@cr.yp.to Date: Wed, 20 Nov 2002 03:06:43 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, is there a specific test that you think I should perform to identify servers that are running your code? are there specific tests that may be performed that will discriminate between the various releases of your code? -- --bill ----- End of forwarded message from The qsecretary program ----- -- --bill -- 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 Nov 20 09:48:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20539 for ; Wed, 20 Nov 2002 09:48:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EVvl-000KGZ-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 06:34:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18EVvf-000KGE-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 06:34:12 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18EVve-000Mc1-00; Wed, 20 Nov 2002 06:34:10 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org, dns@list.cr.yp.to Subject: Re: axfr-clarify on the move again References: <96C102324EF9D411A49500306E06C8D1020200B6@eketsv02.cubis.de> <5.1.1.6.2.20021119143305.02dd6838@mail.amaranth.net> <20021120084916.34961.qmail@cr.yp.to> Message-Id: Date: Wed, 20 Nov 2002 06:34:10 -0800 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > P.S. Randy Bush has been discarding my messages to namedroppers again. false. namedroppers allows posts from subscribers. djb@cr.yp.to is not one. when messages from non-subscribers arrive for approval, then, if i see them, i approve them. but, as the warning i put on says [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] 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 Nov 20 10:01:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21045 for ; Wed, 20 Nov 2002 10:01:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EW9L-000KgB-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 06:48:19 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18EW9J-000Kft-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 06:48:17 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAKEmDYm038553 for ; Wed, 20 Nov 2002 09:48:13 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA06796 for ; Wed, 20 Nov 2002 09:48:10 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 20 Nov 2002 09:41:46 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wildcard optimization and b/w incompatibility Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:12 -0800 11/19/02, Brian Wellington wrote: >The last case will affect servers that support wildcard proof, of which >there is at least one. No dnssec capable server that I'm aware of >will look for missing NXT records, as this would be extremely >complicated and would likely lead to deadlocks. By "no dnssec capable server" do you mean "no dnssec capable resolver in use by a server?" The confusion is: 1) Are you talking about the problem of finding all NXT records needed to accomplish a validation of authenticated denial of existence? 2) Are you talking about the problem of locating all necessary NXT records when assembling a reply? I'm assuming that you mean #1 - the "last case" was an old resolver and a new server. If so - could you expand on your rationale. "Extremely complicated" leaves me with not enough data to know if this is because of an implementation decision or a protocol definition. Also, a phrase such as "likely lead" is just as hard to evaluate. The reason I ask is that when I once wrote a non-threaded, dedicated resolver, discovering that some piece of data is missing and needed to be retrieved wasn't all that hard. Given that BIND 9 is a much more complicated code base, perhaps there is some deadlock potential (especially if data keeps timing out before you can evaluate the signatures), but I'd like a deeper description. (else - let me know if it's #2 you mean) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 20 10:45:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22576 for ; Wed, 20 Nov 2002 10:45:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EWuI-000Ly4-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 07:36:50 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18EWuE-000Lxr-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 07:36:48 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAKFajYm040756 for ; Wed, 20 Nov 2002 10:36:45 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA09808; Wed, 20 Nov 2002 10:36:31 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 20 Nov 2002 10:36:15 -0500 To: From: Edward Lewis Subject: Re: Clear path requirement Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm not sure how to take this thread. The problem is a failure in the end to end assumption of the Internet. Not personally being on top of the the general topic of what we colloquially call "NAT," I think the problem is that components are interacting with the DNS protocol in a non-compliant (with the RFCs) way. How does a protocol go about hardening itself against miscreant devices. Ignoring the issue I call NAT, this is something that needs to be addresses. Bugs, outages, etc. are cases of "miscreant" action. There are some basic principles to keep in mind. First - graceful degradation of services. (Best example of this refers to the loss of bandwidth as channels break.) Another principle is - don't panic. By this I mean, don't start complaining needlessly as this just irritates the rest of the network. (E.g., in a diskless environment while recovering from a power failure, clients became too aggressive in reattaching to the server, causing the server to fall down. I could use a more recent example of a particular resolver and lame delegations.) There are probably other principles, I'd ask others if they can think of any. I'm not claiming to be complete here, but those are the two principles I've held most dear. The first principle says - if we can't get the secure data and can't evaluate the security, we might want to just drop the level of security. Ooh - heresy, but faced with less secure or no network at all, well, it's your choice. The second principle says - a few things. One, whatever the new code does, do not cause harm to the old code. E.g., let's avoid the situation that old caches mark servers lame for incorrect reasons. Two, don't screw with the basic architecture to solve this problem. Once we fool with the basic nature of the protocol, we begin playing with fire. (E.g., KEY RR's use of the flags as an end-run around the name-type-class assumption of DNS and the resulting "key restrict" document.) I just thought of a third principle, which really doesn't apply here. Explicit recovery. Don't be afraid to alter some basic assumptions while healing the system. Since we aren't considering system failure here, there isn't a "healing" phase to consider. If we had, well, we don't so I won't go there. So - what do I think should be done (as of now)? I think we should have a DS-aware bit in the message (OPT RR, whatever), we should define "DS-lame" as a condition of servers that are DNSSEC-aware but not DS-aware, and that when DS-lameness detected, a resolver experiences a hard failure and hopefully will retry another "path." I think we should not do any kind of tinkering with naming schemes because we might then cause servers to have to assemble answers differently, and/or run into problems with the concept of credibility (RFC 2181) at the resolver. The previous paragraph is a summary of a message that appeared on the dnssec@cafax.se list, a draft of a discussion held at a workshop just before the IETF 55. I'd attach a link to the message in the archives, but the IETF-net is "not good" right now. (I can ping www.cafax.se, but I can't http://www.cafax.se./dnssec now.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 20 11:19:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23586 for ; Wed, 20 Nov 2002 11:19:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EXSq-000N0D-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 08:12:32 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18EXSo-000Mzx-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 08:12:30 -0800 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gAKGAoD62590; Wed, 20 Nov 2002 11:10:51 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021120092144.0216fe68@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 20 Nov 2002 09:37:04 -0500 To: Paul Vixie , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Proposal for TSIG update In-Reply-To: <20021119235100.A4D0B37A2AB@as.vix.com> References: <84DD35E3DD87D5489AC42A59926DABE90888E8@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:51 2002-11-19, Paul Vixie wrote: > > I propose that TSIG-bis allows TKEY to sign the last response as soon as > > shared secret key is established (even if the query was not signed). > > > > Comments? > >sounds right to me. In the DNSEXT meeting yesterday, I asked for the "sense of the room" on this issue. After explaining the issue as a general conflict between two RFC's[1] both trying to do the right thing but for different reasons: TSIG RFC (I'm one of the authors) was trying to make sure that the parties in the exchange would never be surprised by a spontaneous TSIG in the middle. GSSAPI TSIG document is trying to do the right thing from security point of view by protecting the last message of a key exchange and allows client to determine that it and the server have agreed to the same secret. The change that has been proposed supports both TSIG intent (no surprises) and the security desire of GSSAPI. This change is only seen by a TSIG enabled entity that engages in a GSSAPI TKEY exchange. Thus it is harmless to the installed base. Any further additions of TSIG messages in a middle of a exchange will be limited to new uses of TSIG and thus are harmless to installed base. The only drawback to this change is that some implantations make design choices that prevent/make hard to add support for GSSAPI TKEY exchange. Olafur [1] TSIG is an Proposed Standard RFC, GSSAPI TSIG is in RFC editors queue after passing working group and IETF review. -- 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 Nov 20 12:48:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25845 for ; Wed, 20 Nov 2002 12:48:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EYii-000PFc-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 09:33:00 -0800 Received: from h140.s251.netsol.com ([216.168.251.140] helo=twister.rgy.netsol.com) by psg.com with esmtp (Exim 3.36 #2) id 18EYig-000PEE-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 09:32:58 -0800 Received: from typhoon (unknown [10.131.128.57]) by twister.rgy.netsol.com (Postfix) with SMTP id 171623D261F; Wed, 20 Nov 2002 12:32:27 -0500 (EST) Message-ID: <011f01c290ba$cb6d7420$3980830a@typhoon> Reply-To: "Matt Larson" From: "Matt Larson" To: Cc: References: Subject: Re: Clear path requirement Date: Wed, 20 Nov 2002 12:32:26 -0500 Organization: VeriSign Global Registry Services 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > So - what do I think should be done (as of now)? I think we should > have a DS-aware bit in the message (OPT RR, whatever), Olaf asked this question earlier and no one replied, so I'll ask it again: Why do we need a DS-aware bit when we've already got the OK bit, and we're having a flag day anyway? I really don't want to see a DS-aware bit--I think that's unnecessarily complicated. > I think we should not do any kind of tinkering with naming schemes > because we might then cause servers to have to assemble answers > differently, and/or run into problems with the concept of credibility > (RFC 2181) at the resolver. Name space tinkering doesn't necessarily imply credibility problems if all the modifications are done at the resolver, i.e., the server needs no special knowledge and a resolver has to issue a second query to retrieve the DS record at the "alternate" name (example._ds.com, _ds_example.com, whatever). Yes, it's an ugly hack that requires additional queries, not to mention another NXT and SIG(NXT). But it doesn't mess with the fundamental DNS resolution algorithm, which makes me Very Nervous. Matt -- 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 Nov 20 13:33:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26822 for ; Wed, 20 Nov 2002 13:33:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EZOJ-0000cW-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 10:15:59 -0800 Received: from h140.s251.netsol.com ([216.168.251.140] helo=twister.rgy.netsol.com) by psg.com with esmtp (Exim 3.36 #2) id 18EZOG-0000aQ-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 10:15:56 -0800 Received: from typhoon (unknown [10.131.128.57]) by twister.rgy.netsol.com (Postfix) with SMTP id 006C63D261F for ; Wed, 20 Nov 2002 13:15:25 -0500 (EST) Message-ID: <013701c290c0$cc956aa0$3980830a@typhoon> Reply-To: "Matt Larson" From: "Matt Larson" To: Subject: Clear path? I'll give you clear path Date: Wed, 20 Nov 2002 13:15:25 -0500 Organization: VeriSign Global Registry Services 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.8 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_02_03,USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A way around the non-DNSSEC-aware, non-DS-aware, non-EDNS0-aware, transparent NATting, broken DNS caches from hell is to use another port for DNSSEC queries. Bear with me on this one. - The alternate port supports the traditional DNS protocol, but with some assumptions: - The protocol speakers are DNSSEC-aware, including DS support and whatever else gets thrown in for the flag day. - The protocol speakers support EDNS0 with a large message size, say 1220 bytes as specified in RFC 3226. - A DNSSEC-capable server listens on this alternate port as well as port 53. - Any query, whether DNSSEC-related or not, can be sent to the alternate port. But the assumptions about the sender's capabilities (see above) hold. - A recursive resolver sends a query to the alternate port when it wants a DNSSEC response or has reason to believe the queried server to be DNSSEC-capable (i.e., it has a trusted key configured for a given apex that's an ancestor of a QNAME it's recursing on). - When a recursive resolver gets an indication that the server doesn't support DNSSEC or crosses a boundary into an unsigned zone, it reverts to port 53. - I believe this makes the OK bit redundant, at least for the alternate port. This is NOT an attempt to fuss with the DNS protocol or invent something new for this alternate port. It's using the same protocol, but with different underlying assumptions about the speakers' capabilities, on a different port. Before you light into me, think about the alternatives: an ugly name space hack for DS or yet another DNSSEC-capabilities flag (to indicate DS awareness). And even with all that, we'd still have EDNS0 probing issues and other "clear path" issues, such as transparent proxies. All this goes away with an alternate port. Matt -- 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 Nov 20 14:35:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28499 for ; Wed, 20 Nov 2002 14:35:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EaVm-0003V8-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 11:27:46 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 18EaVk-0003UN-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 11:27:44 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id B0ACB137F03; Wed, 20 Nov 2002 11:27:30 -0800 (PST) To: "Matt Larson" Cc: namedroppers@ops.ietf.org Subject: Re: Clear path? I'll give you clear path In-Reply-To: Message from "Matt Larson" of "Wed, 20 Nov 2002 13:15:25 EST." <013701c290c0$cc956aa0$3980830a@typhoon> Date: Wed, 20 Nov 2002 11:27:30 -0800 Message-ID: <85278.1037820450@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Matt" == Matt Larson writes: Matt> A way around the non-DNSSEC-aware, non-DS-aware, Matt> non-EDNS0-aware, transparent NATting, broken DNS caches from Matt> hell is to use another port for DNSSEC queries. It's probably not a good idea to run the same protocol -- albeit where one flavour has DNSSEC -- on >1 port. Other protocols have not done this whenever extensions or new versions have come along. An extra port for DNS may well create lots of operational problems, like requiring another hole to get punched though everyone's firewall and router configurations. [And what happens when a DNSSEC-aware query that becomes DNSSEC-unware (or vice versa) resolves through a stateful firewall or proxy?] It's not clear to me what benefit arises from using another port number compared to just using the OK bit, assuming that bit can helps the clear path issue. -- 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 Nov 20 16:23:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01432 for ; Wed, 20 Nov 2002 16:23:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ec9G-0006va-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 13:12:38 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18Ec9D-0006vN-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 13:12:35 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 239E337A037 for ; Wed, 20 Nov 2002 21:12:35 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Clear path? I'll give you clear path In-Reply-To: Message from "Matt Larson" of "Wed, 20 Nov 2002 13:15:25 EST." <013701c290c0$cc956aa0$3980830a@typhoon> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 20 Nov 2002 21:12:35 +0000 Message-Id: <20021120211235.239E337A037@as.vix.com> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i used to love this idea. i remember when eastlake proposed it in 1996. > - The protocol speakers are DNSSEC-aware, including DS support and > whatever else gets > thrown in for the flag day. yes, well, other things that would get thrown in for flag day would most likely include unicode name encoding, xml message encoding, and a pile of other stuff we havn't even heard of yet. in other words, this would be madness, the dns community lacks the required discipline to make a moderate change. small or large, we can do. moderate, i don't think so. > This is NOT an attempt to fuss with the DNS protocol or invent something > new for this alternate port. (as if we'd have a choice about complete reinvention if we cut that deep.) > It's using the same protocol, but with different underlying > assumptions about the speakers' capabilities, on a different port. one more objection, having more to do with deployed human nature than latent human nature: there are a LOT of firewalls that only allow known port numbers. i'd say there are more segments which are isolated from udp/42 (or whatever this dns++ would speak) than there are segments whose gateways pervert/rewrite udp/53 as it passes through. > Before you light into me, think about the alternatives: an ugly name > space hack for DS or yet another DNSSEC-capabilities flag (to indicate > DS awareness). And even with all that, we'd still have EDNS0 probing > issues and other "clear path" issues, such as transparent proxies. All > this goes away with an alternate port. the edns0 probing issues are tractible, and another flag bit would be tractible. even some kind of odd name hack would be tractible. but trying to get an alternate port number standardized without resolving the rest of the community's long standing gripes against dns would just be intractible. it's a nice thought of course, for some kind of alternate universe where deadlines mattered. -- 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 Nov 20 16:30:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01582 for ; Wed, 20 Nov 2002 16:30:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EcJU-0007VP-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 13:23:12 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18EcJS-0007VC-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 13:23:10 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAKLN8Ym056524; Wed, 20 Nov 2002 16:23:08 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA15305; Wed, 20 Nov 2002 16:23:07 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <011f01c290ba$cb6d7420$3980830a@typhoon> References: <011f01c290ba$cb6d7420$3980830a@typhoon> Date: Wed, 20 Nov 2002 16:07:32 -0500 To: "Matt Larson" , From: Edward Lewis Subject: Re: Clear path requirement Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:32 -0500 11/20/02, Matt Larson wrote: >Olaf asked this question earlier and no one replied, so I'll ask it >again: Why do we need a DS-aware bit when we've already got the OK bit, >and we're having a flag day anyway? I really don't want to see a >DS-aware bit--I think that's unnecessarily complicated. BIND 9.2 - at least. >Name space tinkering doesn't necessarily imply credibility problems if >all the modifications are done at the resolver, i.e., the server needs >no special knowledge and a resolver has to issue a second query to >retrieve the DS record at the "alternate" name (example._ds.com, >_ds_example.com, whatever). Yes, it's an ugly hack that requires >additional queries, not to mention another NXT and SIG(NXT). But it >doesn't mess with the fundamental DNS resolution algorithm, which makes >me Very Nervous. The problem is that caching resolvers attach the credibility to the data admitted to the cache. When a caching server answers from cached data, the credibility is part of the equation used to know what records to put in the response. Or so I believe. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 20 16:49:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02180 for ; Wed, 20 Nov 2002 16:49:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ecbo-0008dB-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 13:42:08 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18Ecbl-0008cq-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 13:42:05 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAKLg3Ym057136; Wed, 20 Nov 2002 16:42:03 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA09033; Wed, 20 Nov 2002 16:41:46 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <85278.1037820450@shell.nominum.com> References: <85278.1037820450@shell.nominum.com> Date: Wed, 20 Nov 2002 16:41:42 -0500 To: Jim Reid , "Matt Larson" From: Edward Lewis Subject: Re: Clear path? I'll give you clear path Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm going to counter Jim's point. At 11:27 -0800 11/20/02, Jim Reid wrote: >>>>>> "Matt" == Matt Larson writes: > > Matt> A way around the non-DNSSEC-aware, non-DS-aware, > Matt> non-EDNS0-aware, transparent NATting, broken DNS caches from > Matt> hell is to use another port for DNSSEC queries. > >It's probably not a good idea to run the same protocol -- albeit where >one flavour has DNSSEC -- on >1 port. Other protocols have not done Donald broached this possibility (at least) recently. What this does is remove danger to old implementations (do no/less harm). It removes a need to be overly concerned with remaining compatible with "broken" parts of the old protocol. 'Course Jim is right is that mean that the anti-end-to-end boxes will have to be updated for this anyway (i.e., you can't just blast through a firewall). But at least if we're messing on another port, there's a assurance of a hard failure when there's no clear channel. Delving in to the realm of conjecture, has adding a second port to a protocol ever made improvement easier? I think there are examples where a new port hasn't helped. Whois, maybe? (Perhaps I'm wrong, but that leaps to mind.) Okay, hasn't helped yet. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 20 17:03:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02788 for ; Wed, 20 Nov 2002 17:03:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EcdV-0008mQ-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 13:43:53 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18EcdT-0008mD-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 13:43:51 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gAKLhWkw011846; Wed, 20 Nov 2002 13:43:32 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 13:43:49 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: Paul Vixie , namedroppers@ops.ietf.org Subject: RE: Clear path? I'll give you clear path Date: Wed, 20 Nov 2002 13:43:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0019_01C290B3.EFEF7A70"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.7 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C290B3.EFEF7A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I agree with Paul. If you are going to move to a different port then you really have to start asking why design DNSSEC within the straitjacket of deployed DNS in the first place. If you are going to take that approach you could start asking how many corner cases can be eliminated by simply taking a flag day and modifying the protocol in a more radical fashion. Drop support for Heisod, Chaosnet for starters, drop in a cryptographic framing protocol, DIME, use manifests for signatures, .... If however you problem is simply that you need to route arround lossage then you do not need a standard and in fact you don't want a standard, all the standard does is help the attacker (the hotel ISP or whatever). Set up a DNS relay on a random non standard port above 1024, set yourself up with a DNS relay to that server on localhost. That way you can adapt to changes in the DoS your ISP is playing against you. Phill > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com] > Sent: Wednesday, November 20, 2002 4:13 PM > To: namedroppers@ops.ietf.org > Subject: Re: Clear path? I'll give you clear path > > > i used to love this idea. i remember when eastlake proposed > it in 1996. > > > - The protocol speakers are DNSSEC-aware, including DS support and > > whatever else gets > > thrown in for the flag day. > > yes, well, other things that would get thrown in for flag day > would most > likely include unicode name encoding, xml message encoding, and a pile > of other stuff we havn't even heard of yet. in other words, > this would > be madness, the dns community lacks the required discipline to make a > moderate change. small or large, we can do. moderate, i > don't think so. > > > This is NOT an attempt to fuss with the DNS protocol or > invent something > > new for this alternate port. > > (as if we'd have a choice about complete reinvention if we > cut that deep.) > > > It's using the same protocol, but with different underlying > > assumptions about the speakers' capabilities, on a different port. > > one more objection, having more to do with deployed human nature than > latent human nature: there are a LOT of firewalls that only > allow known > port numbers. i'd say there are more segments which are isolated from > udp/42 (or whatever this dns++ would speak) than there are > segments whose > gateways pervert/rewrite udp/53 as it passes through. > > > Before you light into me, think about the alternatives: an ugly name > > space hack for DS or yet another DNSSEC-capabilities flag > (to indicate > > DS awareness). And even with all that, we'd still have > EDNS0 probing > > issues and other "clear path" issues, such as transparent > proxies. All > > this goes away with an alternate port. > > the edns0 probing issues are tractible, and another flag bit would be > tractible. even some kind of odd name hack would be tractible. but > trying to get an alternate port number standardized without resolving > the rest of the community's long standing gripes against dns > would just > be intractible. > > it's a nice thought of course, for some kind of alternate > universe where > deadlines mattered. > > -- > 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: > ------=_NextPart_000_0019_01C290B3.EFEF7A70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyMDIx NDMyMVowIwYJKoZIhvcNAQkEMRYEFMm5LfmUuiAxq8xRMdfYsajQB9P/MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAA7e8E4FQqbmruRpZOMtprJ9AE8ZGvAnc3VDGuSZu8RhNnahX fA4ZrICa4JDL8/SMrLqBuFphY/ysF/NC0NVWGYxOff3D60pEVjAwKMpSGg5I7zDDIbUjJB4xeDUP Q/jTNkp9B97ohGz5Ztws/xQYWtkVkV1Pjx8uzvgegHG6k5EAAAAAAAA= ------=_NextPart_000_0019_01C290B3.EFEF7A70-- -- 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 Nov 20 17:13:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02990 for ; Wed, 20 Nov 2002 17:13:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ecxc-000A6D-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 14:04:40 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18EcxR-000A4e-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 14:04:30 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gAKM3xZm022311; Wed, 20 Nov 2002 23:03:59 +0100 Date: Wed, 20 Nov 2002 23:03:59 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org cc: "D. J. Bernstein" Subject: How to post to a mailing list In-Reply-To: <20021120202122.31601.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_08_13,SUBJECT_IS_LIST, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Was Re: axfr-clarify on the move again ] [ excessive lists removed from cc line. ] On 20 Nov 2002, D. J. Bernstein wrote: > Randy Bush writes: > > it is easy to miss and therefore delete mis-posts > > You have been repeatedly informed that there are newsgroup readers, > sublist readers, readers with private subscription addresses, etc.--- > but you don't fix your software, you don't turn the list over to someone > competent, and you don't even take responsibility for your mistakes. I think you've confused the namedroppers list with the majordomo users list for starters. To address your particular points (as relevant to the namedroppers mailing list management) : > You have been repeatedly informed that there are newsgroup readers, > sublist readers, readers with private subscription addresses, etc.--- * If you are subscribed to a mailing list as a particular address, the common-sense thing to do is to either post using that address, or have your common posting address added to the approved posters sublist (eg listname-post ) As namedroppers, like _most_ of the IETF-related mailing lists, indeed, _most_ mailing lists, is not configured with a separate -post list, you can either post using your subscribed address just like everyone else does and have your message delivered to all subscribers, or you can take your chances at being noticed by the moderators in amongst the spam messages, (f)lemmings etc. > but you don't fix your software, * Randy has been known to fix majordomo-related problems in response to polite requests regarding that being sent to himself (or rather, to owner-namdroppers, as per the welcome message that you've naturally saved), based on personal experience. However, if your issue is 'the namedroppers does not accept posts from non-subscribed addresses', then the software is functioning as expected. If you wish to have a different behaviour, then stating the behaviour that you are after is far, far better than saying over and over that something is broken without stating how it is broken (as you have done). > you don't turn the list over to someone competent, * In terms of mailing list management, namedroppers works. A shade slow for my tastes at times (for instance, I don't expect Randy to deal with things whilst he is flying), but it does work provided you keep within its known limits. > and you don't even take responsibility for your mistakes. * In Randy's installing majordomo, or in occasionally not sifting out posts from non-subscribers from the spam? These things happen (I personally find it better to put a tag 'posts may vanish if you are not a subscriber' tag on my own mailing lists). You seem to be the only one publically having these problems, and it seems to be because you want to be Right, without the possibility of other arguments being entered into. Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security -- 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 Nov 20 17:22:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03223 for ; Wed, 20 Nov 2002 17:22:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ed2H-000AO0-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 14:09:29 -0800 Received: from h140.s251.netsol.com ([216.168.251.140] helo=twister.rgy.netsol.com) by psg.com with esmtp (Exim 3.36 #2) id 18Ed2E-000ALp-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 14:09:26 -0800 Received: from typhoon (unknown [10.131.128.57]) by twister.rgy.netsol.com (Postfix) with SMTP id DC8A43D261F; Wed, 20 Nov 2002 17:08:55 -0500 (EST) Message-ID: <029b01c290e1$6b1fe950$3980830a@typhoon> Reply-To: "Matt Larson" From: "Matt Larson" To: Cc: References: <011f01c290ba$cb6d7420$3980830a@typhoon> Subject: Re: Clear path requirement Date: Wed, 20 Nov 2002 17:08:55 -0500 Organization: VeriSign Global Registry Services 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 12:32 -0500 11/20/02, Matt Larson wrote: >> Olaf asked this question earlier and no one replied, so I'll ask it >> again: Why do we need a DS-aware bit when we've already got the OK >> bit, and we're having a flag day anyway? I really don't want to see >> a DS-aware bit--I think that's unnecessarily complicated. > > BIND 9.2 - at least. I'm sorry, but I don't understand. BIND 9.2 is not DS-aware, so it can't be used as a recursive resolver to retrieve DS records. Even though it has support for unknown types, there'll be the problems that you pointed out in your recent posting on the DNSSEC list. And do we really expect someone to try to use BIND 9.2 as an authoritative server for a zone hosting DS records, again in light of the issues you pointed out? I still think the need for a DS-aware flag is obviated by the flag day. > The problem is that caching resolvers attach the credibility to the > data admitted to the cache. When a caching server answers from > cached data, the credibility is part of the equation used to know > what records to put in the response. I think you're assuming that we'd require DS records whose owner name was mangled to be inserted in responses for other QNAMEs by a server. I'm pointing out that name-mangled DS records need not invoke additional section processing--all the knowledge of this could be done in the resolver. But maybe I'm just not understanding your comment. Matt -- 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 Nov 20 17:30:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03376 for ; Wed, 20 Nov 2002 17:30:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EdAp-000B1d-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 14:18:19 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100] ident=firewall-user) by psg.com with esmtp (Exim 3.36 #2) id 18EdAm-000B1K-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 14:18:16 -0800 Received: by sentry.gw.tislabs.com; id RAA02616; Wed, 20 Nov 2002 17:18:21 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma002600; Wed, 20 Nov 02 17:17:26 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id gAKMHHd14450 for ; Wed, 20 Nov 2002 17:17:17 -0500 (EST) Date: Wed, 20 Nov 2002 17:17:17 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: tagged DS records (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [I sent this to dnssec@cafax.se yesterday. There's some discussion at the end that won't make much sense without reference to Ed's message on that list. I encourage reading Ed's message -- it does a nice job of describing the problem.] DS Record Legacy Resolver Support (Tagged DS Records), or This Time We Mean It: DS Lives at the Parent As Ed said, these problems stem from legacy code not being able to determine the correct authority for DS records. One class of solutions is to mandate that every resolver/cache/proxy along the path be not only DNSSEC aware, but also DS aware. Such a requirement is likely to be a burden on backward compatibility that significantly adds to the problem of getting DNSSEC deployed in the public internet. Another class of solutions addresses the fundamental problem of legacy resolvers knowing to find DS records. This is only one possible solution for the specific problem, details can vary, and other ideas are welcomed. One fix is to change the label on the DS record so that legacy code properly determines that it is in the parent zone. This not only eliminates the lameness, grandparent, and DS-timeout before NS-timeout problems already identified -- it dodges the "fundamental change" that caused them. We discovered the basic lameness problem in DC in late August. It took two more months to find the grandparent problem. There's always the possibility that we've missed more nasty fallout of the "fundamental change" -- this avoids digging ourselves into a deep hole. I propose adding a tag to the label on DS records. For example, a parent zone might contain: $ORIGIN example. child NS ns.child.example. NXT delta.example. NS SIG NXT DS SIG NXT ... _ds_child DS ... SIG DS ... Adding the tag allows legacy code to clearly see that the DS is in the parent zone. In all respects, tagged DS records are treated as though the tag were not present. DS-aware authoritative servers MUST return the tagged DS record exactly when it would be returned according to [DS]. Tagged DS records are not sorted separately using the rules in Section 8.2 of [2535]. Instead, tagged DS records are sorted as though the _ds_ tag were not present, and the presence or absence of a DS record is reflected in the delegation NXT bitmap. This avoids needing a separate NXT/SIG to show if the delegation is secure or not. Similarly, if a query is received for a non-existent DS at an existent delegation, the negative answer should be: Query: _ds_insecure.example DS Answer: insecure.example NXT secure.example. ... SIG NXT ... For a non-existent name, the NXT returned must cover the label as though the _ds_ tag was not present. As DS records can only exist at a delegation, and wildcards cannot be delegations, no proof of wildcard non-existence is needed. Query: _ds_nonexistent.example DS Answer: insecure.example NXT secure.example. ... SIG NXT ... There may be cases where cache-poisoning prevention code rejects a DS record attached to a referral since the name on the DS does match the name on the NS. In those cases, a DS-aware resolver will see the DS bit in the NXT bitmap and can query explicitly for the tagged DS record. This is the only case where this change results in more queries. This does (minimally) limit the DNS namespace. This solution makes it more likely that a resolver without a "clear path" to authoritative servers will be able to get DS records. This solution addresses all of the cases Ed enumerated: Case 1 (all DS aware): c zone (upper srvr) returns a referral to bc. The lower srvr answers. Case 2 (parent (lower srvr) is DS unaware): lower srvr returns NXDOMAIN. It could also be argued that if you're following a secure chain from zone c, all servers for bc should be DS aware. Case 3 (only the cache is DS unaware): the cache, using old logic, correctly finds the DS. Footnote: The exact tagging byte(s) can be argued later. I prefer printable and readily typable characters, even if it means a longer tag. I've heard NULL suggested, and I've heard ctrl-A suggested. We can argue about this later. To be clear, the bytes(s) cannot be (in) a prepended label (ie. _ds_.child.example), since that would be in the child zone. -- 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 Nov 20 20:05:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06813 for ; Wed, 20 Nov 2002 20:05:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EfZ2-000Kgo-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 16:51:28 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18EfZ0-000Kgc-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 16:51:26 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAL0pPYm062433; Wed, 20 Nov 2002 19:51:25 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA21649; Wed, 20 Nov 2002 19:51:23 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <029b01c290e1$6b1fe950$3980830a@typhoon> References: <011f01c290ba$cb6d7420$3980830a@typhoon> <029b01c290e1$6b1fe950$3980830a@typhoon> Date: Wed, 20 Nov 2002 19:51:18 -0500 To: "Matt Larson" , From: Edward Lewis Subject: Re: Clear path requirement Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:08 -0500 11/20/02, Matt Larson wrote: >I'm sorry, but I don't understand. BIND 9.2 is not DS-aware, so it >can't be used as a recursive resolver to retrieve DS records. Even >though it has support for unknown types, there'll be the problems that >you pointed out in your recent posting on the DNSSEC list. And do we >really expect someone to try to use BIND 9.2 as an authoritative server >for a zone hosting DS records, again in light of the issues you pointed >out? A BIND 9.2 caching server might be in use on a proxy firewall. If a BIND 9.3 resolver asks it for the DS set, the 9.2 can be forced to "misbehave." >I still think the need for a DS-aware flag is obviated by the flag day. Hmmm, has anyone ever defined what is meant by a "flag day?" It's not like the old days when we switched all of our routers from all 0's broadcast to all 1's broadcast. >I think you're assuming that we'd require DS records whose owner name >was mangled to be inserted in responses for other QNAMEs by a server. >I'm pointing out that name-mangled DS records need not invoke additional >section processing--all the knowledge of this could be done in the >resolver. But maybe I'm just not understanding your comment. If you are relying on using a query to a second name to get the additional data, you will incur more round trips (times) to get the answer. Not much detail in this answer. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 20 20:24:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07330 for ; Wed, 20 Nov 2002 20:24:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Efsq-000M5t-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 17:11:56 -0800 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18Efsl-000M5c-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 17:11:52 -0800 Received: from tecotoo.www.gis.net ([67.30.177.37]) by mx05.gis.net; Wed, 20 Nov 2002 20:11:45 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ua029270 for ; Wed, 20 Nov 2002 20:12:27 -0500 Message-Id: <4.3.1.2.20021120200145.038c7400@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 20 Nov 2002 20:12:09 -0500 To: Jim Reid , "Matt Larson" From: Danny Mayer Subject: Re: Clear path? I'll give you clear path Cc: namedroppers@ops.ietf.org In-Reply-To: <85278.1037820450@shell.nominum.com> References: <013701c290c0$cc956aa0$3980830a@typhoon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:27 PM 11/20/02, Jim Reid wrote: > >>>>> "Matt" == Matt Larson writes: > > Matt> A way around the non-DNSSEC-aware, non-DS-aware, > Matt> non-EDNS0-aware, transparent NATting, broken DNS caches from > Matt> hell is to use another port for DNSSEC queries. > >It's probably not a good idea to run the same protocol -- albeit where >one flavour has DNSSEC -- on >1 port. Other protocols have not done >this whenever extensions or new versions have come along. An extra >port for DNS may well create lots of operational problems, like >requiring another hole to get punched though everyone's firewall and >router configurations. [And what happens when a DNSSEC-aware query >that becomes DNSSEC-unware (or vice versa) resolves through a stateful >firewall or proxy?] It's not clear to me what benefit arises from >using another port number compared to just using the OK bit, assuming >that bit can helps the clear path issue. Well, https, the SSL'ed version of HTTP Protocol DOES use a different port. You can argue that it's different in the sense that the setup of the connection is different. I remember having this revelation in December, 1995 in the middle of teaching a seminar on firewalls that maybe we couldn't do https through our Netscape proxy server. I had to go back to the office to confirm that it wouldn't work and that furthermore that version of Netscape's proxy server couldn't handle it. Danny -- 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 Nov 20 20:29:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07400 for ; Wed, 20 Nov 2002 20:29:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eg2T-000Mil-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 17:21:53 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100] ident=firewall-user) by psg.com with esmtp (Exim 3.36 #2) id 18Eg2Q-000MiY-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 17:21:51 -0800 Received: by sentry.gw.tislabs.com; id UAA07900; Wed, 20 Nov 2002 20:21:59 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma007872; Wed, 20 Nov 02 20:21:12 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id gAL1L2h22703; Wed, 20 Nov 2002 20:21:02 -0500 (EST) Date: Wed, 20 Nov 2002 20:21:02 -0500 (EST) From: Sam Weiler X-X-Sender: To: Edward Lewis cc: Matt Larson , Subject: Re: Clear path requirement In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Edward Lewis wrote: > > >I still think the need for a DS-aware flag is obviated by the flag day. > > Hmmm, has anyone ever defined what is meant by a "flag day?" I presumed it meant "anyone signing with 2535 will potentially see things break and they will stop signing with 2535 if that's necessary to keep other things from breaking". Or "we can deprecate any and all code that deals with 2535-signed zones". We can't assume all 2535-aware resolvers will go away, just like we can't assume that all older resolvers will go away. At the time, I don't think we recognized how interesting the legacy resolver interactions would be. -- Sam -- 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 Nov 20 21:56:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09466 for ; Wed, 20 Nov 2002 21:56:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EhKy-0002SU-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 18:45:04 -0800 Received: from adsl-67-119-98-58.dsl.snfc21.pacbell.net ([67.119.98.58] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #2) id 18EhKt-0002QO-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 18:44:59 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id gAL2hXXx023901; Wed, 20 Nov 2002 18:43:33 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id gAL2hWmF023898; Wed, 20 Nov 2002 18:43:32 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Wed, 20 Nov 2002 18:43:32 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: wildcard optimization and b/w incompatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Edward Lewis wrote: > At 23:12 -0800 11/19/02, Brian Wellington wrote: > >The last case will affect servers that support wildcard proof, of which > >there is at least one. No dnssec capable server that I'm aware of > >will look for missing NXT records, as this would be extremely > >complicated and would likely lead to deadlocks. > > By "no dnssec capable server" do you mean "no dnssec capable resolver > in use by a server?" The confusion is: Yes. > 1) Are you talking about the problem of finding all NXT records > needed to accomplish a validation of authenticated denial of > existence? Yes. > 2) Are you talking about the problem of locating all necessary NXT > records when assembling a reply? No. For a non-SERVFAIL reply to be sent, all of the NXT records must already be present, since they were needed for validation. > I'm assuming that you mean #1 - the "last case" was an old resolver > and a new server. > > If so - could you expand on your rationale. "Extremely complicated" > leaves me with not enough data to know if this is because of an > implementation decision or a protocol definition. Also, a phrase > such as "likely lead" is just as hard to evaluate. Writing such an implementation would be extremely difficult and not worth it, since any compliant authoritative server should return all needed NXTs anyway. Yes, 'likely lead' is hard to evaluate. Having written multiple DNSSEC validating resolvers, there are many things which lead to deadlock. Without implementing this, I can't tell you for sure, but based on prior experience, I think there's a very good chance that it would. I'm not going to implement this just to find out. > The reason I ask is that when I once wrote a non-threaded, dedicated > resolver, discovering that some piece of data is missing and needed > to be retrieved wasn't all that hard. Given that BIND 9 is a much > more complicated code base, perhaps there is some deadlock potential > (especially if data keeps timing out before you can evaluate the > signatures), but I'd like a deeper description. I'm not talking about BIND 9. I"m talking about servers in general. Yes, going out to get a missing piece of data sounds easy, but then when you try to validate it, you might be missing something else, or it might depend on the validation which is already in progress, or any of a number of other issues which lead to deadlock. Brian -- 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 Nov 20 22:15:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09974 for ; Wed, 20 Nov 2002 22:14:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ehja-0004Mp-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 19:10:30 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18EhjX-0004Mb-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 19:10:27 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAL3APYm065019; Wed, 20 Nov 2002 22:10:26 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA19371; Wed, 20 Nov 2002 22:10:24 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 20 Nov 2002 22:10:21 -0500 To: Brian Wellington , Edward Lewis From: Edward Lewis Subject: Re: wildcard optimization and b/w incompatibility Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:43 -0800 11/20/02, Brian Wellington wrote: >Writing such an implementation would be extremely difficult and not worth >it, since any compliant authoritative server should return all needed NXTs >anyway. True, but, 1) "compliant" changes and 2) I know of current servers that don't return the wildcard NXT in NXDOMAIN answers now. Yes, this is non-compliance, but there's always that discussion of 'miscreant' elements to consider. >Yes, 'likely lead' is hard to evaluate. Having written multiple DNSSEC >validating resolvers, there are many things which lead to deadlock. >Without implementing this, I can't tell you for sure, but based on prior >experience, I think there's a very good chance that it would. I'm not >going to implement this just to find out. There are three possible responses to this. 1) Does anyone else want to try? (As it's Brian's right to refuse a try.) 2) Can someone prove this analytically? 3) Should we drop this discussion and 'assume' backwards compatibility? >I'm not talking about BIND 9. I"m talking about servers in general. I used "BIND 9" in the sense that it's code that is much more complicated than what I wrote, so my experience may not be applicable here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 21 00:44:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12949 for ; Thu, 21 Nov 2002 00:44:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EjzV-000ETY-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 21:35:05 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18EjzR-000ESS-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 21:35:01 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 8C17737A037 for ; Thu, 21 Nov 2002 05:35:00 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Clear path requirement In-Reply-To: Message from Sam Weiler of "Wed, 20 Nov 2002 20:21:02 EST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 21 Nov 2002 05:35:00 +0000 Message-Id: <20021121053500.8C17737A037@as.vix.com> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > >I still think the need for a DS-aware flag is obviated by the flag day. > > > > Hmmm, has anyone ever defined what is meant by a "flag day?" > > I presumed it meant "anyone signing with 2535 will potentially see > things break and they will stop signing with 2535 if that's necessary > to keep other things from breaking". ... i'm the one who keeps bringing it up so i'll say what i've been meaning by the term "flag day." a flag day is when everyone who wants to continue to have functionality of some type has to upgrade. ncp->tcp was a flag day. sure, there were islands of ncp after the flag day, but none today. when you make an incompatible change to the on-the-wire format of a protocol, you invalidate a set of older clients. by "incompatible" i don't mean breaking older implementations of a looser spec, nor anything for which being liberal in what you accept is an antidote. i mean "the people who had this functionality before the date, will have to change their software or configuration in order to ever have it again after the date." in dnssec terms, we have at least one flag day coming, due to DS or whatever we use instead of DS if we can't make DS work. the thing we don't know yet is whether that will be our last flag day. why not? because we are still doing basic research on what kind of data model will work for dns security. after three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?" for comparison purposes, it's hard (bordering on beyond impossible) to imagine declaring another flag day for IPv6, such that all pre-flagday implementations would become obsolete and incompatible until upgraded. whereas, for DNSSEC, the opposite is far from false: it's impossible to know how many more flag days we'll have before it's safe to burn ROMs that marshall and unmarshall the DNSSEC related RR's, or follow chains trying to validate signatures. it sure isn't plain old SIG+KEY, and it sure isn't DS as currently specified. when will it be? we don't know. what has to happen before we will know? we don't know that either. right now i'm ready to treat "that was our last flag day" as a victory, even if the specs and tools are a little rough on that particular day. i'm interested in seeing a clear list of things that have to happen before we will know what has to happen before our final DNSSEC flag day. 2535 is already dead and buried. there is no installed base. we're starting from scratch. that's both a boon and a curse. -- 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 Nov 21 01:54:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14358 for ; Thu, 21 Nov 2002 01:54:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18El55-000Jak-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 22:44:55 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18El53-000JaY-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 22:44:53 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18El52-0003bt-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 01:44:52 -0500 Message-ID: <20021120202122.31601.qmail@cr.yp.to> References: <96C102324EF9D411A49500306E06C8D1020200B6@eketsv02.cubis.de> <5.1.1.6.2.20021119143305.02dd6838@mail.amaranth.net> <20021120084916.34961.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 20 Nov 2002 20:21:22 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org, dns@list.cr.yp.to Subject: Re: axfr-clarify on the move again X-Spam-Status: No, hits=0.1 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 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 mis-posts. so fix subscription addresses! ] Randy Bush writes: > it is easy to miss and therefore delete mis-posts Funny how this happens so often for people you disagree with. Several incidents are documented in http://cr.yp.to/djbdns/namedroppers.html. You have been repeatedly informed that there are newsgroup readers, sublist readers, readers with private subscription addresses, etc.--- but you don't fix your software, you don't turn the list over to someone competent, and you don't even take responsibility for your mistakes. ---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 Nov 21 02:14:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24385 for ; Thu, 21 Nov 2002 02:13:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ElNu-000LEx-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 23:04:22 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18ElNs-000LEj-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 23:04:20 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18ElNq-0003dZ-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 02:04:18 -0500 Message-Id: <200211210052.gAL0qMD17398@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3425 on Obsoleting IQUERY Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Wed, 20 Nov 2002 16:52:22 -0800 X-Spam-Status: No, hits=2.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,RESENT_TO,SPAM_PHRASE_00_01, TO_MALFORMED version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3425 Title: Obsoleting IQUERY Author(s): D. Lawrence Status: Standards Track Date: November 2002 Mailbox: tale@nominum.com Pages: 5 Characters: 8615 Updates: 1035 I-D Tag: draft-ietf-dnsext-obsolete-iquery-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3425.txt The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. 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: <021120165015.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3425 --OtherAccess Content-Type: Message/External-body; name="rfc3425.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021120165015.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 Thu Nov 21 02:29:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24542 for ; Thu, 21 Nov 2002 02:29:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ElYe-000M4G-00 for namedroppers-data@psg.com; Wed, 20 Nov 2002 23:15:28 -0800 Received: from gw.gbch.net ([203.143.238.93] ident=belz20) by psg.com with smtp (Exim 3.36 #2) id 18ElYb-000M44-00 for namedroppers@ops.ietf.org; Wed, 20 Nov 2002 23:15:26 -0800 Received: (qmail 23303 invoked by uid 1001); 21 Nov 2002 17:15:17 +1000 X-Posted-By: GJB-Post 2.29 08-Nov-2002 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Uptime: 140 days, 23:12 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-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Thu, 21 Nov 2002 17:15:17 +1000 From: Greg Black To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: axfr-clarify on the move again References: <96C102324EF9D411A49500306E06C8D1020200B6@eketsv02.cubis.de> <5.1.1.6.2.20021119143305.02dd6838@mail.amaranth.net> <20021120084916.34961.qmail@cr.yp.to> <20021120202122.31601.qmail@cr.yp.to> In-reply-to: <20021120202122.31601.qmail@cr.yp.to> of 20 Nov 2002 20:21:22 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "D. J. Bernstein" wrote: | [ post by non-subscriber. with the massive amount of spam, it is easy to | miss and therefore delete mis-posts. so fix subscription addresses! ] | | Randy Bush writes: | > it is easy to miss and therefore delete mis-posts | | Funny how this happens so often for people you disagree with. Several | incidents are documented in http://cr.yp.to/djbdns/namedroppers.html. | | You have been repeatedly informed that there are newsgroup readers, | sublist readers, readers with private subscription addresses, etc.--- | but you don't fix your software, you don't turn the list over to someone | competent, and you don't even take responsibility for your mistakes. Beautifully spoken words from the man who likes to make even subscribers to his lists jump through ludicrous hoops in order to post to those lists. Anybody who does things differently from DJB is incompetent and wrong; only the DJB take on any subject is reasonable. Time to grow up. -- 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 Nov 21 14:51:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17702 for ; Thu, 21 Nov 2002 14:51:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ExBa-000EoO-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 11:40:26 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135]) by psg.com with esmtp (Exim 3.36 #2) id 18ExBX-000EkM-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 11:40:23 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id gALJdmXx025384; Thu, 21 Nov 2002 11:39:48 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id gALJdlCS025381; Thu, 21 Nov 2002 11:39:48 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Thu, 21 Nov 2002 11:39:47 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: wildcard optimization and b/w incompatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_05_08,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Edward Lewis wrote: > At 18:43 -0800 11/20/02, Brian Wellington wrote: > >Writing such an implementation would be extremely difficult and not worth > >it, since any compliant authoritative server should return all needed NXTs > >anyway. > > True, but, 1) "compliant" changes and 2) I know of current servers > that don't return the wildcard NXT in NXDOMAIN answers now. Yes, > this is non-compliance, but there's always that discussion of > 'miscreant' elements to consider. Yes, but at some point you need to just say that if you're getting bad responses to your queries, you're going to fail. > >Yes, 'likely lead' is hard to evaluate. Having written multiple DNSSEC > >validating resolvers, there are many things which lead to deadlock. > >Without implementing this, I can't tell you for sure, but based on prior > >experience, I think there's a very good chance that it would. I'm not > >going to implement this just to find out. > > There are three possible responses to this. > > 1) Does anyone else want to try? (As it's Brian's right to refuse a try.) > 2) Can someone prove this analytically? > 3) Should we drop this discussion and 'assume' backwards compatibility? I'd vote for (3). > >I'm not talking about BIND 9. I"m talking about servers in general. > > I used "BIND 9" in the sense that it's code that is much more > complicated than what I wrote, so my experience may not be applicable > here. Right. The latest validator I've written is far simpler than BIND 9 also, and I still think this behavior could be problematic. Brian -- 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 Nov 21 16:03:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20334 for ; Thu, 21 Nov 2002 16:03:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EyMF-000KpI-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 12:55:31 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18EyMC-000Kp4-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 12:55:28 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gALKtRYm088370 for ; Thu, 21 Nov 2002 15:55:27 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA28364 for ; Thu, 21 Nov 2002 15:55:27 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 21 Nov 2002 15:51:29 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wildcard optimization and b/w incompatibility Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:39 -0800 11/21/02, Brian Wellington wrote: >On Wed, 20 Nov 2002, Edward Lewis wrote: >> 3) Should we drop this discussion and 'assume' backwards compatibility? > >I'd vote for (3). I meant 'incompatibility' (a typo) - does that change your vote? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 21 16:03:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20335 for ; Thu, 21 Nov 2002 16:03:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EyID-000KMu-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 12:51:21 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18EyIB-000KMg-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 12:51:19 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 3304C37A037 for ; Thu, 21 Nov 2002 20:51:19 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: type codes (Re: wildcard optimization and b/w incompatibility ) In-Reply-To: Message from Brian Wellington of "Thu, 21 Nov 2002 11:39:47 PST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 21 Nov 2002 20:51:19 +0000 Message-Id: <20021121205119.3304C37A037@as.vix.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk regarding backward compatibility, let's talk about RR type codes for SIG, NXT, KEY, etc the deployed base of 2535 is insignificant, and no effort has been made to try to "remain true" to the protocol as described in any earlier dnssec specification. therefore in each incompatible revision of dnssec, we ought to deprecate the old type codes for dnssec-specific RRs. this will cause "interrim" implementations to believe that "there is no security data" and fall back to normal, pre-dnssec operation. naturally this also presents an unfortunate opportunity to change the rdata format with each revision, but i hope that we can manage not to take it. it also means that the mneumonics will change with each revision, so we may end up with things like SIG2/KEY2/DS2 or even SIG3950/NXT3950/DS3950 if there were a dnssec revision defined in RFC3950. however, this is the only way to be sure of "b/w compatibility" with interrim dnssec implementations -- and that is, to invalidate them entirely and force them into their pre-dnssec mode. -- 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 Nov 21 16:26:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21208 for ; Thu, 21 Nov 2002 16:26:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EykA-000Mry-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 13:20:14 -0800 Received: from h140.s251.netsol.com ([216.168.251.140] helo=twister.rgy.netsol.com) by psg.com with esmtp (Exim 3.36 #2) id 18Eyk6-000Mqd-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 13:20:10 -0800 Received: from typhoon (unknown [10.131.128.57]) by twister.rgy.netsol.com (Postfix) with SMTP id 680EB3D2624; Thu, 21 Nov 2002 16:19:39 -0500 (EST) Message-ID: <054c01c291a3$b358c030$3980830a@typhoon> Reply-To: "Matt Larson" From: "Matt Larson" To: "Paul Vixie" , References: <20021121205119.3304C37A037@as.vix.com> Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) Date: Thu, 21 Nov 2002 16:19:39 -0500 Organization: VeriSign Global Registry Services MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > it also means that the mneumonics will change with each revision, so > we may end up with things like SIG2/KEY2/DS2 or even > SIG3950/NXT3950/DS3950 if there were a dnssec revision defined in > RFC3950. Why do the mnemonics need to change if the type codes change? Matt -- 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 Nov 21 16:32:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21519 for ; Thu, 21 Nov 2002 16:32:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eyp5-000NM0-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 13:25:19 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18Eyp1-000NKl-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 13:25:15 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id E394D37A037; Thu, 21 Nov 2002 21:25:14 +0000 (GMT) From: Paul Vixie To: "Matt Larson" Cc: namedroppers@ops.ietf.org Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) In-Reply-To: Message from "Matt Larson" of "Thu, 21 Nov 2002 16:19:39 EST." <054c01c291a3$b358c030$3980830a@typhoon> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 21 Nov 2002 21:25:14 +0000 Message-Id: <20021121212514.E394D37A037@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > it also means that the mneumonics will change with each revision, so > > we may end up with things like SIG2/KEY2/DS2 or even > > SIG3950/NXT3950/DS3950 if there were a dnssec revision defined in > > RFC3950. > > Why do the mnemonics need to change if the type codes change? formally speaking, a type code and mneumonic are allocated as a tuple. informally speaking, "dig" will never stop printing the old rrs if it encounters them, even if they came from interrim dnssec implementations. -- 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 Nov 21 16:44:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21929 for ; Thu, 21 Nov 2002 16:44:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ez1o-000OSn-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 13:38:28 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18Ez1m-000OSG-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 13:38:26 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gALLcPYm090308 for ; Thu, 21 Nov 2002 16:38:25 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA06164 for ; Thu, 21 Nov 2002 16:38:24 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20021121205119.3304C37A037@as.vix.com> References: <20021121205119.3304C37A037@as.vix.com> Date: Thu, 21 Nov 2002 16:38:23 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Yes! I once suggested that we just chuck the KEY RR instead of publishing the 'KEY RR restrict' document. But I can't find any record that I sent this to a public list. At 20:51 +0000 11/21/02, Paul Vixie wrote: >specification. therefore in each incompatible revision of dnssec, we ought >to deprecate the old type codes for dnssec-specific RRs. this will cause -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 21 16:45:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21971 for ; Thu, 21 Nov 2002 16:45:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ez36-000OVk-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 13:39:48 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18Ez33-000OVC-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 13:39:45 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gALLdiYm090354; Thu, 21 Nov 2002 16:39:44 -0500 (EST) Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA06327; Thu, 21 Nov 2002 16:39:41 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <054c01c291a3$b358c030$3980830a@typhoon> References: <20021121205119.3304C37A037@as.vix.com> <054c01c291a3$b358c030$3980830a@typhoon> Date: Thu, 21 Nov 2002 16:39:41 -0500 To: "Matt Larson" , "Paul Vixie" , From: Edward Lewis Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:19 -0500 11/21/02, Matt Larson wrote: >Why do the mnemonics need to change if the type codes change? So the documents are also obviously obsoleted. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 21 21:51:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03115 for ; Thu, 21 Nov 2002 21:51:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F3hZ-000OGR-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 18:37:53 -0800 Received: from p105.n-atpop03.stsn.com ([12.129.82.105] helo=atpop.smtp.stsn.com) by psg.com with esmtp (Exim 3.36 #2) id 18F3hX-000OCc-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 18:37:51 -0800 Received: from P612389 ([10.16.43.43]) by atpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 21 Nov 2002 21:36:31 -0500 Message-ID: <000701c291d0$2533ebe0$2b2b100a@P612389> From: "Scott Rose" To: References: <20021121205119.3304C37A037@as.vix.com> Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) Date: Thu, 21 Nov 2002 21:37:48 -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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 22 Nov 2002 02:36:31.0484 (UTC) FILETIME=[F767FBC0:01C291CF] X-Spam-Status: No, hits=0.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To quote the "A-Team": That's so crazy it just might work! But I still have some doubts. That will help identify the "true" security aware servers/resolvers, but will it help the problem of a non-DS aware cache between the resolver and authoritative server? If a recursive forwarder doesn't know where to ask for the DS record, it doesn't matter what the type code is. I don't know. I need to think about it. It does make some other unpleasent problems go away. Scott PS (non US) The A-Team was a TV show in the 80's where a band of ex-military misfits solve problems with wierd plans that always worked, no matter how silly/crazy/outlandish. ----- Original Message ----- From: "Paul Vixie" To: Sent: Thursday, November 21, 2002 3:51 PM Subject: type codes (Re: wildcard optimization and b/w incompatibility ) > regarding backward compatibility, let's talk about RR type codes for > SIG, NXT, KEY, etc > > the deployed base of 2535 is insignificant, and no effort has been made > to try to "remain true" to the protocol as described in any earlier dnssec > specification. therefore in each incompatible revision of dnssec, we ought > to deprecate the old type codes for dnssec-specific RRs. this will cause > "interrim" implementations to believe that "there is no security data" and > fall back to normal, pre-dnssec operation. > > naturally this also presents an unfortunate opportunity to change the rdata > format with each revision, but i hope that we can manage not to take it. > > it also means that the mneumonics will change with each revision, so we may > end up with things like SIG2/KEY2/DS2 or even SIG3950/NXT3950/DS3950 if there > were a dnssec revision defined in RFC3950. > > however, this is the only way to be sure of "b/w compatibility" with interrim > dnssec implementations -- and that is, to invalidate them entirely and force > them into their pre-dnssec mode. > > -- > 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 Thu Nov 21 22:27:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03763 for ; Thu, 21 Nov 2002 22:27:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F4Nu-0002Yj-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 19:21:38 -0800 Received: from bartok.sidn.nl ([193.176.144.164]) by psg.com with esmtp (Exim 3.36 #2) id 18F4Nr-0002YX-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 19:21:36 -0800 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id gAM3LQOG050328; Fri, 22 Nov 2002 04:21:27 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200211220321.gAM3LQOG050328@bartok.sidn.nl> To: "Scott Rose" cc: namedroppers@ops.ietf.org Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) In-reply-to: Your message of Thu, 21 Nov 2002 21:37:48 -0500. <000701c291d0$2533ebe0$2b2b100a@P612389> Date: Fri, 22 Nov 2002 04:21:26 +0100 From: Jaap Akkerhuis X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk PS (non US) The A-Team was a TV show in the 80's where a band of ex-military misfits solve problems with wierd plans that always worked, no matter how silly/crazy/outlandish. The show hit Europe as well. We get the best of american culture: A-team, McDonalds, etc :-). Yes, I too have always wondered why people are so hang-up on compatabilaty with 2535, a propossed standard, hardly been deployed and according to the rules should not be deployed for disruption-sensitive producting work. (RFC 2026, secton 4.1.1). 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 Thu Nov 21 23:05:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04867 for ; Thu, 21 Nov 2002 23:05:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F4si-0005YT-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 19:53:28 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 18F4sf-0005Y5-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 19:53:25 -0800 Received: from sandelman.ottawa.on.ca (marajade.dasblinkenled.org [204.42.73.244]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gAM3q2d03567 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 21 Nov 2002 22:52:09 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gAM3q13Y002237 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 21 Nov 2002 22:52:02 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gAM3q0Rt002232 for ; Thu, 21 Nov 2002 22:52:01 -0500 Message-Id: <200211220352.gAM3q0Rt002232@sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) In-reply-to: Your message of "Thu, 21 Nov 2002 21:37:48 EST." <000701c291d0$2533ebe0$2b2b100a@P612389> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Nov 2002 22:52:00 -0500 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott Rose writes: Scott> But I still have some doubts. That will help identify the "true" security Scott> aware servers/resolvers, but will it help the problem of a non-DS aware Scott> cache between the resolver and authoritative server? If a recursive Scott> forwarder doesn't know where to ask for the DS record, it doesn't matter Scott> what the type code is. Bingo. Fundamentally, both DS and pre-DS KEY are broken because they are defined to live in the parent zone. (SIG is even more bizarre...) As such, they need specific behaviour to make them work with caches that are unaware of their special nature. pre-DS KEY lived in both places, but like NS, the child is considered the authoritative respository for the record and the parent just has some "hints". We could have solved this by having the child pull the records out of the parent zone, and then insisting that the parent has to maintain the old KEY/SIG records for some long time. This could work, and with a lot more thought I think that we can make the KEY rollover work as well. However, I think that DS is probably a good seperation for zone cuts. If we can simply make the child pull records from the parent again, then we might find a resolution to this problem. The stub zone stuff that bind has might be a good model - pull it down when you can and save it. If you are offline and can not speak to the zone's parent during a key rollover is a clear problem here. So, we either find a way to put the DS record CLEARLY in the parent, or a way for the CHILD to get a copy of it. BTW: NS also lives in both places, BUT, we don't have failures if the child and parent disagree. In fact, this is often a feature for some. Scott> Scott Scott> PS (non US) The A-Team was a TV show in the 80's where a band of ex-military Scott> misfits solve problems with wierd plans that always worked, no matter how Scott> silly/crazy/outlandish. _I love it when a plan comes together_ I watch it more often than I'd like to admit... 6pm on DejaView. ] At IETF55 in Atlanta, GA | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPd2p3YqHRg3pndX9AQE0+AQAm8Q8pUQQVATb6ZTSXU7iHL724heAlt+y Nn2gfN01WE8Sb4Gaoqm149sLSZIbsR6pbSbjIqKvK+rsj7C0/EhkcgYNElr6Hhuf 7GfBmUKw1Dw1ra+dyHdzxnAbDIArpPLwJc/50jwsBJT7hWKjKYhIpYh4areTKVFI xAYx+QlHRiA= =loKU -----END PGP SIGNATURE----- -- 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 Nov 21 23:10:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05065 for ; Thu, 21 Nov 2002 23:10:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F4y0-00068F-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 19:58:56 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 18F4xx-000681-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 19:58:54 -0800 Received: from sandelman.ottawa.on.ca (marajade.dasblinkenled.org [204.42.73.244]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gAM3vKd03576 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 21 Nov 2002 22:57:31 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gAM3vK3Y002362 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 21 Nov 2002 22:57:21 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gAM3vKos002358 for ; Thu, 21 Nov 2002 22:57:20 -0500 Message-Id: <200211220357.gAM3vKos002358@sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) In-reply-to: Your message of "Fri, 22 Nov 2002 04:21:26 +0100." <200211220321.gAM3LQOG050328@bartok.sidn.nl> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Nov 2002 22:57:19 -0500 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jaap" == Jaap Akkerhuis writes: Jaap> Yes, I too have always wondered why people are so hang-up on Jaap> compatabilaty with 2535, a propossed standard, hardly been deployed Jaap> and according to the rules should not be deployed for disruption-sensitive Jaap> producting work. (RFC 2026, secton 4.1.1). My understanding is that we have a problem whenever there is a caching resolver in the way that is not DS aware. It doesn't matter if it is 2535 aware or not. As I understand the problem, it is irrelevant whether or not it is 2535 aware, so long as it can deal with records that it doesn't understand. If it fails to return SIG/NXT/KEY records because it doesn't understand them, then there is no problem. ] At IETF55 in Atlanta, GA | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPd2rHoqHRg3pndX9AQEBbwP+Oa9DpWoo6ZgqPEOwAt9yqDh2W6zftLu8 qTKrtygabVSlS8iCFOZjvTXkJoHqhBc5mCf+sqhueYzebUiJNLmFhlyqbLr25kYE DjAV/uD1q1oXREH6x2+tzD+S7VTrxiF666g7jCfE2P76+GV5iR0RRC/jmPQ/0eK4 lVpNJic81ts= =/5ga -----END PGP SIGNATURE----- -- 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 Nov 21 23:18:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05330 for ; Thu, 21 Nov 2002 23:18:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F5BM-0007TA-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 20:12:44 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18F5BJ-0007Sy-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 20:12:41 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 4476737A2AB for ; Fri, 22 Nov 2002 04:12:41 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) In-Reply-To: Message from "Scott Rose" of "Thu, 21 Nov 2002 21:37:48 EST." <000701c291d0$2533ebe0$2b2b100a@P612389> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 22 Nov 2002 04:12:41 +0000 Message-Id: <20021122041241.4476737A2AB@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > To quote the "A-Team": That's so crazy it just might work! i apologize for keeping the thought to myself for the last year, then. (i keep wanting to stay out of dnssec's innards because security hurts me to think about, but then dnssec keeps running aground on issues more related to dns than security... i promise to speak up sooner next time.) > But I still have some doubts. That will help identify the "true" security > aware servers/resolvers, but will it help the problem of a non-DS aware > cache between the resolver and authoritative server? no, and it isn't expected to. what we want to do is limit the cases to "pre-dnssec" and "current-dnssec" and not "interim-dnssec-N" or even "interim-dnssec-N+1". > If a recursive forwarder doesn't know where to ask for the DS record, > it doesn't matter what the type code is. right. but that problem is separately tractible. later tonight i will write in with "ENS", which while uglier than sin, may yet be prettier than namehack. -- 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 Nov 21 23:56:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06262 for ; Thu, 21 Nov 2002 23:56:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F5mD-000BSG-00 for namedroppers-data@psg.com; Thu, 21 Nov 2002 20:50:49 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18F5mB-000BS3-00 for namedroppers@ops.ietf.org; Thu, 21 Nov 2002 20:50:47 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1FE8E37A037 for ; Fri, 22 Nov 2002 04:50:47 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility ) In-Reply-To: Message from Michael Richardson of "Thu, 21 Nov 2002 22:52:00 EST." <200211220352.gAM3q0Rt002232@sandelman.ottawa.on.ca> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 22 Nov 2002 04:50:47 +0000 Message-Id: <20021122045047.1FE8E37A037@as.vix.com> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > However, I think that DS is probably a good seperation for zone cuts. > If we can simply make the child pull records from the parent again, then we > might find a resolution to this problem. The stub zone stuff that bind has > might be a good model - pull it down when you can and save it. it's not reasonable to ask an authoritative server to have to fetch anything from anybody. it should not need a root.cache file, it should never have to ask a udp/53 question other than, perhaps, when a slave server asks a master for its SOA to find out if "now" is a good time for an AXFR. > If you are offline and can not speak to the zone's parent during a key > rollover is a clear problem here. > > So, we either find a way to put the DS record CLEARLY in the parent, or > a way for the CHILD to get a copy of it. watch for the "ENS RR", coming soon to a namedroppers list near you. > BTW: NS also lives in both places, BUT, we don't have failures if the > child and parent disagree. In fact, this is often a feature for some. putting crap at the delegation point is hairy business. -- 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 Nov 22 09:02:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25144 for ; Fri, 22 Nov 2002 09:02:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FE0X-000Nz4-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 05:38:09 -0800 Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by psg.com with esmtp (Exim 3.36 #2) id 18FE0V-000NyS-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 05:38:07 -0800 Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAMDbn6d013822 for ; Fri, 22 Nov 2002 08:37:56 -0500 (EST) Received: from MJS-W2K.cisco.com (che-vpn-cluster-1-68.cisco.com [10.86.240.68]) by goblet.cisco.com (Mirapoint) with ESMTP id ACD59367; Fri, 22 Nov 2002 08:37:19 -0500 (EST) Message-Id: <4.3.2.7.2.20021122083249.01dd1750@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Nov 2002 08:37:15 -0500 To: namedroppers@ops.ietf.org From: Mark Stapp Subject: Re: Fwd: [dhcwg] update on dhcp/dns drafts' progress Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.2 required=5.0 tests=FWD_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olafur has reminded me that I should point out that the IANA considerations section has changed in the most recent version of the dhcid RR draft. It reflects the decision to move to an enumerated list of types of client data. The current draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-06.txt -- 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: From owner-namedroppers@ops.ietf.org Fri Nov 22 14:18:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01765 for ; Fri, 22 Nov 2002 14:18:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FJ5a-000JoS-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 11:03:42 -0800 Received: from adsl-67-119-98-58.dsl.snfc21.pacbell.net ([67.119.98.58] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #2) id 18FJ5X-000Jke-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 11:03:39 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id gAMJ30Xx012492; Fri, 22 Nov 2002 11:03:00 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id gAMJ30rv012489; Fri, 22 Nov 2002 11:03:00 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Fri, 22 Nov 2002 11:03:00 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: wildcard optimization and b/w incompatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Edward Lewis wrote: > >On Wed, 20 Nov 2002, Edward Lewis wrote: > >> 3) Should we drop this discussion and 'assume' backwards compatibility? > > > >I'd vote for (3). > > I meant 'incompatibility' (a typo) - does that change your vote? Not really. We've known all along that 2535 DNSSEC will not work when DS is deployed, so I don't see why this is an issue at all. Brian -- 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 Nov 22 14:46:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02638 for ; Fri, 22 Nov 2002 14:46:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FJXM-000Lu7-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 11:32:24 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18FJXK-000Ltu-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 11:32:22 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gAMJTTg01260; Fri, 22 Nov 2002 11:29:29 -0800 (PST) Date: Fri, 22 Nov 2002 11:29:29 -0800 (PST) Message-Id: <200211221929.gAMJTTg01260@guava.araneus.fi> To: Kenji Rikitake Cc: "D. J. Bernstein" , dns@list.cr.yp.to, namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: axfr-clarify on the move again In-Reply-To: <20021122152754.A42609@k2r.org> References: <20021117211006.98837.qmail@cr.yp.to> <20021118033728.GA13838@codeblau.de> <20021119204308.52994.qmail@cr.yp.to> <20021122152754.A42609@k2r.org> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_05_08 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ietf@ietf.org has once again been removed from list of recipients.] Kenji Rikitake writes: > I would like to urge that the database structure of BIND MUST NOT define > the semantics of DNS. Breaking the RFC1034 model which assures the > uniqueness of DNS RR integrity will significantly hamper the fundamental > security of the current non-cryptographic DNS, which is still heavily > dependent of the uniqueness of AXFR-transferred data. If you all > disapprove A6, please do NOT approve such an idea, again. I'm sorry, but I'm unable to make sense of this message - it is vague to the degree that I can't even tell for sure if it is a statement for or against axfr-clarify. I'm guessing against, but I can't defend the draft until I understand what you actually mean by your criticism. Please define what you mean by "uniqueness of DNS RR integrity" and explain how it is "assured by the RFC1034 model". Please explain how the axfr-clarify draft "breaks" this, and exactly how that will "significantly hamper the fundamental security of the current non-cryptographic DNS". Also, please define the property of "uniqueness of AXFR-transferred data" and explain how the "fundamental security" depends on it. -- 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 Fri Nov 22 16:49:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05005 for ; Fri, 22 Nov 2002 16:49:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FLaa-0005Z8-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 13:43:52 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18FLaU-0005Uw-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 13:43:50 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18FLa9-0000Iz-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 13:43:25 -0800 Message-ID: <20021122152754.A42609@k2r.org> References: <20021117211006.98837.qmail@cr.yp.to> <20021118033728.GA13838@codeblau.de> <20021119204308.52994.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit In-Reply-To: <20021119204308.52994.qmail@cr.yp.to>; from djb@cr.yp.to on Tue, Nov 19, 2002 at 08:42:46PM -0000 Date: Fri, 22 Nov 2002 15:27:54 +0900 From: Kenji Rikitake To: "D. J. Bernstein" Cc: dns@list.cr.yp.to, namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org, Kenji Rikitake Subject: Re: axfr-clarify on the move again X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] To the readers of this mail: I would like to urge that the database structure of BIND MUST NOT define the semantics of DNS. Breaking the RFC1034 model which assures the uniqueness of DNS RR integrity will significantly hamper the fundamental security of the current non-cryptographic DNS, which is still heavily dependent of the uniqueness of AXFR-transferred data. If you all disapprove A6, please do NOT approve such an idea, again. // Kenji Rikitake -- 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 Nov 22 19:46:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08041 for ; Fri, 22 Nov 2002 19:46:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FOIl-000IwA-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 16:37:39 -0800 Received: from d61.wireless.hilander.com ([216.241.32.61] helo=ramirez.hilander.com) by psg.com with esmtp (Exim 3.36 #2) id 18FOIi-000Iv4-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 16:37:36 -0800 Received: from [216.241.32.58] (helo=d58.wireless.hilander.com) by ramirez.hilander.com with esmtp (Exim 4.10) id 18FOIg-0001G9-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 17:37:34 -0700 Date: Fri, 22 Nov 2002 17:37:31 -0700 From: "Alec H. Peterson" To: namedroppers@ops.ietf.org Subject: DNS Server DoS Attacks Message-ID: <1507321518.1037986651@d58.wireless.hilander.com> X-Mailer: Mulberry/3.0.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.8 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18FOIg-0001G9-00*EIiJdfhYEZM* X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit These attacks seem to be on the rise. There were the well-publicized ones on the root servers a few weeks ago, and yesterday UltraDNS was hit with one. It occurs to me that these attacks have the potential to completely shut down the DNS system if they are structured properly. I have a thought on how to make the system more resiliant to authoritative servers getting hammered, and was interested in some thoughts on it. My thought is to add another TTL to DNS responses, similar to the SOA maximum parameter. The current TTL would be similar to the SOA minimum. This would still allow for records to expire in a reasonable amount of time, but it would also allow for DNS responses to be answered in the event that servers in the hierarchy are unreachable for some reason. It occurs to me that it is possible to retrofit existing DNS servers to have a static maximum timeout without any protocol modifications. Anyway, the way I see it since DNS already has a caching infrastructure built in it makes sense to take extra advantage of that infrastructure when things are under attack. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.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 Nov 22 20:59:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09367 for ; Fri, 22 Nov 2002 20:59:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FPUi-000P5S-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 17:54:04 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18FPUf-000P5G-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 17:54:01 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id BB8B737A037 for ; Sat, 23 Nov 2002 01:54:00 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks In-Reply-To: Message from "Alec H. Peterson" of "Fri, 22 Nov 2002 17:37:31 MST." <1507321518.1037986651@d58.wireless.hilander.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Sat, 23 Nov 2002 01:54:00 +0000 Message-Id: <20021123015400.BB8B737A037@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My thought is to add another TTL to DNS responses, similar to the SOA > maximum parameter. The current TTL would be similar to the SOA minimum. > This would still allow for records to expire in a reasonable amount of > time, but it would also allow for DNS responses to be answered in the event > that servers in the hierarchy are unreachable for some reason. keeping copies of somebody else's authoritative data and using or reusing them beyond the (TTL,SOA) parameters would be a disaster. even with DNSSEC it will be dangerous, but the amount of bad data that would circulate without end under such a scheme is unthinkably horrible. (BIND has been criticised for accelerating TTL depreciation when reusing additional data, but this is the kind of data pattern this was designed to end.) > It occurs to me that it is possible to retrofit existing DNS servers > to have a static maximum timeout without any protocol modifications. at the moment, only 2% of the queries hitting the root servers actually need to be answered -- the rest is pure swill, just errors and sideeffects. there is, unfortunately, no way to know in the upstream routers which 2% is which, and so we deliver the whole thing and answer it as best we can. what this means, though, is that the impact on a root server attack would take several days to be felt. while pulsar-style attacks can be harder to track to source, the "off" part of the cycle leaves time for retries to succeed and thus let the "useful" 2% still bear some fruit. a solid attack lasting several days would be trackable, unless it comes from a million-drone windows/xp army, which leads to the ugly necessary of "massive-scale bgp4 anycasting", which at least two root server operators are already planning to implement. (or we could secure the edge, but i guess that's too hard.) > Anyway, the way I see it since DNS already has a caching infrastructure > built in it makes sense to take extra advantage of that infrastructure when > things are under attack. if people would just cache what they already receive, then 98% of the queries seen by the root servers would never be sent. so, i think there's ample evidence to refute the idea that the internet's caching infrastructure is a model we can build on. -- 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 Nov 22 21:10:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09550 for ; Fri, 22 Nov 2002 21:10:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FPhJ-0000Cz-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 18:07:05 -0800 Received: from d61.wireless.hilander.com ([216.241.32.61] helo=ramirez.hilander.com) by psg.com with esmtp (Exim 3.36 #2) id 18FPhH-0000Cl-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 18:07:03 -0800 Received: from [216.241.32.58] (helo=d58.wireless.hilander.com) by ramirez.hilander.com with esmtp (Exim 4.10) id 18FPhF-0001WQ-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 19:07:01 -0700 Date: Fri, 22 Nov 2002 19:07:00 -0700 From: "Alec H. Peterson" To: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks Message-ID: <2147483647.1037992019@d58.wireless.hilander.com> In-Reply-To: <20021123015400.BB8B737A037@as.vix.com> References: <20021123015400.BB8B737A037@as.vix.com> X-Mailer: Mulberry/3.0.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.3 (-) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18FPhF-0001WQ-00*K1cJambeabU* X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, November 23, 2002 1:54 AM +0000 Paul Vixie wrote: > > if people would just cache what they already receive, then 98% of the > queries seen by the root servers would never be sent. so, i think > there's ample evidence to refute the idea that the internet's caching > infrastructure is a model we can build on. That is a good point, that had already been made to me before I posted that actually. I see your point that a sustained attack should be easy to track down, but I think it would be really nice if we could find a way to preemptively come up with a way to help mitigate these attacks, instead of operating in a reactive mode. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.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 Nov 22 21:37:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10413 for ; Fri, 22 Nov 2002 21:37:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FQ77-0002PJ-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 18:33:45 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18FQ75-0002Ov-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 18:33:43 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 628C337A037 for ; Sat, 23 Nov 2002 02:33:43 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks In-Reply-To: Message from "Alec H. Peterson" of "Fri, 22 Nov 2002 19:07:00 MST." <2147483647.1037992019@d58.wireless.hilander.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Sat, 23 Nov 2002 02:33:43 +0000 Message-Id: <20021123023343.628C337A037@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I see your point that a sustained attack should be easy to track down, but > I think it would be really nice if we could find a way to preemptively come > up with a way to help mitigate these attacks, instead of operating in a > reactive mode. well, like i said, we could secure the edge. -- 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 Nov 22 21:59:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10964 for ; Fri, 22 Nov 2002 21:59:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FQRz-0004EW-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 18:55:19 -0800 Received: from d61.wireless.hilander.com ([216.241.32.61] helo=ramirez.hilander.com) by psg.com with esmtp (Exim 3.36 #2) id 18FQRx-0004EJ-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 18:55:17 -0800 Received: from [216.241.32.58] (helo=d58.wireless.hilander.com) by ramirez.hilander.com with esmtp (Exim 4.10) id 18FQRs-0001f9-00; Fri, 22 Nov 2002 19:55:12 -0700 Date: Fri, 22 Nov 2002 19:55:11 -0700 From: "Alec H. Peterson" To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks Message-ID: <2147483647.1037994911@d58.wireless.hilander.com> In-Reply-To: <20021123023343.628C337A037@as.vix.com> References: <20021123023343.628C337A037@as.vix.com> X-Mailer: Mulberry/3.0.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -0.5 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18FQRs-0001f9-00*bFn0IZP1Bq.* X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, November 23, 2002 2:33 AM +0000 Paul Vixie wrote: > > well, like i said, we could secure the edge. While we're at it why don't we deploy IPv6. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.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 Nov 22 22:55:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11889 for ; Fri, 22 Nov 2002 22:55:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FRIr-0008Wj-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 19:49:57 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 18FRIp-0008W5-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 19:49:55 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gAN3nZV02489; Fri, 22 Nov 2002 19:49:35 -0800 (PST) From: Bill Manning Message-Id: <200211230349.gAN3nZV02489@boreas.isi.edu> Subject: Re: DNS Server DoS Attacks In-Reply-To: <2147483647.1037994911@d58.wireless.hilander.com> from "Alec H. Peterson" at "Nov 22, 2 07:55:11 pm" To: ahp@hilander.com (Alec H. Peterson) Date: Fri, 22 Nov 2002 19:49:35 -0800 (PST) Cc: paul@vix.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % --On Saturday, November 23, 2002 2:33 AM +0000 Paul Vixie % wrote: % > well, like i said, we could secure the edge. % % While we're at it why don't we deploy IPv6. % % Alec % we are. :) just not as quickly or as transparently as some would like.. --bill -- 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 Nov 23 00:27:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12927 for ; Sat, 23 Nov 2002 00:27:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FSgA-000Frm-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 21:18:06 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18FSg7-000FrY-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 21:18:04 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18FSg6-0000s1-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 21:18:02 -0800 Message-ID: <20021123125438.A55745@k2r.org> References: <20021117211006.98837.qmail@cr.yp.to> <20021118033728.GA13838@codeblau.de> <20021119204308.52994.qmail@cr.yp.to> <20021122152754.A42609@k2r.org> <200211221929.gAMJTTg01260@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit In-Reply-To: <200211221929.gAMJTTg01260@guava.araneus.fi>; from gson@nominum.com on Fri, Nov 22, 2002 at 11:29:07AM -0800 Date: Sat, 23 Nov 2002 12:54:38 +0900 From: Kenji Rikitake To: Andreas Gustafsson Cc: "D. J. Bernstein" , dns@list.cr.yp.to, namedroppers@ops.ietf.org, iesg@ietf.org, Kenji Rikitake Subject: Re: axfr-clarify on the move again X-Spam-Status: No, hits=-0.6 required=5.0 tests=DEAR_SOMEBODY,IN_REP_TO,REFERENCES,RESENT_TO, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Dear Andreas: I do not want to involve in the definition game you have proposed, since I do not want to waste time of the readers. I'll keep it concise just for the fairness and showing my respect for your offering to defend your argument, and to give the answers you requested to me: Yes, I am against axfr-clarify. I 100% support Daniel J. Bernstein's argument on this issue. Please reread http://cr.yp.to/djbdns/axfr-clarify.html for the details. Please allow me repeat this: RFC1034 Section 2.2. on DNS design goals: -- quote -- - The primary goal is a consistent name space which will be used for referring to resources. In order to avoid the problems caused by ad hoc encodings, names should not be required to contain network identifiers, addresses, routes, or similar information as part of the name. -- unquote -- My argument is that: allowing an RR to have two or more inconsistent (not equal to each other) contents, by allowing different contents of RRs in two or multiple zones, is inconsistent with this design goal, and is against DNS semantics. I would refrain from engaging in future arguments on this issue. I appreciate your response, Andreas. // Kenji Rikitake -- 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 Nov 23 00:27:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12928 for ; Sat, 23 Nov 2002 00:27:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FSgV-000Fs3-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 21:18:27 -0800 Received: from yoyo.akc.com ([192.188.192.5]) by psg.com with esmtp (Exim 3.36 #2) id 18FSgT-000Frq-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 21:18:25 -0800 Received: from backup ([192.188.192.55]) by yoyo.akc.com (8.9.3/8.9.3) with SMTP id AAA20495 for ; Sat, 23 Nov 2002 00:18:23 -0500 Message-ID: <002501c292af$164be580$37c0bcc0@akc.com> From: "Al Costanzo" To: References: <200211230349.gAN3nZV02489@boreas.isi.edu> Subject: IPv7 Date: Sat, 23 Nov 2002 00:13:40 -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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=0.5 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, To the best of anyone knowledge on the list. Did anyone ever deploy IPv7 or is it completely dead now. Not that I really seen 6 deployed but .... Al Costanzo -- 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 Nov 23 01:25:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13617 for ; Sat, 23 Nov 2002 01:25:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FTcg-000Kvv-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 22:18:34 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18FTcd-000Kux-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 22:18:32 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18FTcW-0000xH-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 22:18:24 -0800 Message-ID: <20021123061646.22603.qmail@cr.yp.to> References: <1507321518.1037986651@d58.wireless.hilander.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 23 Nov 2002 06:16:46 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks X-Spam-Status: No, hits=-0.2 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 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 mis-posts. so fix subscription addresses! ] The DNS protocol should be augmented with a separate protocol for distributing (signed) copies of the root zone (in a sensible format) through USENET, mailing lists, etc. ISPs can and should run local root servers. I agree with the idea of caching root zone data for a very long time. The root-zone protocol should promise that every piece of data will last for a month. Effects on load: Everybody will receive the entire zone, rather than just the parts they need. On the other hand, any sensible format would be much smaller than DNS packet format. More importantly, the data will be cached much more effectively than it is with the current root-zone protocol. Most importantly, the load will be very widely distributed. Side benefit: It will be easy to expand to hundreds of .com servers. Of course, the root servers could pack more than 20 .com server addresses into a 512-byte UDP packet with the current protocol (if they drop the silly one-name-one-address notion), and nobody would complain if the root servers selected those addresses randomly from a much larger pool; but distributing the root zone lets ISPs pick nearby .com servers. ---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 Sat Nov 23 01:53:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14092 for ; Sat, 23 Nov 2002 01:53:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FU7Y-000NWB-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 22:50:28 -0800 Received: from bilbo.sauron.net ([207.229.164.18] helo=dragon.sauron.net) by psg.com with esmtp (Exim 3.36 #2) id 18FU7W-000NVD-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 22:50:26 -0800 Received: by dragon.sauron.net (Postfix, from userid 201) id 81DB138; Sat, 23 Nov 2002 00:49:55 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by dragon.sauron.net (Postfix) with ESMTP id 7131286C39 for ; Sat, 23 Nov 2002 00:49:55 -0600 (CST) Date: Sat, 23 Nov 2002 00:49:55 -0600 (CST) From: Rob Thomas X-X-Sender: To: Subject: Re: DNS Server DoS Attacks In-Reply-To: <20021123023343.628C337A037@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_08_13 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ] well, like i said, we could secure the edge. Agreed. In one study I conducted of an oft' attacked web site, 66.85% of all naughty packets received were obvious bogons. Not just spoofed legitimate addresses, but outright bogons. Honestly if I never receive another packet from 127.1.2.3 I'll be a happy man. :) Think of the amount of garbage we could avoid with some reasonably simple filtering. The results of the study (along with a few others) can be seen in a presentation I gave to Surfnet entitled "60 Days of Basic Naughtiness." You will find a zip'd copy, in Powerpoint format, here: http://www.cymru.com/Presentations/60Days.zip The analyzed attacks are tame in comparison to what is seen today. The simple things work, often to a great degree. Raising the bar won't solve the world's problems, but it will make things a little better. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); -- 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 Nov 23 02:57:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24701 for ; Sat, 23 Nov 2002 02:57:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FV10-0001kR-00 for namedroppers-data@psg.com; Fri, 22 Nov 2002 23:47:46 -0800 Received: from alderaan.chagres.net ([216.223.236.235] helo=chagres.net) by psg.com with esmtp (Exim 3.36 #2) id 18FV0y-0001dG-00 for namedroppers@ops.ietf.org; Fri, 22 Nov 2002 23:47:44 -0800 Received: (qmail 88221 invoked from network); 23 Nov 2002 07:51:00 -0000 Received: from unknown (HELO laptoy) (jmbrown@chagres.net@216.223.236.249) by alderaan.chagres.net with RC4-MD5 encrypted SMTP; 23 Nov 2002 07:51:00 -0000 Reply-To: From: "John M. Brown" To: "'Alec H. Peterson'" , Subject: RE: DNS Server DoS Attacks Date: Sat, 23 Nov 2002 00:47:04 -0700 Organization: Chagres Technologies, Inc Message-ID: <005001c292c4$83d7abb0$f9ecdfd8@laptoy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <1507321518.1037986651@d58.wireless.hilander.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Status: No, hits=-0.6 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA24701 packet forwarding engines won't tell the difference between a good query and a bad query without serious penalty to the PFE performance. your idea would break caching and cause more flotsam to hang around in various systems. personally, I like having things cache age out of the DNS during an attack. lets me change the A RR for a victim to a different IP. Useful for those scripts that don't update their cached IP for the victim name. three things will help provide better strength against DDOS attacks. a) properly managed anycast of the root infrastructure. b) securing the edge of the net. remove the zombie hosts and they can't be used as a tool. c) signing the root zone, more for layer 8 reasons than others. when providers decide to start applying various tools to improve security on the edge (ergo clients) things will become better. John M. Brown, CEO Chagres Technologies, Inc Le Geek > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Alec H. Peterson > Sent: Friday, November 22, 2002 5:38 PM > To: namedroppers@ops.ietf.org > Subject: DNS Server DoS Attacks > > > These attacks seem to be on the rise. There were the > well-publicized ones > on the root servers a few weeks ago, and yesterday UltraDNS > was hit with > one. It occurs to me that these attacks have the potential > to completely > shut down the DNS system if they are structured properly. I > have a thought > on how to make the system more resiliant to authoritative > servers getting > hammered, and was interested in some thoughts on it. > > My thought is to add another TTL to DNS responses, similar to the SOA > maximum parameter. The current TTL would be similar to the > SOA minimum. > This would still allow for records to expire in a reasonable > amount of > time, but it would also allow for DNS responses to be > answered in the event > that servers in the hierarchy are unreachable for some > reason. It occurs > to me that it is possible to retrofit existing DNS servers to > have a static > maximum timeout without any protocol modifications. > > Anyway, the way I see it since DNS already has a caching > infrastructure > built in it makes sense to take extra advantage of that > infrastructure when > things are under attack. > > Alec > > -- > Alec H. Peterson -- ahp@hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.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: > -- 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 Nov 23 06:21:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27015 for ; Sat, 23 Nov 2002 06:21:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FYCc-0009bn-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 03:11:58 -0800 Received: from mta03-svc.ntlworld.com ([62.253.162.43]) by psg.com with esmtp (Exim 3.36 #2) id 18FYCa-0009ba-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 03:11:56 -0800 Received: from tesco.net ([62.254.154.113]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021123111154.WJHX28295.mta03-svc.ntlworld.com@tesco.net>; Sat, 23 Nov 2002 11:11:54 +0000 Message-ID: <3DDF6410.BE21CC49@tesco.net> Date: Sat, 23 Nov 2002 11:18:40 +0000 From: Jonathan de Boyne Pollard Organization: Wack's Wicks Works X-Mailer: Mozilla 4.04 [en] (OS/2; I) MIME-Version: 1.0 To: DNS on UNIX Mailing List , namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: axfr-clarify on the move again References: <004e01c29014$cc60d940$210d640a@unfix.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit DJB> Nobody would fall for it if the document imposed rules relating DJB> to silly experiments like A6. *********** JM> Lots of snipps, just to remind you that A6 has been moved to JM> experimental [...] It's pretty fair assumption that he had already remembered. -- 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 Nov 23 06:42:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27217 for ; Sat, 23 Nov 2002 06:42:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FYb4-000AOs-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 03:37:14 -0800 Received: from mta02-svc.ntlworld.com ([62.253.162.42]) by psg.com with esmtp (Exim 3.36 #2) id 18FYb0-000AOd-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 03:37:10 -0800 Received: from tesco.net ([62.254.154.113]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021123113709.TPPS3850.mta02-svc.ntlworld.com@tesco.net>; Sat, 23 Nov 2002 11:37:09 +0000 Message-ID: <3DDF69FA.CDDFF265@tesco.net> Date: Sat, 23 Nov 2002 11:43:54 +0000 From: Jonathan de Boyne Pollard Organization: Wack's Wicks Works X-Mailer: Mozilla 4.04 [en] (OS/2; I) MIME-Version: 1.0 To: DNS on UNIX Mailing List , namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: axfr-clarify on the move again References: <200211200534.gAK5YOV17060@guava.araneus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.8 required=5.0 tests=NOSPAM_INC,REFERENCES,SPAM_PHRASE_05_08, USER_AGENT_MOZILLA_XM version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit DJB> * Under RFC 1034, the Domain Name System has a single node DJB> named full.moon.heaven.af.mil. The records at that node DJB> are copied to any place that they're needed. If a copy DJB> isn't exact, the copying mechanism has failed and should be DJB> fixed. AG> RFC1034 talks about copying "NS and glue RRs" to the parent, AG> not entire nodes. The text that you quote doesn't talk about copying entire nodes, either. The point that you are attempting to make isn't clear. What is it ? -- 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 Nov 23 09:39:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29480 for ; Sat, 23 Nov 2002 09:39:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FbIc-000GLw-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 06:30:22 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 18FbIa-000GLk-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 06:30:20 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id C2142137F08; Sat, 23 Nov 2002 06:30:06 -0800 (PST) To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks In-Reply-To: Message from "D. J. Bernstein" of "23 Nov 2002 06:16:46 GMT." <20021123061646.22603.qmail@cr.yp.to> Date: Sat, 23 Nov 2002 06:30:06 -0800 Message-ID: <86155.1038061806@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "djb" == D J Bernstein writes: djb> The DNS protocol should be augmented with a separate protocol djb> for distributing (signed) copies of the root zone I can't believe you just said that. Does this mean you have recanted on your previous strident objections to DNSSEC? :-) -- 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 Nov 23 09:54:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29763 for ; Sat, 23 Nov 2002 09:54:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fbaa-000H22-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 06:48:56 -0800 Received: from d61.wireless.hilander.com ([216.241.32.61] helo=ramirez.hilander.com) by psg.com with esmtp (Exim 3.36 #2) id 18FbaY-000H1p-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 06:48:54 -0800 Received: from [216.241.32.58] (helo=d58.wireless.hilander.com) by ramirez.hilander.com with esmtp (Exim 4.10) id 18FbaV-00037b-00; Sat, 23 Nov 2002 07:48:51 -0700 Date: Sat, 23 Nov 2002 07:48:52 -0700 From: "Alec H. Peterson" To: john@chagres.net, namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks Message-ID: <2147483647.1038037732@d58.wireless.hilander.com> In-Reply-To: <005001c292c4$83d7abb0$f9ecdfd8@laptoy> References: <005001c292c4$83d7abb0$f9ecdfd8@laptoy> X-Mailer: Mulberry/3.0.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.3 (-) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18FbaV-00037b-00*pkIRC2kXLB2* X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, November 23, 2002 12:47 AM -0700 "John M. Brown" wrote: > packet forwarding engines won't tell the difference between > a good query and a bad query without serious penalty to the > PFE performance. I don't think I understand, what does my suggestion have to do with packet forwarding engines distinguishing between good and bad queries? > > your idea would break caching and cause more flotsam to hang > around in various systems. Well yes, it would break the current caching model by changing it. > > personally, I like having things cache age out of the DNS > during an attack. lets me change the A RR for a victim to > a different IP. Useful for those scripts that don't update > their cached IP for the victim name. But if your authoritative DNS servers aren't even reachable to have the cache get re-populated then what good is it to have the cache get aged? My proposal doesn't change the current cache aging system, you can still have a 10 minute TTL and have an authoritative server re-query after the original 10 minutes has expired. This just _allows_ caching nameservers to keep stuff for longer if it is not possible to re-populate the cache due to unreachable nameservers. > > three things will help provide better strength against DDOS > attacks. > > a) properly managed anycast of the root infrastructure. Agreed that anycast does help. > > b) securing the edge of the net. remove the zombie hosts > and they can't be used as a tool. Agreed. > > c) signing the root zone, more for layer 8 reasons than others. I fail to see how signing the root zone would keep somebody from flooding me with packets. > > when providers decide to start applying various tools to improve > security on the edge (ergo clients) things will become better. No argument. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.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 Sat Nov 23 11:12:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01129 for ; Sat, 23 Nov 2002 11:12:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FcnS-000KEf-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 08:06:18 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18FcnQ-000KES-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 08:06:17 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18FcnM-0000yK-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 08:06:12 -0800 Message-ID: <20021123162844.A57751@k2r.org> References: <20021117211006.98837.qmail@cr.yp.to> <20021118033728.GA13838@codeblau.de> <20021119204308.52994.qmail@cr.yp.to> <20021122152754.A42609@k2r.org> <200211221929.gAMJTTg01260@guava.araneus.fi> <20021123162158.A57452@k2r.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit In-Reply-To: <20021123162158.A57452@k2r.org>; from kenji@k2r.org on Sat, Nov 23, 2002 at 04:21:36PM +0900 Date: Sat, 23 Nov 2002 16:28:44 +0900 From: Kenji Rikitake To: Andreas Gustafsson Cc: "D. J. Bernstein" , dns@list.cr.yp.to, namedroppers@ops.ietf.org, iesg@ietf.org, Kenji Rikitake Subject: Re: axfr-clarify on the move again X-Spam-Status: No, hits=-3.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Corrections: In the message <20021123162158.A57452@k2r.org> at Sat, Nov 23, 2002 at 04:21:36PM +0900, Kenji Rikitake writes: > told me I must make a fair acceptable of Andreas's argument. 'a fair acceptance' instead of 'a fair acceptable' > This means if you have two different master servers inconsistent with > each other, the slave received data from those servers, should keep the > inconsistency as is. This will significantly hamper at least the 'those server, MUST keep the' instead of ' 'those server, should keep the' is correct. Please excuse me for the errors. // Kenji Rikitake -- 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 Nov 23 11:14:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01170 for ; Sat, 23 Nov 2002 11:14:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fcon-000KHL-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 08:07:41 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Fcok-000KGL-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 08:07:38 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Fcoj-0000yR-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 08:07:37 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks References: <1507321518.1037986651@d58.wireless.hilander.com> <005001c292c4$83d7abb0$f9ecdfd8@laptoy> Message-Id: Date: Sat, 23 Nov 2002 08:07:37 -0800 X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit perhaps folk should review steve bellovin's nanog talk (dc?) on pushback. 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 Sat Nov 23 12:59:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02881 for ; Sat, 23 Nov 2002 12:59:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FeUL-000PVm-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 09:54:41 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18FeUI-000PVH-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 09:54:39 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18FeUG-00012b-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 09:54:37 -0800 Message-ID: <20021123172816.71385.qmail@cr.yp.to> References: <20021123061646.22603.qmail@cr.yp.to> <86155.1038061806@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 23 Nov 2002 17:28:16 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] PGP 2048-bit ElGamal signatures are probably the best choice for root-zone distribution today: the signature format is reasonably simple and reasonably well documented, and free signature-checking software is already widely deployed. Of course, the root-zone protocol can support multiple signatures on the same file. Jim Reid writes: > I can't believe you just said that. Does this mean you have recanted > on your previous strident objections to DNSSEC? :-) Have you stopped beating your wife, Jim? Anyone who wants to see what I've actually said about DNSSEC should read http://cr.yp.to/djbdns/forgery.html. ---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 Sat Nov 23 15:12:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04313 for ; Sat, 23 Nov 2002 15:12:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FgYM-0004Nv-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 12:06:58 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18FgYK-0004Nj-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 12:06:57 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18FgYI-000197-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 12:06:54 -0800 Message-ID: <20021123195320.98947.qmail@cr.yp.to> References: <20021123061646.22603.qmail@cr.yp.to> <86155.1038061806@shell.nominum.com> <20021123172816.71385.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 23 Nov 2002 19:53:20 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks X-Spam-Status: No, hits=0.1 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] After receiving an email response from the Netherlands, I realize that I should explain for international readers (and perhaps for some American illiterates) what ``Have you stopped beating your wife?'' means. That phrase is, at least in English, a standard reference to a fallacy pointed out by Aristotle and also known as * plurium interrogationum (``many questions''); * the fallacy of interrogation; * the fallacy of presupposition; * the loaded-question fallacy; and * the complex-question fallacy. The fallacy occurs when a question posits an unproven assumption. For example, the fallacious question ``Have you stopped beating your wife, Jim?'' presumes that Jim has a wife, and has been beating her; there is no evidence for these presumptions, and in fact we all presume the opposite. Jim asked a fallacious question making certain incorrect presumptions about what I have said about DNSSEC. I responded by pointing out the fallacy and the underlying facts. ---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 Sat Nov 23 15:41:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04713 for ; Sat, 23 Nov 2002 15:41:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FgyV-0005Ma-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 12:33:59 -0800 Received: from alderaan.chagres.net ([216.223.236.235] helo=chagres.net) by psg.com with esmtp (Exim 3.36 #2) id 18FgyT-0005Kk-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 12:33:57 -0800 Received: (qmail 92370 invoked from network); 23 Nov 2002 20:37:22 -0000 Received: from unknown (HELO laptoy) (jmbrown@chagres.net@68.35.21.40) by alderaan.chagres.net with RC4-MD5 encrypted SMTP; 23 Nov 2002 20:37:22 -0000 Reply-To: From: "John M. Brown" To: "'Alec H. Peterson'" , Subject: RE: DNS Server DoS Attacks Date: Sat, 23 Nov 2002 13:33:23 -0700 Organization: Chagres Technologies, Inc Message-ID: <000f01c2932f$92542810$c57ba8c0@laptoy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <2147483647.1038037732@d58.wireless.hilander.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04713 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Alec H. Peterson > Sent: Saturday, November 23, 2002 7:49 AM > To: john@chagres.net; namedroppers@ops.ietf.org > Subject: RE: DNS Server DoS Attacks > > > --On Saturday, November 23, 2002 12:47 AM -0700 "John M. Brown" > wrote: > > > packet forwarding engines won't tell the difference between > > a good query and a bad query without serious penalty to the PFE > > performance. > > I don't think I understand, what does my suggestion have to > do with packet > forwarding engines distinguishing between good and bad queries? long flight, coffee == empty, it was part of a different conversation that slipped into this thread. sorry. Some people where arguing that you could filter via ACL's and such, that works until the poison (bad packets) looks, smells and tastes like what you think lunch should be. > But if your authoritative DNS servers aren't even reachable > to have the cache get re-populated then what good is it to > have the cache get aged? keeps the system cleaner. see pauls answer > My proposal doesn't change the current cache aging system, you > can still have > a 10 minute TTL and have an authoritative server re-query after the > original 10 minutes has expired. This just _allows_ caching > nameservers to > keep stuff for longer if it is not possible to re-populate > the cache due to > unreachable nameservers. SO how does this caching change handle a zone going away ? If I remove a zone from service, is that not like a DOS ?? what I'm hearing is " lets have a static value that keeps data in a cache longer than what the owner wants, just incase things break"... is that correct ?? > > c) signing the root zone, more for layer 8 reasons than others. > > I fail to see how signing the root zone would keep somebody > from flooding me with packets. It doesn't. It ""protects"" the zone, its a layer 8 warm and fuzzy thing. It does help make sure that the anycast box you are asking is serving the same data as all of the others, and if its not, you can ignore that server. -- 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 Nov 23 15:44:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04763 for ; Sat, 23 Nov 2002 15:44:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fh1i-0005Tf-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 12:37:18 -0800 Received: from d61.wireless.hilander.com ([216.241.32.61] helo=ramirez.hilander.com) by psg.com with esmtp (Exim 3.36 #2) id 18Fh1g-0005TT-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 12:37:16 -0800 Received: from [216.241.32.51] (helo=macleod.hilander.com) by ramirez.hilander.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 18Fh1e-00042U-00; Sat, 23 Nov 2002 13:37:14 -0700 Date: Sat, 23 Nov 2002 13:37:14 -0700 From: "Alec H. Peterson" To: john@chagres.net, namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks Message-ID: <2147483647.1038058634@macleod.hilander.com> In-Reply-To: <000f01c2932f$92542810$c57ba8c0@laptoy> References: <000f01c2932f$92542810$c57ba8c0@laptoy> X-Mailer: Mulberry/3.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.3 (-) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18Fh1e-00042U-00*XnPTDvk7WUM* X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, November 23, 2002 13:33 -0700 "John M. Brown" wrote: > > keeps the system cleaner. see pauls answer In the normal case, yes, and I agree that it does end up making the cache uglier. But isn't it better to keep things running when things are going wrong? > > SO how does this caching change handle a zone going away ? If I remove > a zone from service, is that not like a DOS ?? The entries will stay around for a while. If somebody really wants all of the DNS to disappear immediately then this would present an issue, but is this really a huge concern? > > what I'm hearing is " lets have a static value that keeps data in a > cache > longer than what the owner wants, just incase things break"... is that > correct ?? Not at all. The owner would have complete control over his TTLs, just like he does now. If the owner of the zone doesn't want to take advantage of this feature then he doesn't have to. > > It doesn't. It ""protects"" the zone, its a layer 8 warm and fuzzy > thing. It does help make sure that the anycast box you are asking is > serving the same data as all of the others, and if its not, you can > ignore that server. Uhm, I certainly don't disagree with that, but I still fail to see how it relates to the discussion at hand. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.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 Sat Nov 23 15:59:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04925 for ; Sat, 23 Nov 2002 15:59:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FhHE-00066t-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 12:53:20 -0800 Received: from alderaan.chagres.net ([216.223.236.235] helo=chagres.net) by psg.com with esmtp (Exim 3.36 #2) id 18FhHC-000663-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 12:53:18 -0800 Received: (qmail 92507 invoked from network); 23 Nov 2002 20:56:44 -0000 Received: from unknown (HELO laptoy) (jmbrown@chagres.net@68.35.21.40) by alderaan.chagres.net with RC4-MD5 encrypted SMTP; 23 Nov 2002 20:56:44 -0000 Reply-To: From: "John M. Brown" To: "'Alec H. Peterson'" , Subject: RE: DNS Server DoS Attacks Date: Sat, 23 Nov 2002 13:52:41 -0700 Organization: Chagres Technologies, Inc Message-ID: <001001c29332$470ae760$c57ba8c0@laptoy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <2147483647.1038058634@macleod.hilander.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04925 > > It doesn't. It ""protects"" the zone, its a layer 8 warm and fuzzy > > thing. It does help make sure that the anycast box you are > asking is > > serving the same data as all of the others, and if its not, you can > > ignore that server. > > Uhm, I certainly don't disagree with that, but I still fail > to see how it > relates to the discussion at hand. only that I had mentioned it as one of the things to be done to help protect anycasting the root zones, and you had asked how this helps protect. its now not part of the rest of this thread. > Alec > > -- > Alec H. Peterson -- ahp@hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.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 Sat Nov 23 16:52:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05793 for ; Sat, 23 Nov 2002 16:52:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fi3O-0007vK-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 13:43:06 -0800 Received: from va-leesburg3b-90.stngva.adelphia.net ([68.71.234.90] helo=the-paynes.com) by psg.com with esmtp (Exim 3.36 #2) id 18Fi3L-0007ta-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 13:43:03 -0800 Received: (from repayne@localhost) by the-paynes.com (8.11.6/8.11.6) id gANLg1417057; Sat, 23 Nov 2002 16:42:01 -0500 Date: Sat, 23 Nov 2002 16:42:01 -0500 From: Rob Payne To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks Message-ID: <20021123214201.GB6789@osprey.the-paynes.com> References: <20021123061646.22603.qmail@cr.yp.to> <86155.1038061806@shell.nominum.com> <20021123172816.71385.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline In-Reply-To: <20021123172816.71385.qmail@cr.yp.to> User-Agent: Mutt/1.4i X-Use-Encryption: Encrypted email preferred (see www.gnupg.org) X-GnuPG-Keyid: 9B6E7165 X-GnuPG-Fingerprint: D42C ACC0 CA2A B7D5 7A01 A43F 80B5 FBFE 9B6E 7165 X-Spam-Status: No, hits=-4.0 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 23, 2002 at 05:28:16PM -0000, D. J. Bernstein wrote: > PGP 2048-bit ElGamal signatures are probably the best choice for > root-zone distribution today: the signature format is reasonably simple > and reasonably well documented, and free signature-checking software is > already widely deployed. Of course, the root-zone protocol can support > multiple signatures on the same file. Let me see if I understand your proposal. You want to turn the root zone into a signed "hosts.txt" (RFC 952, 953), and how, exactly does that scale this time around when it did not scale the last time? More distribution methods make for more attack vectors and more opportunities for DOS against different groups. Maybe it's time to review section 2.1 of RFC 1034 to see the problems with that model. Your previous message said: > The root-zone protocol should promise that every piece of data will > last for a month. That data should be guaranteed to last a month from when, exactly? =46rom the time it was signed, or from when it downloaded? The former will mean that *everyone* will be attempting to grab this at the same time (every thirty days from whenever this process starts), the latter will mean that the data can *never* change. The current situation is that data is valid for a shorter period of time (1 TTL) and systems can grab it at any time, meaning that an attack has to last for the current (1/2 TTL) to create an outage that will effect most systems. If we go to a set of static data, valid for a fixed time frame we narrow the "window of opportunity" for attack/DOS to a much smaller period (the first [time period] at the beginning of a 30 day cycle when everyone is grabbing the root zone, thus putting heavy loading on servers that are distributing the new information.) How, exactly does this provide for a system that is more resistant to attack? It actually makes a well planned attack (around the first [time period] of the update cycle) more likely to create an effective DOS. And, of course, this still ignores most of the reasons for DNSSEC. Being able to get trustworthy data from entities with unknown motives is not possible when the data comes to you without its covering signatures. The provider of my DNS service being able to check signatures which they do not pass along with the data does not do anything to provide me with usable data. Nym-based names and bookmarks do not fix the problem. Each time a key is compromised, the name changes (the key changes and therefore the fingerprint of the key which makes up the nym changes). If there is no method for a chain of trust check on DNS signature keys, owners of hosts end up making a choice between invalidating all of the "bookmarks" that other people have stored for their host, or continuing to use the compromised key. -rob --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE93/YpgLX7/ptucWURAhgCAJ4hGMz3xxwJY0jlL0UQAJnViICcUgCfTXze fz02PR42UAqSyJ0AlYIJYr8= =B3v3 -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- -- 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 Nov 23 16:51:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05781 for ; Sat, 23 Nov 2002 16:51:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fi4f-0007y3-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 13:44:25 -0800 Received: from va-leesburg3b-90.stngva.adelphia.net ([68.71.234.90] helo=the-paynes.com) by psg.com with esmtp (Exim 3.36 #2) id 18Fi4c-0007xo-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 13:44:22 -0800 Received: (from repayne@localhost) by the-paynes.com (8.11.6/8.11.6) id gANLhdJ17107; Sat, 23 Nov 2002 16:43:39 -0500 Date: Sat, 23 Nov 2002 16:43:39 -0500 From: Rob Payne To: "Alec H. Peterson" Cc: john@chagres.net, namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks Message-ID: <20021123214339.GC6789@osprey.the-paynes.com> References: <000f01c2932f$92542810$c57ba8c0@laptoy> <2147483647.1038058634@macleod.hilander.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xo44VMWPx7vlQ2+2" Content-Disposition: inline In-Reply-To: <2147483647.1038058634@macleod.hilander.com> User-Agent: Mutt/1.4i X-Use-Encryption: Encrypted email preferred (see www.gnupg.org) X-GnuPG-Keyid: 9B6E7165 X-GnuPG-Fingerprint: D42C ACC0 CA2A B7D5 7A01 A43F 80B5 FBFE 9B6E 7165 X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --xo44VMWPx7vlQ2+2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 23, 2002 at 01:37:14PM -0700, Alec H. Peterson wrote: > --On Saturday, November 23, 2002 13:33 -0700 "John M. Brown"=20 > wrote: >=20 > > > >keeps the system cleaner. see pauls answer >=20 > In the normal case, yes, and I agree that it does end up making the cache= =20 > uglier. But isn't it better to keep things running when things are going= =20 > wrong? It is not better, if "keeping things running" keeps the problem from getting fixed. -rob --xo44VMWPx7vlQ2+2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE93/aLgLX7/ptucWURAsfFAJ0diUQu+w1AoP2IlO92VaQnb+dL3gCghl2h EtdHg/PAYX74Pz8ZPOPSSlo= =we9+ -----END PGP SIGNATURE----- --xo44VMWPx7vlQ2+2-- -- 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 Nov 23 18:11:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07172 for ; Sat, 23 Nov 2002 18:11:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FjMx-000APj-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 15:07:23 -0800 Received: from d61.wireless.hilander.com ([216.241.32.61] helo=ramirez.hilander.com) by psg.com with esmtp (Exim 3.36 #2) id 18FjMv-000APX-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 15:07:21 -0800 Received: from [216.241.32.51] (helo=macleod.hilander.com) by ramirez.hilander.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 18FjMr-0004SY-00; Sat, 23 Nov 2002 16:07:17 -0700 Date: Sat, 23 Nov 2002 16:07:15 -0700 From: "Alec H. Peterson" To: Rob Payne cc: john@chagres.net, namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks Message-ID: <2147483647.1038067635@macleod.hilander.com> In-Reply-To: <20021123214339.GC6789@osprey.the-paynes.com> References: <000f01c2932f$92542810$c57ba8c0@laptoy> <2147483647.1038058634@macleod.hilander.com> <20021123214339.GC6789@osprey.the-paynes.com> X-Mailer: Mulberry/3.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.3 (-) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18FjMr-0004SY-00*zsmxXIZEvso* X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, November 23, 2002 16:43 -0500 Rob Payne wrote: > > It is not better, if "keeping things running" keeps the problem from > getting fixed. *sigh* If people think I'm advocating implementing this instead of attacking DoS vulnerabilities at their source then obviously I'm not communicating very well. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.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 Sat Nov 23 18:26:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07272 for ; Sat, 23 Nov 2002 18:26:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FjZQ-000Air-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 15:20:16 -0800 Received: from d61.wireless.hilander.com ([216.241.32.61] helo=ramirez.hilander.com) by psg.com with esmtp (Exim 3.36 #2) id 18FjZO-000Aid-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 15:20:14 -0800 Received: from [216.241.32.51] (helo=macleod.hilander.com) by ramirez.hilander.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 18FjZL-0004Uv-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 16:20:11 -0700 Date: Sat, 23 Nov 2002 16:20:10 -0700 From: "Alec H. Peterson" To: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks Message-ID: <2147483647.1038068410@macleod.hilander.com> In-Reply-To: <20021123214339.GC6789@osprey.the-paynes.com> References: <000f01c2932f$92542810$c57ba8c0@laptoy> <2147483647.1038058634@macleod.hilander.com> <20021123214339.GC6789@osprey.the-paynes.com> X-Mailer: Mulberry/3.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -0.8 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18FjZL-0004Uv-00*S45rGjdMLgM* X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit So let me re-state in no un-certain terms my goal here, so that nobody can imply anything that is not meant to be implied from my statements. My proposal (essentially a second TTL that keeps records around longer in the event that authoritative servers are unable to answer) is _NOT_ meant to be any sort of 'solution' to DoS attacks. I feel that it is still incredibally important for us to do everything that we can to secure the edge and keep these attacks from happening. HOWEVER, we have been trying to do that for years, and yet the DoS attacks persist. My proposal is intended to harden our infrastructure so that we can tolerate these attacks while they are still going on. Certainly I would rather we secure the edge, but it is obvious that DoS attacks still occur. I feel it is our duty to do everything we can to operate within the parameters of reality on the Internet today. So, we have two options. We can continue to say 'secure the edge' and hope that makes the problem go away. Or we can continue to work on securing the edge while also hardening our existing infrastructure to deal with the issues we face here and now. So, with those parameters in mind, I hope people now clearly understand my goal here. If there has been any misunderstanding please let me know. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.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 Sat Nov 23 19:21:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08431 for ; Sat, 23 Nov 2002 19:21:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FkTa-000C4q-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 16:18:18 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18FkTX-000C4e-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 16:18:15 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gAO0Hqt03238; Sat, 23 Nov 2002 16:17:52 -0800 (PST) Date: Sat, 23 Nov 2002 16:17:52 -0800 (PST) Message-Id: <200211240017.gAO0Hqt03238@guava.araneus.fi> To: Kenji Rikitake Cc: "D. J. Bernstein" , dns@list.cr.yp.to, namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: axfr-clarify on the move again In-Reply-To: <20021123125438.A55745@k2r.org> References: <20021117211006.98837.qmail@cr.yp.to> <20021118033728.GA13838@codeblau.de> <20021119204308.52994.qmail@cr.yp.to> <20021122152754.A42609@k2r.org> <200211221929.gAMJTTg01260@guava.araneus.fi> <20021123125438.A55745@k2r.org> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kenji Rikitake writes: > > Please define what you mean by "uniqueness of DNS RR integrity" and > > explain how it is "assured by the RFC1034 model". > > Uniqueness of DNS RR integrity: a RR, whereever it is stored, in a DNS > cache or a DNS server, is the same as the other copies. I agree that this should be the goal, but the DNS protocol does not itself enforce consistency of glue data between parent and child - it is achieved through the operational procedure of copying glue records from child to parent. > Assurance of the RFC1034 model: See RFC1034 Section 2.2 as I mentioned > in a previous message. It says "names should not be required to contain > network identifiers, addresses, routes, or similar information as part > of the name." That text is about a completely unrelated issue - it is talking about the names themselves, not about the data they are associated with. It is simply noting that naming schemes like UUCP bang paths (e.g., uunet!mcvax!santra), where the very name of a host contains information about how to reach it, are a bad idea. I think we all agree on that, but it is not what we are talking about here. > > Please explain how the axfr-clarify draft "breaks" this, and exactly > > how that will "significantly hamper the fundamental security of the > > current non-cryptographic DNS". > > I will try to describe the definitions by referring to the following > explanation. > [...] > -- quote -- > > The slave MUST associate the RRs received in a zone transfer with the > specific zone being transferred, and maintain that association for > purposes of acting as a master in outgoing transfers. > > -- unquote -- > > This means if you have two different master servers inconsistent with > each other, the slave received data from those servers, MUST keep the > inconsistency as is. Yes, though I must stress that we are specifically talking about inconsistencies between the master of a parent and the master of a child, not about inconsistencies between multiple masters for the same zone. > This will significantly hamper at least the > consistency of the replicated DNS databases. The semantics specified in the draft do not cause any new inconsistencies, they only preserve parent-child inconsistencies that are already there, just as they will be preserved in the typical case where the parent and child are hosted on physically separate servers. Although it is possible to enforce parent-child consistency in the way DJB proposes in the rare case where they happen to be hosted on the same server, that is at the expense of consistency among the authoritative servers for the parent zone ("parent-parent consistency"), since not all the parent servers will have the child zone and therefore the opportunity to "correct" their glue data. > The DNS consistency is a > fundamental basis of Internet security as a set of distributed system. Parent-child glue consistency is not a security issue. If it were, then surely we ought to develop a method to guarantee that consistency everywhere, not just in the rare case where they happen to be hosted on the same server. > DJB's dnscache has an effective heuristic algorithm which he is > explained in the Section of "Parents and Discrepancies" of > http://cr.yp.to/djbdns/axfr-clarify.html to eliminate this sort of > inconsistency, which is actually doing *good* for keeping DNS as > consistent as possible. By this draft, this sort of heuristics is > denied. This is unacceptable. It may be doing some good for parent-child consistency, but at the expense of breaking parent-parent consistency. Note that from the perspective of a client querying (not AXFRing) the combined parent-child slave server, there is no difference between the axfr-clarify semantics and DJB's semantics - in both cases, a query for the NS records at the delegation point will return the child's records, as it should. The difference is only visible to downstream parent-only slaves that transfer the parent zone from the combined parent-child server, and to clients querying such a downstream server. With the axfr-clarify semantics, that parent server will have the parent NS records; with the DJB semantics, it will have the child NS records. > > Also, please define the property of "uniqueness of AXFR-transferred > > data" and explain how the "fundamental security" depends on it. > > The uniqueness of AXFR-transferred data is described by the consistency > (i.e., being equal byte-to-byte) between the RRs received by a slave > server from two or more different master servers is maintained. I figured that's what you meant. That's why I was confused as to whether you were speaking for or against the draft, since the property you describe is precisely the property the axfr-clarify draft is trying to guarantee and the one DJB's server will violate. -- 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 Sat Nov 23 20:51:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09696 for ; Sat, 23 Nov 2002 20:51:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Flq6-000E4f-00 for namedroppers-data@psg.com; Sat, 23 Nov 2002 17:45:38 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18Flq4-000E4T-00 for namedroppers@ops.ietf.org; Sat, 23 Nov 2002 17:45:36 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gAO1jUj03320; Sat, 23 Nov 2002 17:45:30 -0800 (PST) Date: Sat, 23 Nov 2002 17:45:30 -0800 (PST) Message-Id: <200211240145.gAO1jUj03320@guava.araneus.fi> To: Jonathan de Boyne Pollard Cc: DNS on UNIX Mailing List , namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: axfr-clarify on the move again In-Reply-To: <3DDF69FA.CDDFF265@tesco.net> References: <200211200534.gAK5YOV17060@guava.araneus.fi> <3DDF69FA.CDDFF265@tesco.net> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_05_08 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jonathan de Boyne Pollard writes: > DJB> * Under RFC 1034, the Domain Name System has a single node > DJB> named full.moon.heaven.af.mil. The records at that node > DJB> are copied to any place that they're needed. If a copy > DJB> isn't exact, the copying mechanism has failed and should be > DJB> fixed. > > AG> RFC1034 talks about copying "NS and glue RRs" to the parent, > AG> not entire nodes. > > The text that you quote doesn't talk about copying entire nodes, either. The > point that you are attempting to make isn't clear. What is it ? It said "copy the records", which I would interpret as "copy all the records" in the absence of further qualification. I'm simply pointing out that in fact only some of the records are copied, and therefore there will be differences between the parent and child data for the node even in a correctly configured DNS. Please excuse me if I'm stating the obvious. -- 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 Sun Nov 24 11:39:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29299 for ; Sun, 24 Nov 2002 11:39:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fzcm-000DIa-00 for namedroppers-data@psg.com; Sun, 24 Nov 2002 08:28:48 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Fzcj-000DIO-00 for namedroppers@ops.ietf.org; Sun, 24 Nov 2002 08:28:46 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Fzcf-000Fbr-00 for namedroppers@ops.ietf.org; Sun, 24 Nov 2002 08:28:41 -0800 Message-ID: <20021124091420.47876.qmail@cr.yp.to> References: <20021117211006.98837.qmail@cr.yp.to> <20021118033728.GA13838@codeblau.de> <20021119204308.52994.qmail@cr.yp.to> <20021122152754.A42609@k2r.org> <200211221929.gAMJTTg01260@guava.araneus.fi> <20021123125438.A55745@k2r.org> <200211240017.gAO0Hqt03238@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 24 Nov 2002 09:14:20 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dns@list.cr.yp.to, namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: axfr-clarify on the move again X-Spam-Status: No, hits=-0.6 required=5.0 tests=NO_OBLIGATION,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Andreas Gustafsson writes: > I agree that this should be the goal, but the DNS protocol does not > itself enforce consistency of glue data between parent and child RFC 1034 and RFC 1035 make crystal clear that record sets in the Domain Name System at any moment are indexed by class+name+type. Nothing else. Does this semantic rule mean that copies of data around the Internet are magically equalized if they have the same class+name+type? Of course not. Most of the copying protocols have reliability problems, producing accidental (though usually harmless) inconsistencies. Often people deliberately introduce inconsistencies---for example, giving different answers to different clients. What, then, does the semantic rule mean? The answer is simple: Implementations are free to store record sets by class+name+type. If they're faced with two record sets of the same class+name+type, they can throw one away. Three examples: 1. Consider, once again, client differentiation, or ``views'' in BIND 9: some servers store data by class+name+type+clientIP. Everybody else is free to assume that this doesn't happen. For example, a cache that uses two IP addresses for its outgoing requests, and receives different data under the same class+name+type on the two IP addresses, is under absolutely no obligation to keep track of both record sets. 2. Consider, as a simpler example, the fact that different servers for a zone can have different data. Everybody else is free to assume that this doesn't happen. If I receive different record sets from the two servers, under the same class+name+type, I can use either one. I'm under no obligation to keep track of both record sets. 3. Finally, getting back to the situation under discussion: It's certainly possible for a parent and a child to have different data for the same class+name+type. But everybody else is free to assume that this doesn't happen. If I receive different record sets from the two servers, under the same class+name+type, I can use either one. I'm under no obligation to keep track of both record sets. In short, the fact that _you_ index your database by something more than class+name+type does not oblige _me_ to do the same thing. Andersson argues that the possibility of differing data means that everyone else has to keep track of the differences. That argument is clearly fallacious. I'm sure Andersson doesn't believe it himself: the absurdity of the argument is obvious in situation #2, for example. ---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 Sun Nov 24 11:40:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29314 for ; Sun, 24 Nov 2002 11:40:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FzgA-000DPk-00 for namedroppers-data@psg.com; Sun, 24 Nov 2002 08:32:18 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Fzg8-000DPY-00 for namedroppers@ops.ietf.org; Sun, 24 Nov 2002 08:32:17 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Fzg7-000FcB-00 for namedroppers@ops.ietf.org; Sun, 24 Nov 2002 08:32:16 -0800 Message-ID: <20021124092712.50498.qmail@cr.yp.to> References: <20021123061646.22603.qmail@cr.yp.to> <86155.1038061806@shell.nominum.com> <20021123172816.71385.qmail@cr.yp.to> <20021123214201.GB6789@osprey.the-paynes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 24 Nov 2002 09:27:12 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Rob Payne writes: > You want to turn the root zone into a signed "hosts.txt" (RFC 952, > 953), and how, exactly does that scale I already answered that: ``Effects on load: Everybody will receive the entire zone, rather than just the parts they need. On the other hand, any sensible format would be much smaller than DNS packet format. More importantly, the data will be cached much more effectively than it is with the current root-zone protocol. Most importantly, the load will be very widely distributed.'' The last factor is, as I said, the most important one. USENET wouldn't notice if ten copies of the root zone---or ten thousand copies---were sent out every day. > it did not scale the last time Nobody really tried to make it scale, but this is beside the point. ``Root zone'' does not mean ``complete list of Internet hosts.'' ---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 Sun Nov 24 11:53:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29523 for ; Sun, 24 Nov 2002 11:53:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fzqv-000Dnv-00 for namedroppers-data@psg.com; Sun, 24 Nov 2002 08:43:25 -0800 Received: from [63.149.73.20] (helo=vorpal.notabug.com) by psg.com with smtp (Exim 3.36 #2) id 18Fzqs-000Dng-00 for namedroppers@ops.ietf.org; Sun, 24 Nov 2002 08:43:23 -0800 Received: (qmail 19618 invoked from network); 24 Nov 2002 16:43:22 -0000 Received: from 12-249-96-16.client.attbi.com (HELO aaronsw.com) (12.249.96.16) by 0 with SMTP; 24 Nov 2002 16:43:22 -0000 Date: Sun, 24 Nov 2002 10:43:21 -0600 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: objection to axfr-clarify From: Aaron Swartz To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-1.0 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi. As a user of the UltraDNS server and client, the BIND server, and the djbdns server and client, I have a strong interest in AXFR interoperability. I object to the publication of axfr-clarify on the grounds that it imposes requirements not necessary for interoperability, in violation of RFC 2119 (BCP 14), section 6. I also object on the grounds that it outlaws the behavior of deployed tools which I use. Major changes to the protocol like these should not be put into a document that supposedly "clarifies [...] the original AXFR protocol". Specifically, in http://users.starpower.net/ogud/draft-ietf-dnsext-axfr-clarify-04.txt I found the following issues: Section 3: "If the master server is unable or unwilling to provide a zone transfer, it MUST respond with a single DNS message containing an appropriate RCODE other than NOERROR." This is not required for interoperability and appears to prohibit the behavior of the UltraDNS server and djbdns's axfrdns server. Section 3.1: "MUST check the RCODE in each message and abort the transfer if it is not NOERROR." This is not required for interoperability and appears to prohibit the behavior of djbdns's axfr-get client. Section 3.5: "Slaves MUST ignore any authority section contents they may receive from masters that do not comply with this requirement." This is not required for interoperability and appears to prohibit the behavior of djbdns's axfr-get client. Section 3.6: "The slave MUST ignore any unexpected RRs in the additional section." Ditto. Section 4: "An RR is associated with a zone by being loaded from the master file of that zone at the primary master server, or by some other, equivalent method for configuring zone data." This is unclear. Neither djbdns's axfrdns server nor the UltraDNS server have a notion of "master files" or "zone data". This and the requirements based on this should be specified in terms of protocol behavior, not user interface. I did not do a full review of the BIND, UltraDNS, or djbdns implementations. There are likely more requirements that are violated by these popular implementations than I have noted here. I'd be happy to help someone who wants to do a more detailed review of the UltraDNS implementation. -- Aaron Swartz [http://www.aaronsw.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 Sun Nov 24 14:14:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01076 for ; Sun, 24 Nov 2002 14:14:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18G28d-000Ihm-00 for namedroppers-data@psg.com; Sun, 24 Nov 2002 11:09:51 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #2) id 18G28a-000Iha-00 for namedroppers@ops.ietf.org; Sun, 24 Nov 2002 11:09:48 -0800 Received: from amalthea.coyote.org ([192.168.242.14] helo=amalthea) by poledra with asmtp (Exim 3.35 #1 (Debian)) id 18G28X-0007hL-00 for ; Sun, 24 Nov 2002 20:09:45 +0100 Message-ID: <000c01c293ed$0d169070$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: Subject: Re: objection to axfr-clarify Date: Sun, 24 Nov 2002 20:09:24 +0100 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is unsurprisingly similar to the exact statements of a certain DNS server author, but I'll reply to it as if it's Mr Swartz own opinions. From: "Aaron Swartz" > Section 3: "If the master server is unable or unwilling to provide a > zone transfer, it MUST respond with a single DNS message containing an > appropriate RCODE other than NOERROR." This is not required for > interoperability and appears to prohibit the behavior of the UltraDNS > server and djbdns's axfrdns server. What's more logical? Client asks for data. Server responds with "Ok." and sends nothing. Client asks for data. Server responds with "Not allowed" and sends nothing. Client asks for data. Server doesn't respond whatsoever. Just because one or more implementations doesn't follow common courtesy doesn't mean that everyone should do the same. > Section 3.1: "MUST check the RCODE in each message and abort the > transfer if it is not NOERROR." This is not required for > interoperability and appears to prohibit the behavior of djbdns's > axfr-get client. Client asks for data. Server responds with "Whoa! Danger! Danger!" and sends something that might or might not resemble a zone. Just because DJB doesn't bother to make this trivial check doesn't mean that it's the best way to go. > Section 3.5: "Slaves MUST ignore any authority section contents they > may receive from masters that do not comply with this requirement." > This is not required for interoperability and appears to prohibit the > behavior of djbdns's axfr-get client. Once again, just because one implementation doesn't do this doesn't mean it's not the best way to go. > Section 3.6: "The slave MUST ignore any unexpected RRs in the > additional section." Ditto. Ditto. > Section 4: "An RR is associated with a zone by being loaded from the > master file of that zone at the primary master server, or by some > other, equivalent method for configuring zone data." This is unclear. > Neither djbdns's axfrdns server nor the UltraDNS server have a notion > of "master files" or "zone data". This and the requirements based on > this should be specified in terms of protocol behavior, not user > interface. Finally you point out an actual issue. While I haven't seen the UltraDNS server, I assume that it too has some kind of mechanism for loading RRs into its database. I also assume that it has some kind of mechanism for separating RRs into various zones. This is what this quote is refering to. The fact that DJBDNS doesn't use BIND-style zonefiles doesn't matter, since the section specifies "or by some other, equivalent method for configuring zone data" Now, besides the last section, do you have any actual operational arguments for objecting to the draft, besides objecting to it because two of the implementations you use don't follow it? Best regards, Kandra Nygards -- 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 Nov 24 15:19:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01764 for ; Sun, 24 Nov 2002 15:19:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18G35u-000KuA-00 for namedroppers-data@psg.com; Sun, 24 Nov 2002 12:11:06 -0800 Received: from [63.149.73.20] (helo=vorpal.notabug.com) by psg.com with smtp (Exim 3.36 #2) id 18G35s-000Ktt-00 for namedroppers@ops.ietf.org; Sun, 24 Nov 2002 12:11:04 -0800 Received: (qmail 24087 invoked from network); 24 Nov 2002 20:11:02 -0000 Received: from 12-249-96-16.client.attbi.com (HELO aaronsw.com) (12.249.96.16) by 0 with SMTP; 24 Nov 2002 20:11:02 -0000 Date: Sun, 24 Nov 2002 14:11:00 -0600 Subject: Re: objection to axfr-clarify Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: =?ISO-8859-1?Q?Kandra_Nyg=E5rds?= From: Aaron Swartz In-Reply-To: <000c01c293ed$0d169070$0ef2a8c0@amalthea> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Kandra. Thanks for your response. You wrote: > What's more logical? We can discuss what's more logical, but that's not the point. The document claims that in it "the existing practice has been codified in the interest of interoperability". This is obviously false. The vast majority of implementations do not do it this way (notably BIND8, djbdns and UltraDNS) and I've only heard reports that one does (BIND9). How can the actions of only one, recent application be the existing protocol? If I created a new piece of software, that sent email to namedroppers@ops.ietf.org whenever an unauthorized client connected, would the WG clarify the protocol to require that behavior? Even if the majority of deployed code *did* do things this way, RFC2119, a best current practice and a normative reference of this draft, expressly prohibits making requirements which are not necessary for interoperability. I haven't heard anyone explain why these are necessary for interoperability. Even if this *wasn't* a requirement, I've heard reasonable arguments for why a server wouldn't want to explain to unauthorized clients why they're unauthorized. Of course, that is not the issue here. Passing off what you feel as "better" or "more logical" as "the existing practice" when: 1. it clearly is not; 2. is not necessary for interoperability, in violation of a best current practice; and 3. is arguably not the consensus of the working group; seems highly misleading at best and downright dishonest at worst. My objections would be easily resolved if: - the draft suggested future implementations do these things; - the draft recommended current implementations be upgraded; or - the draft specified a new protocol on a different port; but it doesn't any of those. > Just because one or more implementations doesn't follow common courtesy > doesn't mean that everyone should do the same. Just because one or more implementations does provide a response doesn't mean that everyone should be required to do the same. > The fact that DJBDNS doesn't use BIND-style zonefiles doesn't matter, > since > the section specifies "or by some other, equivalent method for > configuring > zone data" It's completely unclear to me what to do in such a case. Is the djbdns method equivalent? I doubt it, since it has no system of specifying what's in what zone. But let's give you the benefit of the doubt and look at the actual requirements. "the master MUST send exactly those records that are associated with the zone" How am I supposed to calculate which are associated? "The slave MUST associate the RRs received in a zone transfer [...] and maintain that association" How am I supposed to associate them if my format has no provision for it? Why can't the draft explain the actual protocol behavior it wants? > do you have any actual operational arguments for objecting to the > draft, besides objecting to it because two of the implementations you > use don't follow it? You imply that those aren't "actual operational arguments". This clarification will lead future implementors to believe this is deployed practice (when as I've show it clearly is not), causing interoperability failure. That is not acceptable. -- Aaron Swartz [http://www.aaronsw.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 Mon Nov 25 10:12:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02595 for ; Mon, 25 Nov 2002 10:12:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GKlD-00078Y-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 07:02:55 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18GKlA-00078M-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 07:02:52 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAPF2pYm066474 for ; Mon, 25 Nov 2002 10:02:51 -0500 (EST) Received: from [192.149.252.235] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA20597 for ; Mon, 25 Nov 2002 10:02:48 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <2147483647.1038068410@macleod.hilander.com> References: <000f01c2932f$92542810$c57ba8c0@laptoy> <2147483647.1038058634@macleod.hilander.com> <20021123214339.GC6789@osprey.the-paynes.com> <2147483647.1038068410@macleod.hilander.com> Date: Mon, 25 Nov 2002 10:02:42 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: DNS Server DoS Attacks Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:20 -0700 11/23/02, Alec H. Peterson wrote: >So let me re-state in no un-certain terms my goal here, so that nobody can >imply anything that is not meant to be implied from my statements. > >My proposal (essentially a second TTL that keeps records around longer in the >event that authoritative servers are unable to answer) is _NOT_ >meant to be any >sort of 'solution' to DoS attacks. I feel that it is still incredibally >important for us to do everything that we can to secure the edge and >keep these >attacks from happening. > The problem with the proposal is that it breaks one goal of the DNS. DNS is a distributed database and as such needs to maintaining coherency in the answers it gives. The TTL is the main parameter that is available to allow caches (needed to alleviate high demand on authoritative servers and paths to them) to attempt to remain coherent. By instructing caches to hold data any longer than the TTL, you are making it less likely the DNS can maintain coherency. It is also important to note that the TTL is really the only way a zone, via an authoritative server, can inform remote caches of how often the zone expects to refresh the data. Masters and slaves have the SOA parameters to govern zone transfer schedules. The last parameter in the SOA is used for negative caching, and just that, in caches. If we were to add a second TTL (as in 'in emergency'), then a lot of other activity in DNS would be more complicated. E.g., in considering key roll over, we are trying to determine how much time should elapse before removing a key. The current calculation involves the TTL as part of an estimate as to when a key will completely disappear from the DNS. That's the more pragmatic answer as to why addressing DOS by encouraging caches to hold data longer should be discouraged. A more philosophical answer is that addressing security concerns should not overwhelm the main mission. No answer to a vulnerability should alter DNS's core goals, and database coherency is one of the most important. Since we often drop in to gross analogies when trying to dismiss an idea, I will include this one: This would be like amputating your hand so that that you won't break a finger. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 25 10:15:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02689 for ; Mon, 25 Nov 2002 10:15:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GKjA-00073k-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 07:00:48 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18GKj4-00073X-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 07:00:42 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gAPF0Lkw025408; Mon, 25 Nov 2002 07:00:21 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 07:00:40 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'D. J. Bernstein'" , namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks Date: Mon, 25 Nov 2002 07:00:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_001C_01C29469.81CE8EF0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.4 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C29469.81CE8EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Why not go the whole hog and transport the entire DNS system over Napster? Of course this would have some minor inconveniences, not least the fact that the assumed resilience of the other infrastructure might be imagined and none of the existing software would work. Anything at the application layer has a severe bootstrap problem. Hint, I don't type a raw IP address into my newsreader, I type nntp.attbi.com... Plus DoS attacks against NNTP are quite easy, particularly at the local level. The services are not configured as critical infrastructure. All it takes is one news server configured with a guest login account and that server canbe used to take down UESnet. Flood fill breaks both ways. Usenet is the biggest packet amplifier out there. Before chasing off with 'fixes' that change the whole architectural model I would like to know some information about the puported success of the attack. Specifically did any machines actually go down or was the reported 'unavailability' due to ISPs and others turning off ICMP responses? Several of the 'measurement' sites were using ping packets. This is a classic example of a reputation attack. We had one at the Whitehouse once. The router blew a fuse and before it was fixed a bunch of Russian hackers were claiming to Wired.com that they were responsible. First we need to get the measurement sites reconfigured so that they use an actual DNS query and not a PING packet. Second it would be useful to know which systems (if any) went down. To date I know the identity of 5 of the 4 servers that stayed up and do not know the identity of a single machine that went down. Then we should consider architectural approaches such as using anycast that allow DNS to be DoS proofed without disruption. Phill > -----Original Message----- > From: D. J. Bernstein [mailto:djb@cr.yp.to] > Sent: Sunday, November 24, 2002 4:27 AM > To: namedroppers@ops.ietf.org > Subject: Re: DNS Server DoS Attacks > > > [ post by non-subscriber. with the massive amount of spam, > it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Rob Payne writes: > > You want to turn the root zone into a signed "hosts.txt" (RFC 952, > > 953), and how, exactly does that scale > > I already answered that: ``Effects on load: Everybody will receive the > entire zone, rather than just the parts they need. On the other hand, > any sensible format would be much smaller than DNS packet format. More > importantly, the data will be cached much more effectively than it is > with the current root-zone protocol. Most importantly, the > load will be > very widely distributed.'' > > The last factor is, as I said, the most important one. USENET wouldn't > notice if ten copies of the root zone---or ten thousand copies---were > sent out every day. > > > it did not scale the last time > > Nobody really tried to make it scale, but this is beside the point. > ``Root zone'' does not mean ``complete list of Internet hosts.'' > > ---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: > ------=_NextPart_000_001C_01C29469.81CE8EF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyNTE1 MDAzOFowIwYJKoZIhvcNAQkEMRYEFH0UH9RUDLY+5qezdf/zgqZSXLA9MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAUdZ65th1VDMUEqh9nS5vQ/hV8yOuYcWexc33ktPmAG33amJP lXGlXC96dElwoSHSy7ryHy7I+ahj0443z7lFOr9u7VD1EiEy6MuKVPx49zqBaV541a8BJTPqtTbM m52uFOSJF0KS8JIZeqi0Sqtcm7yojJsjZPkKOVPlgOoGOl4AAAAAAAA= ------=_NextPart_000_001C_01C29469.81CE8EF0-- -- 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 Nov 25 11:50:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08183 for ; Mon, 25 Nov 2002 11:50:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GMFo-000BJ3-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 08:38:36 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18GMFh-000BIh-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 08:38:29 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAPGcSYm072541 for ; Mon, 25 Nov 2002 11:38:28 -0500 (EST) Received: from [192.149.252.235] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA13119 for ; Mon, 25 Nov 2002 11:38:27 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20021124091420.47876.qmail@cr.yp.to> References: <20021117211006.98837.qmail@cr.yp.to> <20021118033728.GA13838@codeblau.de> <20021119204308.52994.qmail@cr.yp.to> <20021122152754.A42609@k2r.org> <200211221929.gAMJTTg01260@guava.araneus.fi> <20021123125438.A55745@k2r.org> <200211240017.gAO0Hqt03238@guava.araneus.fi> <20021124091420.47876.qmail@cr.yp.to> Date: Mon, 25 Nov 2002 11:38:34 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: axfr-clarify on the move again Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,NO_OBLIGATION,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:14 +0000 11/24/02, D. J. Bernstein wrote: >RFC 1034 and RFC 1035 make crystal clear that record sets in the Domain >Name System at any moment are indexed by class+name+type. Nothing else. RFC 2181, Section 5.4.1., defines a differentiation between two RR sets matching the same {QNAME, QTYPE, QCLASS}. > 1. Consider, once again, client differentiation, or ``views'' in BIND > 9: some servers store data by class+name+type+clientIP. Everybody > else is free to assume that this doesn't happen. For example, a > cache that uses two IP addresses for its outgoing requests, and > receives different data under the same class+name+type on the two > IP addresses, is under absolutely no obligation to keep track of > both record sets. An implementation choice, not part of the DNS protocol. > 2. Consider, as a simpler example, the fact that different servers > for a zone can have different data. Everybody else is free to > assume that this doesn't happen. If I receive different record > sets from the two servers, under the same class+name+type, I can > use either one. I'm under no obligation to keep track of both > record sets. RFC 2181, Section 5.4.1. > 3. Finally, getting back to the situation under discussion: It's > certainly possible for a parent and a child to have different data > for the same class+name+type. But everybody else is free to assume > that this doesn't happen. If I receive different record sets from > the two servers, under the same class+name+type, I can use either > one. I'm under no obligation to keep track of both record sets. RFC 2181, Section 5.4.1. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Nov 25 11:51:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08321 for ; Mon, 25 Nov 2002 11:51:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GMIL-000BSG-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 08:41:13 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18GMIJ-000BS4-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 08:41:11 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18GMIJ-00013x-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 08:41:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200211251636.KAA21818@marut.quarterman.com> In-reply-to: Your message of "Mon, 25 Nov 2002 07:00:39 PST." From: "John S. Quarterman" To: "Hallam-Baker, Phillip" Cc: "John S. Quarterman" cc: "'D. J. Bernstein'" , namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks Date: Mon, 25 Nov 2002 10:36:57 -0600 X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > Second it would be useful to know which systems (if any) went down. To > date I know the identity of 5 of the 4 servers that stayed up and do not > know the identity of a single machine that went down. All 13 root DNS servers were up during the DDoS attack of 22-23 October 2002. 3 of them turned off ICMP ECHO responses, but were responding to DNS requests. There were side effects on Internet performance elsewhere. -jsq -- 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 Nov 25 12:14:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10411 for ; Mon, 25 Nov 2002 12:14:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GMf4-000CY7-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 09:04:42 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #2) id 18GMez-000CXZ-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 09:04:37 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id gAPH3c47014303; Mon, 25 Nov 2002 09:03:38 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Mon, 25 Nov 2002 09:04:34 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'John S. Quarterman'" , "Hallam-Baker, Phillip" Cc: "'D. J. Bernstein'" , namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks Date: Mon, 25 Nov 2002 09:04:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C2947A.CB035770" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.0 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C2947A.CB035770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I thought that was the most likely situation. There may also have been measurement problems due to ISPs turning off transport of ICMP pings and due to ICMP packets being preferentially dropped which would explain some of the measurements. I don't think the answer is to redesign DNS for several reasons, not least the fact that there are other critical infrastructures susceptible to DoS attack. What we need is some sort of mechanism for providing a trusted advertisement that a critical site is under DoS attack from specific (or non-specific) sources. Then we can start implementing successive blocking of the attack packets in the infrastructure. For example we could have DocSIS III have a filtering capability that could be turned on by the cable provider to block packets on specific ports to specific destinations. This would provide a cheap and lightweight handle for turning off machines that have been compromised and turned into a DDoS drone. Phill > -----Original Message----- > From: John S. Quarterman [mailto:jsq@matrix.net] > Sent: Monday, November 25, 2002 11:37 AM > To: Hallam-Baker, Phillip > Cc: John S. Quarterman; 'D. J. Bernstein'; namedroppers@ops.ietf.org > Subject: Re: DNS Server DoS Attacks > > > > Second it would be useful to know which systems (if any) > went down. To > > date I know the identity of 5 of the 4 servers that stayed > up and do not > > know the identity of a single machine that went down. > > All 13 root DNS servers were up during the DDoS attack of > 22-23 October 2002. > 3 of them turned off ICMP ECHO responses, but were responding > to DNS requests. > There were side effects on Internet performance elsewhere. > > -jsq > ------=_NextPart_000_0000_01C2947A.CB035770 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyNTE3 MDQyM1owIwYJKoZIhvcNAQkEMRYEFLV0CWlekMlcWzgPtvxOdzYhAIogMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAc3RGGEi26oo2mKWzUhitQP/j83s0I1iRkiKa2vFnwXtnmPot ZrR3jZQUCP3P0j85tRUBwlPT5Y0eerhXz6QQXrZHa41XV06r7J2cAQQ5Sf+9IW0PJ3HVMI/VvC1l kavCAhih4yq/pwHexFfv61+QRjV8YInP5c3BxEEtrQF+PFQAAAAAAAA= ------=_NextPart_000_0000_01C2947A.CB035770-- -- 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 Nov 25 12:23:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10993 for ; Mon, 25 Nov 2002 12:23:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GMow-000D3z-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 09:14:54 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18GMot-000D3n-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 09:14:51 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gAPHEWkw028093 for ; Mon, 25 Nov 2002 09:14:32 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 09:14:50 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks Date: Mon, 25 Nov 2002 09:14:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0012_01C2947C.3CB055C0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.8 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C2947C.3CB055C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Case in point as to why Prof Bernstein's hack is out to lunch. Like many folk Dan is running a spam filter that requests a respond receipt to verify an email. Unlike most folk however Dan's filter requests a response on every single message. One callback request is OK, every time is bad manners. Now I know that there are spams that hijack mailing list addresses to bypass such filters, but all my mail is signed for that reason. Whatever you think of the VeriSign CPS I think we can all agree that even a self signed cert should be sufficient in combination with a confirmation email and a VeriSign class 1 should be sufficient for spam filtering purposes. Dan's hack solves his problem fine but does not solve the problem for anyone else because it only solves the problem from one perspective. Phill ------=_NextPart_000_0012_01C2947C.3CB055C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyNTE3 MTQ0M1owIwYJKoZIhvcNAQkEMRYEFHgO+Wi512rFYUL7uazJF7p7UXnyMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGABKd9JIUN07YUEo/opJ3cVZSrZDx/VfGBBPsBje2UAPBIfW8n OqSdRC4RgN+iadkr8KTgUeMX9uvf3be0nlEe8qbriPiyn0Y8J7WdSYbX9vxrSbKZEmQzyyLGNsbo ZHrVA9lEhcvE/ui6s+HS4bg5F7poJWwdSYuGU+8sWKaOXEoAAAAAAAA= ------=_NextPart_000_0012_01C2947C.3CB055C0-- -- 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 Nov 25 12:23:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11020 for ; Mon, 25 Nov 2002 12:23:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GMpW-000D7c-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 09:15:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18GMpT-000D7Q-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 09:15:27 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18GMpT-0001Fc-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 09:15:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200211251713.LAA15909@dochalis.aus.us.mids.org> In-reply-to: Your message of "Mon, 25 Nov 2002 09:04:31 PST." From: "John S. Quarterman" To: "Hallam-Baker, Phillip" Cc: "John S. Quarterman" cc: "'D. J. Bernstein'" , namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks Date: Mon, 25 Nov 2002 11:13:13 -0600 X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] >I thought that was the most likely situation. > >There may also have been measurement problems due to ISPs turning off >transport of ICMP pings and due to ICMP packets being preferentially >dropped which would explain some of the measurements. Do you have evidence for either of those things? If not, it would be best not to base architecture on speculation. -jsq >> -----Original Message----- >> From: John S. Quarterman [mailto:jsq@matrix.net] >> Sent: Monday, November 25, 2002 11:37 AM >> To: Hallam-Baker, Phillip >> Cc: John S. Quarterman; 'D. J. Bernstein'; namedroppers@ops.ietf.org >> Subject: Re: DNS Server DoS Attacks >> >> >> > Second it would be useful to know which systems (if any) >> went down. To >> > date I know the identity of 5 of the 4 servers that stayed >> up and do not >> > know the identity of a single machine that went down. >> >> All 13 root DNS servers were up during the DDoS attack of >> 22-23 October 2002. >> 3 of them turned off ICMP ECHO responses, but were responding >> to DNS requests. >> There were side effects on Internet performance elsewhere. >> >> -jsq -- 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 Nov 25 12:35:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11822 for ; Mon, 25 Nov 2002 12:35:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GN1X-000DkM-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 09:27:55 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18GN1S-000Dk7-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 09:27:50 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gAPHRSkw000872; Mon, 25 Nov 2002 09:27:29 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 09:27:47 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'John S. Quarterman'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks Date: Mon, 25 Nov 2002 09:27:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0017_01C2947E.08BA6A60" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C2947E.08BA6A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit John, I assert that unless you know for certain that the measurements are not contaminated in the manner hypothesised that you would be operating on speculation by accepting them at face value. The onus of proof is generally held to be on the observation. The only exception being cases like holocaust denial, moon landing hoax conspiracy theories and claims that OJ was innocent where the objections to the evidence require a vast number of other assumptions to be made. The figures you give, 3 servers turned off ICMP do not match the measurements reported in the press (9 servers down) or my reading of the measurement sites at the time. Ergo it appears that either more sites turned off ICMP than you report or some network operations decision or network related effect, probably due to congenstion may have occured. Of course there may be yet another reason. Phill > -----Original Message----- > From: John S. Quarterman [mailto:jsq@matrix.net] > Sent: Monday, November 25, 2002 12:13 PM > To: Hallam-Baker, Phillip > Cc: John S. Quarterman; 'D. J. Bernstein'; namedroppers@ops.ietf.org > Subject: Re: DNS Server DoS Attacks > > > >I thought that was the most likely situation. > > > >There may also have been measurement problems due to ISPs turning off > >transport of ICMP pings and due to ICMP packets being preferentially > >dropped which would explain some of the measurements. > > Do you have evidence for either of those things? > If not, it would be best not to base architecture on speculation. > > -jsq > > >> -----Original Message----- > >> From: John S. Quarterman [mailto:jsq@matrix.net] > >> Sent: Monday, November 25, 2002 11:37 AM > >> To: Hallam-Baker, Phillip > >> Cc: John S. Quarterman; 'D. J. Bernstein'; > namedroppers@ops.ietf.org > >> Subject: Re: DNS Server DoS Attacks > >> > >> > >> > Second it would be useful to know which systems (if any) > >> went down. To > >> > date I know the identity of 5 of the 4 servers that stayed > >> up and do not > >> > know the identity of a single machine that went down. > >> > >> All 13 root DNS servers were up during the DDoS attack of > >> 22-23 October 2002. > >> 3 of them turned off ICMP ECHO responses, but were responding > >> to DNS requests. > >> There were side effects on Internet performance elsewhere. > >> > >> -jsq > ------=_NextPart_000_0017_01C2947E.08BA6A60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyNTE3 MjczNVowIwYJKoZIhvcNAQkEMRYEFL08PunhauzbVEI5jB/gIKQZlqb1MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGADsSKp/9/XXkP06VzCXT1rdYjFeW1BLY838dhAwu5U3tk/2sh vKcN69BlAnkxTy39wbEv9jbdtrmOP4spZJX1AaT3ClVpnEqqBGhtSeXEUdH5wHFKL7V32hywwwll RQ3Vh3Ngt0vkSD2/XVyVLGd8lBj+73BprPxsxu4vXqJ4RB8AAAAAAAA= ------=_NextPart_000_0017_01C2947E.08BA6A60-- -- 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 Nov 25 12:49:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12822 for ; Mon, 25 Nov 2002 12:49:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GNG8-000EYu-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 09:43:00 -0800 Received: from vim.quarterman.com ([206.225.33.194] helo=quarterman.com ident=[Cy2i5fkpTBT0ygF6It3HUSZFhWr1Ii/W]) by psg.com with esmtp (Exim 3.36 #2) id 18GNG3-000EYV-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 09:42:55 -0800 Received: from marut.quarterman.com (marut [192.168.1.8]) by quarterman.com (8.11.6/8.11.0) with ESMTP id gAPHgmD27912; Mon, 25 Nov 2002 11:42:48 -0600 Received: from marut.quarterman.com (localhost [127.0.0.1]) by marut.quarterman.com (8.9.3/8.9.3) with ESMTP id LAA22241; Mon, 25 Nov 2002 11:42:37 -0600 Message-Id: <200211251742.LAA22241@marut.quarterman.com> From: "John S. Quarterman" To: "Hallam-Baker, Phillip" cc: "'John S. Quarterman'" , namedroppers@ops.ietf.org Subject: Re: DNS Server DoS Attacks In-reply-to: Your message of "Mon, 25 Nov 2002 09:27:45 PST." Date: Mon, 25 Nov 2002 11:42:37 -0600 X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Phill, > I assert that unless you know for certain that the measurements > are not contaminated in the manner hypothesised that you would be > operating on speculation by accepting them at face value. > > The onus of proof is generally held to be on the observation. I'm having a little trouble with this logic. You made two speculations, with no evidence, and now you wish to shift the burden of proof for those speculations to someone else? > The only exception being cases like holocaust denial, moon > landing hoax conspiracy theories and claims that OJ was innocent where > the objections to the evidence require a vast number of other > assumptions to be made. > > The figures you give, 3 servers turned off ICMP do not match the > measurements reported in the press (9 servers down) or my reading of the > measurement sites at the time. Ergo it appears that either more sites > turned off ICMP than you report I have data showing regular ping responses from the other 10 DNS roots during that period, as well as regular ping attempts to the 3 that stopped responding to ping, plus direct correspondence with the operators of those 3. > or some network operations decision or > network related effect, probably due to congenstion may have occured. > Of course there may be yet another reason. Indeed. One could speculate any number of potential causes for any effect. The burden of proof would be on the person so speculating. If you have concrete evidence for your speculations, please cite it; otherwise, we might as well move on. > Phill -jsq > > -----Original Message----- > > From: John S. Quarterman [mailto:jsq@matrix.net] > > Sent: Monday, November 25, 2002 12:13 PM > > To: Hallam-Baker, Phillip > > Cc: John S. Quarterman; 'D. J. Bernstein'; namedroppers@ops.ietf.org > > Subject: Re: DNS Server DoS Attacks > > > > > > >I thought that was the most likely situation. > > > > > >There may also have been measurement problems due to ISPs turning off > > >transport of ICMP pings and due to ICMP packets being preferentially > > >dropped which would explain some of the measurements. > > > > Do you have evidence for either of those things? > > If not, it would be best not to base architecture on speculation. > > > > -jsq > > > > >> -----Original Message----- > > >> From: John S. Quarterman [mailto:jsq@matrix.net] > > >> Sent: Monday, November 25, 2002 11:37 AM > > >> To: Hallam-Baker, Phillip > > >> Cc: John S. Quarterman; 'D. J. Bernstein'; > > namedroppers@ops.ietf.org > > >> Subject: Re: DNS Server DoS Attacks > > >> > > >> > > >> > Second it would be useful to know which systems (if any) > > >> went down. To > > >> > date I know the identity of 5 of the 4 servers that stayed > > >> up and do not > > >> > know the identity of a single machine that went down. > > >> > > >> All 13 root DNS servers were up during the DDoS attack of > > >> 22-23 October 2002. > > >> 3 of them turned off ICMP ECHO responses, but were responding > > >> to DNS requests. > > >> There were side effects on Internet performance elsewhere. > > >> > > >> -jsq > > > -- 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 Nov 25 13:04:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13857 for ; Mon, 25 Nov 2002 13:04:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GNV7-000FJI-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 09:58:29 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18GNV1-000FJ0-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 09:58:23 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gAPHw1kw011119; Mon, 25 Nov 2002 09:58:01 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 09:58:20 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'John S. Quarterman'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks Date: Mon, 25 Nov 2002 09:58:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0028_01C29482.4D93B3E0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.3 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C29482.4D93B3E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > I'm having a little trouble with this logic. You made two > speculations, > with no evidence, and now you wish to shift the burden of proof for > those speculations to someone else? It depends what you consider the hypothesis to be. The one I thought we were considering was the statements made by the measurement sites. I was pointing out that they can be contaminated by a number of sources. That is why I said that "There may also have been measurement problems..." If I had intended to claim that the effects hypothesised definitively happened I would have said "There were also". Try reading before you flame. The measurements from the measurement sites plus your own observations show a discrepancy. The measurement sites I saw had something like 7 sites offline. You say you have data showing responses from 10 of the servers. Thus there is a discrepancy of 4 servers to be accounted for and an indication that the effect was dependent on the observation point. The precise cause of the result is irrelevant, the only conclusions we can draw are that the measurements from the sites were not sound and that we should build measurement systems that are not subject to the possible sources of contamination described. Phill ------=_NextPart_000_0028_01C29482.4D93B3E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyNTE3 NTgwOFowIwYJKoZIhvcNAQkEMRYEFGugyoC/3KeohfJ+o2GwajVuNx17MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAqrQ8ar5bMABkc6dKS9GePdePIucKW8ZISu4lfXGGs3nf4oEh qWDKXTP9dPk+FZ6EdaNISdPaoot+Gm2w+EInpg9mSgLTmEfrnBvzYgTW5X/amif3oTZ30JceGr7c A0XJyzX7sJkIAEXEK6gTkCQD6PfkOfCETmBXOOk1BoAt/MIAAAAAAAA= ------=_NextPart_000_0028_01C29482.4D93B3E0-- -- 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 Nov 25 13:19:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15065 for ; Mon, 25 Nov 2002 13:19:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GNm4-000GKg-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 10:16:00 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18GNla-000GJn-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 10:15:30 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18GNla-0001ab-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 10:15:30 -0800 Message-ID: <20021125174457.28844.qmail@cr.yp.to> References: <20021117211006.98837.qmail@cr.yp.to> <20021118033728.GA13838@codeblau.de> <20021119204308.52994.qmail@cr.yp.to> <20021122152754.A42609@k2r.org> <200211221929.gAMJTTg01260@guava.araneus.fi> <20021123125438.A55745@k2r.org> <200211240017.gAO0Hqt03238@guava.araneus.fi> <20021124091420.47876.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 25 Nov 2002 17:44:57 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify on the move again X-Spam-Status: No, hits=2.4 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Edward Lewis writes: > RFC 2181, Section 5.4.1., defines a differentiation between two RR > sets matching the same {QNAME, QTYPE, QCLASS}. Learn to read. RFC 2181 is completely consistent with what I said. It does _not_ require anybody to keep track of two record sets under the same class+name+type. On the contrary: RFC 2181 suggests a particular strategy for deciding which record set to throw away. The core of that strategy is choosing child data over parent data, which is exactly what I tell AXFR users to do. I don't mean to suggest that I approve of (elective proposed standard) RFC 2181. On the contrary: several parts of it, including this strategy over-specification, are implementation details whose standardization blatantly violates RFC 2119, and some parts of it are really bad ideas. But it certainly doesn't contradict what I'm saying about axfr-clarify. ---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 Nov 25 13:56:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17349 for ; Mon, 25 Nov 2002 13:56:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GOHq-000I76-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 10:48:50 -0800 Received: from vim.quarterman.com ([206.225.33.194] helo=quarterman.com ident=[+cXLqGYEfxJ86wpm/SkweAydJT9kCn5n]) by psg.com with esmtp (Exim 3.36 #2) id 18GOHl-000I6m-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 10:48:46 -0800 Received: from marut.quarterman.com (marut [192.168.1.8]) by quarterman.com (8.11.6/8.11.0) with ESMTP id gAPImbD28380; Mon, 25 Nov 2002 12:48:37 -0600 Received: from marut.quarterman.com (localhost [127.0.0.1]) by marut.quarterman.com (8.9.3/8.9.3) with ESMTP id MAA22500; Mon, 25 Nov 2002 12:48:25 -0600 Message-Id: <200211251848.MAA22500@marut.quarterman.com> From: "John S. Quarterman" To: namedroppers@ops.ietf.org cc: "'John S. Quarterman'" Subject: Re: DNS Server DoS Attacks In-reply-to: Your message of "Mon, 25 Nov 2002 09:58:16 PST." Date: Mon, 25 Nov 2002 12:48:25 -0600 X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jon Postel used to have a rule that no one should post to namedroppers more than once a day. The wisdom of that rule has become evident in this thread. This will be my last post on this subject today. > The measurements from the measurement sites plus your own observations > show a discrepancy. The measurement sites I saw had something like 7 > sites > offline. You say you have data showing responses from 10 of the servers. > > Thus there is a discrepancy of 4 servers to be accounted for and an > indication that the effect was dependent on the observation point. As I said, I have regular responses during that period from 10 DNS root servers and regular pings with no responses for the other 3. I think 10 + 3 = 13 total root DNS servers. The data I am referring to was publicly visible at the time via http://average.matrix.net/dns-root/ That data for each DNS root server was collected from half a dozen different observation points, not one. It's hard to tell what you mean by "the measurement sites". I'd be happy hold a conversation about them, but that's not possible without any specifics. > The precise cause of the result is irrelevant, the only conclusions we > can draw are that the measurements from the sites were not sound and > that we should build measurement systems that are not subject to the > possible sources of contamination described. Indeed, we took such considerations into account when we constructed our services. I don't know about "the sites". > Phill -jsq -- 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 Nov 25 15:44:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24392 for ; Mon, 25 Nov 2002 15:44:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GPv2-000NQn-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 12:33:24 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18GPuy-000NQQ-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 12:33:20 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gAPKWukw001650; Mon, 25 Nov 2002 12:33:00 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 12:33:14 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'John S. Quarterman'" , namedroppers@ops.ietf.org Subject: RE: DNS Server DoS Attacks Date: Mon, 25 Nov 2002 12:33:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01C29497.F2364290" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.0 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C29497.F2364290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Indeed, we took such considerations into account when we constructed > our services. I don't know about "the sites". In which case we have to work out why the press either got hold of the wrong figures or misinterpreted the figures and used those as the basis of the Associated Press and Reuters reports. By design or chance someone managed a reputation attack against the system that reached the mainstream media and resulted in senior policy people calling CEOs etc. That is a major problem. Media management must be a part of the solution. Phill ------=_NextPart_000_0055_01C29497.F2364290 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyNTIw MzMwNFowIwYJKoZIhvcNAQkEMRYEFG3k1k+TgNzxe3OuwIGiNeRKkcJDMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAF7WWGAoIlI8i/lF0QNKGmCBEfzAgNPcikj9ZLNfbuO7xgvJ2 HADmP6Ez14A3VnUTPDIUqVCzUELndF3BtYQbxS2UtP2rLXU4nh5fk658APUnkQQno9IOzFYxh5TP VGzEdMkTyZVa3QAZ/PFo6C4eD6AqxQYIlfNZULTzsY8xVSEAAAAAAAA= ------=_NextPart_000_0055_01C29497.F2364290-- -- 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 Nov 25 18:40:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01214 for ; Mon, 25 Nov 2002 18:40:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GSaE-0006e6-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 15:24:06 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18GSaB-0006dt-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 15:24:03 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gAPNNxn08206; Mon, 25 Nov 2002 15:23:59 -0800 (PST) Date: Mon, 25 Nov 2002 15:23:59 -0800 (PST) Message-Id: <200211252323.gAPNNxn08206@guava.araneus.fi> To: Aaron Swartz CC: Kandra Nygårds , Subject: Re: objection to axfr-clarify In-Reply-To: References: <000c01c293ed$0d169070$0ef2a8c0@amalthea> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Aaron Swartz writes: > Hi, Kandra. Thanks for your response. > > You wrote: > > What's more logical? > > We can discuss what's more logical, but that's not the point. The > document claims that in it "the existing practice has been codified in > the interest of interoperability". This is obviously false. You are quoting the draft out of context. It says: Where the text in RFC1034 conflicts with existing practice, the existing practice has been codified in the interest of interoperability. The only part of the draft that claims there is a conflict between RFC1034 and existing practice is the first two sentences of section 5, "transmission order". The text you quoted is intended as a reference specifically to that part. If this is unclear, I will be happy to change the text to make the reference to section 5 explicit. > The vast > majority of implementations do not do it this way (notably BIND8, > djbdns and UltraDNS) and I've only heard reports that one does (BIND9). > How can the actions of only one, recent application be the existing > protocol? You are incorrect regarding both BIND 8 and UltraDNS - they both "respond with a single DNS message containing an appropriate RCODE other than NOERROR" as the draft specifies. I didn't dare try to run BIND 4.8.3, but inspection of the code suggests that it does the same thing, meaning this behavior is established practice at least since 1990. > RFC2119, a best current practice and a normative reference of this > draft, expressly prohibits making requirements which are not necessary > for interoperability. I haven't heard anyone explain why these are > necessary for interoperability. Although you are correct in that requiring a response to be sent in an error case is not necessary for interoperability in the sense of being able to successfully complete a zone transfer, it is necessary in order to have an interoperable means of indicating the reason for failure. This text was discussed at length on namedroppers in April 2001 and I believe the current text reflects the rough consensus of the working group at that time. At one time during that discussion I proposed changing the MUST to a SHOULD, but Robert Elz specifically requested that I retain the MUST. As for the other issue you raised, I thought this had already been adequately covered by my response to DJB's message, but here we go anyway... > > The fact that DJBDNS doesn't use BIND-style zonefiles doesn't matter, > > since > > the section specifies "or by some other, equivalent method for > > configuring > > zone data" > > It's completely unclear to me what to do in such a case. Is the djbdns > method equivalent? I doubt it, since it has no system of specifying > what's in what zone. But let's give you the benefit of the doubt and > look at the actual requirements. > > "the master MUST send exactly those records that are associated with > the zone" How am I supposed to calculate which are associated? If you received the zone by AXFR, it's what you received in that AXFR (as opposed to what you received in AXFRs of other zones). If you are the primary master and load from a master file, it's what you loaded from that master file (as opposed to other master files). If you are the primary master and using some other configuration method, it's entirely up to you how you define the association; the point is that you must be able to unambigously say which records are part of which zone (or zones, in the case of a djbdns-like mechanism where a record can be configured into two zones at once) for the purpose of outgoing transfers. > "The slave MUST associate the RRs received in a zone transfer [...] and > maintain that association" How am I supposed to associate them if my > format has no provision for it? What do you mean by "your format"? A file format? If your server stores the data from incoming zone transfers in files, then it must either store each zone in a separate file, or if they are stored in a common file, the file format must have a provision for keeping the data separate. > Why can't the draft explain the actual protocol behavior it wants? It is trying to. The use of the term "associated with" may be a bit confusing, but previous attempts at phrasing it using more common terms like "the records of a zone" or "in a zone" were objected to on the basis that there were existing, conflicting definitions of those terms based on the viewpoint of the resolver rather than the server; e.g., a resolver may consider an NS record to be "in" a child zone even though it was received from a parent server that loaded it from the master file of the parent zone. Suggestions for clearer terminology are welcome. -- 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 Mon Nov 25 22:37:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07944 for ; Mon, 25 Nov 2002 22:37:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GWN6-000Kkc-00 for namedroppers-data@psg.com; Mon, 25 Nov 2002 19:26:48 -0800 Received: from mx04.gis.net ([208.218.130.12] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18GWN4-000KkQ-00 for namedroppers@ops.ietf.org; Mon, 25 Nov 2002 19:26:46 -0800 Received: from tecotoo.www.gis.net ([63.214.89.69]) by mx04.gis.net; Mon, 25 Nov 2002 22:26:43 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id xa029351 for ; Mon, 25 Nov 2002 22:28:24 -0500 Message-Id: <4.3.1.2.20021125222352.037d1850@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 25 Nov 2002 22:28:07 -0500 To: "Hallam-Baker, Phillip" , "'John S. Quarterman'" , namedroppers@ops.ietf.org From: Danny Mayer Subject: RE: DNS Server DoS Attacks In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-1.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:33 PM 11/25/02, Hallam-Baker, Phillip wrote: > > Indeed, we took such considerations into account when we constructed > > our services. I don't know about "the sites". > >In which case we have to work out why the press either got hold of the >wrong figures or misinterpreted the figures and used those as the basis >of the Associated Press and Reuters reports. This has nothing to do with namedroppers. You can't control where the agencies and the newspapers get their information. >By design or chance someone managed a reputation attack against the >system >that reached the mainstream media and resulted in senior policy people >calling CEOs etc. That is a major problem. Media management must be a >part of the solution. I've almost never seen a newspaper article on something for which I have direct personal knowledge get it right. However, this is not a TECHNICAL problem, it's a management problem. You're asking in the wrong forum. Danny > 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 Tue Nov 26 07:05:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28019 for ; Tue, 26 Nov 2002 07:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GeIL-000KW9-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 03:54:25 -0800 Received: from mail0.epfl.ch ([128.178.50.57]) by psg.com with smtp (Exim 3.36 #2) id 18GeIH-000KVF-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 03:54:22 -0800 Received: (qmail 16585 invoked from network); 26 Nov 2002 11:54:12 -0000 Received: from icmbpc140.epfl.ch (HELO pc22) (128.178.55.185) by mail0.epfl.ch with SMTP; 26 Nov 2002 11:54:12 -0000 From: Heinrich Mendelssohn Date: Tue, 26 Nov 2002 12:53:47 +0100 To: namedroppers@ops.ietf.org Subject: Re: Your friend's DNS User-Agent: Microsoft-Entourage/10.1.1.2418 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bi X-Spam-Status: No, hits=4.6 required=5.0 tests=FORGED_HOTMAIL_RCVD,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,SPAM_PHRASE_00_01,TO_HAS_SPACES, USER_AGENT,USER_AGENT_ENTOURAGE version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bi It seems that CH, the ccTLD for Switzerland, was listed as non-existant during a few hours on Monday November 25, 2002 by A.ROOT-SERVERS.NET, as well as all the other ROOT-SERVERS.NET servers I checked. I noticed the problem as suddenly a lot of .ch domains became unresolvable and e-mails started to bounce... The CH ccTLD was relisted again by A.ROOT-SERVERS.NET at about 14:55 GMT on November 25. Did anyone this, or know what happened ? A human error at VeriSign ? Have other ccTLDs been affected ? Just curious, Heinrich Mendelssohn -- 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 Nov 26 09:35:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02980 for ; Tue, 26 Nov 2002 09:35:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ggi4-0001Nj-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 06:29:08 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Gghd-0001NN-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 06:28:41 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Gghb-000Cg9-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 06:28:39 -0800 Message-ID: <20021126114942.79397.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 26 Nov 2002 11:49:42 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: namedroppers mismanagement, continued X-Spam-Status: No, hits=3.7 required=5.0 tests=NO_MX_FOR_FROM,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: *** 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] I've sent twelve messages to the namedroppers mailing list this month. Five of them have been silently discarded by the namedroppers censor, Randy Bush. (See http://cr.yp.to/djbdns/namedroppers.html for previous incidents.) Bush says that the only relevant feature of my messages is that they're sent from an address that isn't subscribed to namedroppers. Okay, boys and girls, let's look at some statistics: * 5/12 of my messages have been silently discarded; * according to Bush, this has nothing to do with me or the content, so we estimate that about 5/12 of all non-subscriber messages have been silently discarded; * in the past three months, there have been about 100 legitimate messages from other people who Bush labelled as non-subscribers; * so we estimate that, in the last three months, Bush has silently discarded about 71 legitimate messages from other people. That's a rate of hundreds per year. Bush doesn't say ``Your message didn't go through.'' Bush doesn't say ``Reply to this bounce to confirm your original message.'' He simply throws the message away. This is supposed to be the mailing list for an open IETF working group. It's outrageous that valid messages are being silently discarded---even if the number is not as large as hundreds per year. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago P.S. Out of my twelve messages, the five that were silently discarded are exactly the five that I would pick if I were a censor trying to bias the DNSEXT decisions in favor of the BIND company. Coincidence, right? P.P.S. Bush's mailing-list software doesn't cryptographically confirm unsubscription requests. I kept my subscription address private until Bush revealed it a few days ago. I'm working on obtaining a subscription through an address that Bush doesn't know is connected to me. -- 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 Nov 26 09:37:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03050 for ; Tue, 26 Nov 2002 09:37:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GglP-0001Zh-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 06:32:35 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18GglM-0001ZV-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 06:32:32 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18GglL-000CgS-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 06:32:31 -0800 Message-ID: <20021126121325.GF6588@newman.frascone.com> References: <20021126114942.79397.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021126114942.79397.qmail@cr.yp.to> Date: Tue, 26 Nov 2002 06:13:26 -0600 From: David Frascone To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued X-Spam-Status: No, hits=-3.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02 version=2.43 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 mis-posts. so fix subscription addresses! ] Why not simply subscribe and resend? As a maintainer of several lists, I can confirm what a royal pain it is to deal with people posting from non-subscribed addresses. I usually get 1-2 a week as I'm sorting through the 10-15 SPAMs a day. I'm sure I mistakenly reject many of them. Just my $.02 worth, -Dave On Tuesday, 26 Nov 2002, D. J. Bernstein wrote: > I've sent twelve messages to the namedroppers mailing list this month. > Five of them have been silently discarded by the namedroppers censor, > Randy Bush. (See http://cr.yp.to/djbdns/namedroppers.html for previous > incidents.) > > Bush says that the only relevant feature of my messages is that they're > sent from an address that isn't subscribed to namedroppers. Okay, boys > and girls, let's look at some statistics: > > * 5/12 of my messages have been silently discarded; > > * according to Bush, this has nothing to do with me or the content, > so we estimate that about 5/12 of all non-subscriber messages have > been silently discarded; > > * in the past three months, there have been about 100 legitimate > messages from other people who Bush labelled as non-subscribers; > > * so we estimate that, in the last three months, Bush has silently > discarded about 71 legitimate messages from other people. That's a > rate of hundreds per year. > > Bush doesn't say ``Your message didn't go through.'' Bush doesn't say > ``Reply to this bounce to confirm your original message.'' He simply > throws the message away. > > This is supposed to be the mailing list for an open IETF working group. > It's outrageous that valid messages are being silently discarded---even > if the number is not as large as hundreds per year. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > P.S. Out of my twelve messages, the five that were silently discarded > are exactly the five that I would pick if I were a censor trying to bias > the DNSEXT decisions in favor of the BIND company. Coincidence, right? > > P.P.S. Bush's mailing-list software doesn't cryptographically confirm > unsubscription requests. I kept my subscription address private until > Bush revealed it a few days ago. I'm working on obtaining a subscription > through an address that Bush doesn't know is connected to me. > -- David Frascone My karma ran over my dogma -- 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 Nov 26 09:48:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03688 for ; Tue, 26 Nov 2002 09:48:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ggsy-000217-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 06:40:24 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18Ggsv-00020V-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 06:40:21 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQEd3l19320; Tue, 26 Nov 2002 09:39:03 -0500 (EST) Message-Id: <200211261439.gAQEd3l19320@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued In-reply-to: (Your message of "26 Nov 2002 11:49:42 GMT.") <20021126114942.79397.qmail@cr.yp.to> Date: Tue, 26 Nov 2002 09:39:03 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I've sent twelve messages to the namedroppers mailing list this month. > Five of them have been silently discarded by the namedroppers censor, > Randy Bush. (See http://cr.yp.to/djbdns/namedroppers.html for previous > incidents.) in my experience, if you send mail to the list administrator and say "please add user@example.com as an address that is allowed to post to this list", the problem goes away - for that list. and no, I don't think that one should have to "say the secret magic words" to make the right thing happen. but it does seem to work in practice. Keith -- 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 Nov 26 10:09:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04953 for ; Tue, 26 Nov 2002 10:09:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GhDf-0003Bt-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 07:01:47 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #2) id 18GhDb-0003Bh-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 07:01:43 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id gAQF0j47015522; Tue, 26 Nov 2002 07:00:45 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Tue, 26 Nov 2002 07:01:42 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'D. J. Bernstein'" Cc: namedroppers@ops.ietf.org Subject: RE: namedroppers mismanagement, continued Date: Tue, 26 Nov 2002 07:01:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007E_01C29532.D0485560" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.1 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_007E_01C29532.D0485560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I can't say that I am the worlds greatest Randy Bush fan, but he does not appear to be behaving in the manner indicated. I strongly suspect that the cause of this problem is more likely to be found in Bersnsteins obnoxious qsecretary program which requests repeated confirmation of emails sent to Bernstein. The obvious solution to this problem would be to subscribe the address to namedroppers and then use the majordomo option to stop sending the messages. Phill > -----Original Message----- > From: D. J. Bernstein [mailto:djb@cr.yp.to] > Sent: Tuesday, November 26, 2002 6:50 AM > To: ietf@ietf.org > Cc: iesg@ietf.org; namedroppers@ops.ietf.org > Subject: namedroppers mismanagement, continued > > > [ post by non-subscriber. with the massive amount of spam, > it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > I've sent twelve messages to the namedroppers mailing list this month. > Five of them have been silently discarded by the namedroppers censor, > Randy Bush. (See http://cr.yp.to/djbdns/namedroppers.html for previous > incidents.) > > Bush says that the only relevant feature of my messages is > that they're > sent from an address that isn't subscribed to namedroppers. Okay, boys > and girls, let's look at some statistics: > > * 5/12 of my messages have been silently discarded; > > * according to Bush, this has nothing to do with me or the content, > so we estimate that about 5/12 of all non-subscriber > messages have > been silently discarded; > > * in the past three months, there have been about 100 legitimate > messages from other people who Bush labelled as non-subscribers; > > * so we estimate that, in the last three months, Bush has silently > discarded about 71 legitimate messages from other > people. That's a > rate of hundreds per year. > > Bush doesn't say ``Your message didn't go through.'' Bush doesn't say > ``Reply to this bounce to confirm your original message.'' He simply > throws the message away. > > This is supposed to be the mailing list for an open IETF > working group. > It's outrageous that valid messages are being silently > discarded---even > if the number is not as large as hundreds per year. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > P.S. Out of my twelve messages, the five that were silently discarded > are exactly the five that I would pick if I were a censor > trying to bias > the DNSEXT decisions in favor of the BIND company. Coincidence, right? > > P.P.S. Bush's mailing-list software doesn't cryptographically confirm > unsubscription requests. I kept my subscription address private until > Bush revealed it a few days ago. I'm working on obtaining a > subscription > through an address that Bush doesn't know is connected to me. > > > > -- > 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: > ------=_NextPart_000_007E_01C29532.D0485560 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyNjE1 MDEzOVowIwYJKoZIhvcNAQkEMRYEFCyIDFULuUaVGeHOZSXI28dhZ9yeMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAAYfXztMW0tyupARSbjXt2fmmIWXIBUM/Tzd/sbxe91cs6w0T U5/nVj2m0J3vik0wJ8Bkx/7BeeP4jUXiTvVLuaWcM2F6ybWAJMDXsqRW0cKjGOUtmQ6DDf/K08np xfxqQvJrrodWKK+w7JtuF4jEMKJ/jM+e+hOopihh5wXAhnsAAAAAAAA= ------=_NextPart_000_007E_01C29532.D0485560-- -- 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 Nov 26 10:30:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06226 for ; Tue, 26 Nov 2002 10:30:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ghc9-0004X5-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 07:27:05 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18Ghc6-0004Wk-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 07:27:02 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id ED88237A037 for ; Tue, 26 Nov 2002 15:27:01 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Your friend's DNS In-Reply-To: Message from Heinrich Mendelssohn of "Tue, 26 Nov 2002 12:53:47 +0100." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 26 Nov 2002 15:27:01 +0000 Message-Id: <20021126152701.ED88237A037@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It seems that CH, the ccTLD for Switzerland, was listed as non-existant > during a few hours on Monday November 25, 2002 by A.ROOT-SERVERS.NET, as > well as all the other ROOT-SERVERS.NET servers I checked. while i share your alarm that the data was missing, i am both relieved and gratified that it was consistently missing. all of the root servers offer the same data all the time, subject only to axfr delays and soa parameters. -- 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 Nov 26 10:31:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06273 for ; Tue, 26 Nov 2002 10:31:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GhZW-0004LB-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 07:24:22 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18GhZT-0004Kt-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 07:24:19 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18GhZS-000Ck9-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 07:24:18 -0800 In-Reply-To: <20021126114942.79397.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 26 Nov 2002 09:34:54 -0500 (EST) From: Joe Baptista To: "D. J. Bernstein" cc: , , Subject: Re: namedroppers mismanagement, continued X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 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 mis-posts. so fix subscription addresses! ] Bernstein - I'm not surprised this is happening. I've experimented with your dns daemon and it is by far superior to the existing bind implimentations. So I'm frankly not very surprised Bush don't like your posts. But I will admit the behaviour is juvenile. But again this should not surprise us. But to end this on a positive note - let me make clear I admire your work. regards joe baptista On 26 Nov 2002, D. J. Bernstein wrote: > I've sent twelve messages to the namedroppers mailing list this month. > Five of them have been silently discarded by the namedroppers censor, > Randy Bush. (See http://cr.yp.to/djbdns/namedroppers.html for previous > incidents.) > > Bush says that the only relevant feature of my messages is that they're > sent from an address that isn't subscribed to namedroppers. Okay, boys > and girls, let's look at some statistics: > > * 5/12 of my messages have been silently discarded; > > * according to Bush, this has nothing to do with me or the content, > so we estimate that about 5/12 of all non-subscriber messages have > been silently discarded; > > * in the past three months, there have been about 100 legitimate > messages from other people who Bush labelled as non-subscribers; > > * so we estimate that, in the last three months, Bush has silently > discarded about 71 legitimate messages from other people. That's a > rate of hundreds per year. > > Bush doesn't say ``Your message didn't go through.'' Bush doesn't say > ``Reply to this bounce to confirm your original message.'' He simply > throws the message away. > > This is supposed to be the mailing list for an open IETF working group. > It's outrageous that valid messages are being silently discarded---even > if the number is not as large as hundreds per year. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > P.S. Out of my twelve messages, the five that were silently discarded > are exactly the five that I would pick if I were a censor trying to bias > the DNSEXT decisions in favor of the BIND company. Coincidence, right? > > P.P.S. Bush's mailing-list software doesn't cryptographically confirm > unsubscription requests. I kept my subscription address private until > Bush revealed it a few days ago. I'm working on obtaining a subscription > through an address that Bush doesn't know is connected to me. > -- 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 Nov 26 10:33:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06368 for ; Tue, 26 Nov 2002 10:33:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gheg-0004fn-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 07:29:42 -0800 Received: from mail47-s.fg.online.no ([148.122.161.47] helo=mail47.fg.online.no) by psg.com with esmtp (Exim 3.36 #2) id 18GheU-0004d6-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 07:29:30 -0800 Received: from karepr.Presttun.org (ti200710a080-2579.bb.online.no [80.213.42.19]) by mail47.fg.online.no (8.9.3/8.9.3) with ESMTP id QAA00197 for ; Tue, 26 Nov 2002 16:29:01 +0100 (MET) Message-Id: <5.2.0.9.0.20021126161637.033045f8@localhost> X-Sender: kaaprest@pop.online.no@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Nov 2002 16:27:28 +0100 To: namedroppers@ops.ietf.org From: Kare Presttun Subject: Is this correct behavior? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=2.6 required=5.0 tests=LINES_OF_YELLING,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA06368 Dear list readers! I decided to dig into a mail bouncing problem and found some behavior of two of the .no ccTLD servers that made me wonder what is correct. Otlined below: From time to time I get a notice that a mail to me has bounced with a notice saying: > -----Opprinnelig melding----- > Fra: postmaster@imail.oslonett.no [mailto:postmaster@imail.oslonett.no] > Sendt: 21. november 2002 00:26 > Til: < address deleted by me> > Emne: Undeliverable Mail > > Unknown host: Kare@Presttun.org > Or like this one from Securityfocus: : Name service error for mail.securityfocus.com: Host not found, try again \--45AD4A3131.1036699892/outgoing.securityfocus.com So I decided to dig into it. Using the Squish service at: http://www.squish.net/dnscheck/ I get error messages on two of the .no nameservers (Outsourced to UltraDNS who bought the customers from Nominum) namely not.norid.no and njet.norid.no. Asking one of the gtld servers for my domain I get: ; <<>> DiG 9.2.1 <<>> @i.gtld-SERVERS.NET presttun.org mx ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 ;; QUESTION SECTION: ;presttun.org. IN MX ;; AUTHORITY SECTION: presttun.org. 172800 IN NS NS2.NEXTRA.NO. presttun.org. 172800 IN NS SID.NIMROD.NO. presttun.org. 172800 IN NS THREE.PSEUDOSPACE.COM. ;; ADDITIONAL SECTION: THREE.PSEUDOSPACE.COM. 172800 IN A 209.51.13.174 ;; Query time: 406 msec ;; SERVER: 192.43.172.30#53(i.gtld-SERVERS.NET) ;; WHEN: Mon Nov 25 12:31:11 2002 ;; MSG SIZE rcvd: 133 So far everything looks fine. So asking one of the .no servers to resolve the .no DNS servers for me I get: ; <<>> DiG 9.2.1 <<>> @nac.no sid.nimrod.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;sid.nimrod.no. IN A ;; AUTHORITY SECTION: nimrod.no. 86400 IN NS nn.uninett.no. nimrod.no. 86400 IN NS sid.nimrod.no. nimrod.no. 86400 IN NS desoto.nimrod.no. ;; ADDITIONAL SECTION: nn.uninett.no. 3600 IN A 158.38.0.181 sid.nimrod.no. 75029 IN A 195.139.160.2 desoto.nimrod.no. 75029 IN A 195.139.160.6 ;; Query time: 515 msec ;; SERVER: 129.240.2.40#53(nac.no) ;; WHEN: Mon Nov 25 12:39:32 2002 ;; MSG SIZE rcvd: 139 Once again it looks fine. Asking the same question to ether not or njet.norid.no I get: ; <<>> DiG 9.2.1 <<>> @njet.norid.no sid.nimrod.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;sid.nimrod.no. IN A ;; ANSWER SECTION: sid.nimrod.no. 86400 IN A 195.139.160.2 ;; AUTHORITY SECTION: nimrod.no. 86400 IN NS sid.nimrod.no. nimrod.no. 86400 IN NS nn.uninett.no. nimrod.no. 86400 IN NS desoto.nimrod.no. ;; ADDITIONAL SECTION: nn.uninett.no. 86400 IN A 158.38.0.181 desoto.nimrod.no. 86400 IN A 195.139.160.6 ;; Query time: 390 msec ;; SERVER: 198.133.199.105#53(njet.norid.no) ;; WHEN: Mon Nov 25 12:46:18 2002 ;; MSG SIZE rcvd: 139 Where the the server I'm asking for is in the answer section (without being AA) but not in the additional section. Reading 1034, end of 4.2.1: "To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response.". It seems to be correct but it also seems to be the reason for dropped mail. So is this correct behavior? Thanks in advance. Med vennlig hilsen | Best regards, Kåre Presttun Tel.: +47 4100 4908 mailto:Kare@Presttun.org http://www.presttun.org/kare/ -- 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 Nov 26 11:23:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09249 for ; Tue, 26 Nov 2002 11:23:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GiKb-00072g-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 08:13:01 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18GiKO-00071X-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 08:12:49 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18GiKN-000Cp1-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 08:12:47 -0800 Message-ID: <000b01c29564$2e03e2b0$7d7ba8c0@laptoy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20021126114942.79397.qmail@cr.yp.to> From: "John M. Brown" To: "'D. J. Bernstein'" , Subject: RE: namedroppers mismanagement, continued Date: Tue, 26 Nov 2002 08:54:59 -0700 X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09249 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] so stop bitching and subscribe to the mailing list like the rest of us....... Then you make your problem go away, and Randy doesn't have to baby sit your messages. just my $0.00002 worth > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of D. J. Bernstein > Sent: Tuesday, November 26, 2002 4:50 AM > To: ietf@ietf.org > Cc: iesg@ietf.org; namedroppers@ops.ietf.org > Subject: namedroppers mismanagement, continued > > > [ post by non-subscriber. with the massive amount of spam, > it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > I've sent twelve messages to the namedroppers mailing list > this month. Five of them have been silently discarded by the > namedroppers censor, Randy Bush. (See > http://cr.yp.to/djbdns/namedroppers.html for previous > incidents.) > > Bush says that the only relevant feature of my messages is > that they're sent from an address that isn't subscribed to > namedroppers. Okay, boys and girls, let's look at some statistics: > > * 5/12 of my messages have been silently discarded; > > * according to Bush, this has nothing to do with me or the content, > so we estimate that about 5/12 of all non-subscriber > messages have > been silently discarded; > > * in the past three months, there have been about 100 legitimate > messages from other people who Bush labelled as non-subscribers; > > * so we estimate that, in the last three months, Bush has silently > discarded about 71 legitimate messages from other > people. That's a > rate of hundreds per year. > > Bush doesn't say ``Your message didn't go through.'' Bush > doesn't say ``Reply to this bounce to confirm your original > message.'' He simply throws the message away. > > This is supposed to be the mailing list for an open IETF > working group. It's outrageous that valid messages are being > silently discarded---even if the number is not as large as > hundreds per year. > > ---D. J. Bernstein, Associate Professor, Department of > Mathematics, Statistics, and Computer Science, University of > Illinois at Chicago > > P.S. Out of my twelve messages, the five that were silently > discarded are exactly the five that I would pick if I were a > censor trying to bias the DNSEXT decisions in favor of the > BIND company. Coincidence, right? > > P.P.S. Bush's mailing-list software doesn't cryptographically > confirm unsubscription requests. I kept my subscription > address private until Bush revealed it a few days ago. I'm > working on obtaining a subscription through an address that > Bush doesn't know is connected to me. > > > > -- > 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 Nov 26 11:23:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09295 for ; Tue, 26 Nov 2002 11:23:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GiL8-00074u-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 08:13:34 -0800 Received: from crow.verisign.com ([216.168.237.103]) by psg.com with esmtp (Exim 3.36 #2) id 18GiL1-000748-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 08:13:27 -0800 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA02910; Tue, 26 Nov 2002 11:13:25 -0500 (EST) Received: from TYPHOON ([10.131.128.57]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V5CJBWQ7; Tue, 26 Nov 2002 11:13:04 -0500 Message-ID: <0a3401c29566$bf703580$3980830a@typhoon> Reply-To: "Matt Larson" From: "Matt Larson" To: "Heinrich Mendelssohn" , References: Subject: Re: Your friend's DNS Date: Tue, 26 Nov 2002 11:13:23 -0500 Organization: VeriSign Global Registry Services 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Heinrich Mendelssohn wrote: > It seems that CH, the ccTLD for Switzerland, was listed as > non-existant during a few hours on Monday November 25, 2002 by > A.ROOT-SERVERS.NET, as well as all the other ROOT-SERVERS.NET servers > I checked. I noticed the problem as suddenly a lot of .ch domains > became unresolvable and e-mails started to bounce... > > The CH ccTLD was relisted again by A.ROOT-SERVERS.NET at about 14:55 > GMT on November 25. > Did anyone this, or know what happened ? A human error at VeriSign ? > Have other ccTLDs been affected ? There have been no changes to the .ch delegation in the root zone since October 22, 2002. I verified this in the database from which the zone is produced, as well as the resulting root zone files. Did you save the output of the query or note the serial number of the root zone that was affected? Did you use dig for this query? You might have been burned by dig assuming that "ch" meant the CHAOS class. For example, the version of dig that I have lying around (9.1.3) assumes that "dig @a.root-servers.net ch ns" is a query for ./CHAOS/NS. On the other hand, adding a period after the TLD (dig @a.root-servers.net ch. ns) performs the desired query for CH/IN/NS. Could that have been what you saw? Matt -- Matt Larson VeriSign Global Registry Services -- 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 Nov 26 12:34:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12391 for ; Tue, 26 Nov 2002 12:34:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GjTj-000BGL-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 09:26:31 -0800 Received: from vim.quarterman.com ([206.225.33.194] helo=quarterman.com ident=[Vefm0TkbI63goOCaGb2VOMrZGE0vMj18]) by psg.com with esmtp (Exim 3.36 #2) id 18GjTf-000BFd-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 09:26:27 -0800 Received: from marut.quarterman.com (marut [192.168.1.8]) by quarterman.com (8.11.6/8.11.0) with ESMTP id gAQHQID07074 for ; Tue, 26 Nov 2002 11:26:18 -0600 Received: from marut.quarterman.com (localhost [127.0.0.1]) by marut.quarterman.com (8.9.3/8.9.3) with ESMTP id LAA02408 for ; Tue, 26 Nov 2002 11:26:09 -0600 Message-Id: <200211261726.LAA02408@marut.quarterman.com> From: "John S. Quarterman" To: namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued In-reply-to: Your message of "Tue, 26 Nov 2002 09:34:54 EST." Date: Tue, 26 Nov 2002 11:26:09 -0600 X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is supposed to be the mailing list for an open IETF working group. > It's outrageous that valid messages are being silently discarded---even > if the number is not as large as hundreds per year. Messages from non-subscribers are not valid messages for a mailing list. Personally, what I wonder is why Randy bothers to forward any messages from non-subscribers, especially if this is the thanks he gets. -jsq -- 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 Nov 26 12:58:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13596 for ; Tue, 26 Nov 2002 12:58:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GjtP-000CtP-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 09:53:03 -0800 Received: from bartok.sidn.nl ([193.176.144.164]) by psg.com with esmtp (Exim 3.36 #2) id 18GjtL-000CtB-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 09:52:59 -0800 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id gAQHqoOG091135; Tue, 26 Nov 2002 18:52:50 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200211261752.gAQHqoOG091135@bartok.sidn.nl> To: "Matt Larson" cc: "Heinrich Mendelssohn" , namedroppers@ops.ietf.org Subject: Re: Your friend's DNS In-reply-to: Your message of Tue, 26 Nov 2002 11:13:23 -0500. <0a3401c29566$bf703580$3980830a@typhoon> Date: Tue, 26 Nov 2002 18:52:50 +0100 From: Jaap Akkerhuis X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Did you use dig for this query? You might have been burned by dig assuming that "ch" meant the CHAOS class. For example, the version of dig that I have lying around (9.1.3) assumes that "dig @a.root-servers.net ch ns" is a query for ./CHAOS/NS. On the other hand, adding a period after the TLD (dig @a.root-servers.net ch. ns) performs the desired query for CH/IN/NS. Could that have been what you saw? Dig 9.2.1 has the same behavior (see below). jaap dig @a.root-servers.net ch ns ; <<>> DiG 9.2.1 <<>> @a.root-servers.net ch ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24254 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. CH NS ;; Query time: 98 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Tue Nov 26 18:50:57 2002 ;; MSG SIZE rcvd: 17 -- 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 Nov 26 14:26:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17013 for ; Tue, 26 Nov 2002 14:26:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GlDd-000I2v-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 11:18:01 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18GlDW-000I2b-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 11:17:55 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id OAA23607; Tue, 26 Nov 2002 14:11:21 -0500 Date: Tue, 26 Nov 2002 14:12:51 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "John S. Quarterman" cc: namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued In-Reply-To: <200211261726.LAA02408@marut.quarterman.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=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy also drops messages from subscribers whom he doesn't like. I've been subject to this, and I resent the message to a few other people to see if they thought my message was relevant and on-topic, and they responded they thought it was. Once, even the person I was disagreeing with agreed that I had a valid point, and my message should have been posted. --Dean On Tue, 26 Nov 2002, John S. Quarterman wrote: > > This is supposed to be the mailing list for an open IETF working group. > > It's outrageous that valid messages are being silently discarded---even > > if the number is not as large as hundreds per year. > > Messages from non-subscribers are not valid messages for a mailing list. > > Personally, what I wonder is why Randy bothers to forward any messages > from non-subscribers, especially if this is the thanks he gets. > > -jsq > > -- > 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 Nov 26 16:06:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20706 for ; Tue, 26 Nov 2002 16:06:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gmn0-000NGH-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 12:58:38 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Gmmx-000NG5-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 12:58:36 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gAQKwRgU002455; Wed, 27 Nov 2002 07:58:28 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211262058.gAQKwRgU002455@drugs.dv.isc.org> To: "Matt Larson" Cc: "Heinrich Mendelssohn" , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Your friend's DNS In-reply-to: Your message of "Tue, 26 Nov 2002 11:13:23 CDT." <0a3401c29566$bf703580$3980830a@typhoon> Date: Wed, 27 Nov 2002 07:58:27 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Heinrich Mendelssohn wrote: > > It seems that CH, the ccTLD for Switzerland, was listed as > > non-existant during a few hours on Monday November 25, 2002 by > > A.ROOT-SERVERS.NET, as well as all the other ROOT-SERVERS.NET servers > > I checked. I noticed the problem as suddenly a lot of .ch domains > > became unresolvable and e-mails started to bounce... > > > > The CH ccTLD was relisted again by A.ROOT-SERVERS.NET at about 14:55 > > GMT on November 25. > > Did anyone this, or know what happened ? A human error at VeriSign ? > > Have other ccTLDs been affected ? > > There have been no changes to the .ch delegation in the root zone since > October 22, 2002. I verified this in the database from which the zone > is produced, as well as the resulting root zone files. Did you save the > output of the query or note the serial number of the root zone that was > affected? > > Did you use dig for this query? You might have been burned by dig > assuming that "ch" meant the CHAOS class. For example, the version of > dig that I have lying around (9.1.3) assumes that "dig > @a.root-servers.net ch ns" is a query for ./CHAOS/NS. On the other > hand, adding a period after the TLD (dig @a.root-servers.net ch. ns) > performs the desired query for CH/IN/NS. Could that have been what you > saw? > > Matt > -- > Matt Larson > VeriSign Global Registry Services Well "CH" is the official class name. "CHAOS" is a BINDism that is supported as a alias for backwards compatability. Mark From RFC 1034. class which is an encoded 16 bit value which identifies a protocol family or instance of a protocol. This memo uses the following classes: IN the Internet system CH the Chaos system From RFC 1035. 3.2.4. CLASS values CLASS fields appear in resource records. The following CLASS mnemonics and values are defined: IN 1 the Internet CS 2 the CSNET class (Obsolete - used only for examples in some obsolete RFCs) CH 3 the CHAOS class HS 4 Hesiod [Dyer 87] > > > > -- > 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 Nov 26 17:26:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23659 for ; Tue, 26 Nov 2002 17:26:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Go2j-0000jz-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 14:18:57 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18Go2f-0000ig-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 14:18:53 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gAQMILR21566 for ; Tue, 26 Nov 2002 17:18:21 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAA_SaOhQ; Tue, 26 Nov 02 17:18:21 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002112617182024687 for ; Tue, 26 Nov 2002 17:18:20 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gAQMIGf01578 for ; Tue, 26 Nov 2002 17:18:16 -0500 (EST) Message-ID: <3DE3F2EF.EE3D3768@daimlerchrysler.com> Date: Tue, 26 Nov 2002 17:17:19 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Is this correct behavior? References: <5.2.0.9.0.20021126161637.033045f8@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kare Presttun wrote: > Dear list readers! > > I decided to dig into a mail bouncing problem and found > some behavior of two of the .no ccTLD servers that made > me wonder what is correct. Otlined below: > > From time to time I get a notice that a mail to me has bounced with > a notice saying: > > -----Opprinnelig melding----- > > Fra: postmaster@imail.oslonett.no > [mailto:postmaster@imail.oslonett.no] > > Sendt: 21. november 2002 00:26 > > Til: < address deleted by me> > > Emne: Undeliverable Mail > > > > Unknown host: Kare@Presttun.org > > > > Or like this one from Securityfocus: > > : Name service error for mail.securityfocus.com: > Host not found, try again > > \--45AD4A3131.1036699892/outgoing.securityfocus.com > > So I decided to dig into it. Using the Squish service at: > http://www.squish.net/dnscheck/ I get error messages on > two of the .no nameservers (Outsourced to UltraDNS > who bought the customers from Nominum) namely > not.norid.no and njet.norid.no. Asking one of the gtld > servers for my domain I get: > > ; <<>> DiG 9.2.1 <<>> @i.gtld-SERVERS.NET presttun.org mx > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 > > ;; QUESTION SECTION: > ;presttun.org. IN MX > > ;; AUTHORITY SECTION: > presttun.org. 172800 IN NS NS2.NEXTRA.NO. > presttun.org. 172800 IN NS SID.NIMROD.NO. > presttun.org. 172800 IN NS THREE.PSEUDOSPACE.COM. > > ;; ADDITIONAL SECTION: > THREE.PSEUDOSPACE.COM. 172800 IN A 209.51.13.174 > > ;; Query time: 406 msec > ;; SERVER: 192.43.172.30#53(i.gtld-SERVERS.NET) > ;; WHEN: Mon Nov 25 12:31:11 2002 > ;; MSG SIZE rcvd: 133 > > So far everything looks fine. So asking one of the .no > servers to resolve the .no DNS servers for me I get: > > ; <<>> DiG 9.2.1 <<>> @nac.no sid.nimrod.no > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 > > ;; QUESTION SECTION: > ;sid.nimrod.no. IN A > > ;; AUTHORITY SECTION: > nimrod.no. 86400 IN NS nn.uninett.no. > nimrod.no. 86400 IN NS sid.nimrod.no. > nimrod.no. 86400 IN NS desoto.nimrod.no. > > ;; ADDITIONAL SECTION: > nn.uninett.no. 3600 IN A 158.38.0.181 > sid.nimrod.no. 75029 IN A 195.139.160.2 > desoto.nimrod.no. 75029 IN A 195.139.160.6 > > ;; Query time: 515 msec > ;; SERVER: 129.240.2.40#53(nac.no) > ;; WHEN: Mon Nov 25 12:39:32 2002 > ;; MSG SIZE rcvd: 139 > > Once again it looks fine. Asking the same question to ether not or > njet.norid.no I get: > > ; <<>> DiG 9.2.1 <<>> @njet.norid.no sid.nimrod.no > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 > ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;sid.nimrod.no. IN A > > ;; ANSWER SECTION: > sid.nimrod.no. 86400 IN A 195.139.160.2 > > ;; AUTHORITY SECTION: > nimrod.no. 86400 IN NS sid.nimrod.no. > nimrod.no. 86400 IN NS nn.uninett.no. > nimrod.no. 86400 IN NS desoto.nimrod.no. > > ;; ADDITIONAL SECTION: > nn.uninett.no. 86400 IN A 158.38.0.181 > desoto.nimrod.no. 86400 IN A 195.139.160.6 > > ;; Query time: 390 msec > ;; SERVER: 198.133.199.105#53(njet.norid.no) > ;; WHEN: Mon Nov 25 12:46:18 2002 > ;; MSG SIZE rcvd: 139 > > Where the the server I'm asking for is in the answer section > (without being AA) but not in the additional section. > > Reading 1034, end of 4.2.1: "To fix this problem, a zone contains > "glue" RRs which are not part of the authoritative data, and are > address RRs for the servers. These RRs are only necessary if the > name server's name is "below" the cut, and are only used as part > of a referral response.". It seems to be correct but it also seems > to be the reason for dropped mail. > > So is this correct behavior? Thanks in advance. Yes, this is correct behavior. RFC 2181 Section 5.5 requires that RRsets not be repeated in a response. This "squish" tool seems to be rather misguided. It seems to assume that referrals will *always* contain *all* glue records in the Additional Section, but this is not guaranteed. Note that the RFC verbiage you quoted says that glue is "necessary when the name server's name is 'below' the cut"; since "sid.nimrod.no" is not below the "presttun.org" zone cut, there is no requirement for glue to be provided. To simplify matters, each gTLD nameserver tends to have glue for all the gTLD domains, which explains why "THREE.PSEUDOSPACE.COM" glue is available on a .org nameserver; however, the same simplification doesn't hold true for ccTLD glue -- ns2.nextra.no and sid.nimrod.no -- and that's why no glue is provided for those names and they need to be looked up separately. It's possible that the mail originators in this case are running BIND 4, BIND 8 or some other DNS package which lacks "query restart", and therefore may fail to perform all of these extra lookups automatically. This would cause the query to fail initially, and if the client resolver reached its retry threshold, to fail fatally. - 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 Nov 26 17:34:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23971 for ; Tue, 26 Nov 2002 17:34:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GoBf-000176-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 14:28:11 -0800 Received: from mail0.epfl.ch ([128.178.50.57]) by psg.com with smtp (Exim 3.36 #2) id 18GoBb-00016s-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 14:28:07 -0800 Received: (qmail 10618 invoked from network); 26 Nov 2002 22:27:54 -0000 Received: from icmbpc140.epfl.ch (HELO myxp2k) (128.178.55.185) by mail0.epfl.ch with SMTP; 26 Nov 2002 22:27:54 -0000 From: Heinrich Mendelssohn Date: 26 Nov 2002 23:27:11 +0100 To: namedroppers@ops.ietf.org Subject: Re: Your friend's DNS In-Reply-To: User-Agent: Microsoft-Entourage/10.1.1.2418 Message-ID: <3a6398798baf$0624@myxp2k> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit References: X-Spam-Status: No, hits=1.0 required=5.0 tests=FORGED_HOTMAIL_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_ENTOURAGE version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Matt Larson wrote: > Heinrich Mendelssohn wrote: > >>It seems that CH, the ccTLD for Switzerland, was listed as >>non-existant during a few hours on Monday November 25, 2002 by >>A.ROOT-SERVERS.NET, as well as all the other ROOT-SERVERS.NET servers >>I checked. I noticed the problem as suddenly a lot of .ch domains >>became unresolvable and e-mails started to bounce... >> >>The CH ccTLD was relisted again by A.ROOT-SERVERS.NET at about 14:55 >>GMT on November 25. >>Did anyone this, or know what happened ? A human error at VeriSign ? >>Have other ccTLDs been affected ? > > > There have been no changes to the .ch delegation in the root zone since > October 22, 2002. I verified this in the database from which the zone > is produced, as well as the resulting root zone files. Did you save the > output of the query or note the serial number of the root zone that was > affected? > > Did you use dig for this query? You might have been burned by dig > assuming that "ch" meant the CHAOS class. For example, the version of > dig that I have lying around (9.1.3) assumes that "dig > @a.root-servers.net ch ns" is a query for ./CHAOS/NS. On the other > hand, adding a period after the TLD (dig @a.root-servers.net ch. ns) > performs the desired query for CH/IN/NS. Could that have been what you > saw? > > Matt *Red-faced shame* Matt's diagnostic is probably correct. I think I queried for a plain "CH", instead of "CH." My sendmail config rejects e-mail coming from unresolvable domains, and I noticed that it started to bounce mails coming from sunrise.ch, a fairly large swiss telecom carrier. For US guys, it would be a bit as if your sendmail was decreeing that, say, Verizon or Sprint weren't resolvable anymore. I ran a few queries, and when I couldn't even resolve well-known domains like cern.ch, I started to look one level above. Anyway, I now think that the probable cause was some transient IP routing instability between the US server I was working on and Switzerland. It's probable that when I queried dig again at around 14:55 GMT and got back the expected servers for CH, I was appending a dot at the end of "CH". I thus assumed that "CH" was back on-line... I'm a bit lazy/inconsistent and sometimes forget to add the dot. Sorry for the false alarm... Heinrich Mendelssohn P.S. With dig v8.2, the two name servers for sunrise.ch (195.141.56.5 and 193.192.227.3) respond as expected to the queries. With dig v9.2.1, both name servers don't send back any response at all. Peculiar. Maybe a difference in the level of the resolver libraries linked to dig v.8 and dig v.9 changes the DNS UDP packet's contents, and Sunrise's firewalls kill the v.9 packets. -- 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 Nov 26 18:31:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26509 for ; Tue, 26 Nov 2002 18:31:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gp4A-0003WO-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 15:24:30 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Gp48-0003Up-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 15:24:28 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Gp47-000DWi-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 15:24:27 -0800 Message-ID: <20021126210623.88754.qmail@cr.yp.to> References: <20021126114942.79397.qmail@cr.yp.to> <20021126121325.GF6588@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 26 Nov 2002 21:06:23 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued X-Spam-Status: No, hits=0.1 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] David Frascone writes: > Why not simply subscribe and resend? How does that help namedroppers recover all the lost messages from _other_ people? Bush has _sent_ 115 legitimate namedroppers messages from non-subscribers in the last three months; how many has he _lost_? > I'm sure I mistakenly reject many of them. Do you _silently discard_ them? If the sender isn't monitoring the list, how will he ever know that his message didn't go through? If he _is_ monitoring the list, how long is he supposed to wait before complaining? Bush imposed his mailing-list control methods without IESG approval, in violation of RFC 2418, section 3.2. He has been caught engaging in content-based censorship several times: http://cr.yp.to/djbdns/namedroppers.html What's stopping him from selectively delaying or discarding messages that he doesn't like? How can we tell whether these were actually ``mistakes''? Manual reviews are completely inappropriate for a standardization forum. They allow uncontrolled abuse, even when they aren't exacerbated by a lack of notification to the sender. ---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 Tue Nov 26 19:00:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27616 for ; Tue, 26 Nov 2002 19:00:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GpYf-0004nn-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 15:56:01 -0800 Received: from mail41-s.fg.online.no ([148.122.161.41] helo=mail41.fg.online.no) by psg.com with esmtp (Exim 3.36 #2) id 18GpYc-0004lp-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 15:55:59 -0800 Received: from karepr.Presttun.org (ti200710a080-1833.bb.online.no [80.213.39.41]) by mail41.fg.online.no (8.9.3/8.9.3) with ESMTP id AAA29777; Wed, 27 Nov 2002 00:55:16 +0100 (MET) Message-Id: <5.2.0.9.0.20021127002354.01d70fb0@localhost> X-Sender: kaaprest@pop.online.no@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 27 Nov 2002 00:55:05 +0100 To: namedroppers@ops.ietf.org, Kevin Darcy From: Kare Presttun Subject: Re: Is this correct behavior? In-Reply-To: <3DE3F2EF.EE3D3768@daimlerchrysler.com> References: <5.2.0.9.0.20021126161637.033045f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA27616 Thanks Kevin! At 26.11.2002 17:17 -0500, Kevin Darcy wrote: > >Yes, this is correct behavior. RFC 2181 Section 5.5 requires that RRsets >not be repeated in a response. So this is what not.norid.no and njet.norid.no follows, but not the rest of the .no ccTLD servers as we could see from the nac.no responce (the others all the glue as well). > >This "squish" tool seems to be rather misguided. It seems to assume that >referrals will *always* contain *all* glue records in the Additional That was my suspicion. The response from Squish is actually: "198.133.199.105 (NJET.NORID.NO) with failed to resolve SID.NIMROD.NO due to 198.133.199.105 - no answers". Well the answer was there but without the aa bit. >Section, but this is not guaranteed. Note that the RFC verbiage you quoted >says that glue is "necessary when the name server's name is 'below' the >cut"; since "sid.nimrod.no" is not below the "presttun.org" zone cut, >there is no requirement for glue to be provided. To simplify matters, each That is why I said that it looked correct. >gTLD nameserver tends to have glue for all the gTLD domains, which >explains why "THREE.PSEUDOSPACE.COM" glue is available on a .org >nameserver; however, the same simplification doesn't hold true for >ccTLD glue -- ns2.nextra.no and sid.nimrod.no -- and that's why no glue is >provided for those names and they need to be looked up separately. If you look up a zone like nextra.no or nimrod.no there is no problem, you get the answer with all (.no) glue. It is only when I look up the nameservers directly because I got them refered from .org (or somewhere not .no) the problem arrises. Since these servers are registered for .no domains all the .no servers know them. While nac.no did not provide answer, only glue, not and njet.norid.no provided partly both: answer without glue for the question, and glue without answer for the other server(s). > >It's possible that the mail originators in this case are running BIND 4, >BIND 8 or some other DNS package which lacks "query restart", and >therefore may fail to perform all of these extra lookups automatically. >This would cause the query to fail initially, and if the client resolver >reached its retry threshold, to fail fatally. > BIND8 is widely used so this lack of backward compatibility cause a big problem. This is not new or?? Is it the resolvers that has the problem? Med vennlig hilsen | Best regards, Kåre Presttun Tel.: +47 4100 4908 mailto:Kare@Presttun.org http://www.presttun.org/kare/ -- 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 Nov 26 20:28:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29526 for ; Tue, 26 Nov 2002 20:28:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gqw3-0008aI-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 17:24:15 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Gqvu-0008a0-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 17:24:06 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gAR1NtgU004165; Wed, 27 Nov 2002 12:23:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211270123.gAR1NtgU004165@drugs.dv.isc.org> To: Kare Presttun Cc: namedroppers@ops.ietf.org, Kevin Darcy From: Mark.Andrews@isc.org Subject: Re: Is this correct behavior? In-reply-to: Your message of "Wed, 27 Nov 2002 00:55:05 BST." <5.2.0.9.0.20021127002354.01d70fb0@localhost> Date: Wed, 27 Nov 2002 12:23:55 +1100 X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Squish has case sensitivity bugs. sid.nimrod.no and SID.NIMROD.NO produce different results. Query restart should not a issue here. The question should be answered on the second query and UDP clients should be making more than one request. Mark -- 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 Nov 27 00:08:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05617 for ; Wed, 27 Nov 2002 00:08:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GuGz-000H7u-00 for namedroppers-data@psg.com; Tue, 26 Nov 2002 20:58:05 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18GuGx-000H7i-00 for namedroppers@ops.ietf.org; Tue, 26 Nov 2002 20:58:03 -0800 Received: by as.vix.com (Postfix, from userid 716) id E773D37A2A9; Wed, 27 Nov 2002 04:58:02 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: in support of axfr-clarify From: Paul Vixie Date: 27 Nov 2002 04:58:02 +0000 Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk axfr-clarify should go forward, for two reasons. first, bind has done wrong. early versions were only barely within rfc1035, forcing other implementors (notably microsoft) to bend to match field behaviour. bind9 is entirely within rfc1035 regarding axfr, and current bind8 is reasonably close. we need to clarify the spec so that all future implementations can know what the right thing is. second, i've seen comments here to the effect that a name node's ownership was zone-independent, and that's just plain wrong. again, early bind got this horribly wrong and caused a lot of pain and confusion, and we need to retain what's been learned (which is foundational to rfc2181 and rfc2308), which is that a delegation point is owned by the child zone and the parent can at best send delegations, never answers and never authoritative, when queried for things at a child zone's delegation point. bind9 does this correctly. an apparently common misunderstanding as to the contents of a zone is that data can be copied from a child without changing the identity of the parent. this is just false, and is indicative of other conceptual errors. i hereby call for the rapid progression of axfr-clarify along the standards track. it will do much good, and right many wrongs. -- 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 Wed Nov 27 05:46:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05451 for ; Wed, 27 Nov 2002 05:46:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GzaF-0001tc-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 02:38:19 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18GzaD-0001tO-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 02:38:17 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 5EC8C44F5; Wed, 27 Nov 2002 11:38:14 +0100 (CET) Date: Wed, 27 Nov 2002 11:38:14 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify Message-ID: <20021127103814.GB27317@outpost.ds9a.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Nov 27, 2002 at 04:58:02AM +0000, Paul Vixie wrote: > axfr-clarify should go forward, for two reasons. > > first, bind has done wrong. early versions were only barely within rfc1035, > forcing other implementors (notably microsoft) to bend to match field > behaviour. bind9 is entirely within rfc1035 regarding axfr, and current > bind8 is reasonably close. we need to clarify the spec so that all future > implementations can know what the right thing is. Indeed. PowerDNS had a very hard time implementing AXFR reasonably correctly until we stumbled on the axfr-clarify draft. Without it, there basically is *no* specification. RFC1035 has two paragraphs on it on flowery language which try to pass themselves off as a specification. So 'being within rfc1035' strikes me as a statement more like 'we spent heaps of time interpreting the meaning of 1035 and we think we are within it'. In any case, we need a clarification. On a related note, for interop interest, PowerDNS just went open source, initial drop is on http://ds9a.nl/pdns > second, i've seen comments here to the effect that a name node's ownership > was zone-independent, and that's just plain wrong. again, early bind got > this horribly wrong and caused a lot of pain and confusion, and we need to > retain what's been learned (which is foundational to rfc2181 and rfc2308), > which is that a delegation point is owned by the child zone and the parent How is this related to a proposed RFC about zone transfers? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- 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 Nov 27 09:50:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12781 for ; Wed, 27 Nov 2002 09:50:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H3Ol-0008G6-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 06:42:43 -0800 Received: from mail46-s.fg.online.no ([148.122.161.46] helo=mail46.fg.online.no) by psg.com with esmtp (Exim 3.36 #2) id 18H3Og-0008F4-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 06:42:39 -0800 Received: from karepr.Presttun.org (ti200710a080-0936.bb.online.no [80.213.35.168]) by mail46.fg.online.no (8.9.3/8.9.3) with ESMTP id PAA20620; Wed, 27 Nov 2002 15:42:23 +0100 (MET) Message-Id: <5.2.0.9.0.20021127151436.02da79c0@localhost> X-Sender: kaaprest@pop.online.no@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 27 Nov 2002 15:42:24 +0100 To: Mark.Andrews@isc.org, namedroppers@ops.ietf.org From: Kare Presttun Subject: Re: Is this correct behavior? Cc: james@squish.net, Paul Vixie In-Reply-To: <200211270123.gAR1NtgU004165@drugs.dv.isc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA12781 At 27.11.2002 12:23 +1100, Mark.Andrews@isc.org wrote: > > Squish has case sensitivity bugs. sid.nimrod.no and > SID.NIMROD.NO produce different results. You are very correct in observing this (I did a test, and included James in the CC). > > Query restart should not a issue here. The question should be > answered on the second query and UDP clients should be making > more than one request. > At 27.11.2002 04:58 +0000, Paul Vixie wrote: > >second, i've seen comments here to the effect that a name node's ownership >was zone-independent, and that's just plain wrong. again, early bind got >this horribly wrong and caused a lot of pain and confusion, and we need to >retain what's been learned (which is foundational to rfc2181 and rfc2308), >which is that a delegation point is owned by the child zone and the parent >can at best send delegations, never answers and never authoritative, when >queried for things at a child zone's delegation point. bind9 does this >correctly. an apparently common misunderstanding as to the contents of a >zone is that data can be copied from a child without changing the identity >of the parent. this is just false, and is indicative of other conceptual >errors. From the statement of Mr. Vixie I draw the following conclusion about the .no ccTLD servers (please correct me if I'm wrong): nn.uninett.no. Correct (authority for nimrod.no) ifi.uio.no. Correct (recursive) nac.no. Correct not.norid.no. Wrong (gives answer and partly glue) njet.norid.no. Wrong (gives answer and partly glue) slave1.sth.netnod.se. Correct All diged below for completeness (using sid.nimrod.no as example): ; <<>> DiG 9.2.1 <<>> @nn.uninett.no sid.nimrod.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;sid.nimrod.no. IN A ;; ANSWER SECTION: sid.nimrod.no. 86400 IN A 195.139.160.2 ;; AUTHORITY SECTION: nimrod.no. 86400 IN NS sid.nimrod.no. nimrod.no. 86400 IN NS desoto.nimrod.no. nimrod.no. 86400 IN NS nn.uninett.no. ;; ADDITIONAL SECTION: nn.uninett.no. 3600 IN A 158.38.0.181 desoto.nimrod.no. 86400 IN A 195.139.160.6 ; <<>> DiG 9.2.1 <<>> @ifi.uio.no sid.nimrod.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;sid.nimrod.no. IN A ;; ANSWER SECTION: sid.nimrod.no. 86400 IN A 195.139.160.2 ;; AUTHORITY SECTION: nimrod.no. 86400 IN NS nn.uninett.no. nimrod.no. 86400 IN NS sid.nimrod.no. nimrod.no. 86400 IN NS desoto.nimrod.no. ;; ADDITIONAL SECTION: nn.uninett.no. 86400 IN A 158.38.0.181 sid.nimrod.no. 86400 IN A 195.139.160.2 desoto.nimrod.no. 86400 IN A 195.139.160.6 ; <<>> DiG 9.2.1 <<>> @nac.no sid.nimrod.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;sid.nimrod.no. IN A ;; AUTHORITY SECTION: nimrod.no. 86400 IN NS sid.nimrod.no. nimrod.no. 86400 IN NS desoto.nimrod.no. nimrod.no. 86400 IN NS nn.uninett.no. ;; ADDITIONAL SECTION: nn.uninett.no. 3600 IN A 158.38.0.181 sid.nimrod.no. 86400 IN A 195.139.160.2 desoto.nimrod.no. 86400 IN A 195.139.160.6 ; <<>> DiG 9.2.1 <<>> @not.norid.no sid.nimrod.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;sid.nimrod.no. IN A ;; ANSWER SECTION: sid.nimrod.no. 86400 IN A 195.139.160.2 ;; AUTHORITY SECTION: nimrod.no. 86400 IN NS sid.nimrod.no. nimrod.no. 86400 IN NS nn.uninett.no. nimrod.no. 86400 IN NS desoto.nimrod.no. ;; ADDITIONAL SECTION: nn.uninett.no. 86400 IN A 158.38.0.181 desoto.nimrod.no. 86400 IN A 195.139.160.6 ; <<>> DiG 9.2.1 <<>> @njet.norid.no sid.nimrod.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;sid.nimrod.no. IN A ;; ANSWER SECTION: sid.nimrod.no. 86400 IN A 195.139.160.2 ;; AUTHORITY SECTION: nimrod.no. 86400 IN NS sid.nimrod.no. nimrod.no. 86400 IN NS nn.uninett.no. nimrod.no. 86400 IN NS desoto.nimrod.no. ;; ADDITIONAL SECTION: nn.uninett.no. 86400 IN A 158.38.0.181 desoto.nimrod.no. 86400 IN A 195.139.160.6 ; <<>> DiG 9.2.1 <<>> @slave1.sth.netnod.se sid.nimrod.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;sid.nimrod.no. IN A ;; AUTHORITY SECTION: nimrod.no. 86400 IN NS desoto.nimrod.no. nimrod.no. 86400 IN NS nn.uninett.no. nimrod.no. 86400 IN NS sid.nimrod.no. ;; ADDITIONAL SECTION: nn.uninett.no. 86400 IN A 158.38.0.181 sid.nimrod.no. 86400 IN A 195.139.160.2 desoto.nimrod.no. 86400 IN A 195.139.160.6 Thanks a lot for clarifications and observations. Med vennlig hilsen | Best regards, Kåre Presttun Tel.: +47 4100 4908 mailto:Kare@Presttun.org http://www.presttun.org/kare/ -- 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 Nov 27 11:58:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19004 for ; Wed, 27 Nov 2002 11:58:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H5NV-000CNy-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 08:49:33 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18H5NM-000CNN-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 08:49:24 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18H5NM-0009TM-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 08:49:24 -0800 Message-ID: <20021127155832.12772.qmail@cr.yp.to> References: <20021126114942.79397.qmail@cr.yp.to> <20021126121325.GF6588@newman.frascone.com> <20021126210623.88754.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 27 Nov 2002 15:58:32 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued X-Spam-Status: No, hits=0.1 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Once again: Bush is (1) subjecting a huge number of legitimate messages to manual review and (2) silently discarding many of these legitimate messages, apparently at a rate of hundreds per year (not counting mine). Both #1 and #2 are unacceptable. I want the manual reviews _eliminated_. If a message isn't posted immediately, it must be bounced, with a clear explanation of how to have it posted without Bush's intervention. If the IETF documentation doesn't make sufficiently clear that Bush's behavior is unacceptable, that documentation also has to be fixed. ---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 Wed Nov 27 12:45:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21321 for ; Wed, 27 Nov 2002 12:45:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H6CS-000EfU-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 09:42:12 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18H6CP-000EfI-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 09:42:09 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18H6CP-0009p7-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 09:42:09 -0800 Message-ID: <20021127174104.41801.qmail@cr.yp.to> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 27 Nov 2002 17:41:04 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: iesg@ietf.org, ietf@ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=0.1 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Paul Vixie writes: > bind has done wrong. Interoperability is more important than your notions of what's ``right'' and ``wrong''---never mind the question of whether your notions are actually supported by the Full Standard DNS specifications. The ``axfr-clarify'' document claims to codify existing practice. The problem is that what it actually codifies is BIND 9 practice. You admit that this ``clarification'' imposes rules that are disobeyed by BIND 8, for example, and by djbdns. My web pages have said for three years that the DNS specifications are horribly inadequate. This doesn't mean that I will support a dishonest, clearly biased document that tries to force me to imitate BIND 9's silly implementation decisions at the expense of my users. You say that your optional IXFR extension doesn't work correctly unless every DNS server on the planet works the way that BIND 9 does. You leap to the conclusion that everybody else should change their software for IXFR's benefit. Has it ever occurred to you to fix IXFR instead? ---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 Wed Nov 27 14:09:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24808 for ; Wed, 27 Nov 2002 14:09:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H7Pw-000Hoz-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 11:00:12 -0800 Received: from pcls3.std.com ([199.172.62.105] helo=TheWorld.com) by psg.com with esmtp (Exim 3.36 #2) id 18H7Pt-000Hoe-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 11:00:09 -0800 Received: from shell.TheWorld.com (doyle@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id OAA02146 for ; Wed, 27 Nov 2002 14:00:07 -0500 Received: from localhost (schlitt@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id OAA76052391 for ; Wed, 27 Nov 2002 14:00:07 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: schlitt owned process doing -bs Date: Wed, 27 Nov 2002 14:00:06 -0500 From: Dan Schlitt X-X-Sender: schlitt@shell01.TheWorld.com cc: namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued In-Reply-To: <20021127155832.12772.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=IN_REP_TO,MISSING_HEADERS,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I believe that this statement applies. Perhaps both Randy and DJB might review it before continuing this off-topic thread. Date: Thu, 14 Mar 2002 10:03:56 -0500 From: The IESG To: IETF-Announce: ; Subject: Guidance for spam-control on IETF mailing lists The level of spam on IETF mailing lists has now reached the level that we encourage the use of operational controls as described in: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt In particular, list managers are encouraged to employ the use of automatic mechanisms that immediately distribute messages submitted by subscribers and other known email addresses while directing all other messages to a human reviewer for rejection or approval. -- Dan Schlitt schlitt@world.std.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 Nov 27 15:06:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26255 for ; Wed, 27 Nov 2002 15:06:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H8Lk-000K3i-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 11:59:56 -0800 Received: from pcp816583pcs.nrockv01.md.comcast.net ([68.49.62.108] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18H8LN-000K17-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 11:59:41 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id gARJnmm00773; Wed, 27 Nov 2002 14:49:48 -0500 (EST) (envelope-from ogud@ogud.com) Date: Wed, 27 Nov 2002 14:49:47 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: "D. J. Bernstein" cc: ietf@ietf.org, , Subject: Re: namedroppers mismanagement, continued In-Reply-To: <20021127155832.12772.qmail@cr.yp.to> Message-ID: <20021127143933.X657-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 27 Nov 2002, D. J. Bernstein wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Once again: Bush is (1) subjecting a huge number of legitimate messages > to manual review and (2) silently discarding many of these legitimate > messages, apparently at a rate of hundreds per year (not counting mine). All you need to do is ONE of the following: Use the same subcription address and posting address Ask Randy to put your posting address on the approved posters list. > > Both #1 and #2 are unacceptable. I want the manual reviews _eliminated_. > If a message isn't posted immediately, it must be bounced, with a clear > explanation of how to have it posted without Bush's intervention. The ONLY reason there is manual review is because you are not addhearing to the protocol for posting to the mailing list. > > If the IETF documentation doesn't make sufficiently clear that Bush's > behavior is unacceptable, that documentation also has to be fixed. Send text. 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 Nov 27 15:31:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26926 for ; Wed, 27 Nov 2002 15:31:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H8j7-000KoZ-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 12:24:05 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18H8j4-000Kn7-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 12:24:02 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gARKNV205573 for ; Wed, 27 Nov 2002 15:23:31 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAArsaG4k; Wed, 27 Nov 02 15:23:31 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002112715233011922 for ; Wed, 27 Nov 2002 15:23:31 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gARKNQf20113 for ; Wed, 27 Nov 2002 15:23:26 -0500 (EST) Message-ID: <3DE52984.219E825A@daimlerchrysler.com> Date: Wed, 27 Nov 2002 15:22:28 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify References: <20021127174104.41801.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Paul Vixie writes: > > bind has done wrong. > > Interoperability is more important than your notions of what's ``right'' > and ``wrong''---never mind the question of whether your notions are > actually supported by the Full Standard DNS specifications. > > The ``axfr-clarify'' document claims to codify existing practice. The > problem is that what it actually codifies is BIND 9 practice. You admit > that this ``clarification'' imposes rules that are disobeyed by BIND 8, > for example, and by djbdns. > > My web pages have said for three years that the DNS specifications are > horribly inadequate. This doesn't mean that I will support a dishonest, > clearly biased document that tries to force me to imitate BIND 9's silly > implementation decisions at the expense of my users. Dan, Interoperability is fine and dandy, but should not stand in the way of writing new specifications to do The Right Thing. This new specification makes AXFR error reporting and behavior more intuitive, and it puts data in the proper parts of the AXFR response (vis-a-vis Answer, Authority and Additional) in order to allow for future extensions. These two points -- error/reporting behavior and allocation of records among sections -- seem to be your (and your minions') major objections to the new specification, because you've been bending the _de_facto_ rules in these regards (e.g. "section agnosticism" or whatever you call it). If your users have any "expense" due to the new specification, it is because you chose to _ad_lib_ in the absence of a clear specification, instead of proceeding in a conservative and/or cautious fashion. C'est la vie... For the record, I support the draft. - 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 Wed Nov 27 16:00:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27776 for ; Wed, 27 Nov 2002 16:00:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H9Ao-000Lqi-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 12:52:42 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18H9Ak-000LqQ-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 12:52:38 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA16805; Wed, 27 Nov 2002 15:48:26 -0500 Date: Wed, 27 Nov 2002 15:50:07 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Olafur Gudmundsson cc: "D. J. Bernstein" , , , Subject: Re: namedroppers mismanagement, continued In-Reply-To: <20021127143933.X657-100000@hlid.dc.ogud.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I am not on the ietf or iesg list. I don't know if this will go through to those lists. While DJB may also have some subscription issue, that is not the fundamental problem. It seems from your comments below, that you think that Randy isn't manually blocking/forwarding messages from subscribed addresses. However, that it not true. The real problem is that Randy sometimes don't post messages from people he doesn't like or on topics he has an interest in, even when they are posted from subscribed addresses. This has happened to me several times. One of the occasions where it happened to me is documented on Bernstein's web page. It has probably happened many more times that haven't made it on DJB's webpage. There seems to be no reason that Randy should set himself up as a moderator, or any reason whatsoever there should be any manual intervention on posting from subscribed addresses. Do you agree? --Dean On Wed, 27 Nov 2002, Olafur Gudmundsson wrote: > > > On 27 Nov 2002, D. J. Bernstein wrote: > > > [ post by non-subscriber. with the massive amount of spam, it is easy to > > miss and therefore delete mis-posts. your subscription address is > > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > > fix subscription your subscription address! ] > > > > Once again: Bush is (1) subjecting a huge number of legitimate messages > > to manual review and (2) silently discarding many of these legitimate > > messages, apparently at a rate of hundreds per year (not counting mine). > > All you need to do is ONE of the following: > Use the same subcription address and posting address > Ask Randy to put your posting address on the approved posters > list. > > > > > Both #1 and #2 are unacceptable. I want the manual reviews _eliminated_. > > If a message isn't posted immediately, it must be bounced, with a clear > > explanation of how to have it posted without Bush's intervention. > > The ONLY reason there is manual review is because you are not > addhearing to the protocol for posting to the mailing list. > > > > > If the IETF documentation doesn't make sufficiently clear that Bush's > > behavior is unacceptable, that documentation also has to be fixed. > > Send text. > > 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: > -- 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 Nov 27 16:26:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28252 for ; Wed, 27 Nov 2002 16:26:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H9eb-000Msw-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 13:23:29 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18H9eX-000MsX-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 13:23:25 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 836CA4583; Wed, 27 Nov 2002 22:23:22 +0100 (CET) Date: Wed, 27 Nov 2002 22:23:22 +0100 From: bert hubert To: Dean Anderson Cc: Olafur Gudmundsson , "D. J. Bernstein" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued Message-ID: <20021127212322.GA15355@outpost.ds9a.nl> References: <20021127143933.X657-100000@hlid.dc.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Nov 27, 2002 at 03:50:07PM -0500, Dean Anderson wrote: > There seems to be no reason that Randy should set himself up as a > moderator, or any reason whatsoever there should be any manual > intervention on posting from subscribed addresses. Do you agree? The lack of transparency smacks of impropriety. I see this list well served with some moderation. I do not see it benefit from unfettered solo activity with no external checks and balances. 'Trust me' does not apply here. To resolve this I suggest a page with any articles that have been refused for whatever reason. Randy? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- 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 Nov 27 16:45:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28977 for ; Wed, 27 Nov 2002 16:45:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H9s4-000NPb-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 13:37:24 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18H9s1-000NPN-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 13:37:21 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA32456; Wed, 27 Nov 2002 16:30:24 -0500 Date: Wed, 27 Nov 2002 16:32:04 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <3DE52984.219E825A@daimlerchrysler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would note that the "de facto rules" are defined by the "de facto" implementations, which is not Bind 9. While there could be reasons to change something, that isn't what "clarify" means. "Clarify" is where you document what was _done_ when the specifications were vague. It seems highly inappropriate to make seemingly gratiutous changes in a particular commercial product, begin distributing those changes to users, and then attempt to change the standards to reflect the changes, and describing those changes as a "clarification". This seems more like behind the scenes dirty tricks. --Dean > Interoperability is fine and dandy, but should not stand in the way > of writing new specifications to do The Right Thing. This new specification > makes AXFR error reporting and behavior more intuitive, and it puts data in > the proper parts of the AXFR response (vis-a-vis Answer, Authority and > Additional) in order to allow for future extensions. These two points -- > error/reporting behavior and allocation of records among sections -- seem to > be your (and your minions') major objections to the new specification, > because you've been bending the _de_facto_ rules in these regards (e.g. > "section agnosticism" or whatever you call it). If your users have any > "expense" due to the new specification, it is because you chose to _ad_lib_ > in the absence of a clear specification, instead of proceeding in a > conservative and/or cautious fashion. C'est la vie... -- 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 Nov 27 16:55:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29288 for ; Wed, 27 Nov 2002 16:55:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HA53-000NyB-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 13:50:49 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #2) id 18HA51-000Nxj-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 13:50:47 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA22089; Wed, 27 Nov 2002 16:50:44 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA06555; Wed, 27 Nov 2002 16:48:10 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA03667; Wed, 27 Nov 2002 16:48:08 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id QAA12633; Wed, 27 Nov 2002 16:48:06 -0500 Subject: Re: in support of axfr-clarify From: Greg Hudson To: Dean Anderson Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Nov 2002 16:48:06 -0500 Message-Id: <1038433686.1211.210.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=2.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SPAM_PHRASE_00_01, X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-11-27 at 16:32, Dean Anderson wrote: > It seems highly inappropriate to make seemingly gratiutous changes in a > particular commercial product, begin distributing those changes to users, > and then attempt to change the standards to reflect the changes, and > describing those changes as a "clarification". Would it really make any of you happier if the title were changed from "clarifications" to "revisions" and the introductory text modified accordingly? (If so, I'm all for it.) -- 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 Nov 27 17:25:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00209 for ; Wed, 27 Nov 2002 17:25:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HAaP-000PDj-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 14:23:13 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #2) id 18HAaN-000PDL-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 14:23:11 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id gARMMKJ18256 for ; Wed, 27 Nov 2002 17:22:20 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAZNa4PJ; Wed, 27 Nov 02 17:22:20 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002112717225630240 for ; Wed, 27 Nov 2002 17:22:56 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gARMMpf08496 for ; Wed, 27 Nov 2002 17:22:51 -0500 (EST) Message-ID: <3DE54582.1C9704ED@daimlerchrysler.com> Date: Wed, 27 Nov 2002 17:21:54 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dean Anderson wrote: > I would note that the "de facto rules" are defined by the "de > facto" implementations, which is not Bind 9. Well, when I said "_de_facto_ rules" I was referring not only to a mere survey of what extant AXFR implementations do, but also the rules followed generally for query/response transactions within DNS. AXFR is, after all, a query/response transaction, albeit a somewhat "special" kind. The general rules say that data answering a DNS query goes into the Answer section (along with possibly CNAMEs and DNSSEC goop), and the Authority and Additional sections are reserved for specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.), none of which really apply to "classic" unsigned AXFR responses. The general rules also say that if a server declines to answer a query for some administratively-defined reason, it sends back an approriate RCODE, rather than just dropping the connection (as DJB's server apparently does, because he considers AXFR client/server transactions to be "local matter[s]" rather than something to be governed by protocol, go figure). > While there could be reasons to change something, that isn't what > "clarify" means. "Clarify" is where you document what was _done_ when the > specifications were vague. > No, the purpose of clarifying AXFR is not to spread a "big tent" that accommodates the idiosyncratic behavior of every AXFR implementation out there. Such a specification, if it is possible at all, would be so watered down it would be useless. The purpose of clarifying AXFR is to bring it into the mainstream of DNS as a whole, and to allow future implementations to be based on a common understanding of how AXFR works, and therefore be able to interoperate with a minimum of hassle. If this means DJB actually has to touch some of his existing code to make it conformant to the clarified spec, then them's the breaks. He shouldn't have taken such liberties in the first place. It is exactly *because* there was a divergence in AXFR implementations (with older BIND versions being among the prime offenders) that the clarifications were deemed necessary. A "clarification" that merely documented the incompatibilities between different implementations would have been pointless: the IETF is not a historical society, merely documenting the mistakes of the past; it is supposed to lead into the future. Also, I'll add that every Tom, Dick and Harriet who decides to implement a poorly-specified IETF protocol doesn't thereby get veto power over any future clarification of that protocol, simply by incanting "but it won't interoperate with my implementation!" as if it were some sort of religious mantra. That's no way to set forward-looking standards. > It seems highly inappropriate to make seemingly gratiutous changes in a > particular commercial product, begin distributing those changes to users, > and then attempt to change the standards to reflect the changes, and > describing those changes as a "clarification". I dispute that the changes are "gratuitous", that BIND is "a commercial product" (yes, it is used *in* some commercial products, but that's not the same thing), and, finally, that the standards are actually being changed here. > This seems more like behind the scenes dirty tricks. > Yeah, it's all a big conspiracy. Sheesh. - 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 Wed Nov 27 18:03:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01557 for ; Wed, 27 Nov 2002 18:03:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HB7m-0000T4-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 14:57:42 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18HB7j-0000Sr-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 14:57:39 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA29931; Wed, 27 Nov 2002 17:50:30 -0500 Date: Wed, 27 Nov 2002 17:52:11 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Greg Hudson cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <1038433686.1211.210.camel@error-messages.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It would make the standards transaction more intellectually honest. But I still think the changes are dubious. I assert that the AXFR protocol and semantics should not need to be changed in order to do IXFR. Changes to the AXFR semantics seems to imply changes to RFC1035, and affects backward compatibility. I think tampering with AXFR is risky, and not well understood. However, I haven't looked into the Bind 9 IXFR modifications enough to know exactly why AXFR changes are really necessary, or if indeed they are really necessary or just a convenient hack to make IXFR work in Bind. I think I would rather change IXFR to make it work without changes to AXFR. So I still wouldn't be for it. --Dean On 27 Nov 2002, Greg Hudson wrote: > On Wed, 2002-11-27 at 16:32, Dean Anderson wrote: > > It seems highly inappropriate to make seemingly gratiutous changes in a > > particular commercial product, begin distributing those changes to users, > > and then attempt to change the standards to reflect the changes, and > > describing those changes as a "clarification". > > Would it really make any of you happier if the title were changed from > "clarifications" to "revisions" and the introductory text modified > accordingly? (If so, I'm all for it.) > > -- 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 Nov 27 18:27:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02325 for ; Wed, 27 Nov 2002 18:27:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HBQo-0001CX-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 15:17:22 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18HBQm-0001CL-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 15:17:20 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA24845; Wed, 27 Nov 2002 18:14:32 -0500 Date: Wed, 27 Nov 2002 18:16:12 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <3DE54582.1C9704ED@daimlerchrysler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Kevin Darcy wrote: > No, the purpose of clarifying AXFR is not to spread a "big tent" that > accommodates the idiosyncratic behavior of every AXFR implementation out there. I agree with this statement. But we aren't talking about a lot of idiosyncratic behavior. We are talking about behavior shared by numerous nameservers, and now significantly changed by Bind 9. So far as I know, _only_ Bind 9 has this change. A clarification should define the common way its done, the way it was reasonably and commonly understood by readers the original document. > > It seems highly inappropriate to make seemingly gratiutous changes in a > > particular commercial product, begin distributing those changes to users, > > and then attempt to change the standards to reflect the changes, and > > describing those changes as a "clarification". > > I dispute that the changes are "gratuitous", that BIND is "a commercial product" Vixie asserts a trademark on "BIND". Though I'm not convinced its really valid, since it was in the public domain by UCB. Trademarks are only valid if used in commerce. .: Bind is a commercial product. I guess "gratuitous" is rather vague. I should say that I think IXFR should be changed instead of AXFR, and that I'm not convinced that any protocol/semantic changes are really necessary to make this work. Rather than accept these changes to AXFR, I think the implementors should give it more thought. > > This seems more like behind the scenes dirty tricks. > > Yeah, it's all a big conspiracy. Sheesh. Appearances of impropriety weigh just as heavily as actual impropriety. --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 Nov 27 19:05:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03407 for ; Wed, 27 Nov 2002 19:05:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HC38-0002jy-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 15:56:58 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HC35-0002jl-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 15:56:56 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HC31-000F5g-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 15:56:51 -0800 Message-ID: <20021127232447.36871.qmail@cr.yp.to> References: <20021127155832.12772.qmail@cr.yp.to> <20021127143933.X657-100000@hlid.dc.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 27 Nov 2002 23:24:47 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement, continued X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Olafur Gudmundsson writes: > Ask Randy to put your posting address on the approved posters list. Messages are not being bounced with explanations of how to set them up as known addresses. Messages are being SILENTLY DISCARDED. (Misdirecting them to some obscure web page would have essentially the same effect.) You say the problem is that _I_ am not doing something. But a whole bunch of namedroppers messages from _other_ people have also been listed as coming from non-subscribers. How many more messages have been lost--- or deliberately thrown away by Bush? THE PROCEDURE IS FLAWED! As for my own sender address djb@cr.yp.to, Bush has already taken manual action---but what he did was _not_ adding the address to a list of known addresses. Instead, he started putting my subscription address on top of all my messages to the list---shortly after I had informed him that I kept _that_ address private to limit the number of people who can forge unsubscription requests. I don't care whether Bush's decisions can be adequately explained by stupidity. The decisions shouldn't be made by hand in the first place. The only acceptable ways to process a message to a standardization mailing list are (1) to immediately pass it through unchanged to the subscribers or (2) to immediately bounce it. The decision between #1 and #2 must be made by objective standards. The bounces must clearly and thoroughly explain the standards. The standards must allow the sender to straightforwardly arrange for #1. ---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 Wed Nov 27 19:39:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03923 for ; Wed, 27 Nov 2002 19:39:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HCa6-00046Z-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 16:31:02 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18HCa3-00046N-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 16:30:59 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gAS0UYgU009457; Thu, 28 Nov 2002 11:30:36 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211280030.gAS0UYgU009457@drugs.dv.isc.org> To: Dean Anderson Cc: Greg Hudson , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: in support of axfr-clarify In-reply-to: Your message of "Wed, 27 Nov 2002 17:52:11 CDT." Date: Thu, 28 Nov 2002 11:30:34 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It would make the standards transaction more intellectually honest. > > But I still think the changes are dubious. I assert that the AXFR > protocol and semantics should not need to be changed in order to do IXFR. > Changes to the AXFR semantics seems to imply changes to RFC1035, and > affects backward compatibility. I think tampering with AXFR is risky, and > not well understood. > > However, I haven't looked into the Bind 9 IXFR modifications enough to > know exactly why AXFR changes are really necessary, or if indeed they are > really necessary or just a convenient hack to make IXFR work in Bind. > > I think I would rather change IXFR to make it work without changes to > AXFR. > > So I still wouldn't be for it. The rules are required for basic AXFR to work regardless of IXFR. Take the following senario. A is the primary master for example.net. B is the primary master for child.example.net. C is a server for example.net and child.example.net. D is a server for example.net that uses C as a master. A and B both change the NS RRset for child.example.net. The NOTIFY from B is lost so the update relies on refresh. C transfers example.net. C replaces the NS RRset with that from child.example.net. C notifies D that it has a new version of example.net. D transfers example.net from C. C performs a refresh query for child.example.net and transfers it. You now have: A with the NEW NS RRset for child.example.net. B with the NEW NS RRset for child.example.net. C with the NEW NS RRset for child.example.net. D with the OLD NS RRset for child.example.net. This is why you MUST preserve zone contents with AXFR. Mark > > --Dean > > On 27 Nov 2002, Greg Hudson wrote: > > > On Wed, 2002-11-27 at 16:32, Dean Anderson wrote: > > > It seems highly inappropriate to make seemingly gratiutous changes in a > > > particular commercial product, begin distributing those changes to users, > > > and then attempt to change the standards to reflect the changes, and > > > describing those changes as a "clarification". > > > > Would it really make any of you happier if the title were changed from > > "clarifications" to "revisions" and the introductory text modified > > accordingly? (If so, I'm all for it.) > > > > > > > > > -- > 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 Nov 27 19:42:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03952 for ; Wed, 27 Nov 2002 19:42:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HCha-0004QV-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 16:38:46 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HChX-0004Pq-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 16:38:44 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HChV-000F8u-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 16:38:41 -0800 Message-ID: <20021128002526.68429.qmail@cr.yp.to> References: <20021127174104.41801.qmail@cr.yp.to> <3DE52984.219E825A@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 28 Nov 2002 00:25:26 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Kevin Darcy writes: > you've been bending the _de_facto_ rules in these regards (e.g. > "section agnosticism" or whatever you call it) How is it possible for people to be so fundamentally confused about such a simple issue? RFC 1034 says that the AXFR server sends ``messages'' that ``carry'' all the records. This is ambiguous: does ``carry'' refer to all sections of the message, or is it restricted to the answer section? I decided to take the safest possible interpretation: * My AXFR _server_ puts all records in the answer section, just in case some clients look only at the answer section. * My AXFR _client_ reads all sections, just in case some servers use other sections. The accusation that I'm ``bending the rules'' is utterly without merit. I am doing what any careful implementor would have done, for the sake of interoperability. My server behavior and client behavior are both fully compliant with the protocol specifications. Now, it appears that every other _server_ implementor has made the same decision to use only the answer section, so no harm would have arisen if my _client_ had been less careful. But the leap from ``this client can handle protocol violations that, thankfully, do not occur'' to ``this client itself violates the protocol'' is utterly absurd. The BIND company's ``clarification'' does two things: * It requires _servers_ to use the careful _server_ strategy. I have no objection to this: it's what servers are already doing, it is necessary for interoperability with careless clients, and it removes a frivolous source of variability in the protocol. * It prohibits _clients_ from using the careful _client_ strategy. I object to this: it is _not_ consistent with the installed base, and it is _not_ necessary for interoperability. How can anyone confuse a constraint on _servers_ with a constraint on _clients_? It isn't just Kevin; the same blatant confusion appeared in the message from the DNSEXT chairs on 13 November. ---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 Wed Nov 27 20:08:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04385 for ; Wed, 27 Nov 2002 20:08:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HD4J-0005ST-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 17:02:15 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HD4G-0005SE-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 17:02:12 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HD4F-000FAe-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 17:02:11 -0800 Message-ID: <001501c29677$b632eaa0$f9ecdfd8@laptoy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20021127232447.36871.qmail@cr.yp.to> From: "John M. Brown" To: "'D. J. Bernstein'" , Cc: , Subject: RE: namedroppers mismanagement, continued Date: Wed, 27 Nov 2002 17:47:21 -0700 X-Spam-Status: No, hits=-0.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA04385 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Dan, sounds like a plan. I say all messages from Bernstein be handled via his option #2 Can we please BOUNCE all of Dr. Bernsteins email with the correct procedure, in the bounce message, on how to subscribe and be a participating member of the list instead of bitching and wasting time. If you have specific complaints about the List Manager then forward them, in private, to the NomCom. This list is NOT the place for this bitch fest. Now lets get back to something more important like arguing over DNS SEC. ;) Jeesh, what a waste... > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of D. J. Bernstein > Sent: Wednesday, November 27, 2002 4:25 PM > To: ietf@ietf.org > Cc: iesg@ietf.org; namedroppers@ops.ietf.org > Subject: Re: namedroppers mismanagement, continued > > > [ post by non-subscriber. with the massive amount of spam, > it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Olafur Gudmundsson writes: > > Ask Randy to put your posting address on the approved posters list. > > Messages are not being bounced with explanations of how to > set them up as known addresses. Messages are being SILENTLY > DISCARDED. (Misdirecting them to some obscure web page would > have essentially the same effect.) > > You say the problem is that _I_ am not doing something. But a > whole bunch of namedroppers messages from _other_ people have > also been listed as coming from non-subscribers. How many > more messages have been lost--- or deliberately thrown away > by Bush? THE PROCEDURE IS FLAWED! > > As for my own sender address djb@cr.yp.to, Bush has already > taken manual action---but what he did was _not_ adding the > address to a list of known > addresses. Instead, he started putting my subscription > address on top of all my messages to the list---shortly after > I had informed him that I kept _that_ address private to > limit the number of people who can forge unsubscription requests. > > I don't care whether Bush's decisions can be adequately > explained by stupidity. The decisions shouldn't be made by > hand in the first place. The only acceptable ways to process > a message to a standardization mailing list are > > (1) to immediately pass it through unchanged to the subscribers or > (2) to immediately bounce it. > > The decision between #1 and #2 must be made by objective > standards. The bounces must clearly and thoroughly explain > the standards. The standards must allow the sender to > straightforwardly arrange for #1. > > ---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: > -- 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 Nov 27 20:17:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04550 for ; Wed, 27 Nov 2002 20:17:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HDFS-0005y0-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 17:13:46 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18HDFA-0005wp-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 17:13:28 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gAS1DAk13480; Wed, 27 Nov 2002 17:13:10 -0800 (PST) Date: Wed, 27 Nov 2002 17:13:10 -0800 (PST) Message-Id: <200211280113.gAS1DAk13480@guava.araneus.fi> To: Dean Anderson Cc: Greg Hudson , namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: References: <1038433686.1211.210.camel@error-messages.mit.edu> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > It would make the standards transaction more intellectually honest. > > But I still think the changes are dubious. I assert that the AXFR > protocol and semantics should not need to be changed in order to do IXFR. These are not protocol changes. The one and only protocol change specified by the draft is that of marking the end of a transfer by sending the SOA rather than the apex node, since the former is what every implementation does. Everything else in the draft is specifying things that were previously left unspecified. > I think tampering with AXFR is risky, and not well understood. I belive I have a pretty good understanding of AXFR after implementing it in four different name servers for three different companies and reapeatedly having to deal with the consequences of the underspecification in RFC1034/1035. I find that it is far more risky to leave the protocol as vague as it is than to specify it in detail. As for "tampering", you might as well say that this whole IETF thing is a bad idea - after all, tampering with the Internet is risky and not well understood. -- 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 Nov 27 21:00:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05541 for ; Wed, 27 Nov 2002 21:00:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HDwB-0007t4-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 17:57:55 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #2) id 18HDw9-0007qN-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 17:57:53 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id gAS1ujq23999 for ; Wed, 27 Nov 2002 20:56:45 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAuKaW3U; Wed, 27 Nov 02 20:56:45 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002112720572104070 for ; Wed, 27 Nov 2002 20:57:21 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gAS1vGf02426 for ; Wed, 27 Nov 2002 20:57:16 -0500 (EST) Message-ID: <3DE577C4.4FAA2846@daimlerchrysler.com> Date: Wed, 27 Nov 2002 20:56:20 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify References: <20021127174104.41801.qmail@cr.yp.to> <3DE52984.219E825A@daimlerchrysler.com> <20021128002526.68429.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Kevin Darcy writes: > > you've been bending the _de_facto_ rules in these regards (e.g. > > "section agnosticism" or whatever you call it) > > How is it possible for people to be so fundamentally confused about such > a simple issue? > > RFC 1034 says that the AXFR server sends ``messages'' that ``carry'' all > the records. This is ambiguous: does ``carry'' refer to all sections of > the message, or is it restricted to the answer section? You're only reinforcing the need for a Clarify draft. > I decided to take the safest possible interpretation: > > * My AXFR _server_ puts all records in the answer section, just in > case some clients look only at the answer section. > > * My AXFR _client_ reads all sections, just in case some servers use > other sections. Okay, Dan, I appreciate now that you were just trying to be cautious in your client. But the threat that you protected against never actually materialized, and at the same time the mechanism you used to protect against it appears to have made an implicit assumption -- that non-Answer sections of an AXFR response would never be used productively -- which turned out to be false because of things like EDNS0 and TSIG. No-one blames you for having less-than-perfect foresight. But when the DNS world changes, sometimes old assumptions are invalidated and code which is based on those assumptions needs to change or become non-standards-compliant. The proposed AXFR Clarify draft, inasmuch as it seeks to accommodate relatively recent developments like EDNS0 and TSIG, not to mention future extensions, with its "must ignore" provisions, seems to be incompatible with the behavior of your AXFR client. Something has to give here. The question is: is your codebase the "immovable object" which prevents AXFR from being clarified in this way, or is AXFR Clarify the "irresistible force" which requires you to change your code in order to maintain standards-compliance? As inconvenient as it may be for you and the users of your DNS package, I think the rough concensus here is for the latter. The alternative is for AXFR to remain under-specified *indefinitely*, thus leading to more interoperability problems in future implementations. Let's move forward here. - 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 Wed Nov 27 21:01:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05567 for ; Wed, 27 Nov 2002 21:01:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HDtv-0007ht-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 17:55:35 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18HDts-0007hd-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 17:55:32 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gAS1tTv13517; Wed, 27 Nov 2002 17:55:29 -0800 (PST) Date: Wed, 27 Nov 2002 17:55:29 -0800 (PST) Message-Id: <200211280155.gAS1tTv13517@guava.araneus.fi> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <20021128002526.68429.qmail@cr.yp.to> References: <20021127174104.41801.qmail@cr.yp.to> <3DE52984.219E825A@daimlerchrysler.com> <20021128002526.68429.qmail@cr.yp.to> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk D. J. Bernstein writes: > The BIND company's ``clarification'' does two things: > > * It requires _servers_ to use the careful _server_ strategy. I have > no objection to this: it's what servers are already doing, it is > necessary for interoperability with careless clients, and it > removes a frivolous source of variability in the protocol. > > * It prohibits _clients_ from using the careful _client_ strategy. I > object to this: it is _not_ consistent with the installed base, and > it is _not_ necessary for interoperability. We have been over all this before. At the risk of repeating myself: What you say is true, but it is a rather selective view of the truth. As far as I know, the client behavior specified in the draft is consistent with the entire installed base with the sole exception of djbdns. Although it is not necessary for interoperability of the base protocol, it is necessary in order to support protocol extensions that send out-of-band data in sections other than the answer section, such as TSIG signed transfers. I also wouldn't use the word "careful" to describe the indiscriminate conglomeration of data from arbitrary sections of the response, but I suppose that is a matter of taste. -- 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 Nov 27 22:13:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07026 for ; Wed, 27 Nov 2002 22:13:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HF1J-000Ai3-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 19:07:17 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #2) id 18HF1H-000Ahi-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 19:07:15 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id gAS36D47027475 for ; Wed, 27 Nov 2002 19:06:13 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Wed, 27 Nov 2002 19:07:11 -0800 Message-ID: From: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: namedroppers mismanagement, continued Date: Wed, 27 Nov 2002 19:07:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0078_01C29660.3BECD9C0"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.0 required=5.0 tests=EXCHANGE_SERVER,MISSING_HEADERS,MISSING_OUTLOOK_NAME, SPAM_PHRASE_00_01,TO_EMPTY version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0078_01C29660.3BECD9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > This list is NOT the place for this bitch fest. > > Now lets get back to something more important like > arguing over DNS SEC. ;) Yes, please continue this discussion on alt.flame where the other Kevin Darcy will be pleased to discuss the issue at interminable length. Perhaps Dan's list of roots could be posted to the same news group, might liven up the discussion a little. Phill ------=_NextPart_000_0078_01C29660.3BECD9C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTEyODAy NTkxOFowIwYJKoZIhvcNAQkEMRYEFD9ha/xQevnYxuwtrm9Br59nVWiEMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAPZOXN1qQ6Y7B1+OQ/AUDWipEfox2aVhOk4kdm0Tq5M2W6+aO lPEzJ3AoURRRjeBFSitl8JliI9LKTUHPke43WTlhcwssssUvN+holW04vAmUF2e6DST766gczNFL qpCGCaJLXin4f1VW9V73Ic9YpIfm5kKswe1WObzeQv/DVCoAAAAAAAA= ------=_NextPart_000_0078_01C29660.3BECD9C0-- -- 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 Nov 27 23:07:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08288 for ; Wed, 27 Nov 2002 23:07:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HFnY-000CtG-00 for namedroppers-data@psg.com; Wed, 27 Nov 2002 19:57:08 -0800 Received: from mx04.gis.net ([208.218.130.12] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18HFnV-000Csm-00 for namedroppers@ops.ietf.org; Wed, 27 Nov 2002 19:57:05 -0800 Received: from tecotoo.www.gis.net ([63.214.98.223]) by mx04.gis.net; Wed, 27 Nov 2002 22:57:02 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ia029388 for ; Wed, 27 Nov 2002 22:59:08 -0500 Message-Id: <4.3.1.2.20021127224733.0381c580@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 27 Nov 2002 22:57:48 -0500 To: Dean Anderson , Kevin Darcy From: Danny Mayer Subject: Re: in support of axfr-clarify Cc: namedroppers@ops.ietf.org In-Reply-To: References: <3DE54582.1C9704ED@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_00_01,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 06:16 PM 11/27/02, Dean Anderson wrote: >On Wed, 27 Nov 2002, Kevin Darcy wrote: > >A clarification should define the common way its done, the way it was >reasonably and commonly understood by readers the original document. Right. However, if the original document is unclear then different implementors will have implemented differently, resulting in interoperatibility problems. By clarifying you necessarily make some of those implementations non-compliant. You can't clarify without breaking something. > > > It seems highly inappropriate to make seemingly gratiutous changes in a > > > particular commercial product, begin distributing those changes to users, > > > and then attempt to change the standards to reflect the changes, and > > > describing those changes as a "clarification". > > > > I dispute that the changes are "gratuitous", that BIND is "a commercial > product" > >Vixie asserts a trademark on "BIND". Though I'm not convinced its really >valid, since it was in the public domain by UCB. Trademarks are only >valid if used in commerce. .: Bind is a commercial product. That's an untrue statement. You can trademark anything without it being a commercial product. I don't know if Paul has made any trademark claim with repect to BIND, though it would be on behalf of ISC. >I guess "gratuitous" is rather vague. I should say that I think IXFR >should be changed instead of AXFR, and that I'm not convinced that any >protocol/semantic changes are really necessary to make this work. Rather >than accept these changes to AXFR, I think the implementors should give it >more thought. You can't do IXFR unless AXFR is clear and unambiguous. Incremental makes no sense without that. Are you going to negotiate the type of data to be sent based on everyone else's different interpretation of the spec? Danny -- 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 Nov 28 06:38:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25704 for ; Thu, 28 Nov 2002 06:38:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HMqk-0000LN-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 03:28:54 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 18HMqi-0000KL-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 03:28:52 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 0970C137F02; Thu, 28 Nov 2002 03:28:38 -0800 (PST) To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: Message from "D. J. Bernstein" of "28 Nov 2002 00:25:26 GMT." <20021128002526.68429.qmail@cr.yp.to> Date: Thu, 28 Nov 2002 03:28:38 -0800 Message-ID: <65409.1038482918@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "djb" == D J Bernstein writes: djb> RFC 1034 says that the AXFR server sends ``messages'' that djb> ``carry'' all the records. This is ambiguous I'm perplexed. You accept RFC1034 is ambiguous on the subject of zone transfers. Fine. So why are you objecting to a draft which clarifies the specification and eliminates that ambiguity? -- 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 Nov 28 12:12:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00718 for ; Thu, 28 Nov 2002 12:12:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HS5t-000AFW-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 09:04:53 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18HS5r-000AFG-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:04:52 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09933; Thu, 28 Nov 2002 10:04:50 -0700 (MST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gASH4mH13641; Thu, 28 Nov 2002 18:04:49 +0100 (MET) Date: Thu, 28 Nov 2002 18:01:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: namedroppers mismanagement, continued To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I don't care whether Bush's decisions can be adequately explained by > stupidity. The decisions shouldn't be made by hand in the first place. > The only acceptable ways to process a message to a standardization > mailing list are > > (1) to immediately pass it through unchanged to the subscribers or > (2) to immediately bounce it. > > The decision between #1 and #2 must be made by objective standards. The > bounces must clearly and thoroughly explain the standards. The standards > must allow the sender to straightforwardly arrange for #1. I disagree that there is no room for human beings filtering out spam. Your approach means that an IETF participant can't cross-post messages to mailing lists to which s/he is not subscribed, which I think would make inter-WG coordination much more difficult when we need to make it easier. 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 Nov 28 12:13:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00755 for ; Thu, 28 Nov 2002 12:13:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HS0e-000A3Q-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 08:59:28 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18HS0c-000A3E-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 08:59:26 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07026; Thu, 28 Nov 2002 09:59:23 -0700 (MST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gASGxMH12799; Thu, 28 Nov 2002 17:59:22 +0100 (MET) Date: Thu, 28 Nov 2002 17:56:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: namedroppers mismanagement, continued To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Bush imposed his mailing-list control methods without IESG approval, in > violation of RFC 2418, section 3.2. Dan, The spam filtering applied to the namedroppers list is consistent with the IESG policy on spam control at http://www.ietf.org/IESG/Statements.html > What's stopping him from selectively delaying or discarding messages > that he doesn't like? How can we tell whether these were actually > ``mistakes''? Messages sent by subscribers to the list, or from addresses that have been explicitly requested to be added to the exception list of automatically approved non-subscriber posters, are sent to the list without any manual review. The manual review only applies to non-subscriber postings with the intent of filtering out spam that isn't caught by the automatic spam filtering, while allowing occasional messages, such as WG cross postings, to get through. However, any frequent posters to the list should either post from their subscription address or ask to be added to the exception list. 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 Nov 28 12:28:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01044 for ; Thu, 28 Nov 2002 12:28:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HSMk-000B1H-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 09:22:18 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HSMi-000B11-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:22:17 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HSMf-000Gcz-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:22:13 -0800 Message-ID: <20021128102107.75560.qmail@cr.yp.to> References: <200211280030.gAS0UYgU009457@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 28 Nov 2002 10:21:07 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=-0.2 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Mark.Andrews@isc.org writes: > This is why you MUST preserve zone contents with AXFR. No. If a screwy configuration causes problems with the deployed AXFR protocol, the solution is to outlaw the configuration, not to demand that the entire universe deploy new software. Is interoperability such a difficult concept to grasp? If you want a new protocol, use a new query type. Using the existing AXFR type is clearly malicious: you're trying to hurt other implementors and users. ---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 Nov 28 12:47:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01385 for ; Thu, 28 Nov 2002 12:47:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HSiI-000Btw-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 09:44:34 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HSiF-000Btj-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:44:32 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HSiF-000GiN-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:44:31 -0800 Message-ID: <20021128110429.82052.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 28 Nov 2002 11:04:29 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Kevin Darcy writes: > incanting "but it won't interoperate with my implementation!" as if > it were some sort of religious mantra Interoperability is incredibly important in the real world. You have no right to go creating interoperability problems where none exist today. > No, the purpose of clarifying AXFR is not to spread a "big tent" that > accommodates the idiosyncratic behavior of every AXFR implementation > out there. Such a specification, if it is possible at all, would be > so watered down it would be useless. That's absurd. In fact, many future implementors would benefit from an accurate specification of the existing AXFR protocol. This does _not_ mean screwing up interoperability. It does _not_ mean documenting irrelevant BIND 9 implementation details as if they were the protocol. > (as DJB's server apparently does, because he considers AXFR > client/server transactions to be "local matter[s]" rather than > something to be governed by protocol, go figure). When did I ever say that local protocols aren't protocols? What I'm saying is that unauthorized users like you have no right to demand a response---or even to try to participate in the protocol in the first place. The protocol is for authorized users. > The general rules also say that if a server declines to answer a query > for some administratively-defined reason, it sends back an approriate > RCODE No, the specifications don't say that. Servers can say REFUSED if they want to, but there's no rule saying that they have to. > the Authority and Additional sections are reserved for > specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.) AXFR responses include glue, remember? A server implementor who doesn't investigate existing practice could reasonably interpret RFC 1034 as _requiring_ use of the additional section. That would, in turn, cause failures with careless clients that don't look at the additional section. I support requiring the careful server behavior. I object to prohibiting the careful client behavior. Analogy that I pointed out last year: RFC 2821 clearly prohibits SMTP clients from sending non-ASCII header bytes, but clearly allows SMTP servers to accept those bytes. ---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 Nov 28 12:48:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01418 for ; Thu, 28 Nov 2002 12:48:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HSkf-000C3y-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 09:47:01 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HSkd-000C3j-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:46:59 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HSkc-000Gj0-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:46:58 -0800 Message-ID: <20021128112620.85306.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 28 Nov 2002 11:26:20 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] BIND company employee Danny Mayer writes: > You can't clarify without breaking something. That's absurd. Right now, because the specifications are unclear, implementors have to spend a lot of time investigating how the protocol actually works. Most of us have been very careful about this; consequently, there have been very few AXFR interoperability problems. (The ``non-glue records'' bug introduced in BIND 8.2.3 is an exception.) We can save tons of time for future implementors, and reduce the chance of future interoperability problems, by clarifying the existing AXFR protocol. This need not, and should not, break anything. If there were a current interoperability problem between two deployed pieces of software, and if both implementors claimed to be right, then we'd have to resolve the conflict one way or another, after evaluating the costs of each approach. But that's not the situation here. You're wrong when you suggest that all differences between implementations are interoperability problems. > can't do IXFR So fix IXFR. Stop demanding that _my_ users pay to make _your_ silly protocol extensions work. Compatibility is not rocket science. > You can trademark anything without it being a commercial product. An applicant for a trademark must declare that he is using, or intends to use, the mark in commerce. See 37 C.F.R. 2.33. ---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 Nov 28 12:49:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01446 for ; Thu, 28 Nov 2002 12:49:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HSlD-000C4t-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 09:47:35 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HSlC-000C4f-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:47:34 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HSlB-000GjJ-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 09:47:33 -0800 Message-ID: <20021128114055.87612.qmail@cr.yp.to> References: <20021127174104.41801.qmail@cr.yp.to> <3DE52984.219E825A@daimlerchrysler.com> <20021128002526.68429.qmail@cr.yp.to> <3DE577C4.4FAA2846@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 28 Nov 2002 11:40:55 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Kevin Darcy writes: > You're only reinforcing the need for a Clarify draft. I've been saying for years that the DNS specifications are horribly inadequate. I thought axfr-clarify sounded like a great idea until I read the document and discovered twelve problems. Two of those problems have now been fixed; ten more to go. > an implicit assumption -- that non-Answer sections of an AXFR response > would never be used productively -- which turned out to be false > because of things like EDNS0 and TSIG. These issues have been discussed before. First, contrary to your claim, there is no evidence of an actual problem. Second, and more importantly, if an optional protocol extension fails to ensure compatibility with the previous protocol, that is entirely the extension's fault. As I wrote when we last discussed this in July 2001, after you asked why I wasn't changing my code: The benefits are nonexistent. The harms include encouraging further disregard for compatibility. What stops incompetent implementors from demanding another code change every week? Ignore AXFR AR, discard TKEY, ignore types 128-255, recognize IXFR, ignore MS garbage. This is not a sane way to handle optional protocol extensions. Is compatibility such a difficult concept to grasp? ---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 Nov 28 16:28:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04708 for ; Thu, 28 Nov 2002 16:28:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HW78-000LFW-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 13:22:26 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18HW73-000LEb-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 13:22:22 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gASLMAgU020779; Fri, 29 Nov 2002 08:22:11 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211282122.gASLMAgU020779@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: in support of axfr-clarify In-reply-to: Your message of "28 Nov 2002 10:21:07 -0000." <20021128102107.75560.qmail@cr.yp.to> Date: Fri, 29 Nov 2002 08:22:10 +1100 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * 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 mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Mark.Andrews@isc.org writes: > > This is why you MUST preserve zone contents with AXFR. > > No. If a screwy configuration causes problems with the deployed AXFR > protocol, the solution is to outlaw the configuration, not to demand > that the entire universe deploy new software. There is nothing "screwy" about that configuration. It and others like it happen all the time in large organisations. Can't you see that any implementation that CHANGES the contents of a zone and then transfers it is BROKEN. The purpose of AXFR it to transfer the zone unaltered between server. If the server doesn't maintain the zone it is no longer transfering the zone. BIND 4 and BIND 8 AXFR implementations have ALWAYS been broken as they change the replace parts of the zones contents silently. > Is interoperability such a difficult concept to grasp? If you want a new > protocol, use a new query type. Using the existing AXFR type is clearly > malicious: you're trying to hurt other implementors and users. The server behaviour was under specified. Common sense says that you have to maintain the zone contents if you are going to be part of a zone transfer graph. Clarifications are EXPECTED to correct mis-implementations. We mis-implemented AXFR for years (and still do in BIND 4 and BIND 8). Mark > ---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: -- 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 Nov 28 16:33:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04844 for ; Thu, 28 Nov 2002 16:32:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HWCn-000LW5-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 13:28:17 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18HWCh-000LVr-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 13:28:12 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gASLS3gU020803; Fri, 29 Nov 2002 08:28:03 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211282128.gASLS3gU020803@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: in support of axfr-clarify In-reply-to: Your message of "28 Nov 2002 11:04:29 -0000." <20021128110429.82052.qmail@cr.yp.to> Date: Fri, 29 Nov 2002 08:28:03 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 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 mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Kevin Darcy writes: > > incanting "but it won't interoperate with my implementation!" as if > > it were some sort of religious mantra > > Interoperability is incredibly important in the real world. You have no > right to go creating interoperability problems where none exist today. > > > No, the purpose of clarifying AXFR is not to spread a "big tent" that > > accommodates the idiosyncratic behavior of every AXFR implementation > > out there. Such a specification, if it is possible at all, would be > > so watered down it would be useless. > > That's absurd. In fact, many future implementors would benefit from an > accurate specification of the existing AXFR protocol. This does _not_ > mean screwing up interoperability. It does _not_ mean documenting > irrelevant BIND 9 implementation details as if they were the protocol. > > > (as DJB's server apparently does, because he considers AXFR > > client/server transactions to be "local matter[s]" rather than > > something to be governed by protocol, go figure). > > When did I ever say that local protocols aren't protocols? What I'm > saying is that unauthorized users like you have no right to demand a > response---or even to try to participate in the protocol in the first > place. The protocol is for authorized users. RFC 1034 says to send REFUSED not drop the connection. Please fix your BROKEN implemetation as it is not RFC 1034 compliant. When the poll shows that the zone has changed, then the secondary server must request a zone transfer via an AXFR request for the zone. The AXFR may cause an error, such as refused, but normally is answered by a sequence of response messages. The first and last messages must contain the data for the top authoritative node of the zone. Intermediate messages carry all of the other RRs from the zone, including both authoritative and non-authoritative RRs. The stream of messages allows the secondary to construct a copy of the zone. Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. > > > The general rules also say that if a server declines to answer a query > > for some administratively-defined reason, it sends back an approriate > > RCODE > > No, the specifications don't say that. Servers can say REFUSED if they > want to, but there's no rule saying that they have to. > > > the Authority and Additional sections are reserved for > > specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.) > > AXFR responses include glue, remember? A server implementor who doesn't > investigate existing practice could reasonably interpret RFC 1034 as > _requiring_ use of the additional section. That would, in turn, cause > failures with careless clients that don't look at the additional section. > > I support requiring the careful server behavior. I object to prohibiting > the careful client behavior. > > Analogy that I pointed out last year: RFC 2821 clearly prohibits SMTP > clients from sending non-ASCII header bytes, but clearly allows SMTP > servers to accept those bytes. > > ---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: -- 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 Nov 28 21:08:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08562 for ; Thu, 28 Nov 2002 21:08:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HaRm-0008OI-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 18:00:02 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HaRj-0008NM-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 17:59:59 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HaRi-000I34-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 17:59:58 -0800 Message-ID: <20021128222538.28764.qmail@cr.yp.to> References: <20021128110429.82052.qmail@cr.yp.to> <200211282128.gASLS3gU020803@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 28 Nov 2002 22:25:38 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 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 mis-posts. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or fix subscription your subscription address! ] Mark.Andrews@isc.org writes: [ quoting RFC 1034 ] > the secondary server must request a zone transfer via an AXFR request > for the zone. The AXFR may cause an error, such as refused, but > normally is answered See how this starts by saying that the SECONDARY SERVER does something? You are not the secondary server. You have no authorization to even ask for AXFR, let alone demand an answer. Of course, there's also no support in RFC 1034 for your strange claim that a closed connection is not ``an error.'' (As an engineering matter, every protocol has to allow connections to be closed. Even when limiting unauthorized resource use isn't an issue, hosts can and do crash. Forbidding this would be idiotic.) ---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 Nov 28 22:19:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09580 for ; Thu, 28 Nov 2002 22:19:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hbcl-000CKQ-00 for namedroppers-data@psg.com; Thu, 28 Nov 2002 19:15:27 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Hbci-000CKD-00 for namedroppers@ops.ietf.org; Thu, 28 Nov 2002 19:15:24 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gAT3FHgU023121; Fri, 29 Nov 2002 14:15:17 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211290315.gAT3FHgU023121@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify supporting unauthorized users In-reply-to: Your message of "28 Nov 2002 22:25:38 -0000." <20021128222538.28764.qmail@cr.yp.to> Date: Fri, 29 Nov 2002 14:15:17 +1100 X-Spam-Status: No, hits=0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 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 mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Mark.Andrews@isc.org writes: > [ quoting RFC 1034 ] > > the secondary server must request a zone transfer via an AXFR request > > for the zone. The AXFR may cause an error, such as refused, but > > normally is answered > > See how this starts by saying that the SECONDARY SERVER does something? > You are not the secondary server. You have no authorization to even ask > for AXFR, let alone demand an answer. So. Do you claim that your server returns REFUSED to a server that is *supposed* to be a SECONDARY when the PRIMARY is misconfigured? If it doesn't it would appear to be in violation of RFC 1034. > Of course, there's also no support in RFC 1034 for your strange claim > that a closed connection is not ``an error.'' Closing a connection is not sending back a error message. It is just "closing a connection". The caller has know knowledge of why the connection failed. > (As an engineering matter, every protocol has to allow connections to be > closed. Even when limiting unauthorized resource use isn't an issue, > hosts can and do crash. Forbidding this would be idiotic.) We are not forbidding it. RFC 1035 says that the client should initiate the closure. The server should only do it in the face of resourse starvation or when the connection has been idle for several minutes. Having the server close the connection immediately on reciept of a AXFR request doesn't meet these conditions. Client initiation is better for most IP stacks. The client can't initiate closure unless it is told that it in not going to get a AXFR. Follow the protocol. Let the client initiate the closure. RFC 1035 4.2.2. TCP usage Messages sent over TCP connections use server port 53 (decimal). The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. This length field allows the low-level processing to assemble a complete message before beginning to parse it. Several connection management policies are recommended: - The server should not block other activities waiting for TCP data. - The server should support multiple connections. - The server should assume that the client will initiate connection closing, and should delay closing its end of the connection until all outstanding client requests have been satisfied. - If the server needs to close a dormant connection to reclaim resources, it should wait until the connection has been idle for a period on the order of two minutes. In particular, the server should allow the SOA and AXFR request sequence (which begins a refresh operation) to be made on a single connection. Since the server would be unable to answer queries anyway, a unilateral close or reset may be used instead of a graceful close. > > ---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: -- 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 Nov 29 10:38:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01833 for ; Fri, 29 Nov 2002 10:38:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hn3P-000HiD-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 07:27:43 -0800 Received: from pcp816583pcs.nrockv01.md.comcast.net ([68.49.62.108] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18Hn3N-000Hi0-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 07:27:41 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id gATFRPm04360; Fri, 29 Nov 2002 10:27:25 -0500 (EST) (envelope-from ogud@ogud.com) Date: Fri, 29 Nov 2002 10:27:25 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Dean Anderson cc: "D. J. Bernstein" , , , DNSEXT mailing list Subject: Re: namedroppers mismanagement, continued In-Reply-To: Message-ID: <20021129100605.T4318-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Dean Anderson wrote: > I am not on the ietf or iesg list. I don't know if this will go through to > those lists. > > While DJB may also have some subscription issue, that is not the > fundamental problem. > > It seems from your comments below, that you think that Randy isn't > manually blocking/forwarding messages from subscribed addresses. However, > that it not true. As of early this year the policy of the list was changed from "moderation" to "subscriber automated posting". Bringing up ancient history is not productive as that issue has been addressed. Randy is currently wasting valuable time in manually scanning 100+ spams a day that are sent to namedroppers and other IETF mailing lists he runs and we all should thank him for the good citizen service he provides! Every meesage that is reposted from the bounced list contains a header explaining that posting address is not a subscribed address. I agree that the feature to get a message back saying that a message is waiting for manual moderation is good, it requires effort for the list operator to set up. In my personal case I get few of these messages each month in response to viral attempts to post messages as me on random mailing lists. > > The real problem is that Randy sometimes don't post messages from people > he doesn't like or on topics he has an interest in, even when they are > posted from subscribed addresses. This has happened to me several times. > One of the occasions where it happened to me is documented on Bernstein's > web page. It has probably happened many more times that haven't made it > on DJB's webpage. Ancient history. > > There seems to be no reason that Randy should set himself up as a > moderator, or any reason whatsoever there should be any manual > intervention on posting from subscribed addresses. Do you agree? Yes, this is the CURRENT list policy. Thus the only messages that are affected are from non subscribers and people posting from different address. In response the some points raised in this thread two changes will happen: - Montly namedroppers list policy message will contain statement on the posting policy. - Moderated messages will contain more informative instructions on how to avoid moderation. Olafur (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 Fri Nov 29 13:40:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05344 for ; Fri, 29 Nov 2002 13:40:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HpyA-000MG1-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 10:34:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Hpy6-000MFo-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 10:34:26 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Hpy6-000E6J-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 10:34:26 -0800 Message-ID: <20021129180339.70455.qmail@cr.yp.to> References: <20021128222538.28764.qmail@cr.yp.to> <200211290315.gAT3FHgU023121@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 29 Nov 2002 18:03:39 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_03_05 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Mark.Andrews@isc.org writes: > Do you claim that your server returns REFUSED to a server that is > *supposed* to be a SECONDARY when the PRIMARY is misconfigured? RFC 1034 says ``secondary server,'' not ``any clueless twit who _thinks_ he's a secondary server.'' The list of clients authorized to ask a server for zone transfers is entirely up to the server. (As you know, this list is generally _not_ the same as the NS list published in DNS.) > > Of course, there's also no support in RFC 1034 for your strange claim > > that a closed connection is not ``an error.'' > Closing a connection is not sending back a error message. On the contrary. I agree that FIN is, in this context, not a particularly _informative_ error message, but REFUSED and SERVFAIL aren't particularly informative either; they carry only marginally more information than FIN. Anyone who doesn't understand why his AXFR attempt was rejected will have to ask the server administrator. Anyway, as an unauthorized user, you have no right to ask for AXFR in the first place, let alone demand an answer, let alone demand an _informative_ answer. [ quoting RFC 1035 ] > Several connection management policies are recommended: [ ... ] > The server should assume that the client will initiate connection > closing, and should delay closing its end of the connection until all > outstanding client requests have been satisfied. This doesn't say that servers should be polite to attackers trying to grab AXFR results without authorization, or to other clients violating the protocol. Maybe BIND 9 tries to leave the connection open no matter what, but that's an implementation decision, not a protocol requirement. Please stop trying to force everybody else to imitate what BIND 9 does. (Also, please stop pretending that ``recommended'' means ``required.'') ---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 Fri Nov 29 13:49:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05518 for ; Fri, 29 Nov 2002 13:49:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hq5n-000MXx-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 10:42:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Hq5k-000MXZ-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 10:42:20 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Hq5k-000E8t-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 10:42:20 -0800 Message-ID: <20021129183900.89964.qmail@cr.yp.to> References: <20021127174104.41801.qmail@cr.yp.to> <3DE52984.219E825A@daimlerchrysler.com> <20021128002526.68429.qmail@cr.yp.to> <200211280155.gAS1tTv13517@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 29 Nov 2002 18:39:00 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: careless protocol extensions X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_03_05 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] All of this was discussed in detail a long time ago. In any legitimate standards organization, the results of that discussion would have been recorded for future reference. Andreas Gustafsson writes: > Although it is not necessary for interoperability of the base > protocol, it is necessary in order to support protocol extensions that > send out-of-band data in sections other than the answer section, such > as TSIG signed transfers. No, it is not necessary. Backwards compatibility is not rocket science. Servers must not---and, according to you, BIND does not---send TSIG junk to clients that haven't indicated that they want it. (I have no desire to support TSIG; IPSEC is a vastly better solution.) If the TSIG specification fails to impose this basic interoperability requirement, then that's a bug in the TSIG specification. It is the responsibility of optional protocol extensions to maintain perfect compatibility with the unextended protocol. The alternative---forcing the entire Internet to change its software for every careless protocol extension that comes along---is insane. How would you like it if Microsoft wrote an RFC on some incompatible protocol extension, hid the interoperability problems until the RFC was published as an elective Proposed Standard, and then demanded that every BIND installation be ``upgraded'' to deal with the junk produced by that protocol extension? How do you think your users would like it? ---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 Fri Nov 29 14:13:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05913 for ; Fri, 29 Nov 2002 14:13:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HqWD-000N9l-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 11:09:41 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #2) id 18HqWB-000N9Y-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 11:09:39 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA29488; Fri, 29 Nov 2002 14:09:37 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA05524; Fri, 29 Nov 2002 14:06:06 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id OAA05339; Fri, 29 Nov 2002 14:02:22 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id OAA30277; Fri, 29 Nov 2002 14:02:21 -0500 Subject: Re: axfr-clarify supporting unauthorized users From: Greg Hudson To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org In-Reply-To: <20021129180339.70455.qmail@cr.yp.to> References: <20021128222538.28764.qmail@cr.yp.to> <200211290315.gAT3FHgU023121@drugs.dv.isc.org> <20021129180339.70455.qmail@cr.yp.to> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 29 Nov 2002 14:02:21 -0500 Message-Id: <1038596541.1232.221.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=2.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SPAM_PHRASE_03_05, X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-11-29 at 13:03, D. J. Bernstein wrote: > On the contrary. I agree that FIN is, in this context, not a > particularly _informative_ error message, but REFUSED and SERVFAIL > aren't particularly informative either; they carry only marginally more > information than FIN. Anyone who doesn't understand why his AXFR attempt > was rejected will have to ask the server administrator. If you receive a REFUSED message from the server, there is pretty much only one explanation: the server doesn't have you configured as an authorized secondary. If the connection is closed, there are several explanations: the server is djbdns and doesn't have you configured as an authorized secondary, the server process crashed and the kernel closed the connection, the server is running through a misconfigured inetd or tcpserver. I don't think a reasonable implementor can construe a TCP FIN as an error message. > Anyway, as an unauthorized user, you have no right to ask for AXFR in > the first place, let alone demand an answer, let alone demand an > _informative_ answer. You say this a lot, but you're only considering one possible case: the requestor is a twit with no legitimate relationship to the primary. A more interesting case is when the primary or secondary is accidentally misconfigured. Contrary to what you've said before, making it easier to detect common misconfigurations is an important aspect of interoperability. -- 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 Nov 29 14:50:08 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06595 for ; Fri, 29 Nov 2002 14:50:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hr27-000Nnv-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 11:42:39 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 18Hr23-000Nni-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 11:42:35 -0800 Received: from sandelman.ottawa.on.ca (1Cust171.tnt24.toronto.on.da.uu.net [64.10.101.171]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gATJexi05723 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 29 Nov 2002 14:41:16 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gATJdcFR001521 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 29 Nov 2002 14:39:40 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gATG8Jcr003300 for ; Fri, 29 Nov 2002 11:09:19 -0500 Message-Id: <200211291609.gATG8Jcr003300@sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-reply-to: Your message of "27 Nov 2002 04:58:02 GMT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 29 Nov 2002 11:08:19 -0500 From: Michael Richardson X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Vixie writes: Paul> which is that a delegation point is owned by the child zone and the parent Paul> can at best send delegations, never answers and never authoritative, when Paul> queried for things at a child zone's delegation point. bind9 does this Paul> correctly. an apparently common misunderstanding as to the contents of a Paul> zone is that data can be copied from a child without changing the identity Paul> of the parent. this is just false, and is indicative of other conceptual Paul> errors. I agree strongly with you on this - delegations belong to the child. What about DS? The problems identified at the workshop stem PRECISELY from the problems with who is authoritative for the DS record. A hack was proposed, whereby the DS record for example.com would be actually named as _ds_example.com. This restores the principle that you outline above. it would be very nice if we could come up with a solution to the DS problem doesn't violate this principal. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPeeQ8YqHRg3pndX9AQHk7QQAwHU8+i6q8dY2VaZx+zfu7brVS+b02j/a 7PlynC7Fype5616zK44EssmvRuSBZQovLZz620AhtfRSH6x/W908xl7It2A8/v3R i3RPX9Za+cqjoNIra1RkE5Uv0tUgzA8wiQVrRNNuNGwQN6xsgc+f+AN0GHEZKd05 6oSKMS+tQDI= =5XiK -----END PGP SIGNATURE----- -- 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 Nov 29 17:00:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09199 for ; Fri, 29 Nov 2002 17:00:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ht6h-0000AG-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 13:55:31 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Ht6e-00009v-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 13:55:28 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gATLtKgU027672; Sat, 30 Nov 2002 08:55:20 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211292155.gATLtKgU027672@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify supporting unauthorized users In-reply-to: Your message of "29 Nov 2002 18:03:39 -0000." <20021129180339.70455.qmail@cr.yp.to> Date: Sat, 30 Nov 2002 08:55:20 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [ post by non-subscriber. with the massive amount of spam, it is easy to mis > s > and therefore delete posts by non-subscribers. your subscription address i > s > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if yo > u > wish to regularly post from an address that is not subscribed to this > mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to > have the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > Mark.Andrews@isc.org writes: > > Do you claim that your server returns REFUSED to a server that is > > *supposed* to be a SECONDARY when the PRIMARY is misconfigured? > > RFC 1034 says ``secondary server,'' not ``any clueless twit who _thinks_ > he's a secondary server.'' The list of clients authorized to ask a > server for zone transfers is entirely up to the server. (As you know, > this list is generally _not_ the same as the NS list published in DNS.) You didn't answer my question. In this case the ``clueless twit'' is the administator of the PRIMARY. I repeat. "Does your server meet RFC 1034 and return REFUSED under these conditions?" > > > Of course, there's also no support in RFC 1034 for your strange claim > > that a closed connection is not ``an error.'' > > Closing a connection is not sending back a error message. > > On the contrary. I agree that FIN is, in this context, not a > particularly _informative_ error message, but REFUSED and SERVFAIL > aren't particularly informative either; they carry only marginally more > information than FIN. Anyone who doesn't understand why his AXFR attempt > was rejected will have to ask the server administrator. They carry a lot more information when you are trying to diagnose a problem for someone else. I suspect that the DNS admistators of most ISP curse your stupid decision when trying to setup secondary service for one of their customers who is using your servers but forgot to adjust the access controls. Now having that extra infomation really helps them help their customer fix their server. > Anyway, as an unauthorized user, you have no right to ask for AXFR in > the first place, let alone demand an answer, let alone demand an > _informative_ answer. An authorized user does. The ISP above is authorized to transfer the zone. > [ quoting RFC 1035 ] > > Several connection management policies are recommended: > [ ... ] > > The server should assume that the client will initiate connection > > closing, and should delay closing its end of the connection until all > > outstanding client requests have been satisfied. > > This doesn't say that servers should be polite to attackers trying to > grab AXFR results without authorization, or to other clients violating the protocol. Maybe BIND 9 tries to leave the connection open no matter > what, but that's an implementation decision, not a protocol requirement. > Please stop trying to force everybody else to imitate what BIND 9 does. > (Also, please stop pretending that ``recommended'' means ``required.'') Asking for a AXFR is not violating the protocol. > ---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: -- 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 Nov 29 17:23:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09644 for ; Fri, 29 Nov 2002 17:23:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HtSH-0000iI-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 14:17:49 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18HtSD-0000i5-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 14:17:46 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gATMHdgU027738; Sat, 30 Nov 2002 09:17:39 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211292217.gATMHdgU027738@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: careless protocol extensions In-reply-to: Your message of "29 Nov 2002 18:39:00 -0000." <20021129183900.89964.qmail@cr.yp.to> Date: Sat, 30 Nov 2002 09:17:39 +1100 X-Spam-Status: No, hits=0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [ post by non-subscriber. with the massive amount of spam, it is easy to mis > s > and therefore delete posts by non-subscribers. your subscription address i > s > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if yo > u > wish to regularly post from an address that is not subscribed to this > mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to > have the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > All of this was discussed in detail a long time ago. In any legitimate > standards organization, the results of that discussion would have been > recorded for future reference. > > Andreas Gustafsson writes: > > Although it is not necessary for interoperability of the base > > protocol, it is necessary in order to support protocol extensions that > > send out-of-band data in sections other than the answer section, such > > as TSIG signed transfers. > > No, it is not necessary. Backwards compatibility is not rocket science. > Servers must not---and, according to you, BIND does not---send TSIG junk > to clients that haven't indicated that they want it. (I have no desire > to support TSIG; IPSEC is a vastly better solution.) > > If the TSIG specification fails to impose this basic interoperability > requirement, then that's a bug in the TSIG specification. It is the > responsibility of optional protocol extensions to maintain perfect > compatibility with the unextended protocol. The alternative---forcing > the entire Internet to change its software for every careless protocol > extension that comes along---is insane. > > How would you like it if Microsoft wrote an RFC on some incompatible > protocol extension, hid the interoperability problems until the RFC was > published as an elective Proposed Standard, and then demanded that every > BIND installation be ``upgraded'' to deal with the junk produced by that > protocol extension? How do you think your users would like it? > > ---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: No one is trying to force a incompatabile extension on anyone. How is saying that the client should enforce what the server should be enforcing going to create incompatabilities? There is nothing incompatable with saying that servers built from this time on MUST NOT treat records in the authority and additional sections as part of the results of AXFR. We already have servers that enforce this. They have existed since basically the begining. Having servers behave differently in the presence of changes to the spec is *bad*. Specifing what their behaviour is in advance means that the effect of changes can be predicted. Now if anyone is going to add extentions they are also going to need to add knobs to disable the extention. It would just be nice if those knobs rarely need to be changed. Mark -- 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 Nov 29 18:54:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11287 for ; Fri, 29 Nov 2002 18:54:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HurW-0002dz-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 15:47:58 -0800 Received: from sccrmhc01.attbi.com ([204.127.202.61]) by psg.com with esmtp (Exim 3.36 #2) id 18HurU-0002da-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 15:47:56 -0800 Received: from reveille (12-231-159-99.client.attbi.com[12.231.159.99]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2002112923472400100qv0fhe>; Fri, 29 Nov 2002 23:47:25 +0000 Reply-To: From: "Bill Strahm" To: "'D. J. Bernstein'" , Cc: , Subject: RE: namedroppers, continued Date: Fri, 29 Nov 2002 15:46:38 -0800 Message-ID: <002401c29801$92898330$6501a8c0@reveille> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021129232203.63188.qmail@cr.yp.to> Importance: Normal X-Spam-Status: No, hits=1.6 required=5.0 tests=IN_REP_TO,RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Silly question, But you DO know what it will take to get your message to be immediately seen by the list, you just aren't willing to do it... I believe the problem is in your court, easily solved and it is not time to move on to something that might be slightly productive Bill -----Original Message----- From: owner-ietf@IETF.ORG [mailto:owner-ietf@IETF.ORG] On Behalf Of D. J. Bernstein Sent: Friday, November 29, 2002 3:22 PM To: ietf@IETF.ORG Cc: namedroppers@ops.ietf.org; iesg@IETF.ORG Subject: Re: namedroppers, continued Keith claims that allowing ``contributions from outsiders'' requires delay and manual review. That claim is absurd. Immediately bounce the message to the ``outsider,'' with instructions explaining how to have the message sent to subscribers; end of problem. ---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 Fri Nov 29 20:04:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12516 for ; Fri, 29 Nov 2002 20:04:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hvyf-00047x-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 16:59:25 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18Hvyd-00047j-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 16:59:23 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id AF74F37A1C4 for ; Sat, 30 Nov 2002 00:59:22 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: Message from Michael Richardson of "Fri, 29 Nov 2002 11:08:19 EST." <200211291609.gATG8Jcr003300@sandelman.ottawa.on.ca> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Sat, 30 Nov 2002 00:59:22 +0000 Message-Id: <20021130005922.AF74F37A1C4@as.vix.com> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul> ... this is just false, and is indicative of other conceptual errors. > > I agree strongly with you on this - delegations belong to the child. > > What about DS? The problems identified at the workshop stem PRECISELY from > the problems with who is authoritative for the DS record. yes. i've got most of a fix ready to propose. DS as it stands won't work. > A hack was proposed, whereby the DS record for example.com would be > actually named as _ds_example.com. This restores the principle that you > outline above. it would be very nice if we could come up with a solution > to the DS problem doesn't violate this principal. agreed. -- 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 Nov 29 20:35:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13030 for ; Fri, 29 Nov 2002 20:35:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HwWw-0004w5-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 17:34:50 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HwWu-0004vs-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:34:48 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HwWt-0000PR-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:34:47 -0800 Message-ID: <20021129200711.22656.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 29 Nov 2002 20:07:11 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers-owner@ops.ietf.org Cc: namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org Subject: namedroppers, continued X-Spam-Status: No, hits=0.9 required=5.0 tests=RESENT_TO,SPAM_PHRASE_03_05 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Bush stuck the following note into the top of my latest message to namedroppers: [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Okay, Bush: Put djb@cr.yp.to on the list of addresses from which submissions are automatically accepted. Furthermore: Stop publishing private subscription addresses. This includes malicious actions by the list owner, accidents by the list owner, failure to configure the mailing-list software to keep subscription addresses private, etc. Furthermore: When you want to say something to a sender, say it in an immediate bounce message to that sender (which in this case would have been djb-dsn-1038593019.70455@cr.yp.to), not in a stupid editorial note on the top of the sender's message to the list. You're perfectly aware that many senders don't read messages to the list. Furthermore: Stop delaying messages. The delay is unacceptable. The excuse for the delay, namely manual review, is also unacceptable. Under United States antitrust law, standard-setting procedures must ``prevent the standard-setting process from being biased by members with economic interests in stifling product competition''; your reviews plainly flunk this test. ---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 Fri Nov 29 20:36:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13050 for ; Fri, 29 Nov 2002 20:36:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HwUs-0004tI-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 17:32:42 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HwUp-0004t4-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:32:40 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HwUo-0000PE-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:32:38 -0800 Message-ID: <20021129202818.29095.qmail@cr.yp.to> References: <20021128102107.75560.qmail@cr.yp.to> <200211282122.gASLMAgU020779@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 29 Nov 2002 20:28:18 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: how to deploy new zone-transfer protocols X-Spam-Status: No, hits=0.4 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_03_05 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Mark.Andrews@isc.org writes: > There is nothing "screwy" about that configuration. You admit that this configuration doesn't work correctly with the zone-transfer protocol as deployed in most servers. (My current survey shows far more servers running BIND 8 than running BIND 9.) You claim without evidence that this configuration is used ``all the time.'' I'm perfectly willing to accept that some administrators have tried it, but the suggestion that it's popular is simply wrong---even if we ignore the fact that it doesn't work correctly with most servers. Demanding that most DNS server administrators deploy new software, for the sake of a few people who want to try this configuration, is, from an economic perspective, downright stupid. (Of course, from the perspective of a software company trying to squelch competition, it's a good idea.) I'm not trying to say that you have to ignore those people. On the contrary. You can define a new protocol that makes their configuration work. For example: * Allocate a new MMAXFR query type. * Define an MMAXFR response format with all the constraints you want. Note that the response may be from an unextended server that treats MMAXFR as a normal type; remember that you created interoperability problems for IXFR when you screwed this up in BIND 9. * Require master+slave servers that received a zone in MMAXFR format to provide exactly the same bytes in response to an MMAXFR request, and to reject MMAXFR requests if they received the zone in anything other than MMAXFR format. One of the mistakes you made in IXFR was allowing an AXFR-then-IXFR chain. * To prevent zones from being horribly mangled by transfer bugs (such as many of the IXFR implementation bugs), use cryptographic hashes to supplement serial numbers. (For example, the SOA MNAME can start with an MD5 hash of everything else in the MMAXFR response.) You can write software supporting this new protocol, and give that software to the people who care. BUT YOU CANNOT IMPOSE THESE COSTS ON EVERYBODY ELSE. > Can't you see that any implementation that CHANGES the > contents of a zone and then transfers it is BROKEN. ``Can't you see that software that doesn't reliably report replication errors to the zone creator is BROKEN? Can't you see that software that doesn't transmit client-differentiation information (`views') is BROKEN? Can't you see that software that doesn't transmit timestamps (records being created or disappearing at a certain moment) is BROKEN?'' Everybody agrees that the zone-transfer protocol has limitations. That doesn't give you the right to break compatibility. In the words of Kernighan and Pike: ``Change the name if you change the specification.'' You're violating this rule. You're trying to deploy a new AXFR protocol with the same query type as the existing protocol. You're threatening completely unnecessary interoperability problems--- telling people that they can use features of your new protocol as AXFR features, when the existing AXFR protocol says nothing of the sort. ---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 Fri Nov 29 20:37:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13106 for ; Fri, 29 Nov 2002 20:37:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HwXh-0004yV-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 17:35:37 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18HwXf-0004yG-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:35:35 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18HwXe-0000Pd-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:35:34 -0800 Message-ID: <20021129204439.31534.qmail@cr.yp.to> References: <20021128222538.28764.qmail@cr.yp.to> <200211290315.gAT3FHgU023121@drugs.dv.isc.org> <20021129180339.70455.qmail@cr.yp.to> <1038596541.1232.221.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 29 Nov 2002 20:44:39 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Greg Hudson writes: > If the connection is closed, there are several explanations: the server > is djbdns and doesn't have you configured as an authorized secondary, > the server process crashed and the kernel closed the connection, the > server is running through a misconfigured inetd or tcpserver. > I don't think a reasonable implementor can construe a TCP FIN as an > error message. By exactly the same silly argument, SERVFAIL isn't an error message. Maybe the server program ran out of memory; maybe the disk died; maybe the system administrator removed a crucial configuration file; maybe the operating system ran out of file descriptors; etc. > Contrary to what you've said before, making it easier to detect common > misconfigurations is an important aspect of interoperability. By that argument, anybody using AXFR is violating ``interoperability,'' because my recommended use of rsync-over-ssh does a vastly better job of detecting and reporting common misconfigurations. ---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 Fri Nov 29 20:43:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13172 for ; Fri, 29 Nov 2002 20:43:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hwe6-0005BU-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 17:42:14 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Hwe4-0005BI-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:42:12 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Hwe3-0000QY-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:42:11 -0800 Message-ID: <20021129232203.63188.qmail@cr.yp.to> References: <20021129200711.22656.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 29 Nov 2002 23:22:03 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: namedroppers, continued X-Spam-Status: No, hits=-0.2 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Keith claims that allowing ``contributions from outsiders'' requires delay and manual review. That claim is absurd. Immediately bounce the message to the ``outsider,'' with instructions explaining how to have the message sent to subscribers; end of problem. ---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 Fri Nov 29 20:49:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13241 for ; Fri, 29 Nov 2002 20:49:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hwjt-0005O6-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 17:48:13 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Hwjr-0005Nt-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:48:11 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Hwjq-0000Qx-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 17:48:10 -0800 Message-ID: <20021130010111.89535.qmail@cr.yp.to> References: <20021129232203.63188.qmail@cr.yp.to> <002401c29801$92898330$6501a8c0@reveille> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 30 Nov 2002 01:01:11 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: trying to sweep namedroppers mismanagement under the rug X-Spam-Status: No, hits=0.4 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_03_05 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Bill Strahm writes: > I believe the problem is in your court That's patently absurd. It's not _my_ fault that a bunch of messages from _other_ people are being silently discarded. (As I said before, there have been more than 100 messages in the past three months on namedroppers labelled as coming from non-subscribers, only a small fraction of those being mine. Furthermore, Bush has silently discarded several of my recent messages. If we believe Bush's claim that he isn't selectively targeting my messages, the only reasonable conclusion is that he has silently discarded a huge number of messages overall, only a small fraction being mine.) Most namedroppers contributors who don't post from subscription addresses are, presumably, people who don't watch the list at all---for example, people from other lists involved in cross-posted discussions. How are they supposed to find out about the problem? I do tend to watch the list. I noticed the problem. I pointed it out. That doesn't mean I'm the only person with the problem. If the problem is fixed _for me_, but not _for everybody_, then it hasn't gone away. The procedures are still broken. Legitimate messages to namedroppers---potentially quite valuable messages---continue to be thrown away. ---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 Fri Nov 29 21:31:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13804 for ; Fri, 29 Nov 2002 21:31:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HxMM-0006Ke-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 18:27:58 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #2) id 18HxMJ-0006KS-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 18:27:55 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA13160; Fri, 29 Nov 2002 21:27:54 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA17991; Fri, 29 Nov 2002 21:27:53 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id VAA02491; Fri, 29 Nov 2002 21:27:50 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id VAA30436; Fri, 29 Nov 2002 21:27:48 -0500 Subject: Re: axfr-clarify supporting unauthorized users From: Greg Hudson To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org In-Reply-To: <20021129204439.31534.qmail@cr.yp.to> References: <20021128222538.28764.qmail@cr.yp.to> <200211290315.gAT3FHgU023121@drugs.dv.isc.org> <20021129180339.70455.qmail@cr.yp.to> <1038596541.1232.221.camel@error-messages.mit.edu> <20021129204439.31534.qmail@cr.yp.to> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 29 Nov 2002 21:27:48 -0500 Message-Id: <1038623268.1232.258.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=2.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SPAM_PHRASE_00_01, X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-11-29 at 15:44, D. J. Bernstein wrote: > Greg Hudson writes: > > If the connection is closed, there are several explanations: the server > > is djbdns and doesn't have you configured as an authorized secondary, > > the server process crashed and the kernel closed the connection, the > > server is running through a misconfigured inetd or tcpserver. > > > > I don't think a reasonable implementor can construe a TCP FIN as an > > error message. > > By exactly the same silly argument, SERVFAIL isn't an error message. > Maybe the server program ran out of memory; maybe the disk died; maybe > the system administrator removed a crucial configuration file; maybe the > operating system ran out of file descriptors; etc. Those were two unrelated arguments. The paragraph was not intended to support the second, merely to argue that REFUSED is much clearer than FIN. The reason why I don't think a FIN can reasonably be construed as an error message is: at the TCP level, it's not an error, and at the DNS level, it's not a message. An unexpected FIN is rather analagous to a Unix seg fault; it's an indication that something went wrong, but it's not an error message. > > Contrary to what you've said before, making it easier to detect common > > misconfigurations is an important aspect of interoperability. > > By that argument, anybody using AXFR is violating ``interoperability,'' > because my recommended use of rsync-over-ssh does a vastly better job of > detecting and reporting common misconfigurations. Sure, the interoperability of AXFR, and DNS in general,suffers from poor error reporting. So? Your original argument was that mandating an error message for a refused AXFR was not necessary for interoperability at all. If that were true, then virtually all IETF protocols would be violating RFC 2119 by mandating separate error codes for separate failure conditions. (Of course, even if rsync-over-ssh of zone files is more interopable in the area of error reporting, it isn't very interoperable in general; it won't work between BIND and djbdns servers, for instance.) -- 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 Nov 29 22:04:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14486 for ; Fri, 29 Nov 2002 22:04:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HxpG-00070H-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 18:57:50 -0800 Received: from mx04.gis.net ([208.218.130.12] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18HxpD-000705-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 18:57:47 -0800 Received: from tecotoo.www.gis.net ([63.214.120.147]) by mx04.gis.net; Fri, 29 Nov 2002 21:57:43 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ra029397 for ; Fri, 29 Nov 2002 20:05:28 -0500 Message-Id: <4.3.1.2.20021129194515.038705b0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 29 Nov 2002 20:05:08 -0500 To: namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: in support of axfr-clarify In-Reply-To: <20021128112620.85306.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,SPAM_PHRASE_01_02, X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 06:26 AM 11/28/02, D. J. Bernstein wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > >BIND company employee Danny Mayer writes: I am not and never have been an employee of either ISC or Nominum. > > You can't clarify without breaking something. > >That's absurd. No, it's reality. You wouldn't need to clarify if the RFC weren't ambiguous. Since it's ambiguous, people have made different interpretations of the spec resulting in compatibility problems. So the clarification means that someone's interpretation be noncompliant with the draft. Right now that means yours will be noncompliant. Maybe others too. >Right now, because the specifications are unclear, implementors have to >spend a lot of time investigating how the protocol actually works. Most >of us have been very careful about this; consequently, there have been >very few AXFR interoperability problems. (The ``non-glue records'' bug >introduced in BIND 8.2.3 is an exception.) > >We can save tons of time for future implementors, and reduce the chance >of future interoperability problems, by clarifying the existing AXFR >protocol. This need not, and should not, break anything. If the spec is unclear there are bound to be people not implementing the same way as everyone else. >If there were a current interoperability problem between two deployed >pieces of software, and if both implementors claimed to be right, then >we'd have to resolve the conflict one way or another, after evaluating >the costs of each approach. But that's not the situation here. You're >wrong when you suggest that all differences between implementations are >interoperability problems. No, the cost is not relevant. What is relevant is doing it right so there are no future problems and any future extensions will be implementable in some reasonable fashion. The only question being addressed here is what is the meaning of "right"? > > can't do IXFR > >So fix IXFR. Stop demanding that _my_ users pay to make _your_ silly >protocol extensions work. Compatibility is not rocket science. You can't fix IXFR if AXFR is not nailed down. > > You can trademark anything without it being a commercial product. > >An applicant for a trademark must declare that he is using, or intends to >use, the mark in commerce. See 37 C.F.R. 2.33. Your statement does not include the word sell, for profit or otherwise. There are many non-profits in the US that have trademarks. You also seem to be restricting yourself to the US. Are you saying that ISC cannot trademark the name whereever they please? Danny -- 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 Nov 29 22:43:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15385 for ; Fri, 29 Nov 2002 22:43:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HySg-0007oh-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 19:38:34 -0800 Received: from vim.quarterman.com ([206.225.33.194] helo=quarterman.com ident=[mo4uiy0qDirEzAnCs4bYHB4JkZCgxi/x]) by psg.com with esmtp (Exim 3.36 #2) id 18HySc-0007oU-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 19:38:31 -0800 Received: from marut.quarterman.com (marut [192.168.1.8]) by quarterman.com (8.11.6/8.11.0) with ESMTP id gAU3bmD02651; Fri, 29 Nov 2002 21:37:48 -0600 Received: from marut.quarterman.com (localhost [127.0.0.1]) by marut.quarterman.com (8.9.3/8.9.3) with ESMTP id VAA02541; Fri, 29 Nov 2002 21:37:16 -0600 Message-Id: <200211300337.VAA02541@marut.quarterman.com> From: "John S. Quarterman" To: "D. J. Bernstein" Cc: "John S. Quarterman" cc: ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: trying to sweep namedroppers mismanagement under the rug In-reply-to: Your message of "30 Nov 2002 01:01:11 GMT." <20021130010111.89535.qmail@cr.yp.to> Date: Fri, 29 Nov 2002 21:37:16 -0600 X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [ post by non-subscriber. with the massive amount of spam, it is easy to mis > s > and therefore delete posts by non-subscribers. your subscription address i > s > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if yo > u > wish to regularly post from an address that is not subscribed to this > mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to > have the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > Bill Strahm writes: > > I believe the problem is in your court > > That's patently absurd. It's not _my_ fault that a bunch of messages > from _other_ people are being silently discarded. If they're not subscribers and they're not on a posting exception list, there's no reason their messages should be posted. Every complaint message I've seen from djb about this has had an explanation prepended by the list software like the one above, and su bscription information appended automatically. This is a non-problem. Could we stop hearing about it. -jsq -- 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 Nov 30 01:43:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18678 for ; Sat, 30 Nov 2002 01:43:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18I1G5-000Bwa-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 22:37:45 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18I1Fu-000BwO-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 22:37:34 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id BAA04138; Sat, 30 Nov 2002 01:32:28 -0500 Date: Sat, 30 Nov 2002 01:34:11 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Danny Mayer cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <4.3.1.2.20021129194515.038705b0@pop.gis.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > No, the cost is not relevant. I think this is absurd, and irresponsible. Cost and effects on interoperability are always issues to be seriously considered. > What is relevant is doing it right so > there are no future problems and any future extensions will be > implementable in some reasonable fashion. The only question being > addressed here is what is the meaning of "right"? "Right" might not be the same as "Common". But changes from common aren't "clarifications". "Right" depends on your point of view. > You can't fix IXFR if AXFR is not nailed down. I'm OK with that. However, AXFR should be nailed down in ways that correspond to how people reasonably interpreted the vague spec. The clarification should be done so as to minimize the breakage to existing implementations. I think that AXFR can be nailed down without severely impacting existing implementations, and I expect that IXFR can be made to work with the existing (and clarified) AXFR. > >An applicant for a trademark must declare that he is using, or intends to > >use, the mark in commerce. See 37 C.F.R. 2.33. > > Your statement does not include the word sell, for profit or otherwise. > There are many non-profits in the US that have trademarks. You also > seem to be restricting yourself to the US. Are you saying that ISC > cannot trademark the name whereever they please? This says nothing of the sort. Non-profit is not the same as "non-commercial". The ISC uses names in commerce: it seeks donations, owns property, hires employees, and (if I recall, either offers either support or directions to Vixies consulting operations), and promotes the Bind, Inn, and DCHPD packages. ISC claims (rightly or wrongly) a trademark on Bind. That indicates that it intends to use "Bind" in commerce. Whether it makes a profit or not is irrelevant. Bind is a product of ISC. Whether that trademark claim is invalid (by prior public domain use by UCB), is irrelevant. Once ISC makes a declaration of a trademark, it can't later say the "product" is not commercial. --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 Sat Nov 30 01:49:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18755 for ; Sat, 30 Nov 2002 01:49:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18I1LK-000C4X-00 for namedroppers-data@psg.com; Fri, 29 Nov 2002 22:43:10 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18I1LI-000C4I-00 for namedroppers@ops.ietf.org; Fri, 29 Nov 2002 22:43:08 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id BAA10419; Sat, 30 Nov 2002 01:37:13 -0500 Date: Sat, 30 Nov 2002 01:38:57 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "John S. Quarterman" cc: "D. J. Bernstein" , , , Subject: Re: trying to sweep namedroppers mismanagement under the rug In-Reply-To: <200211300337.VAA02541@marut.quarterman.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would agree the problem is solved if Bush adds the proper addresses to the approved subscribers list, as publicly requested. But since it has taken so much discussion to arrive at that solution (and I'm not sure we have yet), list management is clearly a problem, and has been a chronic problem. --Dean > If they're not subscribers and they're not on a posting exception list, > there's no reason their messages should be posted. > > Every complaint message I've seen from djb about this has had an > explanation prepended by the list software like the one above, > and su bscription information appended automatically. > > This is a non-problem. Could we stop hearing about it. > > -jsq -- 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 Nov 30 08:27:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04437 for ; Sat, 30 Nov 2002 08:27:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18I7QI-000KC9-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 05:12:42 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18I7QF-000KAt-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 05:12:40 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gAUDBNpH018616; Sat, 30 Nov 2002 14:11:23 +0100 Date: Sat, 30 Nov 2002 14:11:23 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: Dean Anderson cc: namedroppers@ops.ietf.org Subject: Re: trying to sweep namedroppers mismanagement under the rug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 30 Nov 2002, Dean Anderson wrote: > I would agree the problem is solved if Bush adds the proper addresses to > the approved subscribers list, as publicly requested. > > But since it has taken so much discussion to arrive at that solution (and > I'm not sure we have yet), list management is clearly a problem, and has > been a chronic problem. urm... if you read back, you'll find that a number of people have been suggesting this very solution (ie, Bernstein should ask to have his preferred posting address added to an allow-posters list) for a number of days now. The fact that Bernstein felt that he had to ignore all of these and continue on ancient history until Bush spelled it out for him[1] would tend to indicate a lack of Common Sense on Bernstein's part. Next topic. --==-- Bruce. [1] One would think that something is up when most of one's posts from 16th of March 2002 have all been labeled with something like '[post from non-subscriber]' when they get forwarded to a mailing list, particularly when one has publically complained about mailing list software and written one's own. -- 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 Nov 30 11:17:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07450 for ; Sat, 30 Nov 2002 11:17:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IADN-000OSi-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 08:11:33 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18IADL-000OSU-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 08:11:31 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18IADM-0005bQ-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 08:11:32 -0800 Message-ID: <20021130042703.23356.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 30 Nov 2002 04:27:03 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=0.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_05_08 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Mayer claimed ``You can't clarify without breaking something.'' Is there anyone else here who doesn't understand how ridiculous that claim is? BIND company consultant Danny Mayer writes: > I am not and never have been an employee of either ISC or Nominum. I apologize for the error. The fact remains that you're not disclosing your financial interests in BIND. > Since it's ambiguous, people have made different interpretations of > the spec resulting in compatibility problems. A typical implementation difference---whether or not it is caused by different interpretations of the spec---does _not_ cause any failures. For example, some AXFR servers insert glue records everywhere they're used, while some AXFR servers insert each glue record exactly once. AXFR clients can handle either approach. There are no failures here. Explaining that servers can repeat records, and requiring clients to handle repetitions, would be a clarification of the protocol. It would not cause any failures. It would save time for future implementors, and reduce the chance of careless implementors screwing up. ---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 Sat Nov 30 11:19:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07487 for ; Sat, 30 Nov 2002 11:19:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IADA-000ORe-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 08:11:20 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18IAD6-000ORO-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 08:11:17 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18IAD7-0005bJ-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 08:11:17 -0800 Message-ID: <20021130033001.13255.qmail@cr.yp.to> References: <20021128222538.28764.qmail@cr.yp.to> <200211290315.gAT3FHgU023121@drugs.dv.isc.org> <20021129180339.70455.qmail@cr.yp.to> <1038596541.1232.221.camel@error-messages.mit.edu> <20021129204439.31534.qmail@cr.yp.to> <1038623268.1232.258.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 30 Nov 2002 03:30:01 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Greg Hudson writes: > at the DNS level, it's not a message Irrelevant. The word ``message'' doesn't appear in the text we're discussing. Anyway, the server hasn't authorized you to ask for AXFR in the first place, so you have no right to demand a response. Go away. > Your original argument was that mandating an error message for a > refused AXFR was not necessary for interoperability at all. If that > were true, then virtually all IETF protocols would be violating RFC > 2119 by mandating separate error codes for separate failure conditions. You are massively confused. There is a huge difference between saying ``you must _not_ send this packet if you are _not_ in this situation'' and saying ``you must send this packet if you are in this situation.'' Trivial example: A 5yz response to SMTP VRFY means that the server won't accept mail for that address. Facts: (1) It is crucial for interoperability that servers _not_ say 5yz if they are _not_ in this situation. Otherwise some clients will fail to deliver mail to that address. (2) There is absolutely no requirement for servers to say 5yz if they _are_ in this situation; and, in fact, most servers instead say 252, deliberately hiding information from the client. This has no effect on interoperability. Do you understand the difference between #1 and #2? Do you understand why #1 is an interoperability issue and #2 isn't? ---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 Sat Nov 30 12:56:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09011 for ; Sat, 30 Nov 2002 12:56:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IBm2-0001me-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 09:51:26 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18IBm0-0001m1-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 09:51:24 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18IAY0-0005dB-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 08:32:52 -0800 In-Reply-To: <20021129232203.63188.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sat, 30 Nov 2002 15:00:21 +0200 (EET) From: Pekka Savola To: "D. J. Bernstein" cc: ietf@ietf.org, , Subject: Re: namedroppers, continued X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 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. ] On 29 Nov 2002, D. J. Bernstein wrote: > Keith claims that allowing ``contributions from outsiders'' requires > delay and manual review. That claim is absurd. Immediately bounce the > message to the ``outsider,'' with instructions explaining how to have > the message sent to subscribers; end of problem. No, it's not 'end of problem'. If I cross-post a reply to some message with was cross-posted to a list I'm subscribed at and a list I'm not, in the general case I do *not* want to subscribe to the other list to be able to send my cross-post reply to both. Waiting for moderator approval is just fine for me, much better than requiring to subscribe or do something else. It's not black and white. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- 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 Nov 30 12:56:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09028 for ; Sat, 30 Nov 2002 12:56:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IBm1-0001mZ-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 09:51:25 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18IBly-0001m1-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 09:51:22 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18IAbx-0005dn-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 08:36:57 -0800 Message-ID: <20021130143650.A23239@snowy.squish.net> References: <200211270123.gAR1NtgU004165@drugs.dv.isc.org> <5.2.0.9.0.20021127151436.02da79c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20021127151436.02da79c0@localhost>; from Kare@Presttun.org on Wed, Nov 27, 2002 at 03:42:24PM +0100 Date: Sat, 30 Nov 2002 14:36:50 +0000 From: James Ponder To: Kare Presttun , Mark.Andrews@isc.org Cc: namedroppers@ops.ietf.org Subject: Re: Is this correct behavior? (http://www.squish.net/dnscheck/) X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.43 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. ] On Wed, Nov 27, 2002 at 03:42:24PM +0100, Kare Presttun wrote: > At 27.11.2002 12:23 +1100, Mark.Andrews@isc.org wrote: > > Squish has case sensitivity bugs. sid.nimrod.no and > > SID.NIMROD.NO produce different results. > > You are very correct in observing this (I did a test, and included > James in the CC). Thank you both for notifying me about this, I have hopefully fixed the bugs. Best wishes, James -- James Ponder; www.squish.net; London, 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 Sat Nov 30 13:53:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10187 for ; Sat, 30 Nov 2002 13:53:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ICed-0003IC-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 10:47:51 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18ICeB-0003HH-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 10:47:24 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18ICeB-0005zD-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 10:47:23 -0800 Message-ID: <20021130182447.75037.qmail@cr.yp.to> References: <20021129183900.89964.qmail@cr.yp.to> <200211292217.gATMHdgU027738@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 30 Nov 2002 18:24:47 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: iesg@ietf.org, ietf@ietf.org Subject: Re: careless protocol extensions X-Spam-Status: No, hits=3.2 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: *** 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] BIND company employee Mark Andrews writes: > No one is trying to force a incompatabile extension on anyone. You are demanding a rule whose only purpose is to support incompatible extensions. _You_ are trying to impose costs on _my_ users so that _you_ don't have to bother preserving backwards compatibility in _your_ stupid protocol extensions. Furthermore, adding insult to injury, you're trying to sneak this protocol change through as a ``clarification.'' You didn't answer my question: How would you like it if Microsoft wrote an RFC on some incompatible protocol extension, hid the interoperability problems until the RFC was published as an elective Proposed Standard, and then demanded that every BIND installation be ``upgraded'' to deal with the junk produced by that protocol extension? How do you think your users would like it? If you want to break compatibility with a deployed protocol, you have to admit the massive costs of changing software around the Internet, and demonstrate benefits that are even more massive. Saying something like We'd like to offer people a pointless, clumsy, ad-hoc reinvention of IPSEC, and we realize that there's no need to break compatibility to do this, and our implementation in fact follows a rule that ensures compatibility, but we didn't put this rule into the spec because it's against company policy to think through compatibility issues, and now instead of fixing the spec we're demanding that other people upgrade their software doesn't cut it. What's particularly amazing about your ``axfr-clarify'' document is that you admit that it imposes rules violated by BIND 8. How can you possibly claim that this is necessary for interoperability? > There is nothing incompatable with saying that servers built > from this time on MUST NOT treat records in the authority > and additional sections as part of the results of AXFR. 1. Please stop viewing the entire world through a BIND lens. Don't say ``server'' if you mean ``AXFR client.'' 2. When you use a phrase like ``in future implementations,'' you're admitting that you're violating RFC 2119, section 6. There is no valid excuse for a protocol to refer to software creation dates. 3. It's content-free to say that an extra requirement doesn't create a compatibility problem. What I'm talking about are compatibility problems created by protocol extensions that don't work correctly with unextended protocol implementations. ---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 Sat Nov 30 17:25:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13721 for ; Sat, 30 Nov 2002 17:25:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IFvk-0007GG-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 14:17:44 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18IFvh-0007G4-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 14:17:41 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gAUMHSgU030383; Sun, 1 Dec 2002 09:17:29 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211302217.gAUMHSgU030383@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: in support of axfr-clarify In-reply-to: Your message of "30 Nov 2002 04:27:03 -0000." <20021130042703.23356.qmail@cr.yp.to> Date: Sun, 01 Dec 2002 09:17:28 +1100 X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dan stop demanding that we don't specify what is required to make AXFR work reliably rather than being like a child's game of "... whispers". "... whispers" is a fun game at childrens parties but not appropriate for transfering zones around. AXFR is quite capable of transfering a zone across a AXFR transfer graph provided the servers in the middle don't alter the contents. What comes out the other end of a AXFR graph should be independent of what other zones are being served by the servers involved. Mark -- 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 Nov 30 17:30:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13794 for ; Sat, 30 Nov 2002 17:30:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IG5W-0007TJ-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 14:27:50 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18IG58-0007Ro-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 14:27:26 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18IECL-00063m-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 12:26:45 -0800 Message-ID: <20021130184803.83758.qmail@cr.yp.to> References: <20021129180339.70455.qmail@cr.yp.to> <200211292155.gATLtKgU027672@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 30 Nov 2002 18:48:03 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=2.7 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: ** 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Mark.Andrews@isc.org writes: > "Does your server meet RFC 1034 and return REFUSED under these conditions?" Have you stopped beating your wife, Mark? It is entirely up to the primary to decide who the secondaries are. RFC 1034 imposes no constraints on this decision. A non-secondary asking for AXFR is violating the protocol (specifically, the text that you quoted), and has no right to a response. > I suspect that the DNS admistators of most ISP curse your stupid decision > when trying to setup secondary service for one of their customers who > is using your servers but forgot to adjust the access controls. Funny how nobody has ever complained about that. Maybe this is because step 3 of my upgrade-from-BIND instructions tells people to authorize zone transfers from their third-party servers. Or maybe it's because nobody actually gives a damn whether the AXFR client prints useless error message #1 or useless error message #2---all the useful information is on the server side. Next, I suppose, you're going to demand that everybody have BIND-style promiscuous defaults, so that users who ``forgot to adjust the access controls'' don't have to be bothered fixing their configurations. ---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 Sat Nov 30 17:32:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13842 for ; Sat, 30 Nov 2002 17:32:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IG5H-0007So-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 14:27:35 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18IG57-0007Ro-01 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 14:27:26 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18IECZ-00063r-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 12:26:59 -0800 Message-ID: <20021130191731.92651.qmail@cr.yp.to> References: <1038433686.1211.210.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 30 Nov 2002 19:17:31 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: ** 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Greg Hudson writes: > Would it really make any of you happier if the title were changed from > "clarifications" to "revisions" and the introductory text modified > accordingly? (If so, I'm all for it.) Everybody agrees that a clarification would be useful. This document is fraudulently posing as a clarification, and perhaps fooling some people into supporting it for that reason. Example: In his (false) declarations of consensus in March 2001 and June 2001, Gudmundsson claimed that this document ``formalizes the zone transfer protocol in accordance with the fielded DNS server software.'' Sounds great, doesn't it? The problem is that it simply isn't true. If you're asking whether dishonesty is acceptable, the answer is no. If you're asking whether dishonesty is the only problem with axfr-clarify, the answer is no. See http://cr.yp.to/djbdns/axfr-clarify.html. ---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 Sat Nov 30 17:56:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14054 for ; Sat, 30 Nov 2002 17:56:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IGU0-00088S-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 14:53:08 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18IGTx-00088E-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 14:53:05 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA00483; Sat, 30 Nov 2002 17:45:23 -0500 Date: Sat, 30 Nov 2002 17:47:01 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Bruce Campbell cc: namedroppers@ops.ietf.org Subject: Re: trying to sweep namedroppers mismanagement under the rug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 30 Nov 2002, Bruce Campbell wrote: > urm... if you read back, you'll find that a number of people have been > suggesting this very solution (ie, Bernstein should ask to have his > preferred posting address added to an allow-posters list) for a number of > days now. The fact that Bernstein felt that he had to ignore all of these > and continue on ancient history until Bush spelled it out for him[1] would > tend to indicate a lack of Common Sense on Bernstein's part. This isn't a fair or accurate description of whats been going on. Bush has been asked numerous times (publicly and privately) to do this, over a period of months, but hasn't. Instead, he has delayed or deleted posts from the djb@cr.yp.to address. Bush has been exploiting the fact that djb doesn't receive mail at djb@cr.yp.to, and so can't use the automated methods to change the subscription address. That is the problem. (this time). This is a willful and reckless disregard by Bush in order to inconvenience and harass Dr. Bernstein. It is not the only time Bush has used his position to inappropriately harrass Dr. Bernstein and other people. --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 Sat Nov 30 18:13:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14238 for ; Sat, 30 Nov 2002 18:13:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IGlV-0008e1-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 15:11:13 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18IGlT-0008dn-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 15:11:11 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id C5D3744E2; Sun, 1 Dec 2002 00:11:08 +0100 (CET) Date: Sun, 1 Dec 2002 00:11:08 +0100 From: bert hubert To: namedroppers@ops.ietf.org Cc: gson@nominum.com Subject: where *is* draft-ietf-dnsext-axfr-clarify-05.txt ? Message-ID: <20021130231108.GA9935@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-1.2 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm trying to actually read what all the hubbub is about but I can't even find what was submitted to the IESG, all I find is http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt Which tells me to email Gustafsson directly. If anybody has a pointer, it would be appreciated. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- 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 Nov 30 19:36:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15188 for ; Sat, 30 Nov 2002 19:36:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IHxZ-000AMr-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 16:27:45 -0800 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18IHxW-000ALs-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 16:27:42 -0800 Received: from tecotoo.www.gis.net ([63.214.95.143]) by mx03.gis.net; Sat, 30 Nov 2002 19:27:39 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ya029404 for ; Sat, 30 Nov 2002 19:29:15 -0500 Message-Id: <4.3.1.2.20021130181740.03890910@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 30 Nov 2002 19:28:47 -0500 To: Dean Anderson From: Danny Mayer Subject: Re: in support of axfr-clarify Cc: namedroppers@ops.ietf.org In-Reply-To: References: <4.3.1.2.20021129194515.038705b0@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_03_05,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:34 AM 11/30/02, Dean Anderson wrote: > > No, the cost is not relevant. > >I think this is absurd, and irresponsible. Cost and effects on >interoperability are always issues to be seriously considered. The cheapest thing would be to do nothing. It is, however, not the right thing to do. Figure out the right thing first and then you can take a realistic view of the costs. > > What is relevant is doing it right so > > there are no future problems and any future extensions will be > > implementable in some reasonable fashion. The only question being > > addressed here is what is the meaning of "right"? > >"Right" might not be the same as "Common". But changes from common aren't >"clarifications". "Right" depends on your point of view. It didn't mention the word common. I said right. Right is very rarely objective anyway, so what's your point? > > You can't fix IXFR if AXFR is not nailed down. > >I'm OK with that. However, AXFR should be nailed down in ways that >correspond to how people reasonably interpreted the vague spec. The >clarification should be done so as to minimize the breakage to existing >implementations. > >I think that AXFR can be nailed down without severely impacting existing >implementations, and I expect that IXFR can be made to work with the >existing (and clarified) AXFR. That's what the document is trying to do. So far nothing that you said discusses the document, just how "unfair" it is to djbdns. > > >An applicant for a trademark must declare that he is using, or intends to > > >use, the mark in commerce. See 37 C.F.R. 2.33. > > > > Your statement does not include the word sell, for profit or otherwise. > > There are many non-profits in the US that have trademarks. You also > > seem to be restricting yourself to the US. Are you saying that ISC > > cannot trademark the name whereever they please? > >This says nothing of the sort. > >Non-profit is not the same as "non-commercial". The ISC uses names in >commerce: it seeks donations, owns property, hires employees, and (if I >recall, either offers either support or directions to Vixies consulting >operations), and promotes the Bind, Inn, and DCHPD packages. > >ISC claims (rightly or wrongly) a trademark on Bind. That indicates that >it intends to use "Bind" in commerce. Whether it makes a profit or not >is irrelevant. Bind is a product of ISC. > >Whether that trademark claim is invalid (by prior public domain use by >UCB), is irrelevant. Once ISC makes a declaration of a trademark, it >can't later say the "product" is not commercial. Assuming that you are in the US, you know nothing about UCC. I suggest an introductory course in the Uniform Commercial Code before you discuss this so knowledgably. Please point me to a site that is selling BIND on behalf of ISC. Of course, it is relevant to point out that if BIND were a commercial product it would cost more, in real money, to have it changed than for djbdns to be changed. Since djbdns is apparently a non-commercial product and noone is employed to make changes or fixes to it, it costs nothing to change and we have therefore chosen the cheapest alternative. Danny > --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 Sat Nov 30 21:11:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16301 for ; Sat, 30 Nov 2002 21:11:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IJVw-000D8e-00 for namedroppers-data@psg.com; Sat, 30 Nov 2002 18:07:20 -0800 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18IJVu-000D8S-00 for namedroppers@ops.ietf.org; Sat, 30 Nov 2002 18:07:18 -0800 Received: from tecotoo.www.gis.net ([63.214.108.110]) by mx03.gis.net; Sat, 30 Nov 2002 21:07:17 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ja029415 for ; Sat, 30 Nov 2002 21:09:48 -0500 Message-Id: <4.3.1.2.20021130210846.03867a40@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 30 Nov 2002 21:09:34 -0500 To: namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: careless protocol extensions In-Reply-To: <20021129183900.89964.qmail@cr.yp.to> References: <20021127174104.41801.qmail@cr.yp.to> <3DE52984.219E825A@daimlerchrysler.com> <20021128002526.68429.qmail@cr.yp.to> <200211280155.gAS1tTv13517@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, SPAM_PHRASE_01_02,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:39 PM 11/29/02, D. J. Bernstein wrote: >How would you like it if Microsoft wrote an RFC on some incompatible >protocol extension, hid the interoperability problems until the RFC was >published as an elective Proposed Standard, and then demanded that every >BIND installation be ``upgraded'' to deal with the junk produced by that >protocol extension? How do you think your users would like it? They already did that. See the discussion on GSS-TSIG. Danny -- 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: