From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:46 2006 From: Olaf Kolkman Subject: DNSEXT list policy Date: Thu, 1 Jan 2004 08:35:02 +0100 Lines: 190 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 01 08:55:38 2004 Return-path: To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.500000 X-RIPE-Signature: 194b2e458a7d77469ca040985f32a1ea Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. 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. - Specific items that are not not appropriate for posting 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, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). 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 - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- 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. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:46 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Issue 62: RCODEs Date: Thu, 1 Jan 2004 11:37:31 -0800 (PST) Lines: 70 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Jan 01 20:41:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: December 31, 2003 Reference: Document: LLMNR-28 Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue: Is the RCODE in an LLMNR response always 0? Since LLMNR responders only respond to queries for names for which they are authoritative, LLMNR responders MUST NOT respond with an RCODE of 3. Since the UPDATE opcode is not supported, LLMNR responders MUST NOT respond with an RCODE of 6-10. But what about other RCODEs or situations in which DNSSEC or DNS transaction security are used? While I understand concerns about error storms, without error codes, it may be difficult to negotiate use of DNSSEC or diagnose problems. In Section 2.1.1, change: "RCODE Response code -- this 4 bit field is set as part of LLMNR responses. In an LLMNR query, the RCODE MUST be zero, and is ignored by the responder. The RCODE MUST be zero in an LLMNR response. Instead of sending a response with a non-zero RCODE, an LLMNR responder MUST NOT respond to a query. A sender receiving an LLMNR response with a non-zero RCODE value MUST silently discard the response." To: "RCODE Response code -- this 4 bit field is set as part of LLMNR responses. In an LLMNR query, the RCODE MUST be zero, and is ignored by the responder. Since LLMNR responders only respond to queries for names for which they are authoritative, LLMNR responders MUST NOT respond with an RCODE of 3. Since the UPDATE opcode is not supported, LLMNR responders MUST NOT respond with an RCODE of 6-10. Where a query utilizes DNS transaction security [RFC2845] [RFC2930], RCODE values of 16-21 MAY be returned by an LLMNR responder." Add Section 2.1.2: "2.1.2. EDNS0 support LLMNR implementations supporting EDNS0 [RFC2671] MUST support extended RCODE values. Where an LLMNR query is sent utilizing EDNS0 an RCODE of 16 (BADVERS) MAY be sent in the response. As noted in [RFC3225], in the event an LLMNR responder returns an RCODE of 1 (FORMERR), 2 (SERVFAIL) or 4 (NOTIMP) in response to a query that has the DO bit set, an LLMNR sender SHOULD NOT expect DNSSEC security RRs and SHOULD retry the query without EDNS0 in accordance with section 5.3 of [RFC2671]." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Revised resolution to LLMNR Issue 59: Miscellaneous Issues Date: Thu, 1 Jan 2004 11:41:54 -0800 (PST) Lines: 230 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Jan 01 20:42:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 59 is enclosed below. The revised proposed resolution is as follows: Add Sections 2.1 and 2.1.1: "2.1. LLMNR packet format LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for both queries and responses. Although [RFC1035] restricts DNS queries and responses to 512 octets in length, since LLMNR operates only on the local link, this restriction is not applicable. LLMNR implementations MUST accept queries and responses as large as permitted by the link MTU. 2.1.1. LLMNR header format LLMNR queries and responses utilize the DNS header format defined in [RFC1035] and [RFC2535], as illustrated below: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied from the query to the response and can be used by the sender to match responses to outstanding queries. QR A one bit field that specifies whether this message is an LLMNR query (0), or an LLMNR response (1). OPCODE A four bit field that specifies kind of query in this message. This value is set by the originator of a query and copied into the response. LLMNR senders and responders MUST support standard queries (opcode value of zero). LLMNR queries MUST NOT be sent with other OPCODE values, and if sent, MUST be ignored by responders. AA Authoritative Answer. This bit is valid in LLMNR responses, and specifies that the responder is an authority for the domain name in the question section. Since responders only respond to LLMNR queries for names and addresses they are authoritative for, the AA bit MUST be set in LLMNR responses. If a sender receives a response with the header containing the AA bit not set, the sender MUST act as though the AA bit was set. The AA bit MUST NOT be set in LLMNR queries, and MUST be ignored by LLMNR responders. TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. The TC bit MUST NOT be set in an LLMNR query and if set is ignored by a responder. If the TC bit is set an LLMNR response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the query over TCP using the unicast address of the responder as the destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit. RD Recursion Desired. The RD bit MUST NOT be set in an LLMNR query or response. If a responder receives an LLMNR query with the header containing the RD bit set, the responder MUST act as though the RD bit was not set. LLMNR senders MUST ignore the RD bit in LLMNR responses. RA Recursion Available. The RA bit MUST NOT be set in an LLMNR query or response. If the RA bit is set in an LLMNR response, it MUST be treated by the sender as though it was not set. LLMNR responders MUST ignore the RA bit in LLMNR queries. Z Reserved for future use. MUST be zero in all LLMNR queries and responses. If these bits are set in an LLMNR query or response, they MUST be ignored. AD Authentic Data. The AD bit, defined in [RFC3655], MUST NOT be set in an LLMNR query or response. If the AD bit is set in an LLMNR query, it MUST be ignored by the responder. If the AD bit is set in an LLMNR response, LLMNR senders MUST act as though the AD bit were not set. CD Checking Disabled. The CD bit, defined in [RFC2535], MUST NOT be set in an LLMNR query or response. If the CD bit is set in an LLMNR query, it MUST be ignored by the responder. LLMNR senders MUST ignore the CD bit in LLMNR responses. RCODE Response code -- this 4 bit field is set as part of LLMNR responses. In an LLMNR query, the RCODE MUST be zero, and is ignored by the responder. The RCODE MUST be zero in an LLMNR response. Instead of sending a response with a non-zero RCODE, an LLMNR responder MUST NOT respond to a query. A sender receiving an LLMNR response with a non-zero RCODE value MUST silently discard the response. QDCOUNT An unsigned 16 bit integer specifying the number of entries in the question section. A sender MUST place only one question into the question section of an LLMNR query. LLMNR responders MUST ignore questions after the first question. ANCOUNT An unsigned 16 bit integer specifying the number of resource records in the answer section. NSCOUNT An unsigned 16 bit integer specifying the number of name server resource records in the authority records section. Authority record section processing is described in Section 2.9. ARCOUNT An unsigned 16 bit integer specifying the number of resource records in the additional records section. Additional record section processing is described in Section 2.9." Add the following to the normative reference section: [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2845] Vixie, P., et al., "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. [RFC3655] Wellington, B. and G. Gudmundsson, "Redefinition of the DNS Authenticated Data (AD) bit", RFC 3655, November 2003. --------------------------------------------------------------------- Issue 59: Miscellaneous Issues Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: December 17, 2003 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02305.html Document: LLMNR-27 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The draft could benefit from addition of a section gathering in one place all the requirements relating to the use of the DNS packet format for LLMNR. For example, use of the TC bit is not defined and neither are the AD and CD bits (which I assume are set to zero). In Section 2.2, change: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone root." To: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone appex except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone appex." In Section 2.2, change: "Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." To: "Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." Add the following paragraph to Section 2.2: "Upon configuring an IP address responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has. However, in general whether RRs are manually or automatically created is an implementation decision." Change Section 2.7 from: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 0 is recommended in highly dynamic environments (such as mobile ad-hoc networks). In less dynamic environments, LLMNR traffic can be reduced by setting the TTL to a higher value. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 30 seconds is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc networks), the TTL value may need to be reduced. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: bill <bmanning@karoshi.com> Subject: DISCOVER - the return Date: Fri, 2 Jan 2004 12:24:56 -0800 (PST) Lines: 27 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Jan 02 21:45:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Erik.Nordmark@sun.com X-Mailer: ELM [version 2.5 PL6] Precedence: bulk I would ask the working group chairs to send this to WGLC at the earliest. No other comments have been received. This should be submitted as EXPERIMENTAL. draft-dnsext-opcode-discover-02.txt Forwarded message: > To: namedroppers@ops.ietf.org > Date: Mon, 13 Oct 2003 13:40:46 -0700 (PDT) > > FYI. > the draft that defines a new op-code, discover, that passed > WG last-call early this year and then went into suspended animation > pending some language clarifications will be re-emerging shortly. > Given the delay between last call and the text cleanup, it might be > prudent to have folk look it over again (given the WG has new ADs, > new WG chairs, and has been re-chartered since the last time this doc > has seen the light of day... :) --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Reminder WGLC DNSSECvbis and NSEC++ Date: Mon, 05 Jan 2004 08:59:28 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Jan 05 09:18:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.318771 X-RIPE-Signature: 1defee047d96d4dcdb88a24f5ed5935f Precedence: bulk A happy and productive 2004 !!! This is a reminder for two working group last calls that have been issued. One for the DNSSECbis document set and one for the NSEC format redefinition draft. Please scheadule some time to read and comment on the drafts. References: draft-ietf-dnsext-nsec-rdata-03.txt http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02322.html draft-ietf-dnsext-dnssec-intro-08 draft-ietf-dnsext-dnssec-records-06 draft-ietf-dnsext-dnssec-protocol-04 http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02307.html --Olaf Kolkman DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Reminder WGLC DNSSECvbis and NSEC++ Date: Mon, 5 Jan 2004 15:50:26 +0100 Organization: RIPE NCC Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Jan 05 16:13:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Olaf Kolkman <olaf@ripe.net> In-Reply-To: <200401050759.i057xSMF006856@birch.ripe.net> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.001169 X-RIPE-Signature: 4561d813b9c9131103d21a5a47ecd916 Precedence: bulk I wrote: > Please scheadule some time to read and comment on the drafts. For completeness; the deadline on these WGLCs is January 15, 2004. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: Reminder WGLC DNSSECvbis and NSEC++ Date: Mon, 5 Jan 2004 11:20:46 -0500 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <20040105155026.3ba3e42e.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Jan 05 17:41:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk One thing I noticed. The text in the DNSSECbis -records draft discusses what to do with compressed names in the "next domain name" field. It is dropped in the NSEC++ draft. It is not important there, since I assume the specs on compressed names were already agreed upon on -records, that text would remain. Scott ----- Original Message ----- From: "Olaf M. Kolkman" <olaf@ripe.net> To: "Olaf Kolkman" <olaf@ripe.net> Cc: <namedroppers@ops.ietf.org> Sent: Monday, January 05, 2004 9:50 AM Subject: Re: Reminder WGLC DNSSECvbis and NSEC++ > I wrote: > > Please scheadule some time to read and comment on the drafts. > > > For completeness; the deadline on these WGLCs is January 15, 2004. > > > -- Olaf > > ---------------------------------| Olaf M. Kolkman > ---------------------------------| RIPE NCC > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Simon Josefsson <jas@extundo.com> Subject: Comments on draft-ietf-dnsext-nsec-rdata-03.txt Date: Mon, 05 Jan 2004 16:49:09 +0100 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon Jan 05 17:42:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 24 X-Complaints-To: usenet@sea.gmane.org User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:OfQXvbXoBpPnrHdmvz8w/AIOlXU= Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] 4. Security Considerations The change introducted here does not affect security, since it only updates the RDATA format and encoding. I feel this is insufficient. I believe the document should discuss all security considerations related to the NSEC RR. Here is suggested text for one item that I believe should be included: The NSEC RR make it possible to enumerate all existing names and types within a zone, so called "chaining". DNS administrators that for some reason restrict access to their entire DNS zone file (by, e.g., disabling DNS zone transfer) may want to consider the effects of adding NSEC records in their zone, as supporting them may lead to a similar information leakage as DNS zone transfer does. Also, some nits: the abstract does not parse as English to me (defines/updates?). The document does not mention "NXT" at all, which seems like a useful thing to do. The document says RFC 2535 define the NSEC RDATA, and it reference RFC 2535 for the semantics of NSEC, none of which 2535 cover. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: Comments on draft-ietf-dnsext-nsec-rdata-03.txt Date: Mon, 5 Jan 2004 11:43:39 -0500 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Jan 05 17:58:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk The "zone walking" security risk is listed in the Security Considerations of the DNSSECbis docs. Maybe a reference to those would suffice? Or cut and paste. Scott ----- Original Message ----- From: "Simon Josefsson" <jas@extundo.com> To: <namedroppers@ops.ietf.org> Sent: Monday, January 05, 2004 10:49 AM Subject: Comments on draft-ietf-dnsext-nsec-rdata-03.txt > > [ Moderators note: Post by non-subscriber. With the massive amount of > spam, it is easy to miss and therefore delete relevant posts > by non-subsrcibers. Please fix your subscription addresses. ] > > > > 4. Security Considerations > > The change introducted here does not affect security, since it only > updates the RDATA format and encoding. > > I feel this is insufficient. I believe the document should discuss > all security considerations related to the NSEC RR. Here is suggested > text for one item that I believe should be included: > > The NSEC RR make it possible to enumerate all existing names and > types within a zone, so called "chaining". DNS administrators that > for some reason restrict access to their entire DNS zone file (by, > e.g., disabling DNS zone transfer) may want to consider the effects > of adding NSEC records in their zone, as supporting them may lead to > a similar information leakage as DNS zone transfer does. > > Also, some nits: the abstract does not parse as English to me > (defines/updates?). The document does not mention "NXT" at all, which > seems like a useful thing to do. The document says RFC 2535 define > the NSEC RDATA, and it reference RFC 2535 for the semantics of NSEC, > none of which 2535 cover. > > Thanks, > Simon > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: DISCOVER - the return Date: Tue, 6 Jan 2004 15:38:19 -0800 (PST) Lines: 57 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Jan 07 00:46:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Here are some comments on draft-dnsext-opcode-discover-02.txt that appear to impact the resolution of Issue 59 (see http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html). Section 2: "3. If QDCOUNT equals 0 then only servers willing to do recursion should answer." Section 2.1 as proposed in LLMNR Issue 59 says that the RD and RA bits are reserved and MUST always be zero. So there is no way for an LLMNR sender to request recursion or for an LLMNR responder to specify that it will support recursion. When DISCOVERY opcode is used, is the intent to redefine the meaning of the RD bit in an LLMNR query or the RA bit in an LLMNR response so as to enable discovery of DNS servers supporting recursion? If so, this needs to be explicitly called out (and perhaps text needs to be changed in LLMNR Section 2.1 to make this clear). Also, text proposed in Issue 59 prohibits a DNS server from answering an LLMNR query for an RR that does not directly relate to it. "6. responses have standard Answer, Authority and Addition sections" Section 2.8 of LLMNR-27 specifies differences between the way these sections are handled in DNS and the way they are handled in LLMNR. For example, the draft specifies that RRs in the additional section SHOULD NOT be processed. "Cache all NS and A data learned in this process" Section 2.8 of LLMNR-27 states: "Responders MAY have NS records associated with the names for which they are authoritative, but they SHOULD NOT include these NS records in the authority sections of responses." Also: "Senders MUST NOT cache RRs from the authority or additional section of a response as answers, though they may be used for other purposes such as negative caching." So again, there appears to be a contradiction. Refererences: There is a reference to an expired mDNS draft. This should be updated to a reference to LLMNR, if in fact the DISCOVER opcode is compatible with 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: bill <bmanning@karoshi.com> Subject: Re: DISCOVER - the return Date: Wed, 7 Jan 2004 13:25:33 -0800 (PST) Lines: 86 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0401061517480.25800@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Jan 07 22:51:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: aboba@internaut.com (Bernard Aboba) In-Reply-To: <Pine.LNX.4.56.0401061517480.25800@internaut.com> from "Bernard Aboba" at Jan 06, 2004 03:38:19 PM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Is LLMNR an implementation of DNS or is it something that looks very much like DNS but is not? > > Here are some comments on draft-dnsext-opcode-discover-02.txt that appear > to impact the resolution of Issue 59 (see > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html). > > Section 2: > > "3. If QDCOUNT equals 0 then only servers willing to do recursion > should answer." > > Section 2.1 as proposed in LLMNR Issue 59 says that the RD and RA bits > are reserved and MUST always be zero. So there is no way for an LLMNR > sender to request recursion or for an LLMNR responder to specify that > it will support recursion. These restrictions seem appropriate for LLMNR as defined by the Namedroppers/IETF process. > When DISCOVERY opcode is used, is the intent to redefine the meaning of > the RD bit in an LLMNR query or the RA bit in an LLMNR response so as to > enable discovery of DNS servers supporting recursion? If so, this needs > to be explicitly called out (and perhaps text needs to be changed in > LLMNR Section 2.1 to make this clear). No. it does "redefine" the meaning of these bits to enable the discovery of DNS servers. Not at all clear on what this maydo to LLMNR servers/clients. IT -could- be used for just such a purpose, however it was not defined in an LLMNR context. > Also, text proposed in Issue 59 prohibits a DNS server from answering an > LLMNR query for an RR that does not directly relate to it. > > "6. responses have standard Answer, Authority and Addition sections" > > Section 2.8 of LLMNR-27 specifies differences between the way these > sections are handled in DNS and the way they are handled in LLMNR. For > example, the draft specifies that RRs in the additional section SHOULD > NOT be processed. > > "Cache all NS and A data learned in this process" > > Section 2.8 of LLMNR-27 states: > > "Responders MAY have NS records associated with the names for which they > are authoritative, but they SHOULD NOT include these NS records in the > authority sections of responses." > > Also: > > "Senders MUST NOT cache RRs from the authority or additional section of a > response as answers, though they may be used for other purposes such as > negative caching." > > So again, there appears to be a contradiction. The goal of TBDS, where DISCOVER was defined, revisits the whole idea of "iterative, recursive-mode" resolvers and impacts they way they manage thier cache entries. I would have to re-read LLMNR to see if they follow that model. > > Refererences: > > There is a reference to an expired mDNS draft. This should be updated to > a reference to LLMNR, if in fact the DISCOVER opcode is compatible with > it. Unclear if they (the old draft) and LLMNR are compatable. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: DISCOVER - the return Date: Wed, 7 Jan 2004 14:10:28 -0800 (PST) Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <200401072125.i07LPXe13643@karoshi.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Jan 07 23:09:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: bill <bmanning@karoshi.com> In-Reply-To: <200401072125.i07LPXe13643@karoshi.com> Precedence: bulk >Is LLMNR an implementation of DNS or is it something that looks very >much like DNS but is not? LLMNR utilizes the DNS packet format defined in [RFC1035] but operates on a separate port with a distinct cache. >Unclear if they (the old draft) and LLMNR are compatable. If I understand this correctly, then the DISCOVER opcode is designed to run over a different multicast DNS protocol than LLMNR. That's fine, but then you either need a normative reference to the protocol that you are using or you need to specify this protocol in detail within the DISCOVER draft. Some questions: a. What port does the DISCOVER protocol use? b. To what multicast address are DISCOVER messages sent? c. Are responses sent via unicast or multicast? d. How are name conflicts detected and resolved? e. Exactly how are all the bits within the DNS header handled? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: bill <bmanning@karoshi.com> Subject: Re: DISCOVER - the return Date: Thu, 8 Jan 2004 11:23:33 -0800 (PST) Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0401071401180.12178@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bmanning@karoshi.com (bill), namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 08 20:44:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: aboba@internaut.com (Bernard Aboba) In-Reply-To: <Pine.LNX.4.56.0401071401180.12178@internaut.com> from "Bernard Aboba" at Jan 07, 2004 02:10:28 PM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk > > >Is LLMNR an implementation of DNS or is it something that looks very > >much like DNS but is not? > > LLMNR utilizes the DNS packet format defined in [RFC1035] but operates on > a separate port with a distinct cache. > > >Unclear if they (the old draft) and LLMNR are compatable. > > If I understand this correctly, then the DISCOVER opcode is designed > to run over a different multicast DNS protocol than LLMNR. LLMNR and mDNS may have evolved from the same root, but have taken minor varients in evolution. LLMNR could adopt, with minor tweeks many of the original design features of mDNS. > That's fine, but then you either need a normative reference to the > protocol that you are using or you need to specify this protocol in detail > within the DISCOVER draft. Some questions: the "normative" reference for mDNS was rejected by the IETF but is part of the DARPA final report for that effort. mDNS is normal DNS with multicast capabilities so there is no unique protocol. > a. What port does the DISCOVER protocol use? Its not a protocol, its a DNS opcode. > b. To what multicast address are DISCOVER messages sent? From http://www.iana.org/assignments/multicast-addresses There is a concept of relative addresses to be used with the scoped multicast addresses. These relative addresses are listed here: Relative Description Reference --------- ------------------------------------------------- --------- 0 SAP Session Announcement Protocol [Handley] 1 MADCAP Protocol [RFC2730] 2 SLPv2 Discovery [Guttman] 3 MZAP [Thaler] 4 Multicast Discovery of DNS Services [Manning] ----------------------------------------------- > c. Are responses sent via unicast or multicast? Unicast. > d. How are name conflicts detected and resolved? See the TBDS/DARPA report. > e. Exactly how are all the bits within the DNS header handled? Not clear what this means. There is nothing particularly unique here, its just DNS. > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Explicit support during WGLC. Date: Thu, 08 Jan 2004 20:38:27 +0100 Lines: 62 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 08 20:55:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.208194 X-RIPE-Signature: 2c45280e29caef5f55ba190bb7f75cfb Precedence: bulk Dear colleagues, We have recently sent out two working group last calls that have seen minor comments on the NSEC draft, and no comments on the 3 drafts that make up the DNSSECbis specification. This is worrisome! Let us explain: In an (experimental) effort to get things through the IESG faster the ADs request us to answer a number of questions that will help them assess if a document is really ready for advancement. One of the questions that the WG chairs will need to answer is: 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? In addition we will have to make statements about the following: - are there any reviewers (during the end stages) that merit explicit mention as having done a thorough review that resulted in important changes or a conclusion that the document was fine (except for maybe some nits?) In the case of DNSSECbis, we know that there have been a number of people that have been thoroughly involved in specification review. However, it would be good for speedy progress if the people reviewed the last versions of the document and would 'stand' for that. Our Request: We would like to request the members of this working group to critically read the documents and bring their motivated statements about the quality of the documents to the mailing list. The working group last call on DNSSECbis is next week January 15. We are willing to give you one extra week on the DNSSECbis document set and end the WGLC by the 23rd of January, the NSEC++ document WGLC will be closed by January 15. If there are no statements about the quality of the document on the list by Jan 23 we will forward the documents with the specific note that there was no explicit and motivated support during last call. Don't be surprised if that would cause delays during IETF review. -- Olaf and Olafur DNSEXT Chairs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: DISCOVER - the return Date: Thu, 8 Jan 2004 19:53:30 -0800 (PST) Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <200401081923.i08JNX423314@karoshi.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Jan 09 04:59:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: bill <bmanning@karoshi.com> In-Reply-To: <200401081923.i08JNX423314@karoshi.com> Precedence: bulk > LLMNR and mDNS may have evolved from the same root, but have taken > minor varients in evolution. LLMNR could adopt, with minor tweeks > many of the original design features of mDNS. Is there a way to get a list of the "minor tweeks" that would be required? I'm willing to make the modifications to section 2.1, for example, if this would allow DISCOVER to run over LLMNR. Right now, for example, -28 reserves the RD, RA, CD and AD bits (since they're not used with the QUERY opcode). So DISCOVER could define uses for these bits when used with that opcode. > the "normative" reference for mDNS was rejected by the IETF but > is part of the DARPA final report for that effort. mDNS is > normal DNS with multicast capabilities so there is no unique > protocol. I'm not sure that there is such a thing as "normal DNS with multicast capabilities." When you get into the details, there are elements of the DNS header (RCODEs, for example) that just don't make sense when used with multicast DNS. For example, in LLMNR only responses with RCODE=0 are allowed. Are non-zero RCODEs in allowed in DISCOVER responses? > There is a concept of relative addresses to be used with the scoped > multicast addresses. These relative addresses are listed here: > > > Relative Description Reference > --------- ------------------------------------------------- --------- > 0 SAP Session Announcement Protocol [Handley] > 1 MADCAP Protocol [RFC2730] > 2 SLPv2 Discovery [Guttman] > 3 MZAP [Thaler] > 4 Multicast Discovery of DNS Services [Manning] > ----------------------------------------------- Are you suggesting that LLMNR should use the relative multicast address originally allocated to 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-28.txt Date: Fri, 09 Jan 2004 16:24:43 -0500 Lines: 96 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Jan 09 22:45:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-28.txt Pages : 26 Date : 2004-1-9 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-28.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-28.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-28.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: <2004-1-9164403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-28.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-28.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-9164403.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: David Blacka <davidb@verisignlabs.com> Subject: comments on draft-ietf-dnsext-dnssec-intro-08 Date: Fri, 9 Jan 2004 16:54:24 -0500 Organization: Verisign, Inc. Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Jan 09 23:07:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: KMail/1.5.3 Content-Disposition: inline Precedence: bulk These are some relatively minor comments on the intro-08 document. 1 -- Section 6 ends by describing a "security-aware stub resolver" that does its own signature validation. I am wondering if there should there be an explicit term for this? "Validating sub resolver" perhaps? I only bring this up because I know that some folks that I have talked to in the past wish that this sort of animal were the norm, and I know that this sort of concept sometimes comes up when discussion the CD bit. This would be a term to essentially distinguish between a security aware resolver which does recursion (or iterates) and one that does not. 2 -- Section 11, 6th paragraph ends with: While not an attack on the DNS itself, this could allow an attacker to map network hosts or other resources by enumerating the contents of a zone. There are non-DNS protocol means of limiting this attack such as limiting the number of NSEC queries from a single host, use of intrusion detection tools, etc. This second sentence is not, technically, correct. Limiting "NSEC" queries is not nearly good enough. You would have to limit queries for any non-existant RR type. For at least some of the organizations that are concerned about NSEC walking, rate limiting of any sort could be seen as a very bad idea. I have no idea how intrusion detection tools could be used to mitigate NSEC walking, but that could just be my lack of familiarity with such tools. I recommend that this latter sentence be just dropped. -- David Blacka <davidb@verisignlabs.com> Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Comments on draft-ietf-dnsext-nsec-rdata-03.txt Date: Mon, 12 Jan 2004 04:08:03 -0500 (EST) Lines: 55 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: jakob@schlyter.se X-From: owner-namedroppers@ops.ietf.org Mon Jan 12 10:29:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <ilun0921jm2.fsf@latte.josefsson.org> Precedence: bulk abstract: Strike "defines" "cover" is vague unless someone already knows what you're talking about. How about: "allow signing of records with any typecode" or "remove the limitation ..." ot somesuch intro, paragraph 2: "once the first 127 type codes are allocated," isn't quite right, since 2929 specifies a private range that's available for use now, independent of IANA assignment. I think the bigger problem is that the current behavior in the pressence of big types is unspecified -- we don't know how to handle them (as an authoritative server or as a resolver). intro, paragraph 3: s/ This document introduces a new format for the type bit map/ ...type list/ (since it's no longer a bit map, exactly) s/all possible type/all possible types/ replace semi-colons with commas, and add an "and" section 2: Should "authoritative" be used here? Even non-authoritative RRsets are in the NSEC chain (delegations w/o DS records). Yes, the parent is authoritative for their existance, but that's a subtlety that may be lost on some readers. Also, "the owner name of the next authoritative RRset" sounds wrong. It's the next name -- there can be multiple RRsets at a name. section 2.1.2 The term "window blocks" doesn't sound right to me. Can we think of something better? "ignored upon reading" puzzles me. Can that be better specified? section 2.2 raw numbers not allowed? want to impose any ordering constraints here? And I concur with Simon's suggest to mention NXT, especially when citing 2535. The chain of changes just gets too long. I don't see a need to change the security considerations section. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Miek Gieben <miekg@atoom.net> Subject: Re: Explicit support during WGLC. Date: Mon, 12 Jan 2004 13:55:06 +0100 Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <200401081938.i08JcRMF003137@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon Jan 12 14:12:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <200401081938.i08JcRMF003137@birch.ripe.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Precedence: bulk For what it is worth: we (the NSD team) were able to gather all necessary information from the 2535bis documents (including NSEC) to implement DNSSEC support in NSD. As NSD is only authoritative we haven't look at the rescursion stuff as thoroughly. regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: bill <bmanning@karoshi.com> Subject: Re: DISCOVER - the return Date: Mon, 12 Jan 2004 11:44:45 -0800 (PST) Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0401081941590.23954@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bmanning@karoshi.com (bill), namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Jan 12 21:02:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: aboba@internaut.com (Bernard Aboba) In-Reply-To: <Pine.LNX.4.56.0401081941590.23954@internaut.com> from "Bernard Aboba" at Jan 08, 2004 07:53:30 PM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk > > > LLMNR and mDNS may have evolved from the same root, but have taken > > minor varients in evolution. LLMNR could adopt, with minor tweeks > > many of the original design features of mDNS. > > Is there a way to get a list of the "minor tweeks" that would be required? I expect so, but then one would have to revisit the remit of LLMNR. DISCOVER, in conjunction w/ the TBDS modifications to DNS has zero link-local restrictions. > I'm willing to make the modifications to section 2.1, for example, if this > would allow DISCOVER to run over LLMNR. Right now, for example, -28 > reserves the RD, RA, CD and AD bits (since they're not used > with the QUERY opcode). So DISCOVER could define uses for these bits when > used with that opcode. It could, but I would not wish to derail LLMNR w/ its adoption of a clearly experimental OPCODE. > > the "normative" reference for mDNS was rejected by the IETF but > > is part of the DARPA final report for that effort. mDNS is > > normal DNS with multicast capabilities so there is no unique > > protocol. > > I'm not sure that there is such a thing as "normal DNS with multicast > capabilities." When you get into the details, there are elements of the > DNS header (RCODEs, for example) that just don't make sense when used with > multicast DNS. For example, in LLMNR only responses with RCODE=0 are > allowed. Are non-zero RCODEs in allowed in DISCOVER responses? Yes, they were. > > 3 MZAP [Thaler] > > 4 Multicast Discovery of DNS Services [Manning] > > ----------------------------------------------- > > Are you suggesting that LLMNR should use the relative multicast address > originally allocated to you? > No. You asked what multicast addresses are used in an implementation that supports DISCOVER. I'm not suggesting LLMNR adopt DISCOVER. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: David Blacka <davidb@verisignlabs.com> Subject: question about draft-ietf-dnsext-dnssec-records-06 Date: Mon, 12 Jan 2004 17:34:41 -0500 Organization: Verisign, Inc. Lines: 38 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Jan 12 23:53:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: KMail/1.5.3 Content-Disposition: inline Precedence: bulk When carefully reviewing this excellent document, I came across this sentence in section 4.1.1: Owner names of RRsets not authoritative for the given zone (such as glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name. which made me think of this "unless" case. If an authoritive RRset exists at the same owner name as glue, what should the type map look like? Intuitively, it should contain the types of the authoritative RRsets only, but since it isn't specified in the document, I'm only guessing. Just to make sure folks know what I'm talking about, consider this snippet from the "example." zone: foo.example. IN NS ns1.foo.example. foo.example. IN NS foo.example. foo.example. IN A 1.2.3.5 ns1.foo.example. IN A 1.2.3.4 foo.example. IN NSEC foo2.example. (A?) NS RRSIG NSEC foo.example. IN RRSIG NSEC ... which I think is a valid illustration of this case. Whatever the answer is, I think that it should be spelled out in this document. -- David Blacka <davidb@verisignlabs.com> Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: David Blacka <davidb@verisignlabs.com> Subject: another question about draft-...-records-06 Date: Tue, 13 Jan 2004 10:48:50 -0500 Organization: Verisign, Inc. Lines: 34 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Jan 13 17:11:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: KMail/1.5.3 Content-Disposition: inline Precedence: bulk I noticed that records-06, section 6.3 "Canonical RR Ordering Within An RRset" says: For purposes of DNS security, RRs with the same owner name, class, and type are sorted by RDATA: first by RDATA length, shortest to longest, then by the canonical form of the RDATA itself in the case of length equality, treating the RDATA portion of the canonical form of each RR as a left justified unsigned octet sequence. The absence of an octet sorts before a zero octet. Which seems to contradict rfc 2535, which says: 8.3 Canonical RR Ordering Within An RRset Within any particular owner name and type, RRs are sorted by RDATA as a left justified unsigned octet sequence where the absence of an octet sorts before the zero octet. When and why did this change? I know that previous interpretations of 2535 excluded ordering the RDATA by length first, because I had code that did this by mistake, and it did not interoperate. -- David Blacka <davidb@verisignlabs.com> Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: question about draft-ietf-dnsext-dnssec-records-06 Date: Wed, 14 Jan 2004 16:33:53 -0500 Lines: 69 Sender: owner-namedroppers@ops.ietf.org References: <200401121734.41484.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Jan 14 22:55:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org In-Reply-To: <200401121734.41484.davidb@verisignlabs.com> References: <200401121734.41484.davidb@verisignlabs.com> Precedence: bulk </chair> At 17:34 2004-01-12, David Blacka wrote: >When carefully reviewing this excellent document, I came across this >sentence in section 4.1.1: > > Owner names of RRsets not authoritative for the given zone (such as > glue records) MUST NOT be listed in the Next Domain Name unless at > least one authoritative RRset exists at the same owner name. > >which made me think of this "unless" case. If an authoritive RRset exists >at the same owner name as glue, what should the type map look like? > >Intuitively, it should contain the types of the authoritative RRsets only, >but since it isn't specified in the document, I'm only guessing. > >Just to make sure folks know what I'm talking about, consider this snippet >from the "example." zone: > >foo.example. IN NS ns1.foo.example. >foo.example. IN NS foo.example. >foo.example. IN A 1.2.3.5 >ns1.foo.example. IN A 1.2.3.4 >foo.example. IN NSEC foo2.example. (A?) NS RRSIG NSEC >foo.example. IN RRSIG NSEC ... > >which I think is a valid illustration of this case. Yes this is a good illustration of this case. I can not find any text in any DNS document that outlaws A residing with a NS in parent. (Not sure anyone does this anyway) >Whatever the answer is, I think that it should be spelled out in this >document. It is in a way implied in protocol section 2.2, but it should be spelled out in records. In the case of NS the parent is authoritative for the existence of the name and the type while the child is authoritative for the contents of the record. Thus the NS is included in the NSEC type map but not signed. In the case of NSEC and DS the parent is authoritative for the contents of them and signs them, thus they appear in the NSEC bit map. In the case of glue the parent is not authoritative for any part of the type or content. For this reason (IMHO) the type should not be listed in the NSEC bit map. A different argument is: why should glue that happens to reside at delegation point get preferential treatment over glue that is below a delegation point. With this interpretation of NSEC bitmap at delegations, the contents of a NSEC at delegation points is always NS [DS] RRSIG NSEC, this should be spelled out in the documents. Olafur (himself not as WG-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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Josh Littlefield <joshl@cisco.com> Subject: Re: Reminder WGLC DNSSECvbis and NSEC++ Date: Wed, 14 Jan 2004 20:19:43 -0500 Organization: Cisco Systems Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 02:35:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Olaf Kolkman <olaf@ripe.net> In-Reply-To: <200401050759.i057xSMF006856@birch.ripe.net> Precedence: bulk Olaf Kolkman wrote: > References: > draft-ietf-dnsext-nsec-rdata-03.txt I support moving draft-ietf-dnsext-nsec-rdata-03 forward (as appropriate, or killing it because dnssec-records-06 fully incorporates it). I do request consideration of the following 2 minor editorial nits: - Sec. 1: The first paragraph indicates that NSEC RR was descibed in RFC2535. It is actually NXT that is defined there. - Sec. 2.3: In the second paragraph is says, "The A, MX, RRSIG and NSEC mnemonics indicate there are A, MX, RRSIG, NSEC and TYPE1234 RRsets...". This probably should begin "The A, MX, RRSIG, NSEC and TYPE1234 mnemonics..." > draft-ietf-dnsext-dnssec-intro-08 > draft-ietf-dnsext-dnssec-protocol-04 I support moving draft-ietf-dnsext-dnssec-intro-08 and draft-ietf-dnsext-dnssec-protocol-04 forward as written. > draft-ietf-dnsext-dnssec-records-06 I support moving draft-ietf-dnssext-records-06 forward, with the minor comment above for nsec-rdata-03, sec. 2.3 applied to sec. 4.3 -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Explicit support for nsec-03 Date: Wed, 14 Jan 2004 20:36:55 -0500 (EST) Lines: 11 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 02:47:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <Pine.GSO.4.55.0401120406380.495@filbert> Precedence: bulk This document has nits that need to be fixed before it is progressed (see my earlier message), but it is technically complete. I support its publication, contingent on another editting cycle. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: intro-08 WGLC comments Date: Wed, 14 Jan 2004 21:49:23 -0500 (EST) Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 04:05:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <Pine.GSO.4.55.0401142033400.7196@filbert> Precedence: bulk intro-08 is a beautiful and very complete document. The editors have done a marvelous job, and they've been very responsive to previous suggested changes. I applaud them. In addition to the usual minor nits, I see some things that I expect to cause IESG delays, and I do not support the advancement of this document until they are addressed. To be clear, I will support the document during IETF last call (the document is technically sound). I just think it would be prudent for DNSEXT to fix these things before advancing the doc. First, there's an inconsistency in this document re: which direction the authentication happens in (FROM a preconfigured key, as in section 5, or TO a preconfigured key as in section 3.1). It doesn't really matter, but the inconsistency does show up and may confuse people, including the IESG. Section 2, definitions The distinction between "authenticated" and "validated" is subtle and may be inconsistent, which makes these definitions look cavalier. If we can't clean this up, perhaps we need to add a disclaimer about these being "rough" definitions, lest the IESG throw this back. In the zone signing key definition, please repeat the warning re: the ZSK/KSK distinction not mattering for validation. The second paragraph of 3.1 also confuses this a little (more detail sent to editors). Section 3.1 third paragraph The attempt at DS->DNSKEY chaining formalism misses the optional DNSKEY->DNSKEY indirection inside the zone. 11. Security considerations More should be said about DNSSEC's potential for making zones less reachable and for otherwise causing DNS to appear to break. And it should be stressed that DNSSEC does not necessarily help a resolver to find good data (it may, but we haven't developed those technologies yet). In the second paragraph, is "intermediate" really defined elsewhere? It looks to me like it's both undefined and overloaded. Local policy is discussed several times in this document, but with limited examples. I'd like to see more examples (ie. disabling an algorithm and the impacts thereof). Many minor nits have been sent privately to the editors. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Mark.Andrews@isc.org Subject: WGLC comments Date: Thu, 15 Jan 2004 14:46:28 +1100 Lines: 19 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 04:59:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Protocol Section 5.2 need a paragraph like. If the resolver authenticates the DS RRset and ALL the DS records contain unsupported algorithms, then there is no supported authentication path leading from the parent to the child. The child zone should be treated as if it was unsigned. -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: DNSEXT in Seoul (not) Date: Thu, 15 Jan 2004 00:00:09 -0500 Lines: 24 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 06:11:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: namedroppers@ops.ietf.org Precedence: bulk There will not be a DNSEXT meeting at IETF-59. The working group is just finishing up the DNSEXT document set and few other documents, there are no items on the table that warrant a meeting. Still here is the ID draft deadlines: February 9, Monday - 00 Internet Draft Cut-off February 16, Monday - Internet Draft cut-off Once we have cleared the tables of DNSSEC the working group must turn its attention to the large number of RFC that are in Proposed standards state and start the work of revising and advancing them. Olafur & 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: another question about draft-...-records-06 Date: Wed, 14 Jan 2004 22:57:58 -0500 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <200401131048.50120.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 06:59:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org In-Reply-To: <200401131048.50120.davidb@verisignlabs.com> References: <200401131048.50120.davidb@verisignlabs.com> Precedence: bulk At 10:48 2004-01-13, David Blacka wrote: >I noticed that records-06, section 6.3 "Canonical RR Ordering Within An >RRset" says: > > For purposes of DNS security, RRs with the same owner name, class, > and type are sorted by RDATA: first by RDATA length, shortest to > longest, then by the canonical form of the RDATA itself in the case > of length equality, treating the RDATA portion of the canonical form > of each RR as a left justified unsigned octet sequence. The absence > of an octet sorts before a zero octet. > >Which seems to contradict rfc 2535, which says: > >8.3 Canonical RR Ordering Within An RRset > > Within any particular owner name and type, RRs are sorted by RDATA as > a left justified unsigned octet sequence where the absence of an > octet sorts before the zero octet. > >When and why did this change? Good catch, dnssec-records-04 is the first version with this wording. the text before that was not clear and this was an attempt to fix that. You are right, this is a protocol change, thus this text needs to be revised to comply to 2535. >I know that previous interpretations of 2535 excluded ordering the RDATA by >length first, because I had code that did this by mistake, and it did not >interoperate. I wonder how many of the implementations had picked up on this detail and coded it ? Olafur 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: WGLC on DNSSEC bis document set Date: Thu, 15 Jan 2004 16:11:27 +0900 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 08:24:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Olaf Kolkman <olaf@ripe.net> In-Reply-To: <200312180654.hBI6sOdH023644@birch.ripe.net> Precedence: bulk Olaf Kolkman wrote: > This is a working group last call for the DNSSEC bis specification. Though I still can't see any reason to have DNSSEC, I spent 30 minutes to read: > draft-ietf-dnsext-dnssec-intro-08 and felt alarted that it says: A security-aware resolver should be configured with at least one authentication key or a key's DS RR hash as the starting point from which it will attempt to establish authentication chains. My question is, where is the information on key or hash expiration date stored and how? I spent another 30 minutes to read: > draft-ietf-dnsext-dnssec-records-06 > draft-ietf-dnsext-dnssec-protocol-04 but can't find any information on it yet. First, I thought hash of a resolver should be over key and expiration date, which minimize configuration on resolvers. But I found it not the case. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: expiring preconfigured keys (was: Re: WGLC on DNSSEC bis document set) Date: Thu, 15 Jan 2004 03:08:12 -0500 (EST) Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 09:23:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <40063D1F.8000007@necom830.hpcl.titech.ac.jp> Precedence: bulk > My question is, where is the information on key or hash > expiration date stored and how? Some distributors of keys intended for configuration in resolvers may not expect to ever change their keys. Some may also distribute chains of keys, intended to be rolled over at regular intervals. Some may even distribute algorithms that generate the key to be used at a particular time. Perhaps resolvers should include support for such practices, and I invite you to make that case to resolver authors in appropriate forums. I don't see how this is a protocol issue that needs to be addressed in these specifications. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Miek Gieben <miekg@atoom.net> Subject: direct query for NSEC Date: Thu, 15 Jan 2004 11:41:45 +0100 Lines: 57 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 11:54:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers <namedroppers@ops.ietf.org> Mail-Followup-To: namedroppers <namedroppers@ops.ietf.org> Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Precedence: bulk Hello, When doing some early testing with NSD2 and BIND9.4, we came across the following. Both nameserver were loaded with the example. zone from protocol-04. a.example is delegated in that zonem dig @nsd-server nsec a.example we get a referral to a.example, not the nsec. We feel this is ok. dig @bind-server nsec a.example we get the nsec from the a.example zone. One can argue this is also correct. But what happens when the server is also authoritative the a.example (as a child zone), which nsec do we get? Both? In good old rfc2535 it says: 5.5 Special Considerations at Delegation Points A name (other than root) which is the head of a zone also appears as the leaf in a superzone. If both are secure, there will always be two different NXT RRs with the same name. They can be easily distinguished by their signers, the next domain name fields, the presence of the SOA type bit, etc. Security aware servers should return the correct NXT automatically when required to authenticate the non-existence of a name and both NXTs, if available, on explicit query for type NXT. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ..... deleted the rest of the paragraph .... I'm not really parsing this, but "...and both NXTs, if available, on explicit..." ... so a server authoritative for both example. and a.example should give them both back? I cannot find this in the current protocol draft. The inclusion of NSEC (section 3.3) records only says how to deal with them when including them in a nxdomain (and other) responses. Not what to do when directly queried for NSEC. My feeling is that 2535 makes the nsec record (in this respect) as weird as the DS record. We need to add extra logic to NSD to give back both the NSECs. And this logic is _very_ simular to the DS logic... Is this under specified? Regards, Miek -- GPG fingerprint: miek.nl/about.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: expiring preconfigured keys Date: Thu, 15 Jan 2004 20:32:09 +0900 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <Pine.GSO.4.55.0401150300140.19573@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 12:45:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0401150300140.19573@filbert> Precedence: bulk Samuel Weiler; >>My question is, where is the information on key or hash >>expiration date stored and how? > Some distributors of keys intended for configuration in resolvers may > not expect to ever change their keys. Some may also distribute chains > of keys, intended to be rolled over at regular intervals. Some may > even distribute algorithms that generate the key to be used at a > particular time. You are arguing that DNSSEC specification is incomplete and not ready for last call evaluation, unless all the operational details are specified, which is a valid point against DNSSEC. > Perhaps resolvers should include support for such practices, and I > invite you to make that case to resolver authors in appropriate > forums. I don't see how this is a protocol issue that needs to be > addressed in these specifications. Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says A security-aware resolver should be configured with at least one authentication key or a key's DS RR hash as the starting point from which it will attempt to specify hash should be that of DS RR? It is necessary to standardize hash information format necessary for resolvers so that zone administrators do not have to provide hash information in 1,000 different ways. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: expiring preconfigured keys Date: Thu, 15 Jan 2004 08:24:43 -0500 Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <Pine.GSO.4.55.0401150300140.19573@filbert> <40067A39.8090903@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 14:37:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk ----- Original Message ----- From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> > Samuel Weiler; > > >>My question is, where is the information on key or hash > >>expiration date stored and how? > > > Some distributors of keys intended for configuration in resolvers may > > not expect to ever change their keys. Some may also distribute chains > > of keys, intended to be rolled over at regular intervals. Some may > > even distribute algorithms that generate the key to be used at a > > particular time. > > You are arguing that DNSSEC specification is incomplete and not > ready for last call evaluation, unless all the operational details > are specified, which is a valid point against DNSSEC. > Not exactly. Trust anchors are pre-configured and loaded at startup. This could be done by any number of means, and some administrators and network operators may have a preference for another, existing method instead of the DNS protocol. > > Perhaps resolvers should include support for such practices, and I > > invite you to make that case to resolver authors in appropriate > > forums. I don't see how this is a protocol issue that needs to be > > addressed in these specifications. > > Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says > > A security-aware > resolver should be configured with at least one authentication key or > a key's DS RR hash as the starting point from which it will attempt > > to specify hash should be that of DS RR? > > It is necessary to standardize hash information format necessary > for resolvers so that zone administrators do not have to provide > hash information in 1,000 different ways. > At the time of writing, it was assumed to be similar to the DS RDATA. However, the DS RR can use different algorithms for creating the DNSKEY hash (SHA1 is the only currently defined one). How the trusted keys are stored is strictly an internal resolver issue, not a protocol issue. Zone administers do not have to provide the hash of a DNSKEY anyway: If the resolver loads with hashes of trusted keys, it can compute those hashes for the keys it recieves to match with the trusted values. The resolver does the work in DNSSEC, not the zone servers. > Masataka Ohta > > Scott > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: intro-08 WGLC comments Date: Thu, 15 Jan 2004 11:00:06 -0500 Lines: 74 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 17:15:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk ----- Original Message ----- From: "Samuel Weiler" <weiler@tislabs.com> > First, there's an inconsistency in this document re: which direction > the authentication happens in (FROM a preconfigured key, as in section > 5, or TO a preconfigured key as in section 3.1). It doesn't really > matter, but the inconsistency does show up and may confuse people, > including the IESG. > > Section 2, definitions > > The distinction between "authenticated" and "validated" is > subtle and may be inconsistent, which makes these definitions > look cavalier. If we can't clean this up, perhaps we need to > add a disclaimer about these being "rough" definitions, lest > the IESG throw this back. > > In the zone signing key definition, please repeat the warning > re: the ZSK/KSK distinction not mattering for validation. The > second paragraph of 3.1 also confuses this a little (more > detail sent to editors). > Probably will need some wording changes. All of us know the material already, so we know what it's saying, even though it is written differently. > Section 3.1 third paragraph > > The attempt at DS->DNSKEY chaining formalism misses the > optional DNSKEY->DNSKEY indirection inside the zone. > > 11. Security considerations > > More should be said about DNSSEC's potential for making zones > less reachable and for otherwise causing DNS to appear to > break. And it should be stressed that DNSSEC does not > necessarily help a resolver to find good data (it may, but we > haven't developed those technologies yet). > > In the second paragraph, is "intermediate" really defined > elsewhere? It looks to me like it's both undefined and > overloaded. > > Local policy is discussed several times in this document, but with > limited examples. I'd like to see more examples (ie. disabling an > algorithm and the impacts thereof). > We might wander dangerously close to specificiations (which was to be avoided in this doc). I think local policy, resolver actions, etc. might lead to a deep rathole. Maybe even a seperate doc on how a resolver might intereact with a secure name system. Scott > Many minor nits have been sent privately to the editors. > > -- 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: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: expiring preconfigured keys Date: Thu, 15 Jan 2004 13:37:47 -0500 (EST) Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <Pine.GSO.4.55.0401150300140.19573@filbert> <40067A39.8090903@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 19:51:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <40067A39.8090903@necom830.hpcl.titech.ac.jp> Precedence: bulk On Thu, 15 Jan 2004, Masataka Ohta wrote: > > Some distributors of keys intended for configuration in resolvers may > > not expect to ever change their keys. Some may also distribute chains > > of keys, intended to be rolled over at regular intervals. Some may > > even distribute algorithms that generate the key to be used at a > > particular time. > > You are arguing that DNSSEC specification is incomplete and not > ready for last call evaluation, unless all the operational details > are specified, which is a valid point against DNSSEC. I'm sorry to hear that I was unclear again. That seems to be common in our conversations (see namedroppers on 13 November 2003.) To the contray, I think trust anchor configuration is a matter of local policy. It's a knob, albeit a more complex one than disabling an untrusted algorithm. Conventions for it will develop, and they could have profound impacts on resolvers' configuration interfaces and the user experience of DNSSEC, but they do not affect the on-the-wire protocol. The DNSSECbis document set is complete without documenting more than the token set of them that it documents now. Furthermore, having the base protocol deployed will help us develop more useful trust anchor configuration schemes. > Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says > > A security-aware > resolver should be configured with at least one authentication key or > a key's DS RR hash as the starting point from which it will attempt > > to specify hash should be that of DS RR? As an example of something that might be reasonable. A gentle nudge in the right direction. That's not a 2119 SHOULD. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: prohibiting use of expired RRSIGs Date: Thu, 15 Jan 2004 13:58:13 -0500 (EST) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 20:10:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <Pine.GSO.4.55.0401142142540.12241@filbert> Precedence: bulk >From records-06, section 3.1.5, first paragraph: The Signature Expiration and Inception fields specify a validity period for the signature. The RRSIG record MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date. To accomodate local policy, I think these should be SHOULD NOTs. I can imagine some resolvers wanting to knowingly use expired RRSIGs. Perhaps the error when a RRSIG has expired but otherwise validates will be more gentle (or more user overridable) than an error when the RRSIG is missing or doesn't validate at all. Perhaps a given zone will be known to have bad RRSIGs, and that could be configured on a per-zone basis. Perhaps the resolver lacks any sense of the current time, and doesn't want to check times at all. Perhaps the resolver knows that its clock is wildly inaccurate and wants to globablly allow for five hours of slop in either direction. Perhaps there will be a default local policy that states: for a given zone, unless you've seen more recent RRSIGs, keep accepting the old ones -- once any newer RRSIG appears, reject the old ones. These are all local policies, the merits of which can be debated (we probably shouldn't do that here and now), but I see no need to prohibit them wholesale. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: expiring preconfigured keys Date: Fri, 16 Jan 2004 05:15:15 +0900 Lines: 66 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <Pine.GSO.4.55.0401150300140.19573@filbert> <40067A39.8090903@necom830.hpcl.titech.ac.jp> <Pine.GSO.4.55.0401151047010.6809@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 21:38:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0401151047010.6809@filbert> Precedence: bulk Samuel Weiler; >>You are arguing that DNSSEC specification is incomplete and not >>ready for last call evaluation, unless all the operational details >>are specified, which is a valid point against DNSSEC. > > > I'm sorry to hear that I was unclear again. That seems to be common > in our conversations (see namedroppers on 13 November 2003.) > > To the contray, I think trust anchor configuration is a matter of > local policy. Trust anchor configuration policy of a resolver is a matter of policy local to the resolver. However, trust anchor configuration procedure of a resolver for a zone involves two administrators that there is no locality. Standardization is inevitable. > It's a knob, albeit a more complex one than disabling > an untrusted algorithm. Conventions for it will develop, and they > could have profound impacts on resolvers' configuration interfaces and > the user experience of DNSSEC, but they do not affect the on-the-wire > protocol. To implement something, it is not enough to specify on-the-wire protocol. It is also necessary to specify what (not necessarily how, which is an operational issue) kind of information is obtained off-the-wire. Resolvers which can not handle key hash expiration is broken, if there are zones with key expiration. Protocol specifications to allow for broken implementations are broken. > The DNSSECbis document set is complete without documenting > more than the token set of them that it documents now. It is incomplete. >>Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says >> >> A security-aware >> resolver should be configured with at least one authentication key or >> a key's DS RR hash as the starting point from which it will attempt >> >>to specify hash should be that of DS RR? > As an example of something that might be reasonable. A gentle nudge > in the right direction. That's not a 2119 SHOULD. It is an incomplete attempt to address the real problem. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: expiring preconfigured keys Date: Fri, 16 Jan 2004 05:23:20 +0900 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <Pine.GSO.4.55.0401150300140.19573@filbert> <40067A39.8090903@necom830.hpcl.titech.ac.jp> <00eb01c3db6a$f039c500$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 21:39:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Scott Rose <scottr@nist.gov> In-Reply-To: <00eb01c3db6a$f039c500$b9370681@barnacle> Precedence: bulk Scott Rose; >>>>My question is, where is the information on key or hash >>>>expiration date stored and how? >> >>>Some distributors of keys intended for configuration in resolvers may >>>not expect to ever change their keys. Some may also distribute chains >>>of keys, intended to be rolled over at regular intervals. Some may >>>even distribute algorithms that generate the key to be used at a >>>particular time. >> >>You are arguing that DNSSEC specification is incomplete and not >>ready for last call evaluation, unless all the operational details >>are specified, which is a valid point against DNSSEC. >> > > > Not exactly. Trust anchors are pre-configured and loaded at startup. This > could be done by any number of means, and some administrators and network > operators may have a preference for another, existing method instead of the > DNS protocol. Can you define what is a "trust anchor" which never appears in any of the three IDs. Note that I'm not asking how it is distributed and stored. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: expiring preconfigured keys Date: Thu, 15 Jan 2004 15:32:58 -0500 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <Pine.GSO.4.55.0401150300140.19573@filbert> <40067A39.8090903@necom830.hpcl.titech.ac.jp> <00eb01c3db6a$f039c500$b9370681@barnacle> <4006F6B8.3060509@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 21:50:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk ----- Original Message ----- From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> > > > > > > Not exactly. Trust anchors are pre-configured and loaded at startup. This > > could be done by any number of means, and some administrators and network > > operators may have a preference for another, existing method instead of the > > DNS protocol. > > Can you define what is a "trust anchor" which never appears in > any of the three IDs. > > Note that I'm not asking how it is distributed and stored. > Poor word choice in my statement. I used trust anchor to mean a key that is to be trusted and used to form an authentication chain in DNSSEC. An example would be the root "." zone key, but it could be any zone key, or even a hash of a zone key. Scott > Masataka Ohta > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: expiring preconfigured keys Date: Fri, 16 Jan 2004 05:44:12 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <Pine.GSO.4.55.0401150300140.19573@filbert> <40067A39.8090903@necom830.hpcl.titech.ac.jp> <00eb01c3db6a$f039c500$b9370681@barnacle> <4006F6B8.3060509@necom830.hpcl.titech.ac.jp> <00a101c3dba6$c33aa380$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Jan 15 21:56:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Scott Rose <scottr@nist.gov> In-Reply-To: <00a101c3dba6$c33aa380$b9370681@barnacle> Precedence: bulk Scott Rose; > I used trust anchor to mean a key that is > to be trusted and used to form an authentication chain in DNSSEC. An > example would be the root "." zone key, but it could be any zone key, or > even a hash of a zone key. Then, it is insufficient information for resolvers. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 08:53:18 -0500 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> <Pine.GSO.4.55.0401151349150.16749@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Jan 16 15:21:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk ----- Original Message ----- From: "Samuel Weiler" <weiler@tislabs.com> To: <namedroppers@ops.ietf.org> Sent: Thursday, January 15, 2004 1:58 PM Subject: prohibiting use of expired RRSIGs > >From records-06, section 3.1.5, first paragraph: > > The Signature Expiration and Inception fields specify a validity > period for the signature. The RRSIG record MUST NOT be used for > authentication prior to the inception date and MUST NOT be used for > authentication after the expiration date. > > To accomodate local policy, I think these should be SHOULD NOTs. > > I can imagine some resolvers wanting to knowingly use expired RRSIGs. > Perhaps the error when a RRSIG has expired but otherwise validates > will be more gentle (or more user overridable) than an error when the > RRSIG is missing or doesn't validate at all. Perhaps a given zone > will be known to have bad RRSIGs, and that could be configured on a > per-zone basis. Perhaps the resolver lacks any sense of the current > time, and doesn't want to check times at all. Perhaps the resolver > knows that its clock is wildly inaccurate and wants to globablly allow > for five hours of slop in either direction. Perhaps there will be a > default local policy that states: for a given zone, unless you've seen > more recent RRSIGs, keep accepting the old ones -- once any newer > RRSIG appears, reject the old ones. > > These are all local policies, the merits of which can be debated (we > probably shouldn't do that here and now), but I see no need to > prohibit them wholesale. > I think there is a danger if the specifications say it is ok to go "off the reservation" and accept certain errors. Unless an application and user is willing to accept risky responses (example: RRSIG verified, but time was off, or RRSIG in an algorithm the resolver cannot understand), it can request that, but it should be able to rely on a some base security checks. Since we are talking resolver local policy, there really is nothing stopping a resolver implementation from offering that service as an option, but not as default, where it takes liberty with application requests, and hands back responses that were "close enough", but maybe not to the application's wishes. I would rather see a base "MUST NOT accept expired SIG" as the default operation, and anything beyond that as an option an app can specify, rather than "SHOULD NOT" and have an application not be sure what the resolver is doing. Scott > -- 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: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: bill <bmanning@karoshi.com> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 09:18:28 -0800 (PST) Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <007a01c3dc38$18b80be0$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Jan 16 18:35:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: scottr@nist.gov (Scott Rose) In-Reply-To: <007a01c3dc38$18b80be0$b9370681@barnacle> from "Scott Rose" at Jan 16, 2004 08:53:18 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk > > >From records-06, section 3.1.5, first paragraph: > > > > The Signature Expiration and Inception fields specify a validity > > period for the signature. The RRSIG record MUST NOT be used for > > authentication prior to the inception date and MUST NOT be used for > > authentication after the expiration date. > > > > To accomodate local policy, I think these should be SHOULD NOTs. > > > > I can imagine some resolvers wanting to knowingly use expired RRSIGs. > > > > I think there is a danger if the specifications say it is ok to go "off the > reservation" and accept certain errors. Unless an application and user is > willing to accept risky responses (example: RRSIG verified, but time was > off, or RRSIG in an algorithm the resolver cannot understand), it can > request that, but it should be able to rely on a some base security checks. ... > > I would rather see a base "MUST NOT accept expired SIG" as the default > operation, and anything beyond that as an option an app can specify, rather > than "SHOULD NOT" and have an application not be sure what the resolver is > doing. > > Scott > > -- Sam perhaps its me, but some thinking leads me to beleive that we are mixing features/functionality here. What if folks have a "stock" resolver (whatever the heck that is) and a "validator", where the default is that the resolver "throws" data to the validator, which does the checking and then "throws" a response back to the resolver. Much less change on the part of the resolver (can impliment local policy) and then the validator can retain the "MUST NOT accept expired SIG". Or is this just too wierd? --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 12:31:37 -0500 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> <Pine.GSO.4.55.0401151349150.16749@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Fri Jan 16 18:46:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Samuel Weiler <weiler@tislabs.com>, namedroppers@ops.ietf.org In-Reply-To: <Pine.GSO.4.55.0401151349150.16749@filbert> References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> <Pine.GSO.4.55.0401151349150.16749@filbert> Precedence: bulk MUST be configurable as to whether to accept expired records, SHOULD be configurable to as to the maximum out of date expired records can be to be acceptable. MUST default to not accepting expired records. At 01:58 PM 1/15/2004, Samuel Weiler wrote: > >From records-06, section 3.1.5, first paragraph: > > The Signature Expiration and Inception fields specify a validity > period for the signature. The RRSIG record MUST NOT be used for > authentication prior to the inception date and MUST NOT be used for > authentication after the expiration date. > >To accomodate local policy, I think these should be SHOULD NOTs. > >I can imagine some resolvers wanting to knowingly use expired RRSIGs. >Perhaps the error when a RRSIG has expired but otherwise validates >will be more gentle (or more user overridable) than an error when the >RRSIG is missing or doesn't validate at all. Perhaps a given zone >will be known to have bad RRSIGs, and that could be configured on a >per-zone basis. Perhaps the resolver lacks any sense of the current >time, and doesn't want to check times at all. Perhaps the resolver >knows that its clock is wildly inaccurate and wants to globablly allow >for five hours of slop in either direction. Perhaps there will be a >default local policy that states: for a given zone, unless you've seen >more recent RRSIGs, keep accepting the old ones -- once any newer >RRSIG appears, reject the old ones. > >These are all local policies, the merits of which can be debated (we >probably shouldn't do that here and now), but I see no need to >prohibit them wholesale. > >-- 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: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 12:44:20 -0500 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <200401161718.i0GHIS309905@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Jan 16 18:57:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk ----- Original Message ----- From: "bill" <bmanning@karoshi.com> > > > > I think there is a danger if the specifications say it is ok to go "off the > > reservation" and accept certain errors. Unless an application and user is > > willing to accept risky responses (example: RRSIG verified, but time was > > off, or RRSIG in an algorithm the resolver cannot understand), it can > > request that, but it should be able to rely on a some base security checks. > .... > > > > I would rather see a base "MUST NOT accept expired SIG" as the default > > operation, and anything beyond that as an option an app can specify, rather > > than "SHOULD NOT" and have an application not be sure what the resolver is > > doing. > > > > Scott > > > -- Sam > > perhaps its me, but some thinking leads me to beleive that > we are mixing features/functionality here. What if folks > have a "stock" resolver (whatever the heck that is) and a > "validator", where the default is that the resolver "throws" > data to the validator, which does the checking and then "throws" > a response back to the resolver. Much less change on the > part of the resolver (can impliment local policy) and then > the validator can retain the "MUST NOT accept expired SIG". > > Or is this just too wierd? > nope, sounds like it could be a common set up. I was probably blurring the lines between resolver and validator too much there. If the resolver throws stuff to the validator, and the validator returns the answer, there would have to be other info there if an error occurred so the resolver can make a decision. There is also the problem of a recursive resolver acting on behalf of a stub. If an expired RRSIG is encountered, what should the recursive resolver pass back to the stub? The stub has not said what kind of response it is willing to accept. Scott > --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: bill <bmanning@karoshi.com> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 10:12:48 -0800 (PST) Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <002401c3dc58$5ee67460$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Jan 16 19:26:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: scottr@nist.gov (Scott Rose) In-Reply-To: <002401c3dc58$5ee67460$b9370681@barnacle> from "Scott Rose" at Jan 16, 2004 12:44:20 PM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk > > perhaps its me, but some thinking leads me to beleive that > > we are mixing features/functionality here. What if folks > > have a "stock" resolver (whatever the heck that is) and a > > "validator", where the default is that the resolver "throws" > > data to the validator, which does the checking and then "throws" > > a response back to the resolver. Much less change on the > > part of the resolver (can impliment local policy) and then > > the validator can retain the "MUST NOT accept expired SIG". > > > > Or is this just too wierd? > > > > nope, sounds like it could be a common set up. I was probably blurring the > lines between resolver and validator too much there. If the resolver throws > stuff to the validator, and the validator returns the answer, there would > have to be other info there if an error occurred so the resolver can make a > decision. > > There is also the problem of a recursive resolver acting on behalf of a > stub. If an expired RRSIG is encountered, what should the recursive > resolver pass back to the stub? The stub has not said what kind of response > it is willing to accept. presuming a validator "module" - one could conceive that it would plug into the iterative/caching resolver and then the stub would behave the way it does today... > > Scott > > > --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: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 14:17:09 -0500 (EST) Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> <Pine.GSO.4.55.0401151349150.16749@filbert> <6.0.1.1.2.20040116122716.02c77a08@localhost> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Jan 16 20:39:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <6.0.1.1.2.20040116122716.02c77a08@localhost> Precedence: bulk Going back to 2119: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. On Fri, 16 Jan 2004, Mike StJohns wrote: > MUST be configurable as to whether to accept expired records, SHOULD be > configurable to as to the maximum out of date expired records can be to be > acceptable. MUST default to not accepting expired records. Configurability is not a MUST. At most it's a SHOULD, and probably a MAY. I'm not even sure about the default... I'm happy with taking the original text, replacing MUST with SHOULD, and moving on. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 14:47:31 -0500 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> <Pine.GSO.4.55.0401151349150.16749@filbert> <6.0.1.1.2.20040116122716.02c77a08@localhost> <Pine.GSO.4.55.0401161413351.3612@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Fri Jan 16 21:00:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Samuel Weiler <weiler@tislabs.com>, namedroppers@ops.ietf.org In-Reply-To: <Pine.GSO.4.55.0401161413351.3612@filbert> References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> <Pine.GSO.4.55.0401151349150.16749@filbert> <6.0.1.1.2.20040116122716.02c77a08@localhost> <Pine.GSO.4.55.0401161413351.3612@filbert> Precedence: bulk How about MAY be configurable as to whether to accept expired records. If configurable, SHOULD be configurable to as to the maximum out of date expired records can be to be acceptable. And if configurable, MUST default to not accepting expired records. At 02:17 PM 1/16/2004, Samuel Weiler wrote: >Going back to 2119: > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > >On Fri, 16 Jan 2004, Mike StJohns wrote: > > > MUST be configurable as to whether to accept expired records, SHOULD be > > configurable to as to the maximum out of date expired records can be to be > > acceptable. MUST default to not accepting expired records. > >Configurability is not a MUST. At most it's a SHOULD, and probably a >MAY. I'm not even sure about the default... > >I'm happy with taking the original text, replacing MUST with SHOULD, >and moving on. > >-- 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: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Proposed Resolution to LLMNR issue 63: Miscellaneous NITs (part 3) Date: Tue, 20 Jan 2004 08:14:31 -0800 (PST) Lines: 120 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue Jan 20 17:19:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 63 is enclosed below. The proposed fix is as follows: Change "appex" to "apex" throughout the document. Add the following definition of "reachable" to Section 1.2: "An address is considered reachable over a link if either an ARP or neighbor discovery cache entry exists for the address on the link." In section 2, change: "Enabling LLMNR for use in situations where a DNS server has been configured will result in a change in default behavior without a simultaneous update to configuration information." To: "Enabling LLMNR for use in situations where a DNS server has been configured will result in a change in default behavior without a simultaneous update to configuration information." In Section 3,.1, change: " The order in which various name resolution mechanisms should be used can be specified using the Name Service Search Option for DHCP [RFC2937]." To: " The order in which various name resolution mechanisms should be used can be specified using the Name Service Search Option (NSSO) for DHCP [RFC2937], using the LLMNR Enable Option code carried in the NSSO data." In Section 2.3, add: "For example, a host configured to have computer name "host1" and to be a member of the "example.com" domain, and with IPv4 address 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: host1. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 host1.example.com. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 1.1.1.10.in-addr.arpa. IN PTR host1. IN PTR host1.example.com. 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN PTR host1. IN PTR host1.example.com An LLMNR responder might be further manually configured with the name of a local mail server with an MX RR included in the "host1." and "host1.example.com." records." ------------------------------------------------------------------------ Issue 63: Miscellaneous NITs (Part 3) Submitter name: Ralph Droms Submitter email address: rdroms@cisco.com Date first submitted: January 9, 2004 Reference: Document: LLMNR-28 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: s/appex/apex/ ? Should "reachable" or "reachable through the link" be included in the terminology section? Section 2, fourth paragraph: what are "upgraded hosts"? Section 3.1, sixth paragraph: if LLMNR is to be configured in the name resolution mechanism through the DHCP Name Service Search Option (NSSO), there has to be some option concerning LLMNR whose option code can be carried in the NSSO data. The discussion about dynamic RTO computation seems OK. I still think it would be useful to include some text about the use of LLMNR when responders are authoritative for names that have only a single component, for example, when the responders are hosts on a home network where users may enter a name with no domain. Here is some text that might fit into section 2.3: For example, a Windows 2000 host configured through the "System Properties" control panel to have computer name "host1" and to be a member of the "example.com" domain, and with IPv4 address 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: host1. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 host1.example.com. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 1.1.1.10.in-addr.arpa. IN PTR host1. IN PTR host1.example.com. 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN PTR host1. IN PTR host1.example.com An LLMNR responder might be further manually configured with the name of a local mail server with an MX RR included in the "host1" and "host1.example.com" records. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Proposed resolution to LLMNR Issue 59: Miscellaneous Issues Date: Tue, 20 Jan 2004 08:19:56 -0800 (PST) Lines: 299 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue Jan 20 17:19:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 59 is enclosed below. The proposed fix is as follows:' In Section 2.2, change: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone root." To: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone apex except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone apex." In Section 2.2, change: "Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." To: "Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." Add the following paragraph to Section 2.2: "Upon configuring an IP address responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has. However, in general whether RRs are manually or automatically created is an implementation decision." Change Section 2.7 from: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 0 is recommended in highly dynamic environments (such as mobile ad-hoc networks). In less dynamic environments, LLMNR traffic can be reduced by setting the TTL to a higher value. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 30 seconds is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc networks), the TTL value may need to be reduced. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." Add the following section: "2.1. LLMNR packet format LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for both queries and responses. LLMNR implementations SHOULD send UDP queries and responses only as large as are known to be permissible without causing fragmentation. When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST accept UDP queries and responses as large as permitted by the link MTU. 2.1.1. LLMNR header format LLMNR queries and responses utilize the DNS header format defined in [RFC1035] with exceptions noted below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied from the query to the response and can be used by the sender to match responses to outstanding queries. The ID field in a query SHOULD be set to a pseudo-random value. QR A one bit field that specifies whether this message is an LLMNR query (0), or an LLMNR response (1). OPCODE A four bit field that specifies the kind of query in this message. This value is set by the originator of a query and copied into the response. This specification defines the behavior of standard queries and responses (opcode value of zero). Future specifications may define the use of other opcodes with LLMNR. LLMNR senders and responders MUST support standard queries (opcode value of zero). LLMNR queries with unsupported OPCODE values MUST be silently discarded by responders. TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. The TC bit MUST NOT be set in an LLMNR query and if set is ignored by an LLMNR responder. If the TC bit is set an LLMNR response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the LLMNR query over TCP using the unicast address of the responder as the destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit. Z Reserved for future use. Implementations of this specification MUST set these bits to zero in both queries and responses. If these bits are set in a LLMNR query or response, implementations of this specification MUST ignore them. Since reserved bits could conceivably be used for different purposes than in DNS, implementors are advised not to enable processing of these bits in an LLMNR implementation starting from a DNS code base. RCODE Response code -- this 4 bit field is set as part of LLMNR responses. In an LLMNR query, the RCODE MUST be zero, and is ignored by the responder. The response to a multicast LLMNR query MUST have RCODE set to zero. A sender MUST silently discard an LLMNR response with a non-zero RCODE sent in response to a multicast query. If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to the TCP query. Responding with the TC bit set is preferrable to not sending a response, since it enables errors to be diagnosed. Since LLMNR responders only respond to LLMNR queries for names for which they are authoritative, LLMNR responders MUST NOT respond with an RCODE of 3; instead, they should not respond at all. LLMNR implementations MUST support EDNS0 [RFC2671] and extended RCODE values. QDCOUNT An unsigned 16 bit integer specifying the number of entries in the question section. A sender MUST place only one question into the question section of an LLMNR query. LLMNR responders MUST silently discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders MUST silently discard LLMNR responses with QDCOUNT not equal to one. ANCOUNT An unsigned 16 bit integer specifying the number of resource records in the answer section. LLMNR responders MUST silently discard LLMNR queries with ANCOUNT not equal to zero. NSCOUNT An unsigned 16 bit integer specifying the number of name server resource records in the authority records section. Authority record section processing is described in Section 2.9. ARCOUNT An unsigned 16 bit integer specifying the number of resource records in the additional records section. Additional record section processing is described in Section 2.9." Delete the following sentence from Section 2.2: "An LLMNR query is composed in exactly the same manner and with the same packet format as a DNS query. " Delete the following sentence from Section 2.3: "A response to an LLMNR query is composed in exactly the same manner and with the same packet format as a response to a DNS query. " Add the following to the IANA considerations section 6: "This specification creates one new name space: the reserved bits in the LLMNR header. These are allocated by IETF Consensus, in accordance with BCP 26 [RFC2434]." Add the following to the normative reference section: [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2845] Vixie, P., et al., "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. -------------------------------------------------------------------------- Issue 59: Miscellaneous Issues Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: December 17, 2003 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02305.html Document: LLMNR-27 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The draft could benefit from addition of a section gathering in one place all the requirements relating to the use of the DNS packet format for LLMNR. For example, use of the TC bit is not defined and neither are the AD and CD bits (which I assume are set to zero). In Section 2.2, change: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone root." To: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone appex except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone appex." In Section 2.2, change: "Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." To: "Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." Add the following paragraph to Section 2.2: "Upon configuring an IP address responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has. However, in general whether RRs are manually or automatically created is an implementation decision." Change Section 2.7 from: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 0 is recommended in highly dynamic environments (such as mobile ad-hoc networks). In less dynamic environments, LLMNR traffic can be reduced by setting the TTL to a higher value. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 30 seconds is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc networks), the TTL value may need to be reduced. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: Proposed resolution to LLMNR Issue 59: Miscellaneous Issues Date: Tue, 20 Jan 2004 11:48:00 -0500 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0401200814360.8525@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Tue Jan 20 17:57:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Bernard Aboba <aboba@internaut.com>, namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.56.0401200814360.8525@internaut.com> References: <Pine.LNX.4.56.0401200814360.8525@internaut.com> Precedence: bulk At 11:19 2004-01-20, Bernard Aboba wrote: >The text of LLMNR Issue 59 is enclosed below. I agree that the changes below address all the issues raised by me on this ticket. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-29.txt Date: Tue, 20 Jan 2004 15:43:40 -0500 Lines: 96 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 20 22:02:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-29.txt Pages : 26 Date : 2004-1-20 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-29.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-29.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-29.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: <2004-1-20142545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-29.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-29.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20142545.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Miek Gieben <miekg@atoom.net> Subject: proposed text for 'direct nsec queries' Date: Tue, 20 Jan 2004 22:04:53 +0100 Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Tue Jan 20 22:17:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers <namedroppers@ops.ietf.org> Mail-Followup-To: namedroppers <namedroppers@ops.ietf.org> Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Precedence: bulk Hello, Following up on some discussions on the (tiny) subject of direct queries for NSEC I propose something like the following text to be included in the drafts. [this mail is sent to provoke some discussion] proposed text for protocol-05 Direct Queries for NSEC Records at Delegation Points When the qtype equals NSEC and the qname equals the delegation point of a zone, a problem can pop up when a server is both authoritative for the parent and child. RFC 2535 said that in this case both NSEC's should be returned. It failed to specify how a resolver should treat these two NSEC's. These two records are identical except in their rdata. The child NSEC has the SOA bit set, while the parent has not. Unlike any other RR these two are not a RRset and a resolver must treat them differently from any other RR type. The current spec (2535bis) is silent on this topic and we want to avoid opening a can of worms when specifying this behavior. The current thinking is that direct NSEC queries are never required for the normal operation of the DNS (ie resolving). Another problem is correlated to caches. Depending on the server behavior a cache would either have a child's NSEC or parental NSEC or both. The client can not specify which NSEC it wants. This is also not specified in 2535. For these reasons direct queries for NSEC can not be relied upon, therefor the reply from the server is not specified in this document. Resolvers cannot depend on the data returned in the answer. grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Bernard Aboba <aboba@internaut.com> Subject: LLMNR Change Summary Date: Tue, 20 Jan 2004 15:19:50 -0800 (PST) Lines: 58 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Jan 21 00:15:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Since the conclusion of DNSEXT WG last call on the LLMNR specification, a number of new issues were submitted. Issue Status report ------------------- Total new issues: 14 Resolved: 14 Open: 0 Disposition ----------- Rejected: 1 (Technical) Accepted: 13 Editorial: 5 Technical: 8 Submitters: Ralph Droms: 6 Bernard Aboba: 5 Tony Hain: 1 Olafur G.: 1 Michael Patton: 1 A summary of the Issues is included below: # Type Title Submitter --- ---- ----- --------- 50 Technical LLMNR-24 Review Ralph Droms 51 Technical Clarity Issues Tony Hain 52 Editorial LLMNR-25 Review Ralph Droms 53 Editorial Miscellaneous NITs-1 Ralph Droms 54 Editorial Comments on -25 Michael Patton 55 Technical Sender checks Bernard Aboba 56 Technical Miscellaneous NITs-2 Ralph Droms 57 Editorial Organizational improv. Bernard Aboba 58 Technical DNS server usage of LLMNR Bernard Aboba 59 Technical Miscellaneous Issues Olafur Gudmundsson 60 Technical Uniqueness check on linkup Ralph Droms 61 Technical Miscellaneous Clarif. Bernard Aboba 62 Reject RCODEs Bernard Aboba 63 Editorial Miscellaneous NITs-3 Ralph Droms Details on the issues and their resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The latest copy of the specification with all of the changes applied is available here: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-29.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: proposed text for 'direct nsec queries' Date: Wed, 21 Jan 2004 00:31:43 +0000 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <miekg@atoom.net> X-From: owner-namedroppers@ops.ietf.org Wed Jan 21 01:40:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers <namedroppers@ops.ietf.org> In-Reply-To: Message from Miek Gieben <miekg@atoom.net> of "Tue, 20 Jan 2004 22:04:53 +0100." <20040120210453.GA26114@atoom.net> Precedence: bulk Miek, I have a couple of comments on your proposed text. Since we're supposed to be superseding RFC2535, I think the draft should not refer back to something that's effectively dead. This is even more important when we know a corner case is being left unspecified that was also left unspecified in 2535. If 2535 got this wrong, we should take this opportunity to fix it. As part of the overall DNSSEC tidy-up and rewrite, I think some clarity is needed here on (a) what the server should and shouldn't do; and (b) what a resolver is expected to do with that response. If there's a corner case because a server is authoritative for the parent and child, the draft should eliminate it by clearly documenting what the server and resolver should do and shouldn't do for that case. Or at the very least the draft should say what the preferred behaviour is. [And why.] IMO some clarity is needed here: the draft should say what it means and mean what it says. Your proposed text is too fluffy IMO. It could be misinterpreted. That might lead to inconsistences in implementation because it leaves enough wiggle room for a server to do one thing while a resolver does the other. Some of the language you suggested looks bad. It's inappropriate for a standards-track RFC to use phrases like "a can of worms" or "a problem can pop up". Y'know, like, this doesn't read well, man. Know what I mean, dude? Sure, 2535 is a can of worms. But it's one that should get a bullet in the head, if I can mix metaphors. How about the text below? Explicit Queries for NSEC Records at Delegation Points Special consideration will be needed in the case of queries for an NSEC QTYPE when the QNAME is a delegation point and the server is authoritative for both the parent and child zones. In these circumstances the server will have two NSEC records with different RDATA matching the query. One will be from the parent zone for the delegation and the other will be from the child zone. These two NSEC records MUST NOT be treated as an RRset. The server SHOULD (MUST?) return both NSEC records in response to such queries. When NSEC records exist above and below a zone cut for some QNAME, a resolver making an explicit NSEC query cannot specify which of these two NSEC records it wants. Therefore, a resolver which makes an explicit query for an NSEC qtype MUST (SHOULD?) be prepared to receive a response containing both these NSEC records. It cannot know in advance that the QNAME is a delegation point or if the queried server is authoritative for both the parent and child zones. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Paul Vixie <paul@vix.com> Subject: Re: proposed text for 'direct nsec queries' Date: Wed, 21 Jan 2004 01:47:24 +0000 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <jim@rfc1035.com> X-From: owner-namedroppers@ops.ietf.org Wed Jan 21 03:04:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers <namedroppers@ops.ietf.org> In-Reply-To: Message from Jim Reid <jim@rfc1035.com> of "Wed, 21 Jan 2004 00:31:43 GMT." <1955.1074645103@gromit.rfc1035.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk jim reid wrote: > How about the text below? > > Explicit Queries for NSEC Records at Delegation Points > > Special consideration will be needed in the case of queries for an > NSEC QTYPE when the QNAME is a delegation point and the server is > authoritative for both the parent and child zones. In these > circumstances the server will have two NSEC records with different > RDATA matching the query. One will be from the parent zone for the > delegation and the other will be from the child zone. These two NSEC > records MUST NOT be treated as an RRset. The server SHOULD (MUST?) > return both NSEC records in response to such queries. When NSEC > records exist above and below a zone cut for some QNAME, a resolver > making an explicit NSEC query cannot specify which of these two NSEC > records it wants. Therefore, a resolver which makes an explicit query > for an NSEC qtype MUST (SHOULD?) be prepared to receive a response > containing both these NSEC records. It cannot know in advance that the > QNAME is a delegation point or if the queried server is authoritative > for both the parent and child zones. miek's proposed text was better. (note that miek said it was only draft discussion quality, so it was unfair of jim to question its informality.) there are too many corner cases to cover if we want to define "proper" behaviour for queries at delegation points. for example, what if the reason were that the server had recursion enabled and had thusly cached the above-the-cut NSEC RR? for this reason, a proposal limited to servers who are authoritative for both the parent and child is not useful. miek's proposal is in my opinion the correct one in this circumstance. since there is no protocol necessity for above-the-cut NSEC queries, it is reasonable to specifically undefine them. some servers may decide to answer with delegation responses when queried for anything "at" a delegation point (other than the DS RRset, which may be required due to the grandparent problem). some servers may decide to issue SERVFAIL when queried for NSEC "at" a delegation point. if we place a requirement on it then we have to explain our reasoning and enumerate the cases where our requirement applies. if we just say it's undefined, then we're done. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: proposed text for 'direct nsec queries' Date: Wed, 21 Jan 2004 13:08:07 +0000 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <paul@vix.com> Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Wed Jan 21 14:28:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: Message from Paul Vixie <paul@vix.com> of "Wed, 21 Jan 2004 01:47:24 GMT." <20040121014724.A6B6514C51@sa.vix.com> Precedence: bulk >>>>> "Paul" == Paul Vixie <paul@vix.com> writes: Paul> miek's proposed text was better. (note that miek said it Paul> was only draft discussion quality, so it was unfair of jim Paul> to question its informality.) Maybe so. But that discussion would/should lead to agreed text for the draft that goes to last call. More formal language would be needed eventually. That process might as well start as the proposed text is discussed and refined. Paul> there are too many corner cases to cover if we want to Paul> define "proper" behaviour for queries at delegation points. Sigh. I fear there may well be too many corner cases. But IMO that isn't justification for not documenting them. Paul> some servers may decide to issue SERVFAIL when queried for Paul> NSEC "at" a delegation point. This worries me. Something smells very bad -- more than DNSSEC usually smells bad -- if the spec leaves something so wide open that different implementations could return responses as far apart as NOERROR and SERVFAIL for the same query, all other things being equal. Paul> if we place a requirement on it then we Paul> have to explain our reasoning and enumerate the cases where Paul> our requirement applies. if we just say it's undefined, Paul> then we're done. But we'll have done a sloppy job and could well be revisiting the problem in 5-10 year's time. By which time everyone will have forgotten what those cases and requirements were. [And then they'll pop up wackamole-style again, just as they've been doing for the last umpteen years of DNSSEC development.] If the corner cases are known about now, they should at the very least be enumerated and documented. So if the spec is going to say something is undefined, it should say why the behaviour is undefined. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: DNSKEYset in -protocol Section A example Date: Wed, 21 Jan 2004 08:35:00 -0500 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <Pine.NEB.3.96L.1040121102131.51401A-100000@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: <lcws@secret-wg.org>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Wed Jan 21 14:46:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <DNSSEC-editors@east.isi.edu> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk You are correct, but I think we may be adding more complexity for very little efficiency. Most DNS admins are not security gurus, so presenting a list of conditionals to go through to determine how many RRSIGs are needed at the keyset would be confusing. If all the other RRsets are signed by both DNSKEYs, why not the DNSKEY RRset? While there is some efficiency, dropping one RRSIG from the zone file (and DNSKEY responses) doesn't gain enough to add more complexity to the signing rules IMHO. However, since this would be a spec change, I cc'd namedroppers. Scott ----- Original Message ----- From: "Sam Weiler" <weiler@watson.org> To: <DNSSEC-editors@east.isi.edu> Cc: <lcws@secret-wg.org> Sent: Wednesday, January 21, 2004 4:24 AM Subject: DNSKEYset in -protocol Section A example > Kind Editors, > > It should only be necessary to sign a DNSKEYset with the DNSKEY(s) > that are intended to be used as SEPs unless there are multiple > algorithms in the DNSKEYset, in which case there must be at least one > RRSIG made by each algorithm. Is there any specific guidance anywhere > about the first part of that requirement? Section 2.2 doesn't address > it specifically. > > Perhaps this could be combined with the one-key-per-zone discussion > and SEP clarifications (see my earlier comments on -protocol section > 2.1). > > I noticed this because the signed zone in -protocol appendix A has its > apex DNSKEYset signed by both of the DNSKEYs. That's not necessarily > wrong, but the text should point out that it isn't necessary. > > -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Miek Gieben <miekg@atoom.net> Subject: Re: proposed text for 'direct nsec queries' Date: Wed, 21 Jan 2004 14:47:18 +0100 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <1955.1074645103@gromit.rfc1035.com> <20040121014724.A6B6514C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Wed Jan 21 14:57:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> Mail-Followup-To: Paul Vixie <paul@vix.com>, namedroppers <namedroppers@ops.ietf.org> Content-Disposition: inline In-Reply-To: <20040121014724.A6B6514C51@sa.vix.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Precedence: bulk [On 21 Jan, @02:47, Paul wrote in "Re: proposed text for 'direct ..."] > jim reid wrote: > > > How about the text below? > > > > Explicit Queries for NSEC Records at Delegation Points > > > > for an NSEC qtype MUST (SHOULD?) be prepared to receive a response > > containing both these NSEC records. It cannot know in advance that the > > QNAME is a delegation point or if the queried server is authoritative > > for both the parent and child zones. > > miek's proposed text was better. (note that miek said it was only draft > discussion quality, so it was unfair of jim to question its informality.) it was indeed alpha quality :-) The reason to define explicit server behavior would be: "give back what you've got" - property of DNS. But this leads to weird corner cases that also need to be documented, which could lead to even more corner cases. We don't want to go there for these weirdo nsec queries. Therefor I think it is best to define it to 'undefined'. Direct queries for nsec are not part of the normal resolving process. If a resolver _needs_ an nsec it will get the nsec in the answer (as part of a nxdomain respons, for instance). > miek's proposal is in my opinion the correct one in this circumstance. > since there is no protocol necessity for above-the-cut NSEC queries, it > is reasonable to specifically undefine them. some servers may decide > to answer with delegation responses when queried for anything "at" a > delegation point (other than the DS RRset, which may be required due to > the grandparent problem). some servers may decide to issue SERVFAIL or a 'REFUSED'. The only thing resolvers need to know is that nsec queries are special and that answers to those queries can not relied up on. And that nsec's are always alone in a RRset. regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Paul Vixie <paul@vix.com> Subject: Re: proposed text for 'direct nsec queries' Date: Wed, 21 Jan 2004 17:47:25 +0000 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <jim@rfc1035.com> X-From: owner-namedroppers@ops.ietf.org Wed Jan 21 19:08:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers <namedroppers@ops.ietf.org> In-Reply-To: Message from Jim Reid <jim@rfc1035.com> of "Wed, 21 Jan 2004 13:08:07 GMT." <2458.1074690487@gromit.rfc1035.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > Paul> there are too many corner cases to cover if we want to > Paul> define "proper" behaviour for queries at delegation points. > > Sigh. I fear there may well be too many corner cases. But IMO that > isn't justification for not documenting them. it can be, though, if the corner case you didn't cover ends up being the one that matters to somebody. if you deliberately undefine it, then noone will (sanely) depend on implementation-specific behaviour. > Paul> some servers may decide to issue SERVFAIL when queried for > Paul> NSEC "at" a delegation point. > > This worries me. Something smells very bad -- more than DNSSEC usually > smells bad -- if the spec leaves something so wide open that different > implementations could return responses as far apart as NOERROR and > SERVFAIL for the same query, all other things being equal. it's not the only thing that's deliberately left undefined. if you send a query that makes no sense you will get an answer that makes no sense. consider the "upward referral" problem, where an authority-only server receives a query for a zone it doesn't carry. correct answers range from SERVFAIL to a list of root name servers (which an authority only server might not even have). sometimes the best thing to do is specify the part you care about and explicitly note the unspecificity of the parts you don't care about. asking for NSEC RR's qualifies squarely in this category, and we are indebted to miek for pointing this out. > ... So if the spec is going to say something is undefined, it should > say why the behaviour is undefined. i believe that miek's proposed text does that. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: itojun@iijlab.net Subject: Re: WGLC on DNSSEC bis document set Date: Thu, 22 Jan 2004 16:32:17 +0900 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <200312180654.hBI6sOdH023644@birch.ripe.net> Cc: dnssec-editors@east.isi.edu X-From: owner-namedroppers@ops.ietf.org Thu Jan 22 08:46:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: Your message of "Thu, 18 Dec 2003 07:54:24 +0100" <200312180654.hBI6sOdH023644@birch.ripe.net> To: namedroppers@ops.ietf.org X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Precedence: bulk > draft-ietf-dnsext-dnssec-intro-08 > draft-ietf-dnsext-dnssec-records-06 sorry that i did not meet the last-call deadline. will try to go throgh draft-ietf-dnsext-dnssec-protocoo-04 soon. itojun intro-08 3. or 4. you may want to enumerate what "most of the threats" are solved, or not solved - dnsext-dns-threats have the following sections (dnsext-dns-threats section 3 does not apply here as section 3 analyzes old-DNSSEC), and it is not easy to relate topics in intro-08 to each item. 2. Known Threats 2.1. Packet Interceptionu 2.2. ID Guessing and Query Prediction 2.3. Name Gamesco' 2.4. Betrayal By Trusted Serversu 2.5. Denial of Servicenda! 2.6. Authenticated Denial of Domain Names records-06 1.3.1 i think it fine to move DSA to OPTIONAL. records-06 2, 3, 4 "The xxxx RR is class independent" - which class should I use then? (I assume it to be "IN" but there's no guidance) records-06 2.1.1 by "Bit X" do you mean 2^X ("bit 0" is LSB), or 2^(16-X) ("bit 0" is MSB)? there's no definition given. maybe it is better to put these bits into diagram (2.1). records-06 2.2 description on Flag field seems too restrictive; isn't there any chance that Flag field be 1? i think it better to state "The Flag field MUST be represented as an unsigned decimal integer" (e.g. no example values). records-06 3.1.5 description of signature expiration/inception field is a bit confusing. for instance, when expiration is smaller than inception (like expiration = 1 and inception = 2^32 - 1), expiration field is not the number of seconds since 1970/1/1, but 2^32 more. what happens when 2^32 seconds have passed? (year 2106) maybe it's better to have these fields 64bit, or have scaling parameter like TCP window scaling option? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> Subject: RE: WGLC on DNSSEC bis document set Date: Thu, 22 Jan 2004 10:39:41 -0500 Lines: 47 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: dnssec-editors@east.isi.edu X-From: owner-namedroppers@ops.ietf.org Thu Jan 22 17:56:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.2) Precedence: bulk I think it is clear if you actually go look at the serial number arithmetic RFC; however it would probably be helpful to change Signature Expiration and Inception field values are in POSIX.1 time format: a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. to Signature Expiration and Inception field values are POSIX.1 time format modulo 2**32: the least significant 32-bits of the number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. Since I believe that signature validity periods will rarely be even as long as one year, there is no need to waste bits by expanding these fields to 64 bits or to lose the one second resolution by scaling them. This is an instance where "serial number arithmetic" with a resolution of one second works well. Thanks, Donald -----Original Message----- From: owner-dnssec-editors@east.isi.edu [mailto:owner-dnssec-editors@east.isi.edu] On Behalf Of itojun@iijlab.net Sent: Thursday, January 22, 2004 2:32 AM To: namedroppers@ops.ietf.org Cc: dnssec-editors@east.isi.edu Subject: Re: WGLC on DNSSEC bis document set records-06 3.1.5 description of signature expiration/inception field is a bit confusing. for instance, when expiration is smaller than inception (like expiration = 1 and inception = 2^32 - 1), expiration field is not the number of seconds since 1970/1/1, but 2^32 more. what happens when 2^32 seconds have passed? (year 2106) maybe it's better to have these fields 64bit, or have scaling parameter like TCP window scaling option? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: itojun@iijlab.net Subject: RE: WGLC on DNSSEC bis document set Date: Fri, 23 Jan 2004 11:04:05 +0900 (JST) Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <62173B970AE0A044AED8723C3BCF2381037F33DC@ma19exm01.e6.bcs.mot.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Cc: namedroppers@ops.ietf.org, dnssec-editors@east.isi.edu X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 03:23:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Donald.Eastlake@motorola.com In-Reply-To: Your message of "Thu, 22 Jan 2004 10:39:41 -0500" <62173B970AE0A044AED8723C3BCF2381037F33DC@ma19exm01.e6.bcs.mot.com> X-Mailer: Cue version 0.6 (031125-1130/itojun) Precedence: bulk > I think it is clear if you actually go look at the serial number arithmetic RFC; > however it would probably be helpful to change > > Signature Expiration and Inception field values are in POSIX.1 time > format: a 32-bit unsigned number of seconds elapsed since 1 January > 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. > > to > > Signature Expiration and Inception field values are POSIX.1 time > format modulo 2**32: the least significant 32-bits of the number of > seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap > seconds, in network byte order. > > Since I believe that signature validity periods will rarely be even as > long as one year, there is no need to waste bits by expanding these > fields to 64 bits or to lose the one second resolution by scaling them. > This is an instance where "serial number arithmetic" with a resolution > of one second works well. based on what i get from protocol-04 page 28, expiration/inception field will be compared to wall clock of resolver, therefore DNSSEC baesd on the current packet format will not work after year 2106. so i think it necessary to address "after year 2106" issue by some way. there are multiple possibilities: - expand the field to 64bits - scaling (trade lifetime with resolution) - anything else? itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Conclusion WGLC NSEC++ Date: Fri, 23 Jan 2004 12:16:49 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 12:32:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.609) Precedence: bulk Dear colleagues, This a conclusion of the WGLC on draft-ietf-dnsext-nsec-rdata-03.txt as issued 22nd of December 2003. (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02322.html) The last call did raise a number of editorial issues but there where no comments on the technical specifications. The specification of the representation of the available type codes in the NSEC RDATA will be incorporated into the DNSSECbis document set. The document editor will incorporate the editorial comments and publish that document for review. If during a period of 2 weeks after publication of the new version of the I-D no new editorial comments are received the document will be forwarded to the IESG. --Olaf Kolkman DNSEXT Co-Chair. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: TMM (too many mnemonics) Date: Fri, 23 Jan 2004 12:15:38 +0100 (CET) Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040121174725.35E1814BBE@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 13:32:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers <namedroppers@ops.ietf.org> In-Reply-To: <20040121174725.35E1814BBE@sa.vix.com> Precedence: bulk RFC2535 allows numbers or mnemonics for the flags and protocol fields in the KEY RR presentation format, but -records drops that for DNSKEY and requires numbers. Was that intentional? -records also allows algorithm mnemonics in the DS presentation format, but RFC3658 only allows numbers (for both the algorithm and digest type fields). Again, was that intentional? To summarize: Field Allowed presentation formats Different? -records RFC2535 RFC3658 (DNS)KEY algorithm either either (DNS)KEY flags number either X (DNS)KEY protocol number either X DS algorithm either number X DS digest number number SIG algorithm either either -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: RE: WGLC on DNSSEC bis document set Date: Fri, 23 Jan 2004 13:59:03 +0100 (CET) Lines: 74 Sender: owner-namedroppers@ops.ietf.org References: <62173B970AE0A044AED8723C3BCF2381037F33DC@ma19exm01.e6.bcs.mot.com> <20040123020405.40DE089@coconut.itojun.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 14:06:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <20040123020405.40DE089@coconut.itojun.org> Precedence: bulk Most of the items I found during my review of the DNSSECbis documents were either omissions or editorial in nature. I've included a summary below. I don't think any of these are major technical issues -- most are matters which are well understood but incorrectly or inadequately documented. This message is intended mostly as a reference list. I suggest that we start separate threads for each issue that needs discussion (such as the mnemonics message I just end). For several of these items, more extensive discussion has been sent to the editors' list and many more minor nits have been sent to the editors. In -protocol, the DS-13 resolver-side grandparent problem fixes are missing. Section 3.1.4.1 tells servers authoritative for both a zone and its grandparent how to answer a DS query (with NODATA), and section 4.2 tells resolvers to ask the parent zone for the DS, but it doesn't tell resolvers how to find the parent zone. RFC3658 section 2.1.2.2 has the needed closest encloser logic. -protocol needs to discuss the safety property and the resolver-side mandatory algorithm rules (per Mark Andrews' message). I'll post more about this in a separate thread. The docs need to do a better job explaining the DNSKEY->DNSKEY indirection. Intro's diagram (DNSKEY->[DS->DNSKEY]*->RRset) misses it entirely, as pointed out earlier. Intro and/or protocol need to explicitly say that having only a single DNSKEY in a zone works, and there are times when the mention of SEP/ZSK/KSK is confusing and perhaps misleading. As my comments on -intro noted, there are some very messy editorial changes that I think would be wise to complete before advancing that document. David Blacka found a problem with the canonical ordering section in -records (good eye, David!) In -records section 4, just as in the NSEC doc, "authoritative" is not locally defined and may confuse readers. -protocol section 2.2 does the job admirably. I suggest a direct reference from records section 4 to protocol section 2.2. -protocol section 3.2.2 implies that the default is to ignore the CD bit setting, which has the potential to deny data to clients that specifically want unvalidated data. The default should be to honor it (and copy it to outgoing queries). We can allow resolvers to un-set the bit (with a MAY), but need to add lots of Security Considerations text to explain how this might deny service to unsuspecting clients. Furthermore, it should be clarified that a resolver MAY choose to set CD even though the incoming query didn't set it (ie. if the resolver is planning to do validation itself). (Credit to Mark Andrews for this last observation.) -protocol sections 3.2.2 and 4.2 (and perhaps others) say one MUST do something unless local policy is not to. If it's reasonable for local policy to override something, a 2119 MUST doesn't make much sense. (Noticed by workshop participants.) I posted a specific MUST/SHOULD concern to the list re: out-of-date RRSIGs. I previously observed that intro's security considerations doesn't say enough about how DNSSEC can make the DNS more fragile. protocol-05's security considerations actually does that pretty well. I'd like to see more Security Considerations text across the board, but this concern has been addressed. And I just sent a note about mnemonics. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 23 Jan 2004 14:06:48 +0100 (CET) Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> <Pine.GSO.4.55.0401151349150.16749@filbert> <6.0.1.1.2.20040116122716.02c77a08@localhost> <Pine.GSO.4.55.0401161413351.3612@filbert> <6.0.1.1.2.20040116143609.02a21418@localhost> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 14:13:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Mike StJohns <Mike.StJohns@nominum.com> In-Reply-To: <6.0.1.1.2.20040116143609.02a21418@localhost> Precedence: bulk > MAY be configurable as to whether to accept expired records. If > configurable, SHOULD be > configurable to as to the maximum out of date expired records can be to be > acceptable. And if configurable, MUST default to not accepting expired > records. Much better, but this loses the main sentiment of the original, namely that one MUST NOT or SHOULD NOT use out-of-date (expired or not yet active) RRSIGs. The text above would allow a non-configurable resolver to accept out-of-date records. I have a broader proposal, which I'm about to post. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: TMM (too many mnemonics) Date: Fri, 23 Jan 2004 08:42:06 -0500 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <20040121174725.35E1814BBE@sa.vix.com> <Pine.GSO.4.55.0401231149260.22437@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 14:52:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Samuel Weiler" <weiler@tislabs.com>, "namedroppers" <namedroppers@ops.ietf.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk I do not seem to recall any discussion on the list about dropping the mnemonic option in the presentation format. Someone please correct me if I am wrong. Is there an objection to allowing the algorithm mnemonic in the presentation formats of the DS/RRSIG and DNSKEY RRs? Since there is only one protocol value now (3), I feel the mnemonics for that field could be safely dropped. Scott ----- Original Message ----- From: "Samuel Weiler" <weiler@tislabs.com> To: "namedroppers" <namedroppers@ops.ietf.org> Sent: Friday, January 23, 2004 6:15 AM Subject: TMM (too many mnemonics) > RFC2535 allows numbers or mnemonics for the flags and protocol fields > in the KEY RR presentation format, but -records drops that for DNSKEY > and requires numbers. Was that intentional? > > -records also allows algorithm mnemonics in the DS presentation > format, but RFC3658 only allows numbers (for both the algorithm and > digest type fields). Again, was that intentional? > > To summarize: > > Field Allowed presentation formats Different? > -records RFC2535 RFC3658 > (DNS)KEY algorithm either either > (DNS)KEY flags number either X > (DNS)KEY protocol number either X > DS algorithm either number X > DS digest number number > SIG algorithm either either > > -- 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: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Suzanne Woolf <Suzanne_Woolf@isc.org> Subject: DNSSECbis last call workshop -- summary Date: Fri, 23 Jan 2004 15:35:13 +0000 Lines: 68 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 16:59:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline User-Agent: Mutt/1.4i Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Greetings, As noted to the list, a "DNSSECbis last call" workshop was sponsored this week in Amsterdam by NLnet Labs, ISC, and RIPE NCC. Activities included testing of DNSSEC features in two independent authoritative server implementations and detailed analysis and discussion of the current DNSSEC protocol draft (draft-ietf-dnsext-dnssec-protocol-04.txt). * The operational tests conducted in the workshop found that the core DNSSEC features have been implemented and function as expected. Basic functional tests raised no new corner cases or other protocol issues for either implementation used. * A number of editorial issues with the documents were identified. Those that qualify as "nits" are being sent directly to the DNSSECbis-editors, several of whom were present at the workshop. * Some more extensive editorial work was also identified. This is primarily in the areas of more detailed justifications of MUSTs and SHOULDs, missing or incomplete definitions, and other clarifications in the specification for the benefit of implementors. These were not protocol changes or significant areas for new protocol specification. Individual participants will raise these concerns on namedroppers. * A couple of issues were identified that are substantive enough to need working group consensus for changes to the documents. These will be brought to the working group in the near future, in separate messages as coordinated by the chair. In summary, however, the issues identified were weaknesses in the documents, not significant problems with the specification. The workshop result was that the protocol is functionally complete. At risk of speaking for others, it seems that when the documents are revised to address the concerns raised, participants will be ready to support advancing them to the IESG. Suzanne Workshop participants, alphabetically: Jaap Akkerhuis, Mark Andrews, Roy Arends, David Blacka, Cagri Coltekin, Joao Damas, Miek Gieben, Johan Ihren, Olaf Kolkman, Matt Larson, David Lawrence, Ed Lewis, Ted Lindgreen, Bill Manning, Daniel Massey, Erik Rozendaal, Jakob Schlyter, Sam Weiler and Suzanne Woolf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: DNSSECbis last call workshop -- summary Date: Fri, 23 Jan 2004 11:15:23 -0500 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <20040123153513.GB67664@farside.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 17:26:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Suzanne Woolf <Suzanne_Woolf@isc.org>, namedroppers@ops.ietf.org In-Reply-To: <20040123153513.GB67664@farside.isc.org> References: <20040123153513.GB67664@farside.isc.org> Precedence: bulk At 10:35 2004-01-23, Suzanne Woolf wrote: > [ Moderators note: Post by non-subscriber. With the massive amount of > spam, it is easy to miss and therefore delete relevant posts > by non-subsrcibers. Please fix your subscription addresses. ] > > >Greetings, > >As noted to the list, a "DNSSECbis last call" workshop was sponsored >this week in Amsterdam by NLnet Labs, ISC, and RIPE NCC. Activities >included testing of DNSSEC features in two independent authoritative >server implementations and detailed analysis and discussion of the >current DNSSEC protocol draft >(draft-ietf-dnsext-dnssec-protocol-04.txt). >In summary, however, the issues identified were weaknesses in the >documents, not significant problems with the specification. The >workshop result was that the protocol is functionally complete. At >risk of speaking for others, it seems that when the documents are >revised to address the concerns raised, participants will be ready to >support advancing them to the IESG. > On behalf of the working group, I would like to thank RIPE NCC for hosting this workshop and all the participants for their valuable contributions of time and effort. The outcome of this workshop is a proof that we are finally close to having good DNSSECbis documents as well as two working DNSSEC implementations. Many of the nits raised in the WS and on the mailing lists, have already been addressed in the working versions of the documents. DNSSECbis WGLC formally ends today but keep the comments coming. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: LLMNR is done (RE: LLMNR Change Summary) Date: Fri, 23 Jan 2004 12:00:26 -0500 Lines: 28 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 18:09:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: namedroppers@ops.ietf.org Precedence: bulk The editor of LLMNR has posted a summary of all changes made since the WGLC started. All issues have been addressed. If no issues are raised with the current version, the chairs will advance the document to the IESG next Friday Jan 30'th 2004. Message from editor: http://psg.com/lists/namedroppers/namedroppers.2004/msg00054.html >Details on the issues and their resolutions is available here: > >http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > >The latest copy of the specification with all of the changes applied is >available here: > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-29.txt Olafur & 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> Subject: RE: WGLC on DNSSEC bis document set Date: Fri, 23 Jan 2004 11:30:11 -0500 Lines: 65 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: namedroppers@ops.ietf.org, dnssec-editors@east.isi.edu X-From: owner-namedroppers@ops.ietf.org Fri Jan 23 18:12:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'itojun@iijlab.net'" <itojun@iijlab.net> X-Mailer: Internet Mail Service (5.5.2657.2) Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Where protocol-04 says o The resolver's notion of the current time MUST be less than or equal to the time listed in the RRSIG RR's Expiration field; o The resolver's notion of the current time MUST be greater than or equal to the time listed in the RRSIG RR's Inception field; perhaps "using serial number arithmetic" should be inserted into each of these two points for clarity. This solves the problem you see. Donald -----Original Message----- From: itojun@iijlab.net [mailto:itojun@iijlab.net] Sent: Thursday, January 22, 2004 9:04 PM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org; dnssec-editors@east.isi.edu Subject: RE: WGLC on DNSSEC bis document set > I think it is clear if you actually go look at the serial number arithmetic RFC; > however it would probably be helpful to change > > Signature Expiration and Inception field values are in POSIX.1 time > format: a 32-bit unsigned number of seconds elapsed since 1 January > 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. > > to > > Signature Expiration and Inception field values are POSIX.1 time > format modulo 2**32: the least significant 32-bits of the number of > seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap > seconds, in network byte order. > > Since I believe that signature validity periods will rarely be even as > long as one year, there is no need to waste bits by expanding these > fields to 64 bits or to lose the one second resolution by scaling them. > This is an instance where "serial number arithmetic" with a resolution > of one second works well. based on what i get from protocol-04 page 28, expiration/inception field will be compared to wall clock of resolver, therefore DNSSEC baesd on the current packet format will not work after year 2106. so i think it necessary to address "after year 2106" issue by some way. there are multiple possibilities: - expand the field to 64bits - scaling (trade lifetime with resolution) - anything else? itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Brian Wellington <Brian.Wellington@nominum.com> Subject: Re: TMM (too many mnemonics) Date: Fri, 23 Jan 2004 16:43:11 -0800 (PST) Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <20040121174725.35E1814BBE@sa.vix.com> <Pine.GSO.4.55.0401231149260.22437@filbert> <00da01c3e1b6$b17099f0$b9370681@barnacle> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Jan 24 01:54:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Scott Rose <scottr@nist.gov> In-Reply-To: <00da01c3e1b6$b17099f0$b9370681@barnacle> Precedence: bulk On Fri, 23 Jan 2004, Scott Rose wrote: > I do not seem to recall any discussion on the list about dropping the > mnemonic option in the presentation format. Someone please correct me if I > am wrong. Is there an objection to allowing the algorithm mnemonic in the > presentation formats of the DS/RRSIG and DNSKEY RRs? > > Since there is only one protocol value now (3), I feel the mnemonics for > that field could be safely dropped. This sounds like an argument for dropping the field, not dropping support for mnemonics. If there's only one value, it shouldn't exist at all. Having a field whose only legal value is '3' is confusing. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: TMM (too many mnemonics) Date: Sun, 25 Jan 2004 23:28:00 +0100 (CET) Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <20040121174725.35E1814BBE@sa.vix.com> <Pine.GSO.4.55.0401231149260.22437@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sun Jan 25 23:47:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers <namedroppers@ops.ietf.org> In-Reply-To: <Pine.GSO.4.55.0401231149260.22437@filbert> Precedence: bulk After thinking about this more, I like the choices made by -records now and, even though they are changes, I suggest we adopt them. The DNSKEY flags mnemonic scheme is acrane. The BIND signing tools don't generate DNSKEYs with flags or protocol mnemonics, and I have yet to hear any of us whine. I suggest that we drop those. For the algorithm field, I'd like for DS, RRSIG, and DNSKEY to be consistent. Having spent some time arguing about algorithm mnemonics for the TCR document, I have a bit of a personal attachment to them, and I'd like to see them stay. If someone would be so kind as to dig through the DS discussion from ages past and see why mnemonics were dropped, that might be useful to us now. --- Sam > RFC2535 allows numbers or mnemonics for the flags and protocol fields > in the KEY RR presentation format, but -records drops that for DNSKEY > and requires numbers. Was that intentional? > > -records also allows algorithm mnemonics in the DS presentation > format, but RFC3658 only allows numbers (for both the algorithm and > digest type fields). Again, was that intentional? > > To summarize: > > Field Allowed presentation formats Different? > -records RFC2535 RFC3658 > (DNS)KEY algorithm either either > (DNS)KEY flags number either X > (DNS)KEY protocol number either X > DS algorithm either number X > DS digest number number > SIG algorithm either either -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Paul Vixie <paul@vix.com> Subject: Re: TMM (too many mnemonics) Date: Mon, 26 Jan 2004 01:32:56 +0000 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <weiler@tislabs.com> X-From: owner-namedroppers@ops.ietf.org Mon Jan 26 02:45:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers <namedroppers@ops.ietf.org> In-Reply-To: Message from Samuel Weiler <weiler@tislabs.com> of "Sun, 25 Jan 2004 23:28:00 +0100." <Pine.GSO.4.55.0401252316350.17246@filbert> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > After thinking about this more, I like the choices made by -records > now and, even though they are changes, I suggest we adopt them. as long as this doesn't set a precedent whereby all small changes which are improvements are also accepted (which is infinite regress for dnssec) i agree. > The DNSKEY flags mnemonic scheme is acrane. The BIND signing tools > don't generate DNSKEYs with flags or protocol mnemonics, and I have > yet to hear any of us whine. I suggest that we drop those. for the record, if bind ends up being wrong, we would fix it immediately. what i mean is, the above indicates an oversight, not intention, by isc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: prohibiting use of expired RRSIGs Date: Mon, 26 Jan 2004 10:50:07 +0900 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <200401050759.i057xSMF006856@birch.ripe.net> <ilun0921jm2.fsf@latte.josefsson.org> <Pine.GSO.4.55.0401120406380.495@filbert> <Pine.GSO.4.55.0401142033400.7196@filbert> <Pine.GSO.4.55.0401142142540.12241@filbert> <Pine.GSO.4.55.0401151349150.16749@filbert> <6.0.1.1.2.20040116122716.02c77a08@localhost> <Pine.GSO.4.55.0401161413351.3612@filbert> <6.0.1.1.2.20040116143609.02a21418@localhost> <Pine.GSO.4.55.0401162018540.23506@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike StJohns <Mike.StJohns@nominum.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Jan 26 02:57:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0401162018540.23506@filbert> Precedence: bulk Samuel Weiler; >>MAY be configurable as to whether to accept expired records. If >>configurable, SHOULD be >>configurable to as to the maximum out of date expired records can be to be >>acceptable. And if configurable, MUST default to not accepting expired >>records. > > > Much better, but this loses the main sentiment of the original, > namely that one MUST NOT or SHOULD NOT use out-of-date (expired or > not yet active) RRSIGs. The text above would allow a non-configurable > resolver to accept out-of-date records. Allowing an insecure option is not appropriate. If a protocol is allowed to be operated with less security, most people will do so and still believes they have advertised (full) security. It seems to me that the problem is that people recognizes it essentially impossible to deploy DNSSEC. As a result, requirements in protocol specification is reduced to make DNSSEC not really secure. But, it does not really address the problem and only to make the result useless. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: itojun@itojun.org (Jun-ichiro itojun Hagino) Subject: Re: LLMNR is done (RE: LLMNR Change Summary) Date: Mon, 26 Jan 2004 15:43:54 +0900 (JST) Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <6.0.1.1.2.20040123115338.0261fec0@localhost> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Jan 26 07:57:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: ogud@ogud.com In-Reply-To: Your message of "Fri, 23 Jan 2004 12:00:26 -0500" <6.0.1.1.2.20040123115338.0261fec0@localhost> X-Mailer: Cue version 0.6 (031125-1130/itojun) Precedence: bulk > The editor of LLMNR has posted a summary of all changes made since > the WGLC started. All issues have been addressed. > If no issues are raised with the current version, the chairs will advance > the document to the IESG next Friday Jan 30'th 2004. > > Message from editor: > http://psg.com/lists/namedroppers/namedroppers.2004/msg00054.html maybe a stupid question (sorry) - has the interop issue with Apple Rendezvous implementaiton resolved? if not, i don't think the protocol useful. of course both Apple side as well as LLMNR side should make effort to make it interoperable (Apple cannot just force LLMNR be compatible with Rendezvous), in my opinion. itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Conclusion on WGLC DNSSECbis document set. Date: Mon, 26 Jan 2004 10:05:08 +0100 Organization: RIPE NCC Lines: 61 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Jan 26 10:16:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.119813 X-RIPE-Signature: a04ff09fd9a8f0b1ce8261ce7e7edc37 Precedence: bulk Dear colleagues, This is a conclusion of the WGLC on draft-ietf-dnsext-dnssec-intro-08, draft-ietf-dnsext-dnssec-records-06 and draft-ietf-dnsext-dnssec-protocol-04 as issued Mon, 22 Dec 2003 [1]. The executive summary: The protocol is ready, the documents are not. As mentioned in postings to the list during WGLC and in the report on the work-shop last week in Amsterdam [2], there are a number of editorial nits and issues identified that will need some work by the editors and the working group. Most of them can be identified as unexplained (and or unneeded) MUSTs, SHOULDs or MAYs. Sometimes definitions where not clear. All in all, some of the implicit details will need to be made a little more explicit. How to go forward. The coming days I will try to put new issues (those that are more than just editorial nits) to the list in the forms of questions, this may include issues recently discussed on the list. The questions come with 'default' resolutions. Please raise your voice if the proposed resolutions lead to inconsistencies with other part of the specs, are an example of bad engineering or just plainly wrong. On silence we assume you can live with the proposal and the editors will do further word crafting to merge the resolutions in the specs. Since I would like the editors to try and roll the document set before the final submission cut-off (February 16, 09:00 ET) there will be a week for discussing the issues. The documents will be available for review for some time and we hope to be able to forward the next revision to the IESG around IETF59. -- Olaf Kolkman DNSEXT Co-Chair. [1] WGLC issued in http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02307.html and extended in http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00005.html [2] Workshop report: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00069.html ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR is done (RE: LLMNR Change Summary) Date: Mon, 26 Jan 2004 15:22:55 +0000 Lines: 13 Sender: owner-namedroppers@ops.ietf.org References: <20040126064354.6252AB4@coconut.itojun.org> X-From: owner-namedroppers@ops.ietf.org Mon Jan 26 16:31:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from itojun@itojun.org (Jun-ichiro itojun Hagino) of "Mon, 26 Jan 2004 15:43:54 +0900." <20040126064354.6252AB4@coconut.itojun.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > maybe a stupid question (sorry) - has the interop issue with Apple > Rendezvous implementaiton resolved? if not, i don't think the > protocol useful. of course both Apple side as well as LLMNR side > should make effort to make it interoperable (Apple cannot just force > LLMNR be compatible with Rendezvous), in my opinion. seconded. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR is done Date: Mon, 26 Jan 2004 08:53:33 -0800 (PST) Lines: 46 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Jan 26 17:52:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk > maybe a stupid question (sorry) - has the interop issue with Apple > Rendezvous implementaiton resolved? if not, i don't think the > protocol useful. of course both Apple side as well as LLMNR side > should make effort to make it interoperable (Apple cannot just > force LLMNR be compatible with Rendezvous), in my opinion. On August 29, 2003 Olaf Kolkman posted the following message to the DNSEXT WG mailing list summarizing the situation: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01620.html In this message, he made the request that *all* changes required to achieve interoperability be provided. No answer was received. Subsequently, I went back over the Rendezvous documents to look at the differences. These go well beyond the TTL and multicast address choices. mDNS and LLMNR have taken different approaches on more than half a dozen different points, many going back to the earliest drafts. The differences are more than cosmetic because the protocols began from different assumptions and problem statements, and evolved in separate ways from the beginning. At this point, the protocols only share some similarities in the use of the DNS packet format, and even here the differences are substantial. To sum up the situation, on October 6, 2003, Olafur posted the following reply: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01872.html Known differences between Rendezvous and LLMNR ---------------------------------------------- a. Rendezvous uses multicast responses. LLMNR uses unicast. b. Rendezvous allows proxying; LLMNR does not. c. Rendezvous uses the header bits differently, including AA, TC, RD, RA, AD, CD d. Rendezvous and LLMNR uses different retransmission strategies and timers. e. Rendezvous uses ".local" extension, LLMNR does not. f. Rendezvous requires TTL=255; LLMNR uses TTL=1. g. LLMNR supports unicast queries; Rendezvous does not. h. LLMNR and Rendezvous use different multicast addresses and ports. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Subject: RE: prohibiting use of expired RRSIGs Date: Mon, 26 Jan 2004 11:36:51 -0500 Lines: 53 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: owner-namedroppers@ops.ietf.org Mon Jan 26 17:54:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Various people had written: > >>MAY be configurable as to whether to accept expired records. If > >>configurable, SHOULD be > >>configurable to as to the maximum out of date expired > records can be to be > >>acceptable. And if configurable, MUST default to not > accepting expired > >>records. > > > > > > Much better, but this loses the main sentiment of the original, > > namely that one MUST NOT or SHOULD NOT use out-of-date (expired or > > not yet active) RRSIGs. The text above would allow a > > non-configurable resolver to accept out-of-date records. > > Allowing an insecure option is not appropriate. > > If a protocol is allowed to be operated with less security, most > people will do so and still believes they have advertised (full) > security. Ohta-san: During the transition from DNS-today to DNS-with-signed-zones, many compromises need to be made that allow for configurability without denying DNS to users. The challenge is doing that in a way that does not lead to long-term security issues with DNSSEC. However, in this case Mike StJohns correctly stated an issue with the language. If Sam revises his language appropriately then that would lead to a workable solution that does not detract from security. Are you sure that you're actually reading the e-mails, rather than just responding to a perceived opportunity to denigrate DNSSEC? > It seems to me that the problem is that people recognizes it > essentially impossible to deploy DNSSEC. It seems to me that it is not "essentially impossible to deploy DNSSEC". It seems to me that there will be some effort required, and I'm not sure that we have all the answers yet--but saying "it's too hard" isn't the best solution to most problems in my personal experience. Do you believe that the postulated threats against DNS (which DNSSEC was designed to address) are not realistic? If so, then that would be an...interesting...opinion to me. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: prohibiting use of expired RRSIGs Date: Tue, 27 Jan 2004 06:51:23 +0900 Lines: 66 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE104E51@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Jan 26 23:08:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104E51@US-Columbia-CIST.mail.saic.com> Precedence: bulk Rip; > Various people had written: > >>>>MAY be configurable as to whether to accept expired records. If configurable, SHOULD be >>>>configurable to as to the maximum out of date expired records can be to be >>>>acceptable. And if configurable, MUST default to not accepting expired >>>>records. > During the transition from DNS-today to DNS-with-signed-zones, many > compromises need to be made that allow for configurability without > denying DNS to users. The challenge is doing that in a way that > does not lead to long-term security issues with DNSSEC. OK. > However, > in this case Mike StJohns correctly stated an issue with the language. The statement above says nothing about "long-term". Regardless of whatever is the default, configuration to accept expired records will be used widely forever. That DNSSEC needs a lot of configuration means that, during the configuration, administrators are tempted to change some of the default to reduce the rest of the configuration effort. > Are you sure that you're actually reading the e-mails, rather than > just responding to a perceived opportunity to denigrate DNSSEC? You don't read the e-mails literally and assuming impractical assumptions. >>It seems to me that the problem is that people recognizes it >>essentially impossible to deploy DNSSEC. > > > It seems to me that it is not "essentially impossible to deploy > DNSSEC". It seems to me that there will be some effort required, > and I'm not sure that we have all the answers yet--but saying > "it's too hard" isn't the best solution to most problems in my > personal experience. Introducing options means you recognize "it's too hard". > Do you believe that the postulated threats against DNS (which > DNSSEC was designed to address) are not realistic? If so, then > that would be an...interesting...opinion to me. Just before the previous meeting, I posted a solution for small message ID space, though I don't expect you read it. Othere threats are as realistic as DNSSEC zones with compromized keys or DNSSEC resolvers with faked root public keys (or their signatures). Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Paul Vixie <vixie@vix.com> Subject: Re: LLMNR is done Date: 27 Jan 2004 01:33:33 +0000 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <bv3gn4$16k1$1@sf1.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 02:51:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <bv3gn4$16k1$1@sf1.isc.org> Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Precedence: bulk Bernard Aboba <aboba@internaut.com> writes: > ... > To sum up the situation, on October 6, 2003, Olafur posted the following > reply: > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01872.html can llmnr and rendezvous be issued in tandem, with applicability statements? -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Stuart Cheshire <cheshire@apple.com> Subject: Re: LLMNR is done Date: Mon, 26 Jan 2004 20:04:36 -0800 Lines: 83 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 05:20:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> x-sender: cheshire@mail.apple.com X-Mailer: Claris Emailer 2.0v3, January 22, 1998 To: <namedroppers@ops.ietf.org> Precedence: bulk >On August 29, 2003 Olaf Kolkman posted the following message to the >DNSEXT WG mailing list summarizing the situation: > >http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01620.html > >In this message, he made the request that *all* changes required >to achieve interoperability be provided. No answer was received. Unfortunately, *everything* seems subject to intense debate, even what the list of things to debate is. Before embarking on that debate, I asked if the working group had any interest in working for interoperability with the installed base. No answer was received. >Known differences between Rendezvous and LLMNR I think there are some misperceptions here; I should correct them. >a. Rendezvous uses multicast responses. LLMNR uses unicast. Rendezvous uses both unicast and multicast responses, depending on what is most efficient. If only one client is likely to want a particular response, then unicast is used. If multiple clients are likely to want the response, then multicast is used. >b. Rendezvous allows proxying; LLMNR does not. Sleep proxy servers for power management are an important part of meeting Energy Star and Blue Angel energy consumption requirements. As the limits get tighter and tighter each year, it is going to become increasingly hard to sell products that don't have this kind of intelligent power management. >c. Rendezvous uses the header bits differently, including AA, TC, RD, >RA, AD, CD Can you elaborate? I'm not aware of any substantive differences. >d. Rendezvous and LLMNR uses different retransmission strategies and >timers. Surely these are trivial differences that could be easily agreed. >e. Rendezvous uses ".local" extension, LLMNR does not. This is a red herring. The dot-local debate exists at a layer above Rendezvous/LLMNR. Apple (and others) use dot-local to trigger an explicit multicast query; other names may be looked up according via unicast or multicast depending on situation, just as with LLMNR. >f. Rendezvous requires TTL=255; LLMNR uses TTL=1. The TTL check is, as you know, to guarantee that packets really originated on the local link (*especially* unicast replies). I'm told that in the latest Windows XP Service Pack lots of services have been locked down the local link by default for "security", so I would have thought that having the ability to do the same for LLMNR would have met with Microsoft's approval in the current climate. Note that setting the TTL to 255 allows the receiver to check the TTL; it doesn't *require* the receiver to check if it doesn't want to. >g. LLMNR supports unicast queries; Rendezvous does not. Incorrect. Rendezvous supports unicast queries as well as multicast, and always has. >h. LLMNR and Rendezvous use different multicast addresses and ports. This is the ultimate red herring. They only use different multicast addresses and ports because of perceived differences (a)-(g). So, as I have said before, the only real show-stopping incompatibility I see is the decision on the TTL. Stuart Cheshire <cheshire@apple.com> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: itojun@itojun.org (Jun-ichiro itojun Hagino) Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 18:53:58 +0900 (JST) Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <200401270404.i0R44aPx022075@relay2.apple.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 11:07:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: cheshire@apple.com In-Reply-To: Your message of "Mon, 26 Jan 2004 20:04:36 -0800" <200401270404.i0R44aPx022075@relay2.apple.com> X-Mailer: Cue version 0.6 (031125-1130/itojun) Precedence: bulk > >On August 29, 2003 Olaf Kolkman posted the following message to the > >DNSEXT WG mailing list summarizing the situation: > > > >http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01620.html > > > >In this message, he made the request that *all* changes required > >to achieve interoperability be provided. No answer was received. > > Unfortunately, *everything* seems subject to intense debate, even what > the list of things to debate is. Before embarking on that debate, I asked > if the working group had any interest in working for interoperability > with the installed base. No answer was received. i guess i missed your message - yes, i'd love to see Rendezvous and LLMNR be interoperate (or converge into a single protocol). itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Brad Hards <bhards@bigpond.net.au> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 21:06:51 +1100 Lines: 102 Sender: owner-namedroppers@ops.ietf.org References: <200401270404.i0R44aPx022075@relay2.apple.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 11:27:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Stuart Cheshire <cheshire@apple.com> User-Agent: KMail/1.5.94 In-Reply-To: <200401270404.i0R44aPx022075@relay2.apple.com> Content-Disposition: inline Precedence: bulk =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 27 Jan 2004 15:04 pm, Stuart Cheshire wrote: > Unfortunately, *everything* seems subject to intense debate, even what > the list of things to debate is. Before embarking on that debate, I asked > if the working group had any interest in working for interoperability > with the installed base. No answer was received. I have interest in interoperability with MacOS and Windows boxes. Unix=20 variants in embedded applications, and Unix variant boxes as clients in mix= ed=20 environments require it. > >Known differences between Rendezvous and LLMNR > > I think there are some misperceptions here; I should correct them. > > >a. Rendezvous uses multicast responses. LLMNR uses unicast. > > Rendezvous uses both unicast and multicast responses, depending on what > is most efficient. If only one client is likely to want a particular > response, then unicast is used. If multiple clients are likely to want > the response, then multicast is used. I don't see this as a fundamental issue. Worst case is we require both=20 multicast and unicast responses, but agreement on which is better in some=20 common cases shouldn't be that hard. > >b. Rendezvous allows proxying; LLMNR does not. > > Sleep proxy servers for power management are an important part of meeting > Energy Star and Blue Angel energy consumption requirements. As the limits > get tighter and tighter each year, it is going to become increasingly > hard to sell products that don't have this kind of intelligent power > management. Again, not fundamental. Add proxying as a MAY, and explain to implementers = the=20 tradeoff. > >c. Rendezvous uses the header bits differently, including AA, TC, RD, > >RA, AD, CD > > Can you elaborate? I'm not aware of any substantive differences. Pass for now. > >d. Rendezvous and LLMNR uses different retransmission strategies and > >timers. > > Surely these are trivial differences that could be easily agreed. Without looking at the detail, I'd have to agree. > >e. Rendezvous uses ".local" extension, LLMNR does not. > > This is a red herring. The dot-local debate exists at a layer above > Rendezvous/LLMNR. Apple (and others) use dot-local to trigger an explicit > multicast query; other names may be looked up according via unicast or > multicast depending on situation, just as with LLMNR. I see .local as a useful scoping approach. Easy to explain to part-time=20 sysadmins too. > >f. Rendezvous requires TTL=3D255; LLMNR uses TTL=3D1. > > The TTL check is, as you know, to guarantee that packets really > originated on the local link (*especially* unicast replies). I'm told > that in the latest Windows XP Service Pack lots of services have been > locked down the local link by default for "security", so I would have > thought that having the ability to do the same for LLMNR would have met > with Microsoft's approval in the current climate. Note that setting the > TTL to 255 allows the receiver to check the TTL; it doesn't *require* the > receiver to check if it doesn't want to. This has been done a time or two (perhaps more). There is no obviously best= =20 way. In this case, we might as well choose the path of least gratuitous=20 breakage. =20 > >g. LLMNR supports unicast queries; Rendezvous does not. > > Incorrect. Rendezvous supports unicast queries as well as multicast, and > always has. We probably should support both.=20 > >h. LLMNR and Rendezvous use different multicast addresses and ports. > > This is the ultimate red herring. They only use different multicast > addresses and ports because of perceived differences (a)-(g). I see it as "self fulfilling requirement". Either we agree a compatible=20 protocol, or we support running both on different mc addresses and ports=20 (optionally with a shared cache). Brad =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFjg7GwwszQ/PZzgRAtNRAJ4iLjOsGi95fppbxwB2dscBQGQSKQCcD+F7 EtZtNjXxToZELkN6ssvI3Aw=3D =3D2HJL =2D----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Brad Hards <bhards@bigpond.net.au> Subject: Re: LLMNR is done (RE: LLMNR Change Summary) Date: Tue, 27 Jan 2004 21:19:40 +1100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <6.0.1.1.2.20040123115338.0261fec0@localhost> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 11:35:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: =?iso-8859-1?q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com> User-Agent: KMail/1.5.94 In-Reply-To: <6.0.1.1.2.20040123115338.0261fec0@localhost> Content-Disposition: inline Precedence: bulk =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 24 Jan 2004 04:00 am, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > The editor of LLMNR has posted a summary of all changes made since > the WGLC started. All issues have been addressed. > If no issues are raised with the current version, the chairs will advance > the document to the IESG next Friday Jan 30'th 2004. Per the other voices - please don't do this until we have sorted out the=20 interop issues with the MDNS part of Rendezvous. Brad =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFjs8GwwszQ/PZzgRAlYaAJ9UdBXHpUc16mzVMR5oiCn964gHaQCgh2RJ QnfC2Df7AfjduRTtVRcirRU=3D =3DGp7n =2D----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR is done (RE: LLMNR Change Summary) Date: Tue, 27 Jan 2004 09:46:25 -0600 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <6.0.1.1.2.20040123115338.0261fec0@localhost> <200401272119.40182.bhards@bigpond.net.au> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 17:54:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <200401272119.40182.bhards@bigpond.net.au> To: Brad Hards <bhards@bigpond.net.au> X-Mailer: Apple Mail (2.609) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.488638 X-RIPE-Signature: b5ee9d8ca5300aa70644ff1e7dc6bf29 Precedence: bulk On Jan 27, 2004, at 4:19 AM, Brad Hards wrote: >> If no issues are raised with the current version, the chairs will >> advance >> the document to the IESG next Friday Jan 30'th 2004. > Per the other voices - please don't do this until we have sorted out > the > interop issues with the MDNS part of Rendezvous. Right, please let's give this one more chance. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 09:45:21 -0600 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <200401270404.i0R44aPx022075@relay2.apple.com> <200401272106.51872.bhards@bigpond.net.au> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Stuart Cheshire <cheshire@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 17:54:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <200401272106.51872.bhards@bigpond.net.au> To: Brad Hards <bhards@bigpond.net.au> X-Mailer: Apple Mail (2.609) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.498672 X-RIPE-Signature: 0fcf913bc8c036a1e559239a0b8cabb0 Precedence: bulk I don't have anything substantive to add except that I would really, really like to see Rendezvous be able to interoperate with LLMNR. I use Rendezvous a _lot_, it makes a big difference in the usability of my network, and the one big remaining hole right now is that it doesn't work with Windows. :'( I think that resolving the TTL issue in favor of the way Rendezvous does it is a good solution - there are pros and cons to both ways of doing TTL, and in fact it was as a result of debate about this issue with regard to LLMNR that Rendezvous switched to this scheme originally. I've weighed in on this several times in the past - the only reason I've stopped saying anything about it is because I've given up hope in the process - it's seemed recently that there was no interest at all in making LLMNR and Rendezvous interoperate. It sounds like this is not actually the case, and that a lot of other folks have been silent as well, perhaps for the same reason. :'/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 17:38:38 +0000 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <mellon@fugue.com> X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 19:08:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Ted Lemon <mellon@fugue.com> of "Tue, 27 Jan 2004 09:45:21 CST." <D091F266-50DF-11D8-9E6D-000A95D9C74C@fugue.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > I've weighed in on this several times in the past - the only reason > I've stopped saying anything about it is because I've given up hope in > the process - it's seemed recently that there was no interest at all > in making LLMNR and Rendezvous interoperate. It sounds like this is > not actually the case, and that a lot of other folks have been silent > as well, perhaps for the same reason. :'/ i think aboba's assessment may be accurate, which is that these are different protocols with different applicability statements. if that's true then simply advancing both of them, each with an applicability statement that makes clear why it exists and what its purpose and scope is, is a reasonable approach. for example, i saw a demo where a mac found a desktop printer without either one of them having an ip address, and a mac found an mp3 jukebox without either one of them having an ip address. the chooser/browser widget just came up and showed what it found. is this sufficiently different from llmnr's target and purpose that we can reasonably say that both protocols can be advanced, and both will be in the field, and they are not competing approaches to the same problem space? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Alain Durand <Alain.Durand@Sun.COM> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 10:31:51 -0800 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <20040127173838.51E6D14C60@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7BIT X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 19:49:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 Precedence: bulk I really have a hard time with the idea that LLMNR & Rendez-vous address different needs. There is so much overlap that, in a normal worl, convergence would be the most sensible avenue. If we, as a collection of vocal individuals, cannot put ego aside and can't converge, please, at least, let's make those two interoperable. - Alain. Paul Vixie wrote: >>I've weighed in on this several times in the past - the only reason >>I've stopped saying anything about it is because I've given up hope in >>the process - it's seemed recently that there was no interest at all >>in making LLMNR and Rendezvous interoperate. It sounds like this is >>not actually the case, and that a lot of other folks have been silent >>as well, perhaps for the same reason. :'/ >> >> > >i think aboba's assessment may be accurate, which is that these are >different protocols with different applicability statements. if that's >true then simply advancing both of them, each with an applicability >statement that makes clear why it exists and what its purpose and scope >is, is a reasonable approach. > >for example, i saw a demo where a mac found a desktop printer without >either one of them having an ip address, and a mac found an mp3 jukebox >without either one of them having an ip address. the chooser/browser >widget just came up and showed what it found. is this sufficiently >different from llmnr's target and purpose that we can reasonably say >that both protocols can be advanced, and both will be in the field, and >they are not competing approaches to the same problem space? > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 18:49:16 +0000 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <Alain.Durand@Sun.COM> X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 20:06:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alain Durand <Alain.Durand@Sun.COM> of "Tue, 27 Jan 2004 10:31:51 PST." <4016AE97.2050606@sun.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > I really have a hard time with the idea that LLMNR & Rendez-vous address > different needs. nevertheless i think the llmnr authors might in fact intend it for a different use, in which case we could expect to see microsoft and apple each implement both rendezvous and llmnr, which would lead to... > There is so much overlap that, in a normal worl, convergence would be > the most sensible avenue. ...convergence. in which case, as long as ietf advances them in tandem, and with well written applicability statements to motivate implementors to put both of them in (where appropriate), then... > If we, as a collection of vocal individuals, cannot put ego aside and > can't converge, please, at least, let's make those two interoperable. ...we will have done the job we agreed to do when attending ietf functions. if on the other hand alain (quoted above) is correct and these protocols address identical needs or significantly overlapping needs, then it would be irresponsible of us to advance both drafts, or to advance only one. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:47 2006 From: Ralph Droms <rdroms@cisco.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 14:01:05 -0500 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0401260847260.21653@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 20:21:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.56.0401260847260.21653@internaut.com> Precedence: bulk Following up on Bernard's assessment of the relationship between LLMNR and Rendezvous: At 08:53 AM 1/26/2004 -0800, Bernard Aboba wrote: >[...] The >differences are more than cosmetic because the protocols began from >different assumptions and problem statements, and evolved in separate >ways from the beginning. At this point, the protocols only share some >similarities in the use of the DNS packet format, and even here the >differences are substantial. My understanding is that LLMNR is designed: * to avoid interference with and pollution of DNS information * to transition gracefully to DNS * to avoid generating bogus .local queries * to avoid redfining key IP concepts like TTL * to use TTL correctly so that LLMNR traffic is confined to a link, rather than redefining TTL to provide security (whch it doesn't provide, anyway) I'm working here from observation, not from any requirements explicitly set out in <draft-ietf-dnsext-mdns-29.txt> or the dnsext WG charter... - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: John Schnizlein <jschnizl@cisco.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 14:02:44 -0500 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <bv3gn4$16k1$1@sf1.isc.org> <bv3gn4$16k1$1@sf1.isc.org> <g365eyqioi.fsf@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 20:24:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Paul Vixie <vixie@vix.com> In-Reply-To: <g365eyqioi.fsf@sa.vix.com> References: <bv3gn4$16k1$1@sf1.isc.org> <bv3gn4$16k1$1@sf1.isc.org> Precedence: bulk Where is Rendezvous under consideration in the IETF? I would be glad to see an informational RFC specifying Rendezvous. I never saw it named explicitly in the Zero-Conf charter. At 08:33 PM 1/26/2004, Paul Vixie wrote: >can llmnr and rendezvous be issued in tandem, with applicability statements? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Ralph Droms <rdroms@cisco.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 14:18:01 -0500 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <Message from Ted Lemon <mellon@fugue.com> <D091F266-50DF-11D8-9E6D-000A95D9C74C@fugue.com> <20040127173838.51E6D14C60@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 20:40:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040127173838.51E6D14C60@sa.vix.com> References: <Message from Ted Lemon <mellon@fugue.com> <D091F266-50DF-11D8-9E6D-000A95D9C74C@fugue.com> Precedence: bulk Paul - can you explain what you mean by "without either one of them having an ip address". If I take that statement literally, I wonder why the IETF would be interested in a protocol that doesn't use IP? - Ralph At 05:38 PM 1/27/2004 +0000, Paul Vixie wrote: >for example, i saw a demo where a mac found a desktop printer without >either one of them having an ip address, and a mac found an mp3 jukebox >without either one of them having an ip address. the chooser/browser >widget just came up and showed what it found. is this sufficiently >different from llmnr's target and purpose that we can reasonably say >that both protocols can be advanced, and both will be in the field, and >they are not competing approaches to the same problem space? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 19:26:08 +0000 Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <rdroms@cisco.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 20:42:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ralph Droms <rdroms@cisco.com> In-Reply-To: Message from Ralph Droms <rdroms@cisco.com> of "Tue, 27 Jan 2004 14:18:01 EST." <4.3.2.7.2.20040127141608.00b8c048@flask.cisco.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > Paul - can you explain what you mean by "without either one of them having > an ip address". If I take that statement literally, I wonder why the IETF > would be interested in a protocol that doesn't use IP? > > - Ralph i misspoke. there was no dhcp server, no dhs server, no server of any kind. of course there were ip addresses, but they were self assigned and invisible to the user. to get a non-rendezvous laptop to see a non-rendezvous desktop printer, i'd have had to set, or at least know, one or both ip addresses. and there would not have been a way to get it to show up in the chooser/browser tool. what this really comes down to is applicability. yesterday here, aboba said that rendezvous and llmnr were different protocols intended for different uses. if the community agrees, then both docs should be advanced, with clear applicability statements. if the community doesn't agree, then a new/merged specification should be developed and advanced, with a notation that apple's existing protocol is to enjoy no special advantage, regardless of the size of their installed base. re: > At 05:38 PM 1/27/2004 +0000, Paul Vixie wrote: > > >for example, i saw a demo where a mac found a desktop printer without > >either one of them having an ip address, and a mac found an mp3 jukebox > >without either one of them having an ip address. the chooser/browser > >widget just came up and showed what it found. is this sufficiently > >different from llmnr's target and purpose that we can reasonably say > >that both protocols can be advanced, and both will be in the field, and > >they are not competing approaches to the same problem space? > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 19:34:38 +0000 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <jschnizl@cisco.com> X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 20:50:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from John Schnizlein <jschnizl@cisco.com> of "Tue, 27 Jan 2004 14:02:44 EST." <4.3.2.7.2.20040127140033.05acccc8@wells.cisco.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > Where is Rendezvous under consideration in the IETF? http://www.zeroconf.org/Rendezvous/ http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt > I would be glad to see an informational RFC specifying Rendezvous. i think that would be a cop-out. if dns-sd ("apple's rendezvous") and llmnr have the same target audience, then the existence of both protocols is an indication of chaos or irresponsibility (depending on how far it goes before it's stopped). if they have different target audiences, then both should be advanced, on the standards track, with clear applicability statements to tell implementors which one they need, or why they need both. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 06:17:58 +0900 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040127173838.51E6D14C60@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jan 27 22:39:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Paul Vixie <paul@vix.com> In-Reply-To: <20040127173838.51E6D14C60@sa.vix.com> Precedence: bulk Paul; > i think aboba's assessment may be accurate, which is that these are > different protocols with different applicability statements. if that's > true then simply advancing both of them, each with an applicability > statement that makes clear why it exists and what its purpose and scope > is, is a reasonable approach. As both of them are designed for closed home network with dumb administration (which means it is crazy to make TTL of multicast larger than 1, even more crazy than that of DHCPv6) and neither of them are useful for hosts connected to the public internet, we, Internet ETF, should not mind so much how they evolve or ruin, as long as it is made clear that they are not useful to the Internet and should not be used on hosts connected to the Internet. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: "Al Costanzo" <al@akc.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 17:43:39 -0500 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <Message from Ted Lemon <mellon@fugue.com> <D091F266-50DF-11D8-9E6D-000A95D9C74C@fugue.com> <4.3.2.7.2.20040127141608.00b8c048@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 00:04:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Paul Vixie" <paul@vix.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk Are you speaking about an old protocol (non-routable) that does not need IP because it just finds MAC addresses on small nets? (kinda sorta like one of the options HP has/had for thier network printers?) -Al ----- Original Message ----- From: "Ralph Droms" <rdroms@cisco.com> To: "Paul Vixie" <paul@vix.com> Cc: <namedroppers@ops.ietf.org> Sent: Tuesday, January 27, 2004 2:18 PM Subject: Re: LLMNR is done > Paul - can you explain what you mean by "without either one of them having > an ip address". If I take that statement literally, I wonder why the IETF > would be interested in a protocol that doesn't use IP? > > - Ralph > > At 05:38 PM 1/27/2004 +0000, Paul Vixie wrote: > > >for example, i saw a demo where a mac found a desktop printer without > >either one of them having an ip address, and a mac found an mp3 jukebox > >without either one of them having an ip address. the chooser/browser > >widget just came up and showed what it found. is this sufficiently > >different from llmnr's target and purpose that we can reasonably say > >that both protocols can be advanced, and both will be in the field, and > >they are not competing approaches to the same problem space? > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 14:47:28 +0700 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <200401270404.i0R44aPx022075@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 01:32:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Stuart Cheshire <cheshire@apple.com> In-Reply-To: <200401270404.i0R44aPx022075@relay2.apple.com> Precedence: bulk Date: Mon, 26 Jan 2004 20:04:36 -0800 From: Stuart Cheshire <cheshire@apple.com> Message-ID: <200401270404.i0R44aPx022075@relay2.apple.com> | So, as I have said before, the only real show-stopping incompatibility I | see is the decision on the TTL. Perhaps a possible compromise. (In other contexts I have argued against any TTL rules at all - that wasn't in the context of a particular application, I see no problem with telling applications what TTL is appropriate for them to use). As I understand it, the argument for TTL=1 is that it restricts packets to the local net, they won't accidentally go further than that. The argument for TTL=255 is that it allows hosts to verify that packets originated from the local net, and didn't come from off net. The verification (it seems to me) is only really important for answers. That is, it is entirely reasonable for a host to care whether the answer it received came from a local responder, and not someone-off net doing bad (or just stupid) things. On the other hand, someone being asked a query should not care too much where the query came from - if it is doing things sensibly, it will only be sending its answer to its local net anyway, if the query came from further away, no reply will be received - so by verifying the query came from the local net, all that really can be achieved is to save a little work (perhaps a useful gain, but hardly a requirement). Packets going off net when they serve no useful purpose is a minor annoyance when they're unicast, but it is something that really wants to be avoided with multicast. So, I think setting TTL==1 on multicast packets is definitely right. Even for multicast replies, that's likely the best thing to do. For unicast packets, I'd think TTL==255 is OK - unicast LLMR packets are likely to be replies, where verifying that the packet came from the local net is more important. Preventing unicast packets "escaping" is a pretty meaningless thing to do (or even hope to do) - if LL addresses are involved, they won't escape anyway, otherwise an occasional packet may go somewhere it isn't wanted - I don't see that as an important enough issue to argue about. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Brad Hards <bhards@bigpond.net.au> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 18:58:15 +1100 Lines: 63 Sender: owner-namedroppers@ops.ietf.org References: <20040127193438.5B39B14BBE@sa.vix.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 09:16:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> User-Agent: KMail/1.5.94 In-Reply-To: <20040127193438.5B39B14BBE@sa.vix.com> Content-Disposition: inline Precedence: bulk =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 28 Jan 2004 06:34 am, Paul Vixie wrote: > > Where is Rendezvous under consideration in the IETF? > > http://www.zeroconf.org/Rendezvous/ > http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt > > > I would be glad to see an informational RFC specifying Rendezvous. > > i think that would be a cop-out. if dns-sd ("apple's rendezvous") and The bit of Rendezvous you want is MDNS. DNS-SD is a peer to protocols like = SLP=20 (which could do name<->address conversion, but isn't really intended for=20 that. > llmnr have the same target audience, then the existence of both protocols > is an indication of chaos or irresponsibility (depending on how far it > goes before it's stopped). if they have different target audiences, then > both should be advanced, on the standards track, with clear applicability > statements to tell implementors which one they need, or why they need bot= h. These look pretty similar to me: Abstract Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. Abstract As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up host names and similar DNS resource record data types, in the absence of a conventional managed DNS server, is becoming essential. I don't think those could be considered to be addresses distinct audiences.= =20 Where is the difference? Brad =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAF2uXGwwszQ/PZzgRAqqFAKCoT82Ks563m4J1pLhhqjt7akd5VACgiheQ 7b0gsBs3p+4PoJ3BHSFDSgI=3D =3Dxpf6 =2D----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 10:03:26 +0200 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <200401270404.i0R44aPx022075@relay2.apple.com> <16743.1075189648@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 09:40:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <16743.1075189648@munnari.OZ.AU> User-Agent: Mutt/1.5.5.1i Precedence: bulk On Tue, Jan 27, 2004 at 02:47:28PM +0700, Robert Elz wrote: > As I understand it, the argument for TTL=1 is that it restricts packets > to the local net, they won't accidentally go further than that. > > The argument for TTL=255 is that it allows hosts to verify that packets > originated from the local net, and didn't come from off net. How about requiring queries to use TTL=255, to ensure only members of the local network can generate queries, and requiring answers to use TTL=1, which stops responses leaving the local network? This would stop denial of service attacks caused by injection of queries into the local network, and would damp any DoS attempts originated on the local network before they left. It also strongly ties the protocol to local networks, satisfying at least one member of the working group. Of course, this would have the side effect of breaking both LLMNR and Rendezvous. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 11:40:53 +0100 (CET) Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <200401270404.i0R44aPx022075@relay2.apple.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 11:54:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> In-Reply-To: <200401270404.i0R44aPx022075@relay2.apple.com> Precedence: bulk On Mon, 26 Jan 2004, Stuart Cheshire wrote: > So, as I have said before, the only real show-stopping incompatibility I > see is the decision on the TTL. I'd like to second this and I really hope the chairs will allow the WG to work this out before advancing the docs. rendezvous has been proven to work well in the real world (i.e. outside the ietf) and I cannot see why not to follow the path it has taken. if we, as the WG, cannot resolve this issue, we have failed. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: John Schnizlein <jschnizl@cisco.com> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 06:33:30 -0500 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <200401270404.i0R44aPx022075@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 12:44:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: <namedroppers@ops.ietf.org> In-Reply-To: <200401270404.i0R44aPx022075@relay2.apple.com> Precedence: bulk It is worth noting that this 11th hour attempt to reverse the TTL=1 decision in this WG is much like the 11th hour (after the chair announced ROUGH consensus) change in the Zero-Conf WG. There also, the old history of earlier consideration of TTL=1 was presented as justification for the reversal to support TTL=255. The change of the meaning of this field in the IP header is unnecessary and risky. That it hasn't caused trouble yet is insufficient justification. In the Zero-Conf WG, my concern that the reversal made its specification at odds with the consensus reached in DNS-ext was ignored. Returning to the original rough consensus in Zero-Conf would restore compatibility between these WGs. Why all this new reference to Rendezvous? Note that it was not mentioned in the Zero-Conf charter at all. Zero-Conf progressed as if independent of a single vendor's implementation until near the end. John At 10:45 AM 1/27/2004, Ted Lemon wrote: >I don't have anything substantive to add except that I would really, really like to see Rendezvous be able to interoperate with LLMNR. I use Rendezvous a _lot_, it makes a big difference in the usability of my network, and the one big remaining hole right now is that it doesn't work with Windows. :'( > >I think that resolving the TTL issue in favor of the way Rendezvous does it is a good solution - there are pros and cons to both ways of doing TTL, and in fact it was as a result of debate about this issue with regard to LLMNR that Rendezvous switched to this scheme originally. > >I've weighed in on this several times in the past - the only reason I've stopped saying anything about it is because I've given up hope in the process - it's seemed recently that there was no interest at all in making LLMNR and Rendezvous interoperate. It sounds like this is not actually the case, and that a lot of other folks have been silent as well, perhaps for the same reason. :'/ At 11:04 PM 1/26/2004, Stuart Cheshire wrote: >... > >Unfortunately, *everything* seems subject to intense debate, even what >the list of things to debate is. Before embarking on that debate, I asked >if the working group had any interest in working for interoperability >with the installed base. No answer was received. > >>Known differences between Rendezvous and LLMNR > >I think there are some misperceptions here; I should correct them. > >... >>f. Rendezvous requires TTL=255; LLMNR uses TTL=1. > >The TTL check is, as you know, to guarantee that packets really >originated on the local link (*especially* unicast replies). I'm told >that in the latest Windows XP Service Pack lots of services have been >locked down the local link by default for "security", so I would have >thought that having the ability to do the same for LLMNR would have met >with Microsoft's approval in the current climate. Note that setting the >TTL to 255 allows the receiver to check the TTL; it doesn't *require* the >receiver to check if it doesn't want to. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Q-24 DNSKEY with flag 7=0 not to be used with DNSSEC. Date: Wed, 28 Jan 2004 14:21:11 +0100 Lines: 15 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 14:31:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) Precedence: bulk The behavior for the flag bit (bit7) in the DNSKEY RR set to 0 is not specified. We propose the following text to be added to section 2.1: DNSKEY RRs MUST NOT be used for DNSSEC validation if bit 7 of the flag field is set to 0. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: New DNSSEC Questions Date: Wed, 28 Jan 2004 14:17:44 +0100 Lines: 36 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 14:31:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) Precedence: bulk Colleagues, As a result of the last call we have a number of questions that we would like to get WG feedback on. The questions come with 'default' answers. The dnssec-editors will merge those into the document set if there is no comments received. Some of these questions have been discussed on the list previously, please regard the proposed answers as a proposal for a consensus in those cases. Since we would like to get a new, and final, version of the docs by mid February I would like to ask the WG to respond within before the end of next week. (Feb 6, 2004). These will be posted topic by topic. Please respond to them in thread. These questions will follow shortly: Q-23 Direct NSEC queries; specs for resolvers and servers. Q-24 DNSKEY with flag 7=0 not to be used with DNSSEC. Q-25 Under specification of NSEC TTL. Q-26 Appearance of DS RRs. Q-27 Setting AD for DNAME synthesis of CNAME --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Q-23 Direct NSEC queries; specs for resolvers and servers. Date: Wed, 28 Jan 2004 14:20:22 +0100 Lines: 34 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 14:31:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) Precedence: bulk This is related to the thread starting at: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00053.html The document currently requires a security aware resolver to query for security related RRs needed to complete a validation. Given that both parent and child have NSEC and RRSIG records for a delegation, the logic for fetching those records is likely to be very complicated, much as is the logic for fetching a DS record when the grandparent situation exists. Since the authoritative server special processing rules are supposed to deliver all records needed for validation, it is safe to weaken this requirement. (One must also note that the requirement (RFC2535 5.5) to serve the NSEC from both the parent and the child if both are available will lead to inconsistencies between answer from different authoritative servers and answers from recursive nameservers. Therefore and because of the argument about the special processing rules above the requirement is consciously not copied into the DNSSECbis specs and left unspecified). The proposed text therefore is: security aware resolvers MAY query for missing security RRs; implementations that choose to do so must be aware of the fact that the answers received may not be sufficient to perform validation. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Q-25 Under specification of NSEC TTL. Date: Wed, 28 Jan 2004 14:21:57 +0100 Lines: 16 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 14:32:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) Precedence: bulk The document does not specify the setting of the TTL on NSEC RRs. We propose the following text to be added to 2.3 proto: In the spirit of [RFC negative cache] the TTL of the NSEC RRset SHOULD match the TTL of the zone SOA minimum field. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Q-26 Appearance of DS RRs. Date: Wed, 28 Jan 2004 14:22:51 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 14:35:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) Precedence: bulk Since this is on the boundary between editorial and protocol you should see this more as a notification than a question. DS RR MUST NOT appear at non-delegation point has changed. The new text says DS MUST NOT appear at apex (this is needed). silent on DS appearing elsewhere. The reason for this change is that although it seems rather senseless to have a DS anywhere else than with a delegation there seems no reason to forbid the existence elsewhere --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Q-27 Setting AD for DNAME synthesis of CNAME Date: Wed, 28 Jan 2004 14:24:37 +0100 Lines: 34 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 14:36:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) Precedence: bulk This is a question regarding the interaction between the rules governing the setting of an AD bit in a reply message and the inclusion of a DNAME RR in an answer. In addition to more rules, an AD bit is to be set (to 1) only if the server has cryptographicly verified each of the RRsets in the answer section of the message. According to the rules governing the inclusion a DNAME RR in an answer section, a synthesized CNAME RR is also included to assist older implementations that might not understand the DNAME RR. The question is whether it is appropriate to set the AD bit when a signed, checked, DNAME RR set is in an answer, followed by its synthesized, unsigned CNAME RR? On the one hand, the CNAME RR is unsigned and hence unchecked, suggesting the answer is no. On the other hand, the CNAME RR is verifiably generated via an algorithm from a signed and checked DNAME RR, hence the AD bit can still be set in the answer (barring other reasons to not set the AD bit). The suggested answer is that setting the AD bit is appropriate with the DNAME RR warrants it, regardless of there being the synthesized CNAME RR. If a client is unable to understand DNAME RR, the client is also assumed to not be able to understand the AD bit. If a client does understand the DNAME RR, it can ignore the presence of the CNAME RR, so the lack of a signature covering the CNAME is immaterial. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Mark.Andrews@isc.org Subject: Re: Q-27 Setting AD for DNAME synthesis of CNAME Date: Thu, 29 Jan 2004 00:55:09 +1100 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <5214FE3C-5195-11D8-AF3C-000393DA2D46@ripe.net> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 15:06:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Olaf Kolkman <olaf@ripe.net> In-reply-to: Your message of "Wed, 28 Jan 2004 14:24:37 BST." <5214FE3C-5195-11D8-AF3C-000393DA2D46@ripe.net> Precedence: bulk > This is a question regarding the interaction between the rules > governing the setting of an AD bit in a reply message and the > inclusion of a DNAME RR in an answer. In addition to more rules, an > AD bit is to be set (to 1) only if the server has cryptographicly > verified each of the RRsets in the answer section of the message. > According to the rules governing the inclusion a DNAME RR in an answer > section, a synthesized CNAME RR is also included to assist older > implementations that might not understand the DNAME RR. > > The question is whether it is appropriate to set the AD bit when a > signed, checked, DNAME RR set is in an answer, followed by its > synthesized, unsigned CNAME RR? On the one hand, the CNAME RR is > unsigned and hence unchecked, suggesting the answer is no. On the > other hand, the CNAME RR is verifiably generated via an algorithm from > a signed and checked DNAME RR, hence the AD bit can still be set in > the answer (barring other reasons to not set the AD bit). > > The suggested answer is that setting the AD bit is appropriate with > the DNAME RR warrants it, regardless of there being the synthesized > CNAME RR. If a client is unable to understand DNAME RR, the client is > also assumed to not be able to understand the AD bit. If a client > does understand the DNAME RR, it can ignore the presence of the CNAME > RR, so the lack of a signature covering the CNAME is immaterial. > > > --Olaf This also needs to extended to other synthesised records. If a zone is marked as secure (permitted by RFC 3655) then wildcard answers also set AD. The wording needs to be in terms of synthesised from secure rather than DNAME. DNAME -> CNAME is a example of when you apply the rule. This will future proof the spec. > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Mark.Andrews@isc.org Subject: returning AD through intermediate servers Date: Thu, 29 Jan 2004 01:32:32 +1100 Lines: 22 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 15:49:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Client <-> server <-> validating server <-> world We need to permit AD being returned from the validating server to get to the client iff "server <-> validating server" is secure and there is a existing trust relationship between the two servers. While this is a logical consequence of the rest of the draft it may not be obvious that it needs to be done. Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 09:27:24 -0600 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <4.3.2.7.2.20040127115618.02350130@wells.cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 17:40:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <4.3.2.7.2.20040127115618.02350130@wells.cisco.com> To: John Schnizlein <jschnizl@cisco.com> X-Mailer: Apple Mail (2.609) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.499981 X-RIPE-Signature: 3335e135e5f1ee93ada9e5afee088b8d Precedence: bulk On Jan 28, 2004, at 5:33 AM, John Schnizlein wrote: > It is worth noting that this 11th hour attempt to reverse the TTL=1 > decision in this WG is much like the 11th hour (after the chair > announced ROUGH consensus) change in the Zero-Conf WG. John, this isn't an 11th-hour attempt. We've been arguing about this for several years now, without reaching consensus. If you had the impression that there was consensus, it's only because the people who do not participate in the "consensus" have been quiet for a while because we have little hope that saying anything will be productive. > There also, > the old history of earlier consideration of TTL=1 was presented > as justification for the reversal to support TTL=255. The change > of the meaning of this field in the IP header is unnecessary and > risky. That it hasn't caused trouble yet is insufficient justification. Yes, you and several other people have repeatedly made this assertion. So because of this, we will have two non-interoperating protocols that do the same thing. That's a real world problem that can be demonstrated on networks today. How do I know? Because it's already caused trouble for me personally and for people for whom I provide network support - people who are not John Schnizlein or Ted Lemon and cannot debug these problems without our help. This interoperability problem is a direct result of what appears to be a completely theoretical argument. > Why all this new reference to Rendezvous? Note that it was not > mentioned in the Zero-Conf charter at all. Zero-Conf progressed > as if independent of a single vendor's implementation until near > the end. Rendezvous happened, as far as I can tell, because the Zeroconf working group failed. By which I mean that although there was strong agreement among proponents of zeroconf about what to do, there was strong resistance to the idea of the IETF pushing any kind of zeroconf, and this prevented the working group from succeeding. We have some drafts in/near last call now, but it's a Pyrrhic victory - I'd rather implement Rendezvous than zeroconf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. Date: Wed, 28 Jan 2004 20:32:33 +0000 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <olaf@ripe.net> X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 21:52:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Olaf Kolkman <olaf@ripe.net> of "Wed, 28 Jan 2004 14:20:22 +0100." <BA09033C-5194-11D8-AF3C-000393DA2D46@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk > The proposed text therefore is: security aware resolvers MAY query for > missing security RRs; implementations that choose to do so must be > aware of the fact that the answers received may not be sufficient to > perform validation. this gives no guideance to server implementors, and is therefore inadequate. how about adding this text: security aware responders who receive queries for security RRs which match the content of more than one zone, for example above and below a delegation point, are encouraged to behave self-consistently, which could mean: always return an error; always return above-delegation records; always return below-delegation records; always return no records; always return both above- and below-delegation records; or always something else entirely in other words, driving home the point that requestor implementors ought not depend on the results of queries for security RRs is only part of the story; the document should also clearly state that there is no standard behaviour for responders, and place a self-consistency requirement there instead. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 13:05:37 -0800 (PST) Lines: 76 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 22:10:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk LLMNR was designed to handle situations in which hosts are highly mobile, and to be extensible to use in larger scopes, if the initial deployments prove successful. These situations do not lend themselves to multicast responses. For a highly mobile situation, with a DNS TTL close to zero, multicast responses are not useful to any host other than the one sending the original query, yet they need to be processed by all hosts for marginal benefit. Multicast responses also do not scale beyond link-local scope to situations where hundreds or even thousands of hosts could be listening across a site. Given the design goals of LLMNR, multicast queries were precluded early on. While the content of queries might indeed be a higher layer issue, it is very relevant to the interoperability question. A host sending a query for a ".local" name will not receive a response unless the target also is configured with a ".local" name. So in practice, converging LLMNR and Rendezvous yields no useful benefits unless the hosts also adopt the Rendezvous namespace model. The problem with that model is that it requires users to either type the ".local" extension, or for ".local" to be put into the searchlist. The former is a problem for users used to a flat namespace (e.g. http://foo, which can be resolved via RFC 1001-1002, NetBIOS over TCP/IP). The latter results in lots of bogus ".local" queries. In terms of proxying and power management, name conflict detection can be run when systems power up again, and since name conflicts are relatively unlikely, there is no need in LLMNR to deploy proxies for this purpose, particularly in mobile environments where they are likely to be serving up out of date information. In any case, since proxies depend on multicast responses, once those are eliminated to improve scaling, they can't be used anyway. In terms of differing uses of the header bits, and other sections of the DNS packet, almost every bit and field is used differently in LLMNR and Rendezvous. LLMNR does not allow multiple questions in a query, since these are known to cause confusion. Therefore there is no need to use the TC bit in a query, as Rendezvous does. Since LLMNR is not a service discovery protocol, there is no need to implement known answer suppression. Since in LLMNR there are no proxies or non-authoritative answers, there is no need to use the RA or AA bits either. LLMNR specifies more strict handling of SOA and NS RRs in order to handle the different delegation model of a peer-to-peer name resolution protocol. The CD or AD bits do not apply to a peer-to-peer name resolution protocol where there is no implicit trust, so LLMNR does not use them. In order to be compatible with DNSSEC, LLMNR requires support for EDNS0, which has its own way of handling MTU issues. In LLMNR automatically sending a packet of link MTU size would not be wise because of the need to allow extension to larger scopes going forward. So LLMNR and Rendezvous don't even handle MTU issues the same way. Rather than disallowing all non-zero RCODEs, LLMNR allows error messages to be used in response to unicast queries, in order to permit problem diagnosis and enable use of DNSSEC & TSIG. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 14:27:53 -0800 Lines: 92 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0401281259020.20618@internaut.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-21-384909771; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Jan 28 23:42:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0401281259020.20618@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) Precedence: bulk --Apple-Mail-21-384909771 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Jan 28, 2004, at 1:05 PM, Bernard Aboba wrote: > Multicast responses also do not scale beyond link-local scope to > situations where hundreds or even thousands of hosts could be listening > across a site. Given the design goals of LLMNR, multicast queries were > precluded early on. I'm confused. LLMNR is only useful when there is no configured DNS, otherwise all queries go to unicast DNS and only fall back to LLMNR if the unicast DNS query fails (which one can not rely on). What sort of scenario are you likely to run in to where there would be no unicast DNS but there are routers configured to handle multicast? Where is this mentioned as a design goal? It seems like LLMNR has a subset of the mDNS functionality. LLMNR focuses on solving the problem of resolving DNS entries when there is no DNS server. mDNS attempts to solve the problem of resolving DNS names when there is no DNS as well as resolving names even when there is a configured DNS server. In a number of situations, people may end up on the same network where names for the addresses they receive are arbitrary or nonexistent. A common example would be two people meeting in an airport and joining the same wireless network at the airport. If they had private addresses, there would be no point in using dynamic DNS to register their address. LLMNR wouldn't work. -josh --Apple-Mail-21-384909771 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDEyODIyMjc1NFowIwYJKoZIhvcNAQkEMRYEFK8P XeBNc3hrYKY8/sl9R75UFt86MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBABvy pd50zXHL+u+Us3jP4xUZVj5wnxg/yDZaxZCQoz6KgWwc+Ruc3pFzLd3xtkagRSeCYrdoXnX38k/A 5TgSkeY4cjtamTQFR0rYZNHGGFIEjLshOndUJBygWdbgE2jucRqBYWNF5cmzgbkIgJGERYpYuVlJ iKviqYeCwrXz9X0jAN8OiwnCcgos+ynfYFkcHnCpR/Be+sI7JIxY/C3Cj0tJAkXQgh7OXFi50D/u afPHk3MSxhXJSVaa31u26d2ydeZTXPBEM4y2yb+gdvl2lfMFWDY7FGsEZoAwTksBLGWI9iITcTf0 trp8CDwbhk775dt55q/nD7ownhvZE1WvOXwAAAAAAAA= --Apple-Mail-21-384909771-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 15:45:39 -0800 (PST) Lines: 45 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Jan 29 00:41:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk >I'm confused. LLMNR is only useful when there is no configured DNS, LLMNR can be used where there is a configured DNS server as well, but where the DNS server doesn't answer, or responds with RCODE=3 or RCODE=0 and no answers in the answer section. See Section 2 for details. Also note that LLMNR prefers unicast queries for PTR RRs, and does not use multicast responses, to avoid unnecessary multicast traffic that would become a problem if the scope were expanded beyond link local. See Section 2.4. >What sort of scenario are you likely to run in to where there would be no >unicast DNS but there are routers configured to handle multicast? Where >is this mentioned as a design goal? If the user has a router at home that includes support for DHCPv4 only and no support for IPV6 DNS configuration or resolution of AAAA queries, then LLMNR can be used to resolve names of IPv6-only hosts on the local network. See Section 3.1. >It seems like LLMNR has a subset of the mDNS functionality. mDNS is focussed on discovery of stationary services. LLMNR is about name resolution in environments which may be highly mobile. They are different problems and different design choices were made to address them. >LLMNR focuses on solving the problem of resolving DNS entries when there >is no DNS server. mDNS attempts to solve the problem of resolving DNS >names when there is no DNS as well as resolving names even when there is >a configured DNS server. LLMNR handles both situations. LLMNR can be used to resolve any name. See Section 2. >If they had private addresses, there would be no point in using dynamic DNS to register their address. >LLMNR wouldn't work. LLMNR can resolve a name with any kind of address. LLMNR doesn't rely on dynamic DNS or support dynamic DNS update op codes. See Section 2.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Miek Gieben <miekg@atoom.net> Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. Date: Thu, 29 Jan 2004 10:07:02 +0100 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <BA09033C-5194-11D8-AF3C-000393DA2D46@ripe.net> <20040128203233.08EE614C52@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Jan 29 10:23:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <20040128203233.08EE614C52@sa.vix.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Precedence: bulk [On 28 Jan, @21:32, Paul wrote in "Re: Q-23 Direct NSEC queries; ..."] > > The proposed text therefore is: security aware resolvers MAY query for > > missing security RRs; implementations that choose to do so must be > > aware of the fact that the answers received may not be sufficient to > > perform validation. > > this gives no guideance to server implementors, and is therefore inadequate. > > how about adding this text: > > security aware responders who receive queries for security RRs which > match the content of more than one zone, for example above and below > a delegation point, are encouraged to behave self-consistently, > which could mean: always return an error; always return > above-delegation records; always return below-delegation records; > always return no records; always return both above- and > below-delegation records; or always something else entirely > > in other words, driving home the point that requestor implementors ought not I like this text more than the one provided by Olaf, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: The IESG <iesg-secretary@ietf.org> Subject: WG Action: RECHARTER: DNS Extensions (dnsext) Date: Thu, 29 Jan 2004 10:34:43 -0500 Lines: 148 Sender: owner-namedroppers@ops.ietf.org Cc: namedroppers@ops.ietf.org, Olafur Gudmundsson <ogud@ogud.com>, Olaf Kolkman <olaf@ripe.net> X-From: owner-namedroppers@ops.ietf.org Thu Jan 29 16:51:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk The charter of the DNS Extensions (dnsext) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. DNS Extensions (dnsext) ----------------------- Current Status: Active Working Group Chair(s): Olafur Gudmundsson <ogud@ogud.com> Olaf Kolkman <olaf@ripe.net> Internet Area Director(s): Thomas Narten <narten@us.ibm.com> Margaret Wasserman <margaret@thingmagic.com> Internet Area Advisor: Thomas Narten <narten@us.ibm.com> Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: <http://ops.ietf.org/lists/namedroppers/> Description of Working Group: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication. This WG is focused on advancing the zone transfer, update and notify documents to Draft standard and on the rewrite of the DNSSEC proposed standard. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group. The DNSEXT Working Group actually uses an additional mailing list for discussion of DNS Security related issues. This list is open to all: Discussion: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list The RFC2535bis document set is edited by a team that can be reached through dnssec-editors@east.isi.edu. This team is chartered with making editorial changes only, with all substantative changes discussed on the WG list. Only the document editors and working group chairs are on this list, an archive of the mailing list is available at: Archive: http://www.east.isi.edu/projects/DNSSEC Specific work items are: o Protocol clarifications and corrections for DNSSEC, initially these clarifications will be done as separate RFCs that will later be folded into a document that we refer to as the RFC 2535bis document standard. These include changes that simplify the operation of DNSSEC. o Generate new specification documents of DNSSEC (the RFC 2535bis document set) that includes all changes to RFC2535. This includes the following RFCs 2931, 3007, 3008, 3090 and 3226 and a number of Internet Drafts including DS, AD-is-secure, Key Signing Flag, NSEC RDATA etc. Advance this document set through the standards process. o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. + Case insensitivity rules clarification. o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2672 (DNAME) to Draft Standard, or revision. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3645 GSS/TSIG to Draft Standard + RFC3??? AXFR clarify to Draft Standard. o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. Goals and Milestones: Jan 04 Forward NSEC rdata to IESG for Proposed Standard Feb 04 Forward RFC2535-bis to IESG for proposed standard. Feb 04 Forward Case Insensitive to IESG for Proposed Standard Feb 04 Forward LLMNR to IESG for Proposed Standard. Mar 04 Forward Wildcard clarification to IESG for proposed standard Mar 04 Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard. Apr 04 Update boilerplate text on OPT-IN Apr 04 Submit to IESG RFC2845 (TSIG)to Draft standard. Mar 04 Start of process of reviewing the following RFCs and to move them to Draft Standard status. May 04 RFC1982 (Serial Number Arithmetic) May 04 RFC2782 (SRV RR) to Draft Standard May 04 RFC2538 (CERT RR) to Draft Standard. Jun 04 RFC1995 (IXFR) to Draft standard Jun 04 RFC1996 (Notify) to Draft Standard. Jun 04 RFC2136 (Dynamic Update) to Draft Standard. Jul 04 RFC3007 (Secure Update) to Draft Standard. Jul 04 Submit to IESG RFC2930 (TKEY) to Draft standard. Jul 04 RFC2672 (DNAME) to Draft Standard or revision. Sep 04 RFC2181 (Clarify) to Draft Standard. Sep 04 RFC2671 (EDNS0) to Draft Standard. Sep 04 RFC2308 (Neg Caching) to Draft Standard. Nov 04 RFC3090 (DNSSEC zones tatus) to Draft Standard. Nov 04 FRC2539 (DH Key RR) to Draft Standard. Nov 04 RFC3226 (Message Size) to Draft Standard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:48 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR is done Date: Thu, 29 Jan 2004 14:50:42 -0800 Lines: 86 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0401281539470.30275@internaut.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-472678492; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Fri Jan 30 00:06:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0401281539470.30275@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) Precedence: bulk --Apple-Mail-4-472678492 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Jan 28, 2004, at 3:45 PM, Bernard Aboba wrote: >> I'm confused. LLMNR is only useful when there is no configured DNS, > > LLMNR can be used where there is a configured DNS server as well, but > where the DNS server doesn't answer, or responds with RCODE=3 or > RCODE=0 > and no answers in the answer section. See Section 2 for details. Counting on DNS to return RCODE=3 or RCODE=0 with no answers is error prone. Unless you or someone you know is responsible for a domain, you can't guarantee that a query will fail. If you use an unqualified name, the resolver may attempt to append a search domain first, which may result in a successful unicast DNS query for a name you were not expecting. Maybe I'm missing something obvious? Otherwise, it seems that LLMNR is unreliable (nearly useless) when there is a configured DNS server. -josh --Apple-Mail-4-472678492 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDEyOTIyNTA0MlowIwYJKoZIhvcNAQkEMRYEFGIW bh2hQGh9sELJ9hxAC2HV1Q16MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAEWA l1ypzWcynd8/9CiboerBOghm3SVqOW+JDVUdJfT4moxVy+cAITp/k00jEqoI+H3g7978TI235YI6 heffeImZdgKguVINbTZKS72dXJ5MXKVeYTa7te7ycfhVZpg2yola0Mqp67v3hdSIHEI0zaPgPJRm PmsX7Q6pNtIyltyrItYtSOd4RJ/p3/+/VYlMEaQuGX2TPNvORzeG3EcIM1T1dgqAaMnyrASnTitm rbqStr5H0R6wbsrM5N+hvLsjE0lmUqsdQ6LrYuxl6fYRCvQn/InNcSDIiqU9XnHDyfBlyLmkMcsc PzzdRYn27UtMt97t4bL4g1XseZlDngy3+rgAAAAAAAA= --Apple-Mail-4-472678492-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>