From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:41 2006
From: Randy Bush <randy@psg.com>
Subject: list policy
Date: Wed, 01 Oct 2003 03:00:01 +0000
Lines: 189
Sender: owner-namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 01 05:23:27 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Precedence: bulk

- List Purpose

  namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> 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
  <http://www.ietf.org/html.charters/dnsop-charter.html>. 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

  <NAME> ISSUE: <title>

  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:41 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: Q-10: Reaction to "Silly" NXT's
Date: Wed, 1 Oct 2003 10:22:03 +0200
Organization: RIPE NCC
Lines: 41
Sender: owner-namedroppers@ops.ietf.org
References: <a05111b06baf923307469@[192.168.1.100]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Oct 01 10:40:39 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <a05111b06baf923307469@[192.168.1.100]>
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.000086
X-RIPE-Signature: 5e5df3daf93429db5f735a3454e2aa98
Precedence: bulk


A comment/clarification with respect to this issue and
draft-ietf-dnsext-dnssec-protocol-02.txt

In the initial mail Ed wrote:
 > Any comments on this proposal?  (It's been posted a few times.) 
 > Sooner or later this will be cast into MUST/SHOULD language and 
 > submitted to the dnssec-editors, based on feedback.


The "Silly State" discussion died without text being submitted to the
editors.

The draft now contains in section 5.4:

   Since a verified NSEC RR proves the existance of both itself and
   its corresponding RRSIG RR, a verifier MUST ignore the settings of
   the NSEC and RRSIG bits in an NSEC RR.


In other words it clarifies the RFC2535 approach and does not add
additional checks.

If the Working Group still want to pursue with 'Silly State' then
those interested should come up with a "diff" against
dnssec-protocol-2. That text, which should have a motivation, will
then be discussed on its merits.

We want to try to get a final version of the protocol draft before the
cut-off in about 3 weeks. To allow some time for discussion a text
would need to be submitted within, say, a week.


--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:41 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-02.txt
Date: Wed, 01 Oct 2003 10:57:51 -0400
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 Wed Oct 01 17:19:17 2003
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		: Protocol Modifications for the DNS Security Extensions
	Author(s)	: R. Arends
	Filename	: draft-ietf-dnsext-dnssec-protocol-02.txt
	Pages		: 47
	Date		: 2003-10-1
	
This document is part of a family of documents which describes the
DNS Security Extensions (DNSSEC).  The DNS Security Extensions are a
collection of new resource records and protocol modifications which
add data origin authentication and data integrity to the DNS.  This
document describes the DNSSEC protocol modifications.  This document
defines the concept of a signed zone, along with the requirements for
serving and resolving using DNSSEC.  These techniques allow a
security-aware resolver to authenticate both DNS resource records and
authoritative DNS error indications.
This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dnssec-protocol-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-1103314.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-dnssec-protocol-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-1103314.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:41 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: wcard-clarify's change
Date: Fri, 3 Oct 2003 11:42:56 +0200
Organization: RIPE NCC
Lines: 58
Sender: owner-namedroppers@ops.ietf.org
References: <20030928150322.9E8301394B@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Fri Oct 03 12:03:42 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20030928150322.9E8301394B@sa.vix.com>
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.097100
X-RIPE-Signature: 78b560cc8baeb3e82534932cfafb6cd0
Precedence: bulk


Namedroppers,

We have to get to a consensus on this one at some point. I want to try
and keep momentum going.

Let us define X="something that matches the *"

Then I think we have consensus on the fact that there is a problem in
the fact that for QNAME=X QTYPE=A we will get different answers from a
cache depending on the fact if the cache was asked QNAME=X,QTYPE=CNAME
before.  This is an ambiguity and it needs clarification.

I think that the TTL=0 solution will not lead to consensus so we are
currently left with two possibilities:

- Either clarify the algorithm so that QNAME=X,QNAME!=CNAME will
  produce a CNAME response in the authoritative server.

- Or outlawing "* CNAME".

Am I missing other solutions?


Process:

-  If there is anybody who CANNOT live with one of the two solutions than 
   speak up and motivate.

-  If there is a strong preference for one of the solutions than also speak up
   and motivate.

-  If you can live with the default (below), or you really do not care
   which solution is picked, it would be nice to know so we know people
   actually read this thread.


I hope that based on these two questions we can cook up the consensus
solution. Please keep in mind you do not have to like that solution but you
should be able to live with it.

If there is no input before Oct 18 I will take "Outlawing * CNAME" as
being the consensus outcome of this issue. The motivation for me
choosing that particular solution as default is that it is simplest;
you do not have to deal with all kinds of loop protections etc.


-- Olaf
   DNSEXT Co-Chair.

   Is there an English equivalent to the proverb "een olifant in een
   porcelein kast"?

--
to 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:41 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wcard-clarify's change
Date: Fri, 03 Oct 2003 17:17:48 +0700
Lines: 10
Sender: owner-namedroppers@ops.ietf.org
References: <20031003114256.15494de9.olaf@ripe.net>  <20030928150322.9E8301394B@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 Fri Oct 03 12:28:16 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Olaf M. Kolkman" <olaf@ripe.net>
In-Reply-To: <20031003114256.15494de9.olaf@ripe.net> 
Precedence: bulk

I can live with either, no problem outlawing CNAME in a '*' record.

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:41 2006
From: Randy Bush <randy@psg.com>
Subject: Re: wcard-clarify's change
Date: Fri, 3 Oct 2003 08:16:29 -0700
Lines: 13
Sender: owner-namedroppers@ops.ietf.org
References: <20031003114256.15494de9.olaf@ripe.net>
	<20030928150322.9E8301394B@sa.vix.com>
	<23881.1065176268@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: "Olaf M. Kolkman" <olaf@ripe.net>,
    namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 03 17:32:30 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Elz <kre@munnari.OZ.AU>
Precedence: bulk

> I can live with either, no problem outlawing CNAME in a '*' record.

as paul said, that is a change, not a clarification, and hence
outside the range of this document.

randy


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:41 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wcard-clarify's change
Date: Sat, 04 Oct 2003 00:44:34 +0700
Lines: 22
Sender: owner-namedroppers@ops.ietf.org
References: <E1A5RfR-000FpT-US@ran.psg.com>  <20031003114256.15494de9.olaf@ripe.net> <20030928150322.9E8301394B@sa.vix.com> <23881.1065176268@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 03 19:59:58 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Randy Bush <randy@psg.com>
In-Reply-To: <E1A5RfR-000FpT-US@ran.psg.com> 
Precedence: bulk

    Date:        Fri, 3 Oct 2003 08:16:29 -0700
    From:        Randy Bush <randy@psg.com>
    Message-ID:  <E1A5RfR-000FpT-US@ran.psg.com>

  | > I can live with either, no problem outlawing CNAME in a '*' record.
  | 
  | as paul said, that is a change, not a clarification, and hence
  | outside the range of this document.

Randy, something has to be done.  The option that can be argued that
is not a change is to explicitly permit CNAME in wildcards, and actually
make it work correctly.   That would be OK too.   But just doing nothing
is unacceptable.

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:41 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: wcard-clarify's change
Date: Fri, 03 Oct 2003 18:12:11 +0000
Lines: 20
Sender: owner-namedroppers@ops.ietf.org
References: <kre@munnari.OZ.AU>
X-From: owner-namedroppers@ops.ietf.org Fri Oct 03 20:21:28 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Robert Elz <kre@munnari.OZ.AU> 
	of "Sat, 04 Oct 2003 00:44:34 +0700."
	<28336.1065203074@munnari.OZ.AU> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

>   | > I can live with either, no problem outlawing CNAME in a '*' record.
>   | 
>   | as paul said, that is a change, not a clarification, and hence
>   | outside the range of this document.
> 
> Randy, something has to be done.  The option that can be argued that
> is not a change is to explicitly permit CNAME in wildcards, and actually
> make it work correctly.   That would be OK too.   But just doing nothing
> is unacceptable.

i think that clarifying rfc1034 is the right goal, and that in this case,
that means clarifying that wildcard CNAME's will result in noerror/nodata
responses, which is (a) useless and (b) counterintuitive and (c) probably
not what the zone editor wants and so therefore (d) it's not recommended.

--
to 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:41 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wcard-clarify's change
Date: Sat, 04 Oct 2003 01:17:18 +0700
Lines: 17
Sender: owner-namedroppers@ops.ietf.org
References: <28336.1065203074@munnari.OZ.AU>  <E1A5RfR-000FpT-US@ran.psg.com> <20031003114256.15494de9.olaf@ripe.net> <20030928150322.9E8301394B@sa.vix.com> <23881.1065176268@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Fri Oct 03 20:30:25 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Randy Bush <randy@psg.com>, "Olaf M. Kolkman" <olaf@ripe.net>,
   namedroppers@ops.ietf.org
In-Reply-To: <28336.1065203074@munnari.OZ.AU> 
Precedence: bulk

I just said ...

  | That would be OK too.   But just doing nothing is unacceptable.

I should have also added that we should make the best of the two
choices (if there is a "best" - or for Randy "better") on technical
grounds, not based on some absurd self imposed rule about what this
document is supposed to be permitted to do or not do.

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:41 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wcard-clarify's change
Date: Sat, 04 Oct 2003 01:25:01 +0700
Lines: 29
Sender: owner-namedroppers@ops.ietf.org
References: <20031003181211.747C513948@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 Fri Oct 03 20:37:36 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>
In-Reply-To: <20031003181211.747C513948@sa.vix.com> 
Precedence: bulk

    Date:        Fri, 03 Oct 2003 18:12:11 +0000
    From:        Paul Vixie <paul@vix.com>
    Message-ID:  <20031003181211.747C513948@sa.vix.com>

  | i think that clarifying rfc1034 is the right goal, and that in this case,
  | that means clarifying that wildcard CNAME's will result in noerror/nodata
  | responses, which is (a) useless and (b) counterintuitive and (c) probably
  | not what the zone editor wants and so therefore (d) it's not recommended.

Paul, you keep skipping the point, which is that "wildcard CNAME's will
result in noerror/nodata responses" is simply not true.   And I don't mean
just because a (set of) very popular implementations doesn't do that.

I mean that whether you get the empty response (assuming the server is
implemented the way you believe is the correct way) depends upon where
you ask the question, and what previous questions that server has been
asked.

That is what is unacceptable - the DNS needs to supply predictable
answers, whatever they are.

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:41 2006
From: Sam Weiler <weiler@tislabs.com>
Subject: Re: wcard-clarify's change
Date: Fri, 3 Oct 2003 16:55:37 -0400 (EDT)
Lines: 15
Sender: owner-namedroppers@ops.ietf.org
References: <20030928150322.9E8301394B@sa.vix.com> <20031003114256.15494de9.olaf@ripe.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 03 23:14:08 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: "Olaf M. Kolkman" <olaf@ripe.net>
In-Reply-To: <20031003114256.15494de9.olaf@ripe.net>
Precedence: bulk

>    Is there an English equivalent to the proverb "een olifant in een
>    porcelein kast"?

"An elephant in a china shop?"  "A bull in a china shop" is more
common 'round these parts.

http://www.adbusters.org/oldwebsite/Uncommercials/bullspot.html

-- 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:41 2006
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: wcard-clarify's change
Date: Sat, 4 Oct 2003 07:29:32 +0859 ()
Lines: 28
Sender: owner-namedroppers@ops.ietf.org
References: <20031003114256.15494de9.olaf@ripe.net>
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sat Oct 04 00:56:05 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <20031003114256.15494de9.olaf@ripe.net> from "Olaf M. Kolkman" at
 "Oct 3, 2003 11:42:56 am"
To: "Olaf M. Kolkman" <olaf@ripe.net>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
Precedence: bulk

Olaf;

> - Or outlawing "* CNAME".

> Process:
> 
> -  If there is anybody who CANNOT live with one of the two solutions than 
>    speak up and motivate.

I can't live with a solution that

	QNAME=X, QNAME!=CNAME produces an error

	QNAME=*, QNAME!=CNAME does not produce an error

even though the latter is the behaviour specified at 3a of 4.3.2.

So, just accept the fact that 3c of 4.3.2 contradicts with other
descriptions in rfc1034 and it should be clarified that wildcard
CNAME is OK.

							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:41 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: wcard-clarify's change
Date: Fri, 03 Oct 2003 21:23:23 -0400
Lines: 14
Sender: owner-namedroppers@ops.ietf.org
References: <20030928150322.9E8301394B@sa.vix.com>
	<20031003114256.15494de9.olaf@ripe.net>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Sat Oct 04 03:47:39 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20031003114256.15494de9.olaf@ripe.net>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI)
Precedence: bulk

At Fri, 3 Oct 2003 11:42:56 +0200, Olaf Kolkman wrote:
> 
> If there is no input before Oct 18 I will take "Outlawing * CNAME" as
> being the consensus outcome of this issue. The motivation for me
> choosing that particular solution as default is that it is simplest;
> you do not have to deal with all kinds of loop protections etc.

I think that this is the right thing to do.

--
to 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:41 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wcard-clarify's change
Date: Sat, 04 Oct 2003 14:04:41 +0700
Lines: 21
Sender: owner-namedroppers@ops.ietf.org
References: <200310032229.HAA00984@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sat Oct 04 09:26:23 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <200310032229.HAA00984@necom830.hpcl.titech.ac.jp> 
Precedence: bulk

    Date:        Sat, 4 Oct 2003 07:29:32 +0859 ()
    From:        Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
    Message-ID:  <200310032229.HAA00984@necom830.hpcl.titech.ac.jp>

  | I can't live with a solution that
  | 	QNAME=X, QNAME!=CNAME produces an error
  | 	QNAME=*, QNAME!=CNAME does not produce an error

Otha-san - could you possibly repeat that with a little more detail,
or perhaps precision ...   Why would anyone care if the QNAME  was "CNAME"
for example?   (Is there something wrong with having a host called
cname.example.com ?)

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:41 2006
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: wcard-clarify's change
Date: Sat, 4 Oct 2003 21:24:11 +0859 ()
Lines: 35
Sender: owner-namedroppers@ops.ietf.org
References: <13231.1065251081@munnari.OZ.AU>
Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sat Oct 04 15:07:33 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <13231.1065251081@munnari.OZ.AU> from Robert Elz at "Oct 4, 2003
 02:04:41 pm"
To: Robert Elz <kre@munnari.OZ.AU>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
Precedence: bulk

kre;

>     Date:        Sat, 4 Oct 2003 07:29:32 +0859 ()
>     From:        Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
>     Message-ID:  <200310032229.HAA00984@necom830.hpcl.titech.ac.jp>
> 
>   | I can't live with a solution that
>   | 	QNAME=X, QNAME!=CNAME produces an error
>   | 	QNAME=*, QNAME!=CNAME does not produce an error
> 
> Otha-san - could you possibly repeat that with a little more detail,
> or perhaps precision ...   Why would anyone care if the QNAME  was "CNAME"
> for example?

Oops, I meant (assuming X does not explicitly exist)

  | 	QNAME=X, QTYPE!=CNAME produces an error

  | 	QNAME=*, QTYPE!=CNAME does not produce an error

because latter behaviour is specified at 3a of 4.3.2, which means
code is error prone, regardless of whether it is an implementaion
one or a pseudo one of 3c.

So, just don't believe in pseudo code and follow explanations in
other parts of rfc1034 to allow wildcarded CNAME, which is the
clarification.

							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:41 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wcard-clarify's change
Date: Sat, 04 Oct 2003 20:12:32 +0700
Lines: 47
Sender: owner-namedroppers@ops.ietf.org
References: <200310041224.VAA02688@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sat Oct 04 15:26:10 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <200310041224.VAA02688@necom830.hpcl.titech.ac.jp> 
Precedence: bulk

    Date:        Sat, 4 Oct 2003 21:24:11 +0859 ()
    From:        Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
    Message-ID:  <200310041224.VAA02688@necom830.hpcl.titech.ac.jp>

  | because latter behaviour is specified at 3a of 4.3.2, which means
  | code is error prone, regardless of whether it is an implementaion
  | one or a pseudo one of 3c.

Right - now I think just about everyone agrees that 1034's spec of
wildcard handling (where the wildcard has a CNAME record) is simply
broken.

The question is what to do about it.

This ...

  | So, just don't believe in pseudo code and follow explanations in
  | other parts of rfc1034 to allow wildcarded CNAME, which is the
  | clarification.

is certainly one option.   The other is to simply outlaw wildcarded CNAME.

Defining it to work sensibly (as you're suggesting) has the advantage that
it adds flexibility, and means one less special case (though implementations
at least need to make sure to handle

	* IN CNAME nosuchname

in some rational way).

Outlawing it is easy to accomplish, works everywhere already (if there
is no wildcard CNAME record, what the implementation might do if it
had one is irrelevant - so if wildcard CNAME is illegal, anyone who has
one in their zone simply needs to remove it). and most probably does
no great harm (uses for wildcard CNAME that make sense are few and far
between...)

Do you have a reason for preferring to define it (make it work properly)?

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:41 2006
From: Randy Bush <randy@psg.com>
Subject: Re: wcard-clarify's change
Date: Sat, 4 Oct 2003 08:23:42 -0700
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <E1A5RfR-000FpT-US@ran.psg.com>
	<20031003114256.15494de9.olaf@ripe.net>
	<20030928150322.9E8301394B@sa.vix.com>
	<23881.1065176268@munnari.OZ.AU>
	<28336.1065203074@munnari.OZ.AU>
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 Sat Oct 04 17:36:26 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Elz <kre@munnari.OZ.AU>
Precedence: bulk

>>> I can live with either, no problem outlawing CNAME in a '*' record.
>> as paul said, that is a change, not a clarification, and hence
>> outside the range of this document.
> Randy, something has to be done.

about what exactly?

> The option that can be argued that is not a change is to
> explicitly permit CNAME in wildcards

i think that is pretty clear, as paul also pointed out

> and actually make it work correctly.

what's "correctly?"  they are returned for a direct query.
you want more?  i suspect folk don't.

randy


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:41 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: wcard-clarify's change
Date: Sat, 04 Oct 2003 15:40:22 +0000
Lines: 27
Sender: owner-namedroppers@ops.ietf.org
References: <kre@munnari.OZ.AU>
Cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>,
	"Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sat Oct 04 17:54:46 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: Message from Robert Elz <kre@munnari.OZ.AU> 
	of "Sat, 04 Oct 2003 20:12:32 +0700."
	<11222.1065273152@munnari.OZ.AU> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

robert,

presenting wildcard cnames that way (declaring them broken vs. fixing them)
presumes facts not yet generally accepted.

consider this text from rfc1034:

	If a CNAME RR is present at a node, no other data should be
	present; this ensures that the data for a canonical name and its
	aliases cannot be different.  This rule also insures that a
	cached CNAME can be used without checking with an authoritative
	server for other RR types.

this argues that a wildcard cname would be legal if there were no other
descendents of the same parent.  what's strange is that pvm said "at a
node" rather than "whose owner matches the qname".  but the last sentence
is compelling evidence that the pseudocode is not in error, that the
behaviour you're calling "broken" was intentional, and that wildcard
cnames really just don't do what people intuitively feel they ought to.

paul

--
to 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:41 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wcard-clarify's change
Date: Sun, 05 Oct 2003 17:12:57 +0700
Lines: 86
Sender: owner-namedroppers@ops.ietf.org
References: <20031004154022.741CF13971@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>,
   "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sun Oct 05 12:43:09 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>
In-Reply-To: <20031004154022.741CF13971@sa.vix.com> 
Precedence: bulk

    Date:        Sat, 04 Oct 2003 15:40:22 +0000
    From:        Paul Vixie <paul@vix.com>
    Message-ID:  <20031004154022.741CF13971@sa.vix.com>

  | presenting wildcard cnames that way (declaring them broken vs. fixing them)
  | presumes facts not yet generally accepted.

No, you still keep missing the point.  Or at least, on the list you do.

  | consider this text from rfc1034:
  | 
  | 	If a CNAME RR is present at a node, no other data should be
  | 	present; this ensures that the data for a canonical name and its
  | 	aliases cannot be different.  This rule also insures that a
  | 	cached CNAME can be used without checking with an authoritative
  | 	server for other RR types.

Yes.  All that is fine.

  | this argues that a wildcard cname would be legal if there were no other
  | descendents of the same parent.

Of course.  I am not attempting to claim that 1034 makes wildcard CNAME
illegal.

  | what's strange is that pvm said "at a
  | node" rather than "whose owner matches the qname".

I'm not sure what is strange about that.

  | but the last sentence
  | is compelling evidence that the pseudocode is not in error,

I have no idea how you arrive at that conclusion.   What the last sentence
says is that a CNAME must be the only RR, as otherwise, a cache with a
CNAME record, when asked for an A for that name, wouldn't know whether it
should just chase the CNAME, and return the A for the canonical name, or
whether it was required to query the auth server, and find out if there was
also an A record (in addition to one at the canonical name, if any).

That's all quite clear - but I don't see how it provides any evidence at
all about whether CNAMES at wildcards were intended to be noticed when the
name is not explicitly in the zone, but the wildcard CNAME is.

  | that the behaviour you're calling "broken" was intentional,

Note, the behaviour I am calling "broken" has nothing to do with the
algorithm in 3.4 particularly at all.   If it caused no other problems,
I'd be happy to leave things in the (totally useless) state where a
lookup of type CNAME would find the wildcard record, and a lookup of
type A would not - which is what you claim the algorithm requires.

The broken behaviour is that that does not produce a consistent result when
a cache is queried, rather than the auth server directly.

The answer depends upon earlier queries.   If you're claiming that's
a design feature, I'd like to see some evidence for it.   Nowhere else
in the DNS is it possible to make a query for type=X and have that query
affect the result of a later query for the same qname of type=Y (or not
if everything is correctly configured, and operating).

  | and that wildcard
  | cnames really just don't do what people intuitively feel they ought to.

I don't care what they do, or don't do.  I consider them useless in any
case.   What bothers me is that you're seriously suggesting that the DNS
should be explicitly made non-deterministic, but you won't actually say
so directly.

randy@psg.com said:
  | what's "correctly?"  they are returned for a direct query. you want more?

I want consistent predictable answers.   Is that too much to ask?

In this case, I don't care what the answers are, but I want to know
what answers resolvers will obtain for queries I know they will make,
whenever I make any DNS configuration that is not invalid.

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:41 2006
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: wcard-clarify's change
Date: Mon, 6 Oct 2003 09:30:56 +0859 ()
Lines: 39
Sender: owner-namedroppers@ops.ietf.org
References: <11222.1065273152@munnari.OZ.AU>
Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Oct 06 03:03:18 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <11222.1065273152@munnari.OZ.AU> from Robert Elz at "Oct 4, 2003
 08:12:32 pm"
To: Robert Elz <kre@munnari.OZ.AU>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
Precedence: bulk

kre;

>   | because latter behaviour is specified at 3a of 4.3.2, which means
>   | code is error prone, regardless of whether it is an implementaion
>   | one or a pseudo one of 3c.
> 
> Right - now I think just about everyone agrees that 1034's spec of
> wildcard handling (where the wildcard has a CNAME record) is simply
> broken.

I think it is merely that some description is missing, which, in
general, makes specifcation ambiguous.

A complication is that missing decription in psuedo code makes the
code not ambiguous but broken.

But, it merely means that we shouldn't blindly believe psuedo code,

In this case, the code is not consistent with the rest of the
specification nor other part of the code itself.

> The question is what to do about it.

Add some description.

> Do you have a reason for preferring to define it (make it work properly)?

In this case, it is already defined. See above.

Another reason not to outlaw wildcarded CNAME is that some might
already be using it in some zone.

							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:41 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: wcard-clarify's change
Date: Mon, 6 Oct 2003 10:41:46 +0200
Organization: RIPE NCC
Lines: 45
Sender: owner-namedroppers@ops.ietf.org
References: <20030928150322.9E8301394B@sa.vix.com>
	<20031003114256.15494de9.olaf@ripe.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Mon Oct 06 10:59:40 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20031003114256.15494de9.olaf@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.479190
X-RIPE-Signature: 470d6186f0dbe249ab84d085bd512ad7
Precedence: bulk


> Am I missing other solutions?

I think there is a 3rd solution, although I personally do not like it,
I want to mention it.

 Leaving the existing situation but facing that a security aware
 resolver will need to have the intelligence to do the CNAME query and  
 resolve the ambiguity.

Explanation:

Assume the security aware resolver queries for QNAME=X (X being a name
that matches the wildcard that has a CNAME) and QTYPE=A.

The authoritative server will return something like

RCODE=NOERROR
 ; answer empty

 ; authority
  X    NSEC   CNAME SIG NSEC
  X    SIG    (labelcount indicating wildcard)


So the resolver gets an answer with the NSEC RR proving there is a
CNAME and the SIG proving that the match was against a wildcard. The
security aware resolver would have to know to do a query for QNAME=X,
QTYPE=CNAME to get the proper CNAME.

A non-secure resolver wouldn't know what situation its in.



-- 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:41 2006
From: The IESG <iesg-secretary@ietf.org>
Subject: WG Action: RECHARTER: DNS Extensions (dnsext)
Date: Mon, 06 Oct 2003 16:02:25 -0400
Lines: 132
Sender: owner-namedroppers@ops.ietf.org
Cc: Olafur Gudmundsson <ogud@ogud.com>, Olaf Kolkman <olaf@ripe.net>,
        namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Oct 06 22:27:58 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: IETF-Announce: ;
Precedence: bulk

The DNS Extensions (dnsext) Working Group in the Internet Area of the IETF
has been rechartered. 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>
             Margret Wasserman <Margaret.Wasserman@nokia.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/>

   The DNSEXT Working Group actually uses an additional mailing list:
             DNS Security: dnssec@cafax.se
             To Subscribe: dnssec-request@cafax.se
             Archive: http://www.cafax.se/dnssec/ and
                               ftp://ftp.cafax.se/pub/archives/dnssec.list

 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.

 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, 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 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.
                   + RFC2845 (TSIG)to Draft standard.
                   + RFC2930 (TKEY) to Draft standard.
                   + RFC3007 (Secure Update) to Draft standard.
                   + RFC3??? AXFR clarify to Draft Standard.
                   + RFC3??? GSS/TSIG 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:

     Sep 03 Update boilerplate text on OPT-IN 
     Oct 03 Forward LLMNR to IESG for Proposed Standard.
     Oct 03 WG last call on the DNSSEC document set(RFC2535-bis).
     Oct 03 Forward Wildcard clarification to IESG for proposed standard
     Nov 03 Submit KEY algorithm documents RFC253[69d] and
                     RFC3110 to IESG for proposed standard.
     Sep/Oct 03 Forward RFC2535-bis to IESG for proposed standard.
     Feb 04 Submit to IESG RFC2845 (TSIG)to Draft standard.
     Feb 04 Submit to IESG RFC2930 (TKEY) to Draft standard.
     Nov 03 Start of process of reviewing the following RFCs and to move them to                     PS status.
     Feb 04 RFC1982 (Serial Number Arithmetic)
     Feb 04 RFC2782 (SRV RR) to Draft Standard
     Feb 04 RFC2538 (CERT RR) to Draft Standard.
     May 04 RFC1995 (IXFR) to Draft standard
     May 04 RFC1996 (Notify) to Draft Standard.
     May 04 RFC2136 (Dynamic Update) to Draft Standard.
     May 04 RFC3007 (Secure Update) to Draft standard.
     Aug 04 RFC2181 (Clarify) to Draft Standard.
     Aug 04 RFC2671 (EDNS0) to Draft Standard.
     Aug 04 RFC2308 (Neg Caching) to Draft Standard.
     Nov 04 RFC3090 (TKEY) 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:41 2006
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: Re: LLMNR interoperability with Rendezvous?
Date: Mon, 06 Oct 2003 18:45:10 -0400
Lines: 51
Sender: owner-namedroppers@ops.ietf.org
References: <200309200203.h8K23cCn024691@scv3.apple.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 Oct 07 01:04:09 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: Stuart Cheshire <cheshire@apple.com>
In-Reply-To: <200309200203.h8K23cCn024691@scv3.apple.com>
Precedence: bulk

At 22:04 2003-09-19, Stuart Cheshire wrote:
> >This entire episode, including the reversal of the rough consensus
> >favoring TTL=1 for link-local traffic in the ZeroConf WG, brings to mind
> >the freshman engineering example in which a column is removed from a
> >room for aesthetic reasons, rendering the entire building weak.
> >Please do not mess with the foundation without compelling reasons!
>
>John, you have this completely backwards.
>
>Up to draft-ietf-dnsext-mdns-17.txt, it said:
>
> >In composing an LLMNR response, the responder MUST set the Hop Limit
> >field in the IPv6 header and the TTL field in IPv4 header of the LLMNR
> >response to 255.  The sender MUST verify that the Hop Limit field in
> >IPv6 header and TTL field in IPv4 header of each response to the LLMNR
> >query is set to 255.  If it is not, then sender MUST ignore the
> >response.
>
>It was only a couple of months ago, after Apple and other companies had
>been shipping products for over a year, that DNSEXT decided to reverse
>its consensus.
>
>You may remember that I was one of the people who argued for TTL=1 in the
>first place, but I was swayed by the working group consensus, so we
>shipped with TTL=255, and then the working group changed its mind back
>again.

Stewart,

You shipped code against an uncompleted specification and as it goes
there was development on the TTL issue and consensus changed. Some
room has been provided to review the issue but the fact that there is
code shipped against an uncompleted specification is not a valid
argument in that review, only an argument to revisit the issue.

Thus you on your own and with known consequences decided to ship code
against uncompleted specification.
If your company wants interoperabilty they can update distributions,
and possibly at the same time a put in a kludge to talk to the
old implementations.

         Sorry but that is the cold facts.
         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:41 2006
From: Mark.Andrews@isc.org
Subject: Re: wcard-clarify's change
Date: Tue, 07 Oct 2003 09:23:36 +1000
Lines: 68
Sender: owner-namedroppers@ops.ietf.org
References: <20031006104146.4a0aa5c6.olaf@ripe.net>
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Oct 07 01:36:27 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Olaf M. Kolkman" <olaf@ripe.net>
In-reply-to: Your message of "Mon, 06 Oct 2003 10:41:46 +0200."
             <20031006104146.4a0aa5c6.olaf@ripe.net> 
Precedence: bulk


> 
> > Am I missing other solutions?
> 
> I think there is a 3rd solution, although I personally do not like it,
> I want to mention it.
> 
>  Leaving the existing situation but facing that a security aware
>  resolver will need to have the intelligence to do the CNAME query and  
>  resolve the ambiguity.
>
> Explanation:
> 
> Assume the security aware resolver queries for QNAME=X (X being a name
> that matches the wildcard that has a CNAME) and QTYPE=A.
> 
> The authoritative server will return something like
> 
> RCODE=NOERROR
>  ; answer empty
> 
>  ; authority
>   X    NSEC   CNAME SIG NSEC
>   X    SIG    (labelcount indicating wildcard)
> 
> 
> So the resolver gets an answer with the NSEC RR proving there is a
> CNAME and the SIG proving that the match was against a wildcard. The
> security aware resolver would have to know to do a query for QNAME=X,
> QTYPE=CNAME to get the proper CNAME.

	This is ridiculous.

	Failure to follow wildcard CNAME records in RFC 1034 section
	4.3.2 is clearly a oversite.  There is no technical reason
	not to follow them for QTYPE!=CNAME.  Following them clearly
	works based on years of experience and is consistant with
	the use of CNAME elsewhere in the DNS.

	It has to be a oversite as no engineer (we are engineers arn't
	we) would deliberately design a system which make the answers
	from the cache dependent apon the query order.

	I have argued for a long time to get 3c expanded to include
	following CNAMEs.  I will continue to argue for that result.

> A non-secure resolver wouldn't know what situation its in.
>
> -- 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:41 2006
From: bmanning@karoshi.com
Subject: Re: LLMNR interoperability with Rendezvous?
Date: Mon, 6 Oct 2003 16:23:28 -0700 (PDT)
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <5.1.1.6.2.20030926094448.01648520@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: cheshire@apple.com (Stuart Cheshire), namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Oct 07 01:37:32 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: ogud@ogud.com (=?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair)
In-Reply-To: <5.1.1.6.2.20030926094448.01648520@localhost> from "=?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair" at Oct 06, 2003 06:45:10 PM
X-Mailer: ELM [version 2.5 PL6]
Precedence: bulk

> >It was only a couple of months ago, after Apple and other companies had
> >been shipping products for over a year, that DNSEXT decided to reverse
> >its consensus.

	what consensus? i've not seen any RFC that describes consensus
	on this topic.

> Stewart,
> 
> You shipped code against an uncompleted specification and as it goes

	is the llmnr spec complete?  has it gone past last call
	and reached IESG approval to publish as an RFC?  if not,
	there is still time to tweek the spec to meet empirical, operational
	feedback.

>          Olafur DNSEXT co-chair.

--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:41 2006
From: Stuart Cheshire <cheshire@apple.com>
Subject: Re: LLMNR interoperability with Rendezvous?
Date: Mon, 6 Oct 2003 17:28:15 -0700
Lines: 42
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-From: owner-namedroppers@ops.ietf.org Tue Oct 07 02:47:03 2003
Return-path: <owner-namedroppers@ops.ietf.org>
x-sender: cheshire@mail.apple.com
X-Mailer: Claris Emailer 2.0v3, January 22, 1998
To: "=?ISO-8859-1?Q?=d3lafur_Gudmundsson/DNSEXT_co-chair?=" <ogud@ogud.com>,
        <namedroppers@ops.ietf.org>
Precedence: bulk

>You shipped code against an uncompleted specification and as it goes
>there was development on the TTL issue and consensus changed. Some
>room has been provided to review the issue but the fact that there
>is code shipped against an uncompleted specification is not a valid
>argument in that review, only an argument to revisit the issue.
>
>Thus you on your own and with known consequences decided to ship code
>against uncompleted specification.
>If your company wants interoperabilty they can update distributions,
>and possibly at the same time a put in a kludge to talk to the
>old implementations.
>
>         Sorry but that is the cold facts.
>         Olafur DNSEXT co-chair.

=D3lafur, you're mixing up two issues.

In his pejorative "freshman engineering" analogy, I thought John 
Schnizlein was suggesting that Apple disregarded the Working Group 
consensus and intentionally did the opposite for no good reason (though 
perhaps that's not what he was saying). I was just pointing out one 
simple fact. At the time we shipped, apparent Working Group consensus, as 
reflected in the drafts at that time, was that the TTL should be 255, and 
that's exactly what we did. I did *not* say that Working Groups cannot 
change consensus -- as we know, they do that all the time.

On a related subject, I asked a while back if any LLMNR implementers had 
tested to see if their implementations do or do not interoperate 
successfully with Mac OS X. Specifically, if a LLMNR query is sent to 
224.0.0.251:5353 with an IP TTL of 255, do Mac OS X machines on that link 
respond correctly?

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:41 2006
From: John Schnizlein <jschnizl@cisco.com>
Subject: Re: LLMNR interoperability with Rendezvous?
Date: Mon, 06 Oct 2003 22:40:09 -0400
Lines: 32
Sender: owner-namedroppers@ops.ietf.org
References: <200310070028.h970S3WI015405@scv2.apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Cc: "Ólafur Gudmundsson/DNSEXT co-chair" <ogud@ogud.com>,
   <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Tue Oct 07 04:56:52 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: jschnizl@wells.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Stuart Cheshire <cheshire@apple.com>
In-Reply-To: <200310070028.h970S3WI015405@scv2.apple.com>
Precedence: bulk


>>Thus you on your own and with known consequences decided to ship code
>>against uncompleted specification.
>
>Ólafur, you're mixing up two issues.
>
>In his pejorative "freshman engineering" analogy, I thought John 
>Schnizlein was suggesting that Apple disregarded the Working Group 
>consensus and intentionally did the opposite for no good reason (though 
>perhaps that's not what he was saying). I was just pointing out one 
>simple fact. At the time we shipped, apparent Working Group consensus, as 
>reflected in the drafts at that time, was that the TTL should be 255, and 
>that's exactly what we did. I did *not* say that Working Groups cannot 
>change consensus -- as we know, they do that all the time.

My plea to preserve the semantics of TTL was not pejorative "freshman engineering". The justification of TTL=255, based on misreading multicast implications, was rejected in the discussion of the issue in the ZeroConf WG.

My complaint was that the consensus in the ZeroConf WG in favor of preserving the meaning of TTL, with TTL=1 for no hops (link local) in combination with Christian's accommodation of other TTLs for compatibility where an application needed something else, was reversed by the Chair based on private arguments after the issue was officially closed. I never said Apple disregarded WG consensus in deploying Rendezvous using TTL=255. I did raise the concern when the ZeroConf WG reversed the rough consensus in favor of TTL=1, that the LLMNR draft had settled on it.

My personal background with Apple goes as far back as 1985, when I bought Kinetics FastPaths to connect Macintosh networks on the campus network I designed and managed. I have owned Macintosh computers since 1987, and designed an operated an AppleTalk network from 1989 until 1996. I have been a consistent supporter of the migration of AppleTalk to IP throughout this period. I admired both the Macintosh and NeXT designs and bought systems, either personally or for my various employers reflecting these opinions. This is not about me.

As in the Middle-East, any position can be argued by claiming the basis at a time long enough ago. The history is less important than preserving the foundation of the Internet Protocol. I recall your statements that you had advocated TTL=1 for the reasons it gained rough consensus in the ZeroConf WG (prior to the reversal). Your argument was that Apple deployed the draft specification of TTL=255. Now that the mistaken multicast justification for TTL=255 is deprecated, and the impracticality of demanding that all (previously) installed routers block forwarding of the recently (in the larger picture) LL prefix in order to keep link-local traffic local has been recognized, please re-join the advocacy of TTL=1 for link-local.

With respect,
John


--
to 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:41 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: LLMNR interoperability with Rendezvous?
Date: Tue, 07 Oct 2003 04:39:22 +0000
Lines: 37
Sender: owner-namedroppers@ops.ietf.org
References: <ogud@ogud.com>
X-From: owner-namedroppers@ops.ietf.org Tue Oct 07 06:57:50 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> 
	of "Mon, 06 Oct 2003 18:45:10 -0400."
	<5.1.1.6.2.20030926094448.01648520@localhost> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> >You may remember that I was one of the people who argued for TTL=1 in the
> >first place, but I was swayed by the working group consensus, so we
> >shipped with TTL=255, and then the working group changed its mind back
> >again.
> 
> You shipped code against an uncompleted specification and as it goes
> there was development on the TTL issue and consensus changed. Some
> room has been provided to review the issue but the fact that there is
> code shipped against an uncompleted specification is not a valid
> argument in that review, only an argument to revisit the issue.
> 
> Thus you on your own and with known consequences decided to ship code
> against uncompleted specification.
> If your company wants interoperabilty they can update distributions,
> and possibly at the same time a put in a kludge to talk to the
> old implementations.

you cannot possibly be serious.  apple should have waited an extra two
years to deploy functionality necessary to its product/service technology
simply because the volunteers of namedroppers couldn't be bothered to do
a rigorous enough review to be able to figure out a ttl issue?

that's not just unlikely, it's insane.  it'll never happen and shouldn't
happen.  meanwhile the new products entering the field won't be compatible
with anything previously existing in the field.  if i were a hardware or
software vendor i'd either support both or support rendezvous, just to
make sure there was somebody to sell it to on day 1.

penalizing apple for trying hard to play well with others but launching
their best guess when the deadline loomed isn't going to be effective and
would not be ethical even if it was.

--
to 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:41 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Request for Agenda Items
Date: Tue, 7 Oct 2003 09:18:42 +0200
Organization: RIPE NCC
Lines: 28
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 Oct 07 09:35:56 2003
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.222389
X-RIPE-Signature: 68903cf1bc48d5d8010c5980b21a2904
Precedence: bulk



The DNEXT WG meeting during IETF45 will be @:

   MONDAY, November 10, 2003
   0900-1130 Morning Sessions
   INT       dnsext   DNS Extensions WG


The agenda will cover administrivia and will have a large fraction of
its time devoted to DNSSEC.

Hereby a request for other agenda items.

Please contact the chairs if you have suggestions or want to speak.

-- Olaf
   DNSEXT Co-Chair

---------------------------------| 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:41 2006
From: rfc-editor@rfc-editor.org
Subject: RFC 3596 on DNS Extensions to Support IP Version 6
Date: Tue, 07 Oct 2003 11:13:17 -0700
Lines: 110
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Oct 07 20:40:17 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: IETF-Announce: ;
Precedence: bulk


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3596

        Title:      DNS Extensions to Support IP Version 6
        Author(s):  S. Thomson, C. Huitema, V. Ksinant, M. Souissi
        Status:     Standards Track
        Date:       October 2003
        Mailbox:    sethomso@cisco.com, huitema@microsoft.com,
                    vladimir.ksinant@6wind.com, Mohsen.Souissi@nic.fr
        Pages:      8
        Characters: 14093
        Obsoletes:  3152, 1886

        I-D Tag:    draft-ietf-dnsext-rfc1886bis-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3596.txt


This document defines the changes that need to be made to the Domain
Name System (DNS) to support hosts running IP version 6 (IPv6).  The
changes include a resource record type to store an IPv6 address,
a domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing.  The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.

This document is a product of the DNS Extensions Working Group of the
IETF. 

This is now a Draft Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <031007111143.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3596

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3596.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <031007111143.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:41 2006
From: Sam Weiler <weiler@tislabs.com>
Subject: DS & TCR clarifications
Date: Wed, 8 Oct 2003 19:37:15 -0400 (EDT)
Lines: 32
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 Oct 09 02:20:05 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: namedroppers@ops.ietf.org
Precedence: bulk

1) Section 2.4 of DS-15 says "Algorithm MUST be an algorithm number
assigned in the range 1..251 and the algorithm MUST be allowed to sign
DNS data."  TCR-04 retains types 253 (private, named) and 254
(private, OID), but dropped 252 (indirect), 255 (reserved), and 0
(reserved).  Shouldn't DS be usable with private algorithms, too?  I
propose completely dropping the restriction from the DS draft.

Either way, one of the drafts will probably be editted to make this
explicit -- either DS will remove/change the restriction and
gain a normative reference on TCR, or TCR will immediately
remove/change the restriction.  The question is not which of those
should happen, but what the restriction should be.

2) Does the IANA registry need to include the algorithm mnemonics?  I
think so, since dnssec-records-04 says that DS, RRSIG, and DNSKEY
presentation formats can use mnemonics.  (This will be a change to the
TCR draft.)

2a) Are the mnemonics in records-04, section A.1 correct?  (Some
algorithms need to be removed, but are the mnemonics correct?)

2b) The DS draft says nothing about using mnemonics in the
presentation format (section 2.5).  Do we really want to change that
in DNSSECbis?

-- 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:41 2006
From: "Jack Tavares" <j.tavares@F5.com>
Subject: FW: RFC 3596 on DNS Extensions to Support IP Version 6
Date: Wed, 8 Oct 2003 16:55:34 -0700
Lines: 15
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-From: owner-namedroppers@ops.ietf.org Thu Oct 09 02:20:19 2003
Return-path: <owner-namedroppers@ops.ietf.org>
x-mimeole: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 3596 on DNS Extensions to Support IP Version 6
Thread-Index: AcONAy+US/0YILFhSd6QM3/OmHdYNAA9FJOwAAAHg9A=
To: <namedroppers@ops.ietf.org>
X-OriginalArrivalTime: 08 Oct 2003 23:55:34.0610 (UTC) FILETIME=[AA0FB320:01C38DF7]
Precedence: bulk

So does this mean that A6 and DNAME are dead?

> >=20
> >         I-D Tag:    draft-ietf-dnsext-rfc1886bis-03.txt
> >=20
> >         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3596.txt
> >=20
> >=20
>=20

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: Mark.Andrews@isc.org
Subject: Re: FW: RFC 3596 on DNS Extensions to Support IP Version 6
Date: Thu, 09 Oct 2003 10:40:18 +1000
Lines: 38
Sender: owner-namedroppers@ops.ietf.org
References: <9C44AE0FB9D352429CB57CF47F6F989C428098@exchone>
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 09 02:51:25 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Jack Tavares" <j.tavares@F5.com>
In-reply-to: Your message of "Wed, 08 Oct 2003 16:55:34 MST."
             <9C44AE0FB9D352429CB57CF47F6F989C428098@exchone> 
Precedence: bulk


> So does this mean that A6 and DNAME are dead?

	DNAME is alive and well.
	A6 is experimental.

> > >         I-D Tag:    draft-ietf-dnsext-rfc1886bis-03.txt
> > > 
> > >         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3596.txt

	We use DNAME to map IP6.INT queries to IP6.ARPA queries.
	Hopefully one day there will just be:

		IP6.INT. DNAME IP6.ARPA.

	As you deploy your IP6.ARPA zone ask your IP6.INT upstream
	to replace you delegation with a DNAME record.  Once they
	have a zone of DNAMES they can then do the same upwards.

	This requires your upstream to be using DNAME aware servers.

	Mark

> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: FW: RFC 3596 on DNS Extensions to Support IP Version 6
Date: Thu, 09 Oct 2003 04:55:38 +0000
Lines: 37
Sender: owner-namedroppers@ops.ietf.org
References: <j.tavares@F5.com>
X-From: owner-namedroppers@ops.ietf.org Thu Oct 09 07:18:30 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "Jack Tavares" <j.tavares@F5.com> 
	of "Wed, 08 Oct 2003 16:55:34 MST."
	<9C44AE0FB9D352429CB57CF47F6F989C428098@exchone> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

dname lives

a6 does not

ietf may use different labels but those are the facts anyway

re:

> Subject: FW: RFC 3596 on DNS Extensions to Support IP Version 6
> Date: Wed, 8 Oct 2003 16:55:34 -0700
> X-MS-Has-Attach: 
> Thread-Topic: RFC 3596 on DNS Extensions to Support IP Version 6
> Thread-Index: AcONAy+US/0YILFhSd6QM3/OmHdYNAA9FJOwAAAHg9A=
> From: "Jack Tavares" <j.tavares@F5.com>
> To: <namedroppers@ops.ietf.org>
> Sender: owner-namedroppers@ops.ietf.org
> 
> So does this mean that A6 and DNAME are dead?
> 
> > > 
> > >         I-D Tag:    draft-ietf-dnsext-rfc1886bis-03.txt
> > > 
> > >         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3596.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/>

--
to 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:42 2006
From: Roy Arends <roy@logmess.com>
Subject: DNSSECbis Q-17: typecode change and TKEY
Date: Thu, 9 Oct 2003 10:00:07 +0200 (CEST)
Lines: 31
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 Oct 09 10:14:19 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs
X-X-Sender: roy@elektron.atoom.net
To: namedroppers@ops.ietf.org
X-Virus-Scanned: by amavisd-new
Precedence: bulk

TKEY (2930) provisions key agreement methods. One method for a resolver
and a server to agree about shared secret keying material for use in TSIG
(2845) is through DNS requests using, for example, Diffie-Hellman (DH)
Exchanged Keying.

Essentially, a resolver sends a query accompanied by a KEY RR in the
additional section specifying a resolver DH key (2539), or, a KEY
accompanied by its SIG(KEY).

The issue at hand is the accompanied KEY RR (and SIG) in light of the
recent type-code rollover, which leaves the KEY RR for the use of SIG(0)
only.

There are a few ways out:

1) retain KEY, SIG RR for the use of TKEY as well as SIG(0).
2) Have draft-ietf-dnsext-dnssec-2535typecode-change update RFC 2930 as
   well.

Either way, draft-ietf-dnsext-dnssec-2535typecode-change, and 2535bis
accordingly, has to include some text on this.

Regards,

Roy

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: "Scott Rose" <scottr@nist.gov>
Subject: Re: DNSSECbis Q-17: typecode change and TKEY
Date: Thu, 9 Oct 2003 08:15:20 -0400
Lines: 54
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.58.0310090922070.2350@elektron.atoom.net>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Thu Oct 09 14:36:08 2003
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

Personally, I agree with 1).  KEY could be used for transaction
authentication and DNSKEY used for generating RRSIGs only.

That way, KEY can retain the use of the DH algorithm code, and DNSKEY may
not need it.

Scott


----- Original Message ----- 
From: "Roy Arends" <roy@logmess.com>
To: <namedroppers@ops.ietf.org>
Sent: Thursday, October 09, 2003 4:00 AM
Subject: DNSSECbis Q-17: typecode change and TKEY


> TKEY (2930) provisions key agreement methods. One method for a resolver
> and a server to agree about shared secret keying material for use in TSIG
> (2845) is through DNS requests using, for example, Diffie-Hellman (DH)
> Exchanged Keying.
>
> Essentially, a resolver sends a query accompanied by a KEY RR in the
> additional section specifying a resolver DH key (2539), or, a KEY
> accompanied by its SIG(KEY).
>
> The issue at hand is the accompanied KEY RR (and SIG) in light of the
> recent type-code rollover, which leaves the KEY RR for the use of SIG(0)
> only.
>
> There are a few ways out:
>
> 1) retain KEY, SIG RR for the use of TKEY as well as SIG(0).
> 2) Have draft-ietf-dnsext-dnssec-2535typecode-change update RFC 2930 as
>    well.
>
> Either way, draft-ietf-dnsext-dnssec-2535typecode-change, and 2535bis
> accordingly, has to include some text on this.
>
> Regards,
>
> Roy
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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:42 2006
From: Jakob Schlyter <jakob@rfc.se>
Subject: Re: DNSSECbis Q-17: typecode change and TKEY
Date: Thu, 9 Oct 2003 16:40:26 +0200 (CEST)
Lines: 16
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.58.0310090922070.2350@elektron.atoom.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 09 17:00:52 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Roy Arends <roy@logmess.com>
In-Reply-To: <Pine.LNX.4.58.0310090922070.2350@elektron.atoom.net>
Precedence: bulk

On Thu, 9 Oct 2003, Roy Arends wrote:

> 1) retain KEY, SIG RR for the use of TKEY as well as SIG(0).
> 2) Have draft-ietf-dnsext-dnssec-2535typecode-change update RFC 2930 as
>    well.

I'd would go for (1) since signing transactions and rr sets have different
usages, separating the keys makes sense.

	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:42 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: DNSSECbis Q-17: typecode change and TKEY
Date: Thu, 09 Oct 2003 13:45:28 -0400
Lines: 18
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.58.0310090922070.2350@elektron.atoom.net>
	<Pine.OSX.4.56.0310091638590.3353@forastero.dynamic.schlyter.se>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Oct 09 20:08:13 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <Pine.OSX.4.56.0310091638590.3353@forastero.dynamic.schlyter.se>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

At Thu, 9 Oct 2003 16:40:26 +0200 (CEST), Jakob Schlyter wrote:
> 
> On Thu, 9 Oct 2003, Roy Arends wrote:
> 
> > 1) retain KEY, SIG RR for the use of TKEY as well as SIG(0).
> > 2) Have draft-ietf-dnsext-dnssec-2535typecode-change update RFC 2930 as
> >    well.
> 
> I'd would go for (1) since signing transactions and rr sets have different
> usages, separating the keys makes sense.

What Jakob said.

--
to 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:42 2006
From: Sam Weiler <weiler@tislabs.com>
Subject: Re: DS & TCR clarifications
Date: Thu, 9 Oct 2003 15:53:26 -0400 (EDT)
Lines: 15
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.GSO.4.55.0310081922170.9980@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Oct 09 22:34:34 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: namedroppers@ops.ietf.org
In-Reply-To: <Pine.GSO.4.55.0310081922170.9980@filbert>
Precedence: bulk

> TCR-04 retains types 253 (private, named) and 254
> (private, OID), but dropped 252 (indirect), 255 (reserved), and 0
> (reserved).

OK, I should re-read my own draft before posting: 0 and 255 (and 1)
are still reserved -- even so, why should the DS draft restrict using
them?

-- 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:42 2006
From: Sam Weiler <weiler@tislabs.com>
Subject: mnemonics (was: Re: DS & TCR clarifications)
Date: Thu, 9 Oct 2003 15:54:45 -0400 (EDT)
Lines: 49
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.GSO.4.55.0310081922170.9980@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Oct 09 22:34:36 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: namedroppers@ops.ietf.org
In-Reply-To: <Pine.GSO.4.55.0310081922170.9980@filbert>
Precedence: bulk

On Wed, 8 Oct 2003, Sam Weiler wrote:

> 2a) Are the mnemonics in records-04, section A.1 correct?  (Some
> algorithms need to be removed, but are the mnemonics correct?)

Answering my own question, since no one else has: no.

records-04 also removed the mnemonics for the flags and protocol
fields.  Is that intentional?

RFC2535 section 7 says:
        Value  Symbol

        001    RSAMD5
        002    DH
        003    DSA
        004    ECC
        252    INDIRECT
        253    PRIVATEDNS
        254    PRIVATEOID

RFC3110 does not define a mnemonic for RSA/SHA-1

The current draft (records-04) says:

   VALUE   Algorithm [mnemonic]       RFC          STATUS
   0      Reserved                    -            -
   1      RSA/MD5 [RSA/MD5]           RFC 2537     NOT RECOMMENDED
   2      Diffie-Hellman [DH]         RFC 2539     OPTIONAL
   3      DSA [DSA]                   RFC 2536     OPTIONAL
   4      elliptic curve [ECC]        TBA          OPTIONAL
   5      RSA/SHA1 [RSA/SHA1]         RFC 3110     MANDATORY
   6-251  available for assignment    -
   252    reserved                    -
   253    private [PRIVATE_DNS]       see below    OPTIONAL
   254    private [PRIVATE_OID]       see below    OPTIONAL
   255    reserved                    -

So the mnemonics for 1 (which is "reserved" in the new registry
anyway), 253, and 254 aren't the ones in 2535, and there never was a
mnemonic for RSA/SHA1.

-- 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:42 2006
From: rfc-editor@rfc-editor.org
Subject: RFC 3645 on Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)
Date: Thu, 09 Oct 2003 15:33:33 -0700
Lines: 111
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 10 00:51:57 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: IETF-Announce: ;
Precedence: bulk


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3645

        Title:      Generic Security Service Algorithm for
                    Secret Key Transaction Authentication for DNS
                    (GSS-TSIG)
        Author(s):  S. Kwan, P. Garg, J. Gilroy, L. Esibov,
                    J. Westhead, R. Hall
        Status:     Standards Track
        Date:       October 2003
        Mailbox:    skwan@microsoft.com, praeritg@microsoft.com,
                    jamesg@microsoft.com, levone@microsoft.com,
                    randyhall@lucent.com, jwesth@microsoft.com
        Pages:      26
        Characters: 56162
        Updates:    2845

        I-D Tag:    draft-ietf-dnsext-gss-tsig-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3645.txt


The Secret Key Transaction Authentication for DNS (TSIG) protocol
provides transaction level authentication for DNS.  TSIG is extensible
through the definition of new algorithms.  This document specifies an
algorithm based on the Generic Security Service Application Program
Interface (GSS-API) (RFC2743).  This document updates RFC 2845.

This document is a product of the DNS Extensions Working Group of the
IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <031009153145.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3645

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3645.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <031009153145.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: Mark.Andrews@isc.org
Subject: Fwd:
Date: Fri, 10 Oct 2003 12:32:13 +1000
Lines: 23
Sender: owner-namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 10 04:46:18 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Precedence: bulk


Could you forward this to namedroppers, it was only a private reply.


Mark wrote:
> 
> 	My preference would be just to make * CNAME behave like 
> 	any other CNAME.  There is no good reason to not do this.
> 
> 	It also allows for a level of indirection when the names
> 	that match * goto a HTTP server run by a second party.
> 
> 	I can live with outlawing CNAMEs.
> 	
> 	Note wildcard DNAMEs really need to be outlawed for exactly
> 	the same reason CNAMEs needed to be corrected.  Caches give
> 	inconsistant/differing results based upon query history.

--
to 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:42 2006
From: Sam Weiler <weiler@tislabs.com>
Subject: Re: DS & TCR clarifications
Date: Fri, 10 Oct 2003 11:51:32 -0400 (EDT)
Lines: 16
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.GSO.4.55.0310081922170.9980@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Fri Oct 10 18:11:25 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: namedroppers@ops.ietf.org
In-Reply-To: <Pine.GSO.4.55.0310081922170.9980@filbert>
Precedence: bulk

Next question:

records-04 lists the algorithm status (optional, mandatory, not
recommended)  along with the parameter values and mnemonics.  Should
that in the registry, too?

Also, we need a mnemonic for RSA/SHA-1 (for presentation formats).
Make suggestions, or I'll invent one.

-- 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:42 2006
From: Sam Weiler <weiler@tislabs.com>
Subject: Re: DS & TCR clarifications
Date: Fri, 10 Oct 2003 12:43:09 -0400 (EDT)
Lines: 21
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.GSO.4.55.0310081922170.9980@filbert>
 <Pine.GSO.4.55.0310101148430.3400@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Fri Oct 10 18:53:41 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: namedroppers@ops.ietf.org
In-Reply-To: <Pine.GSO.4.55.0310101148430.3400@filbert>
Precedence: bulk

> records-04 lists the algorithm status (optional, mandatory, not
> recommended)  along with the parameter values and mnemonics.  Should
> that in the registry, too?

Again, answering my own question: no.  Rather, the TCR draft shouldn't
do that.  It's not in the registry now, we're getting by just fine,
and I don't want the TCR draft to have to tackle the DSA
mandatory/optional thing.  If DNSSECbis wants to add status as a
column in the registry, that's wonderful.

Look for a new -05 that retains SIG and KEY for TKEY (sigh), renames
the new registries (IESG request), and adds mnemonics to the new
registry.

-- 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:42 2006
From: Jakob Schlyter <jakob@rfc.se>
Subject: Re: DS & TCR clarifications
Date: Fri, 10 Oct 2003 21:32:42 +0200 (CEST)
Lines: 14
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.GSO.4.55.0310081922170.9980@filbert>
 <Pine.GSO.4.55.0310101148430.3400@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 10 21:54:56 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Sam Weiler <weiler@tislabs.com>
In-Reply-To: <Pine.GSO.4.55.0310101148430.3400@filbert>
Precedence: bulk

On Fri, 10 Oct 2003, Sam Weiler wrote:

> Also, we need a mnemonic for RSA/SHA-1 (for presentation formats).
> Make suggestions, or I'll invent one.

RSASHA1

	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:42 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Any decision on wildcard CNAME ?
Date: Sun, 12 Oct 2003 03:13:03 +0700
Lines: 27
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Sun Oct 12 11:00:02 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Precedence: bulk

I'm trying to work out what the WG decision is on wildcard CNAME
so a new draft can get submitted sometime soon...

As best I can tell, Masatake Ohta and Mark Andrews favour simply
defining it to work (in the full and naturally expected way).

Rob Austein and Olaf Kolkman seemed to prefer simply defining it to
be illegal (or undefined, or something essentially equivalent).

I, and I think some others (but I don't remember the names) want the
thing fixed, but I don't care which of the above ways.

Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent
results possible.   Or did the last time they wrote.

Large numbers of other people who I know read this list haven't
expressed an opinion at all.   Please do - without more input, there
isn't going to be any way to come to any kind of conclusion on this.

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:42 2006
From: Alan Barrett <apb@cequrux.com>
Subject: Re: Any decision on wildcard CNAME ?
Date: Sun, 12 Oct 2003 11:16:51 +0200
Lines: 17
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Sun Oct 12 11:27:48 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
In-Reply-To: <11723.1065903183@munnari.OZ.AU>
Precedence: bulk

On Sun, 12 Oct 2003, Robert Elz wrote:
> Large numbers of other people who I know read this list haven't
> expressed an opinion at all.   Please do - without more input, there
> isn't going to be any way to come to any kind of conclusion on this.

Either "it should work" or "it is illegal" will do, but I have a slight
preference for defining it to work in the naturally expected way.  The
present situation, where people can argue that it is defined to give
inconsistent results, is unacceptable.

--apb (Alan Barrett)

--
to 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:42 2006
From: ted@NLnetLabs.nl (Ted Lindgreen)
Subject: Re: Any decision on wildcard CNAME ?
Date: Sun, 12 Oct 2003 12:13:25 +0200
Lines: 20
Sender: owner-namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sun Oct 12 12:23:51 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: "Robert Elz's message as of Oct 12, 10:55"
X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98)
To: Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org
Precedence: bulk

[Quoting Robert Elz, on Oct 12, 10:55, in "Any decision on wild ..."]

> Large numbers of other people who I know read this list haven't
> expressed an opinion at all.   Please do - without more input, there
> isn't going to be any way to come to any kind of conclusion on this.

We (developers of NSD) are (strongly) in favor of defining it
to be illegal.

Second best is make it work, provided that does not further
complicate DNSSEC.  Leaving it inconsistent will make
implementing DNSSEC very difficult if not impossible.

-- ted

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: Any decision on wildcard CNAME ?
Date: Sun, 12 Oct 2003 22:03:48 +0900
Lines: 26
Sender: owner-namedroppers@ops.ietf.org
References: <200310121013.h9CADPtW029223@open.nlnetlabs.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: Robert Elz <kre@munnari.OZ.AU>,  namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sun Oct 12 15:18:06 2003
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: Ted Lindgreen <ted@NLnetLabs.nl>
In-Reply-To: <200310121013.h9CADPtW029223@open.nlnetlabs.nl>
Precedence: bulk

Ted;

>>Large numbers of other people who I know read this list haven't
>>expressed an opinion at all.   Please do - without more input, there
>>isn't going to be any way to come to any kind of conclusion on this.
> 
> 
> We (developers of NSD) are (strongly) in favor of defining it
> to be illegal.
> 
> Second best is make it work, provided that does not further
> complicate DNSSEC.  Leaving it inconsistent will make
> implementing DNSSEC very difficult if not impossible.

My understanding is that the issue is orthogonal to DNSSEC complexity.

							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:42 2006
From: ted@NLnetLabs.nl (Ted Lindgreen)
Subject: Re: Any decision on wildcard CNAME ?
Date: Sun, 12 Oct 2003 19:21:23 +0200
Lines: 20
Sender: owner-namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sun Oct 12 19:41:08 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98)
To: namedroppers@ops.ietf.org
Precedence: bulk

[Quoting masataka ohta, on Oct 12, 15:12, in "Re: Any decision on  ..."]

> > Second best is make it work, provided that does not further
> > complicate DNSSEC.  Leaving it inconsistent will make
> > implementing DNSSEC very difficult if not impossible.
> 
> My understanding is that the issue is orthogonal to DNSSEC complexity.

Then I am probably missing something. Please enlighten us on what
algoritme to use to prove correctness or non-existence of an RR
derived from expansion of a wildcard CNAME with its current definition?
We have great problems with this now, and want to get on with our work.

-- ted

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: "Christian Huitema" <huitema@windows.microsoft.com>
Subject: RE: Any decision on wildcard CNAME ?
Date: Sun, 12 Oct 2003 12:05:57 -0700
Lines: 22
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-From: owner-namedroppers@ops.ietf.org Sun Oct 12 21:20:54 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Any decision on wildcard CNAME ?
thread-index: AcOQ53oVj9KxG9ajSaiPSWjSAkBVowAC76EQ
To: "Ted Lindgreen" <ted@NLnetLabs.nl>,
	<namedroppers@ops.ietf.org>
X-OriginalArrivalTime: 12 Oct 2003 19:05:58.0355 (UTC) FILETIME=[DEA89A30:01C390F3]
Precedence: bulk

> Then I am probably missing something. Please enlighten us on what
> algoritme to use to prove correctness or non-existence of an RR
> derived from expansion of a wildcard CNAME with its current
definition?

Yup. How is that different from a load balancing DNS making up records
on the fly? Or a server programmed to synthesize PTR records? If you
cannot see the problem on the wire, then you cannot rule out the
behavior.

Now, there are two ways were you might see the behavior "on the wire":
in a zone transfer, and in a DNSSEC computation. Whatever rule is
written can only be written in one of these two contexts.

-- Christian Huitema=20


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= <kandra@foxette.net>
Subject: Re: Any decision on wildcard CNAME ?
Date: Sun, 12 Oct 2003 22:02:39 +0200
Lines: 23
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sun Oct 12 22:15:29 2003
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.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
Precedence: bulk

From: "Robert Elz" <kre@munnari.OZ.AU>

> I'm trying to work out what the WG decision is on wildcard CNAME
> so a new draft can get submitted sometime soon...
>
> As best I can tell, Masatake Ohta and Mark Andrews favour simply
> defining it to work (in the full and naturally expected way).

I don't like wildcards in general, but I don't see any reason why a
synthesized record should have different rules than a "natural" record. I'll
go with this line, at least as far as the protocol goes.


- Kandra




--
to 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:42 2006
From: "Eric A. Hall" <ehall@ehsco.com>
Subject: Re: Any decision on wildcard CNAME ?
Date: Sun, 12 Oct 2003 17:21:43 -0500
Lines: 20
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
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 Oct 13 00:39:02 2003
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
X-Accept-Language: en-US,en
To: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: <11723.1065903183@munnari.OZ.AU>
Precedence: bulk


on 10/11/2003 3:13 PM Robert Elz wrote:

> Large numbers of other people who I know read this list haven't
> expressed an opinion at all.   Please do - without more input, there
> isn't going to be any way to come to any kind of conclusion on this.

I don't have an implementation to vote with but if I did I'd vote to make
wildcards work with CNAME as per other inherent limitations.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/


--
to 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:42 2006
From: Mark.Andrews@isc.org
Subject: Re: Any decision on wildcard CNAME ?
Date: Mon, 13 Oct 2003 08:29:20 +1000
Lines: 39
Sender: owner-namedroppers@ops.ietf.org
References: <200310121721.h9CHLNja031011@open.nlnetlabs.nl>
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Oct 13 00:39:25 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: ted@NLnetLabs.nl (Ted Lindgreen)
In-reply-to: Your message of "Sun, 12 Oct 2003 19:21:23 +0200."
             <200310121721.h9CHLNja031011@open.nlnetlabs.nl> 
Precedence: bulk


> [Quoting masataka ohta, on Oct 12, 15:12, in "Re: Any decision on  ..."]
> 
> > > Second best is make it work, provided that does not further
> > > complicate DNSSEC.  Leaving it inconsistent will make
> > > implementing DNSSEC very difficult if not impossible.
> > 
> > My understanding is that the issue is orthogonal to DNSSEC complexity.
> 
> Then I am probably missing something. Please enlighten us on what
> algoritme to use to prove correctness or non-existence of an RR
> derived from expansion of a wildcard CNAME with its current definition?
> We have great problems with this now, and want to get on with our work.
 
	You prove wildcard CNAMEs exactly the same way that you prove
	wildcard A records.

	Verify the name does not exist. (NSEC)
	Verify that expanded owner name matches the signature. (RRSIG).

	Banning records actually introduces MORE work for DNSSEC.  You
	then have to check that you are not receiving a banned record.
	
> -- ted
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: tony.milton@bnpparibas.com
Subject: Re: Any decision on wildcard CNAME ?
Date: Mon, 13 Oct 2003 09:35:13 +0100
Lines: 84
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Oct 13 10:52:38 2003
Return-path: <owner-namedroppers@ops.ietf.org>
Sensitivity: 
To: kre@munnari.OZ.AU
X-MIMETrack: Serialize by Router on LONSMTP003/SERVERS/SMTP(Release 5.0.12  |February 13, 2003) at
 13/10/2003 09:34:48 AM
Precedence: bulk


I'm with Masatake Ohta and Mark Andrews - define it to work.

Regards,
Tony Milton



Internet
kre@munnari.OZ.AU@ops.ietf.org - 11/10/2003 21:13


Sent by:    owner-namedroppers@ops.ietf.org

To:    namedroppers

cc:


Subject:    Any decision on wildcard CNAME ?


I'm trying to work out what the WG decision is on wildcard CNAME
so a new draft can get submitted sometime soon...

As best I can tell, Masatake Ohta and Mark Andrews favour simply
defining it to work (in the full and naturally expected way).

Rob Austein and Olaf Kolkman seemed to prefer simply defining it to
be illegal (or undefined, or something essentially equivalent).

I, and I think some others (but I don't remember the names) want the
thing fixed, but I don't care which of the above ways.

Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent
results possible.   Or did the last time they wrote.

Large numbers of other people who I know read this list haven't
expressed an opinion at all.   Please do - without more input, there
isn't going to be any way to come to any kind of conclusion on this.

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/>






This message and any attachments (the "message") is
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

                ---------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le 
"message") sont etablis a l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce 
message par erreur, merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce 
message non conforme a sa destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf 
autorisation expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.


--
to 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:42 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: Any decision on wildcard CNAME ?
Date: Mon, 13 Oct 2003 19:52:14 +0700
Lines: 53
Sender: owner-namedroppers@ops.ietf.org
References: <200310122229.h9CMTK0o031812@bsdi.dv.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: ted@NLnetLabs.nl (Ted Lindgreen), namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Oct 13 15:29:07 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Mark.Andrews@isc.org
In-Reply-To: <200310122229.h9CMTK0o031812@bsdi.dv.isc.org> 
Precedence: bulk

    Date:        Mon, 13 Oct 2003 08:29:20 +1000
    From:        Mark.Andrews@isc.org
    Message-ID:  <200310122229.h9CMTK0o031812@bsdi.dv.isc.org>

  | 	Banning records actually introduces MORE work for DNSSEC.  You
  | 	then have to check that you are not receiving a banned record.

I have heard a similar sentiment (expressed in a different way) in
private mail (which I would prefer not to receive - everyone send opinions
to the list - unless you have an editorial not in the document)
though, which suggests that perhaps a clarification of the option
might be in order.

I'm not certain this is what Olaf had in mind when he suggested
this, but my impression of what "banning" the records would do
isn't quite like that.

That is, I don't think it is reasonable (or probably even possible)
to outlaw the transmission of a CNAME record that was constructed from
a wildcard, nor to force servers to barf on such things - as they might on
an RR like

	name IN A 1.2.3.4.5

but that making it illegal would be specified something like is currently
done when specifying that having the RDATA in an NS record be a CNAME
is illegal.

That is, if you do that, the server, caches, resolvers, may do anything
that like with your data, treat the record as if it doesn't exist, treat
it as if it does, with almost any meaning they like ... so just "don't
do that".

That is, provided we make it clear that a wildcard CNAME record isn't
something that should be expected to exist, and is not intended to be
handled (in any way at all), what implementations actually do should
one be found, is entirely their business - including "let's try and
make it work", "BARF loading the zone file and refuse to accept it",
"do according to what appears to be the strict interpretation of the
algorithm in 3.4.2 of 1034", or almost anything else (dumping core is
not included though...)

What effect that might have on the DNSSEC algorithms, especially wrt
non-existence, I have no idea.

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:42 2006
From: Randy Bush <randy@psg.com>
Subject: Re: Any decision on wildcard CNAME ?
Date: Mon, 13 Oct 2003 15:29:45 +0200
Lines: 14
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
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 Oct 13 15:40:04 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Elz <kre@munnari.OZ.AU>
Precedence: bulk

> Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent
> results possible.

no, results consistent with 1034.  if qtype=cname then return it.
if not, don't.

randy


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: Mark.Andrews@isc.org
Subject: Re: Any decision on wildcard CNAME ?
Date: Tue, 14 Oct 2003 00:06:08 +1000
Lines: 32
Sender: owner-namedroppers@ops.ietf.org
References: <E1A92lg-000BMd-3r@roam.psg.com>
X-From: owner-namedroppers@ops.ietf.org Mon Oct 13 16:20:01 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-reply-to: Your message of "Mon, 13 Oct 2003 15:29:45 +0200."
             <E1A92lg-000BMd-3r@roam.psg.com> 
Precedence: bulk


> > Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent
> > results possible.
> 
> no, results consistent with 1034.  if qtype=cname then return it.
> if not, don't.
> 
> randy

	Which leaves caches returning inconsistant result dependent
	on query history.

	So you want mail to go through from a MTA that make explict
	CNAME queries and not to go through from a MTA that makes
	implict CNAME queries (e.g. MX/A/AAAA)?

	Mark

> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: bmanning@vacation.karoshi.com
Subject: Re: Any decision on wildcard CNAME ?
Date: Mon, 13 Oct 2003 09:16:04 -0700
Lines: 17
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Oct 13 18:31:53 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Elz <kre@munnari.OZ.AU>
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <11723.1065903183@munnari.OZ.AU>; from kre@munnari.OZ.AU on Sun, Oct 12, 2003 at 03:13:03AM +0700
Precedence: bulk

On Sun, Oct 12, 2003 at 03:13:03AM +0700, Robert Elz wrote:
> I'm trying to work out what the WG decision is on wildcard CNAME
> so a new draft can get submitted sometime soon...
> 
> As best I can tell, Masatake Ohta and Mark Andrews favour simply
> defining it to work (in the full and naturally expected way).

	In the best of all possible worlds, I think this is
	the right tactic.

--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:42 2006
From: gson@nominum.com
Subject: Re: Any decision on wildcard CNAME ?
Date: Mon, 13 Oct 2003 10:44:49 -0700 (PDT)
Lines: 14
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
X-From: owner-namedroppers@ops.ietf.org Mon Oct 13 20:08:23 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <11723.1065903183@munnari.OZ.AU>
X-Mailer: VM 7.04 under Emacs 20.7.1
Precedence: bulk

Robert Elz writes:
> Large numbers of other people who I know read this list haven't
> expressed an opinion at all.

I favor the option of "defining it to work (in the full and naturally
expected way)".
-- 
Andreas Gustafsson, gson@nominum.com

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: Bob Halley <Bob.Halley@nominum.com>
Subject: Re: Any decision on wildcard CNAME ?
Date: 13 Oct 2003 11:35:54 -0700
Lines: 11
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Mon Oct 13 20:48:11 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <11723.1065903183@munnari.OZ.AU>
Lines: 5
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Precedence: bulk

I prefer "define it to work" as well.  I think this is the least-surprising
approach and it doesn't add any more special cases to the server.

/Bob


--
to 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:42 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-05.txt
Date: Mon, 13 Oct 2003 15:55:19 -0400
Lines: 95
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 Mon Oct 13 22:12:13 2003
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		: Legacy Resolver Compatibility for Delegation Signer
	Author(s)	: S. Weiler
	Filename	: draft-ietf-dnsext-dnssec-2535typecode-change-05.txt
	Pages		: 5
	Date		: 2003-10-13
	
As the DNS Security (DNSSEC) specifications have evolved, the
syntax and semantics of the DNSSEC resource records (RRs) have
changed.  Many deployed nameservers understand variants of these
semantics.  Dangerous interactions can occur when a resolver that
understands an earlier version of these semantics queries an
authoritative server that understands the new delegation signer
semantics, including at least one failure scenario that will cause
an unsecured zone to be unresolvable.  This document changes the
type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
avoid those interactions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dnssec-2535typecode-change-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-13145426.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-dnssec-2535typecode-change-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-13145426.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:42 2006
From: Josh Littlefield <joshl@cisco.com>
Subject: Re: Any decision on wildcard CNAME ?
Date: Mon, 13 Oct 2003 16:13:59 -0400
Organization: Cisco Systems
Lines: 44
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
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 Mon Oct 13 22:25:20 2003
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: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: <11723.1065903183@munnari.OZ.AU>
Precedence: bulk

I believe wildcard CNAMES should be defined to work like other wildcards.

Despite the pseudo-code in 4.3.2, I have to imagine that was the 
original intent of RFC1034, because there is no other indication that 
wildcards to not apply to aliases.  I still think this is in the realm 
of clarification.  I also believe it matches common interpretation and 
implementation.

-josh

Robert Elz wrote:

> I'm trying to work out what the WG decision is on wildcard CNAME
> so a new draft can get submitted sometime soon...
> 
> As best I can tell, Masatake Ohta and Mark Andrews favour simply
> defining it to work (in the full and naturally expected way).
> 
> Rob Austein and Olaf Kolkman seemed to prefer simply defining it to
> be illegal (or undefined, or something essentially equivalent).
> 
> I, and I think some others (but I don't remember the names) want the
> thing fixed, but I don't care which of the above ways.
> 
> Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent
> results possible.   Or did the last time they wrote.
> 
> Large numbers of other people who I know read this list haven't
> expressed an opinion at all.   Please do - without more input, there
> isn't going to be any way to come to any kind of conclusion on this.
> 
> kre
-- 
=====================================================================
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:42 2006
From: bmanning@karoshi.com
Subject: latency/discover
Date: Mon, 13 Oct 2003 13:40:46 -0700 (PDT)
Lines: 17
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: bmanning@karoshi.com
X-From: owner-namedroppers@ops.ietf.org Mon Oct 13 22:52:04 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
X-Mailer: ELM [version 2.5 PL6]
Precedence: bulk


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:42 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-dnsext-opcode-discover-02.txt
Date: Tue, 14 Oct 2003 15:33:41 -0400
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 Oct 14 21:56:49 2003
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		: The DISCOVER opcode
	Author(s)	: B. Manning, P. Vixie, E. Guttman
	Filename	: draft-dnsext-opcode-discover-02.txt
	Pages		: 0
	Date		: 2003-10-14
	
The QUERY opcode in the DNS is designed for unicast. With the
development of multicast capabilities in the DNS, it is desireable
to have a more robust opcode for server interactions since a single
request may result in replies from multiple responders. So DISCOVER
is defined to deal with replies from multiple responders.
As such, this document extend the core DNS specifications to allow
clients to have a method for coping with replies from multiple
responders. Use of this new opcode may facilitate DNS operations in
modern networking topologies. A prototype of the DISCOVER opcode
was developed as part of the TBDS project, funded under DARPA grant
F30602-99-1-0523.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-dnsext-opcode-discover-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-dnsext-opcode-discover-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-14133622.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-dnsext-opcode-discover-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-dnsext-opcode-discover-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-14133622.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:42 2006
From: Miek Gieben <miekg@atoom.net>
Subject: wildcard as empty non terminal
Date: Thu, 16 Oct 2003 14:25:18 +0200
Lines: 42
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 Oct 16 14:49:30 2003
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,

while reading the wildcard clarification draft and trying to implement it in
NSD, we had the following discussion.

The draft states:

2. Defining the Wild Card Domain Name

   A wild card domain name is defined by having the initial label be:

        0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

   This defines domain names that may play a role in being a wild card,
   that is, being a source for synthesized answers.  Domain names
   conforming to this definition that appear in queries and RDATA
   sections do not have any special role.  These cases will be described
   in more detail in following sections.

That is clear. In (to pick one) *.com, the '*' is a wildcard, in 
a.*.com the '*' is not a wildcard.

Next consider this:
we have a zone file with this:
	
	a.*.b		rdata

	(this implicitely defines *.b as an empty non terminal)

Next we get a query for x.y.b. Ok, we process the query, find the closest
encloser, which is .b. Then we look for *.b, now it does start with a '*' so it
has to be considered a wildcard.  So x.y.b will match on *.b?

Is this correct reasening? If not, where do we go wrong?

    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:42 2006
From: Mark.Andrews@isc.org
Subject: Re: wildcard as empty non terminal
Date: Thu, 16 Oct 2003 22:59:55 +1000
Lines: 55
Sender: owner-namedroppers@ops.ietf.org
References: <20031016122518.GB18170@atoom.net>
X-From: owner-namedroppers@ops.ietf.org Thu Oct 16 15:12:29 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers <namedroppers@ops.ietf.org>
Mail-Followup-To: namedroppers <namedroppers@ops.ietf.org> 
In-reply-to: Your message of "Thu, 16 Oct 2003 14:25:18 +0200."
             <20031016122518.GB18170@atoom.net> 
Precedence: bulk


> Hello,
> 
> while reading the wildcard clarification draft and trying to implement it in
> NSD, we had the following discussion.
> 
> The draft states:
> 
> 2. Defining the Wild Card Domain Name
> 
>    A wild card domain name is defined by having the initial label be:
> 
>         0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
> 
>    This defines domain names that may play a role in being a wild card,
>    that is, being a source for synthesized answers.  Domain names
>    conforming to this definition that appear in queries and RDATA
>    sections do not have any special role.  These cases will be described
>    in more detail in following sections.
> 
> That is clear. In (to pick one) *.com, the '*' is a wildcard, in 
> a.*.com the '*' is not a wildcard.
> 
> Next consider this:
> we have a zone file with this:
> 	
> 	a.*.b		rdata
> 
> 	(this implicitely defines *.b as an empty non terminal)
> 
> Next we get a query for x.y.b. Ok, we process the query, find the closest
> encloser, which is .b. Then we look for *.b, now it does start with a '*' so 
> it
> has to be considered a wildcard.  So x.y.b will match on *.b?

	Yes.
 
> Is this correct reasening? If not, where do we go wrong?
> 
>     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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: Miek Gieben <miekg@atoom.net>
Subject: Re: wildcard as empty non terminal
Date: Thu, 16 Oct 2003 15:35:42 +0200
Lines: 26
Sender: owner-namedroppers@ops.ietf.org
References: <20031016122518.GB18170@atoom.net> <200310161259.h9GCxt0o066602@bsdi.dv.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Thu Oct 16 15:47:34 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers <namedroppers@ops.ietf.org>
Mail-Followup-To: namedroppers <namedroppers@ops.ietf.org>
Content-Disposition: inline
In-Reply-To: <200310161259.h9GCxt0o066602@bsdi.dv.isc.org>
User-Agent: Vim/Mutt/Linux
X-Home: www.miek.nl
X-Virus-Scanned: by amavisd-new
Precedence: bulk

[On 16 Oct, @14:59, Mark.Andre wrote in "Re: wildcard as empty non term ..."]
> > Next consider this:
> > we have a zone file with this:
> > 	
> > 	a.*.b		rdata
> > 
> > 	(this implicitely defines *.b as an empty non terminal)
> > 
> > Next we get a query for x.y.b. Ok, we process the query, find the closest
> > encloser, which is .b. Then we look for *.b, now it does start with a '*' so 
> > it
> > has to be considered a wildcard.  So x.y.b will match on *.b?
> 
> 	Yes.
>  

ok, so a "lonely" '*' in a zonefile is always to be considered a wildcard,
only stuff like aba*.com does not qualify?

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:42 2006
From: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: wildcard as empty non terminal
Date: Thu, 16 Oct 2003 22:41:08 +0900
Lines: 30
Sender: owner-namedroppers@ops.ietf.org
References: <200310161259.h9GCxt0o066602@bsdi.dv.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: namedroppers <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Thu Oct 16 15:47:36 2003
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: Mark.Andrews@isc.org
In-Reply-To: <200310161259.h9GCxt0o066602@bsdi.dv.isc.org>
Precedence: bulk

Mark;

>>Next we get a query for x.y.b. Ok, we process the query, find the closest
>>encloser, which is .b. Then we look for *.b, now it does start with a '*' so 
>>it
>>has to be considered a wildcard.  So x.y.b will match on *.b?
> 
> 
> 	Yes.

I think it is a reasonable clarification following 4.3.2, even though
4.3.3 states:

: In the previous algorithm, special treatment was given to RRs with owner
: names starting with the label "*".  Such RRs are called wildcards.

4.3.3 should, instead, have stated

: In the previous algorithm, special treatment was given to owner names
: starting with the label "*".  Such owner names are called wildcards.

							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:42 2006
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: Document review: draft-brand-drip-02.txt
Date: Fri, 17 Oct 2003 22:54:20 -0400
Lines: 44
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: rsbx@acm.org, laurence@sherzer.net, ietf-drip-draft@spamblock.gamerz.net
X-From: owner-namedroppers@ops.ietf.org Sat Oct 18 05:17:48 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: namedroppers@ops.ietf.org
Precedence: bulk


This document has been submitted to the RFC editor for publication.
The IESG has asked the working group to comment on the DNS protocol aspects
of this document. This is one of the roles this working group has
in its charter.

The URI for the document is:
http://www.ietf.org/internet-drafts/draft-brand-drip-02.txt

 From ID announce message:
>         Title           : Designated Relays Inquiry Protocol (DRIP)
>         Author(s)       : R. Brand, L. Sherzer, R. W. Rognlie
>         Filename        : draft-brand-drip-02.txt
>         Pages           : 21
>         Date            : 2003-10-15
>
>The Designated Relays Inquiry Protocol, DRIP, is a method for domain
>name owners to specify the IP addresses that are authorized to relay
>mail as a domain name. The protocol provides a method for server MTAs
>to reject SMTP connections from IP addresses not authorized to use a
>domain name.


Please send in any comments/suggestions about the DNS aspects of
this draft. Any commentary about the applicability of what is described
in the document is out of scope for this discussion.

The document proposes both a new RR type and a naming convention for it,
the first is directly in scope of the working group, the second one
probably is outside the scope of the working group.
Given that the naming convention is closely tied to the structure of
the proposed RR type, we will allow discussion about both.

The DNSEXT chairs will summarize any comments/suggestions received
to the IESG.

         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:42 2006
From: Olafur Gudmundsson <ogud@ogud.com>
Subject: Re: wildcard as empty non terminal
Date: Sat, 18 Oct 2003 09:06:04 -0400 (EDT)
Lines: 53
Sender: owner-namedroppers@ops.ietf.org
References: <20031016122518.GB18170@atoom.net>
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 Oct 18 15:24:20 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: hlid.md.ogud.com: ogud owned process doing -bs
X-X-Sender: ogud@hlid.md.ogud.com
To: Miek Gieben <miekg@atoom.net>
In-Reply-To: <20031016122518.GB18170@atoom.net>
Precedence: bulk



On Thu, 16 Oct 2003, Miek Gieben wrote:

> Hello,
>
> while reading the wildcard clarification draft and trying to implement it in
> NSD, we had the following discussion.
>
> The draft states:
>
> 2. Defining the Wild Card Domain Name
>
>    A wild card domain name is defined by having the initial label be:
>
>         0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
>
>    This defines domain names that may play a role in being a wild card,
>    that is, being a source for synthesized answers.  Domain names
>    conforming to this definition that appear in queries and RDATA
>    sections do not have any special role.  These cases will be described
>    in more detail in following sections.
>
> That is clear. In (to pick one) *.com, the '*' is a wildcard, in
> a.*.com the '*' is not a wildcard.
>
> Next consider this:
> we have a zone file with this:
>
> 	a.*.b		rdata
>
> 	(this implicitely defines *.b as an empty non terminal)
>
> Next we get a query for x.y.b. Ok, we process the query, find the closest
> encloser, which is .b. Then we look for *.b, now it does start with a '*' so it
> has to be considered a wildcard.  So x.y.b will match on *.b?
>
> Is this correct reasening? If not, where do we go wrong?

</chair>
IMHO, wildcard algorigthm is only applicalble to terminal nodes in
the tree. your system should see that when it reaches node *.b that there
is a child node,or at least flag that this name has a child.

Thus the wildcard algorithm should be disabled for that *.b.

	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:42 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: wildcard as empty non terminal
Date: Sat, 18 Oct 2003 18:03:56 +0000
Lines: 12
Sender: owner-namedroppers@ops.ietf.org
References: <ogud@ogud.com>
X-From: owner-namedroppers@ops.ietf.org Sat Oct 18 20:23:47 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers <namedroppers@ops.ietf.org>
In-Reply-To: Message from Olafur Gudmundsson <ogud@ogud.com> 
	of "Sat, 18 Oct 2003 09:06:04 -0400."
	<20031018090310.Y14268@hlid.md.ogud.com> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> ... your system should see that when it reaches node *.b that there
> is a child node,or at least flag that this name has a child.
> 
> Thus the wildcard algorithm should be disabled for that *.b.

i agree.

--
to 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:42 2006
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: Re: Document review: draft-brand-drip-02.txt
Date: Sat, 18 Oct 2003 16:33:31 -0400
Lines: 37
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031016161952.0268eaa0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: rsbx@acm.org, laurence@sherzer.net, ietf-drip-draft@spamblock.gamerz.net
X-From: owner-namedroppers@ops.ietf.org Sat Oct 18 22:47:34 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>,
   namedroppers@ops.ietf.org
In-Reply-To: <6.0.0.22.2.20031016161952.0268eaa0@localhost>
References: <6.0.0.22.2.20031016161952.0268eaa0@localhost>
Precedence: bulk

At 22:54 2003-10-17, =D3lafur Gudmundsson/DNSEXT co-chair wrote:
<chair>

Correction:
>The document proposes both a new RR type and a naming convention for it,
>the first is directly in scope of the working group, the second one
>probably is outside the scope of the working group.
>Given that the naming convention is closely tied to the structure of
>the proposed RR type, we will allow discussion about both.

I made a mistake in my post.
Somehow I misread section 3.2 to mean it was defining ${TYPE}
as a new type. This document only defines a naming structure,
that uses A and AAAA records.

>The DNSEXT chairs will summarize any comments/suggestions received
>to the IESG.

We will close this review in 2 weeks.

         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/>


--
to 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:42 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: Any decision on wildcard CNAME ?
Date: Tue, 21 Oct 2003 13:34:06 +0200
Organization: RIPE NCC
Lines: 68
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: ogud@ogud.com
X-From: owner-namedroppers@ops.ietf.org Tue Oct 21 13:59:30 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <11723.1065903183@munnari.OZ.AU>
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.131299
X-RIPE-Signature: a2bf69b96a34dea516d4a7a2e14f26ac
Precedence: bulk



Namedroppers,

After being off-line for over a week I just had the time to review the
thread. 

Conclusion: The working group has consensus to modify wcard-clarify
to allow for CNAMEs with wildcards and

Process: This is a change to 1034. Even if it is only a clarification
it should stand out really clear. We can do two things, modify the
"wildcard clarify" document or spawn off a small I-D that documents
the change only.

Personally I have a preference for a small I-D, since there is
already consensus on the content it should be a trivial thing to get
through the WG. 

Any takers?


--Olaf




Summary of the discussion follows, no further comments in-line.

The thread started with an issue raised by Vixie.
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01818.html

The core of the problem is that the 1034 algorithm rules will not
allow for a CNAME chain to be followed at a wildcard node except for
when QTYPE=CNAME.  This creates an inconsistency for caching
forwarders: based on the query history (QTYPE has been CNAME or not)
the caching forwarder will give different answers.

After some discussion the consensus was reached that this problem needed
to be addressed.

Two possible solutions where presented and the working group was asked
to reach consensus on those.
(http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01853.html)


After the call by Elz (
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01895.html
) we had a number of people expressing a clear preference for allowing
CNAMEs to exist in combination with wildcards.



-- Olaf
   DNSEXT Co-Chair




---------------------------------| 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:42 2006
From: "Scott Rose" <scottr@nist.gov>
Subject: DNSSECbis algorithm mnemonics (cleanup fix)
Date: Tue, 21 Oct 2003 13:14:13 -0400
Lines: 29
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Tue Oct 21 19:37:32 2003
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

There is an error in the algorithm mnemonics in the current edition of the
DNSSECbis records draft (-04 I believe).

To bring the mnemonics back into line, they should be (and corrected back
to):

code     mnemonic
1        RSAMD5
2        DH
3        DSA
4        ECC
5        RSASHA1
252      PRIVATEDNS
253      PRIVATEOID

NOTE:  there is no previously assigned mnemonic for RSA with SHA1.
'RSASHA1' is in line with the RSAMD5, so it seems reasonable.

If no one has any objections, RSASHA1 will be the mnemonic from this point
on.  If there are, please state what the choice should be.

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/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: DNSEXT WGLC Summary: LLMNR
Date: Tue, 21 Oct 2003 15:24:04 -0400
Lines: 32
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 Tue Oct 21 21:39:34 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: namedroppers@ops.ietf.org
Precedence: bulk


This last call has concluded.
There was been extensive discussion about this draft.
A number of new issues raised and closed. The most new document
version (-24) reflects all the issues raised and closed in the
working group last call.

Summary: the working group has reached consensus to advance this
document as a standards track document.

This document is of high quality and the process that lead to this state
is well documented on the document issues
tracker website: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html.

Some issues raised during the last call that where rejected.  This is
normal and expected. This even holds for objections based on
shipping code tailored to an older version of this document, as no
specification is to be considered final until after publication as an RFC.
In particular there was extensive discussion about the TTL==[1 or 255]
in this case the WG decided that it had made the right choice by
selecting 1, see
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 47
http://psg.com/lists/namedroppers/namedroppers.2003/msg01609.html

         Olafur 


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: Joshua Graessley <jgraessley@apple.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Tue, 21 Oct 2003 13:53:51 -0700
Lines: 180
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031021103604.02697e50@localhost>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-415601979; protocol="application/pkcs7-signature"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Oct 21 23:10:02 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <6.0.0.22.2.20031021103604.02697e50@localhost>
To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk


--Apple-Mail-14-415601979
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed


Speaking as an individual (as is always the case at the IETF), not as a=20=

representative of Apple...

A brilliant move by the working group. My congratulations to those=20
involved. By refusing to interoperate to punish a vendor for shipping a=20=

product in a timely manner, the document this working group has=20
produced will now have to compete with that vendor. It's a good thing=20
the IETF exists to help fragment the market.

LLMNR as defined in draft 24 is useless in my opinion. In order to=20
satisfy everyone, compromises were made. So many compromises that the=20
protocol is nearly useless. I see no reason why any vendor would=20
implement it, it doesn't seem to solve any problems.

I am interested in a solution to the problem of ad-hoc networks. Two=20
people meet and use a cross over cable. LLMNR does not address that=20
scenario because there is no guidance on what name a device would have.=20=

While many on this working group are probably responsible for a domain=20=

or know someone who is, there are many people that use nothing but=20
dial-up and DSL. Many of those people have NATs, where their machines=20
have private addresses. Their computers don't really have a host name=20
they can call their own. In the ad-hoc scenario, such a user would have=20=

no idea what name to use for their laptop. For this reason, LLMNR does=20=

not address my needs for the ad-hoc solution.

I am is also interested in solutions to common home network problems.=20
The world is filled with NATs. Many people have a few machines at home=20=

with private addresses. Those machines don't have DNS names. When a=20
friend comes over with a laptop and plugs in, that friend gets an=20
address. The ability to use names in such a scenario would be a huge=20
benefit. As it is, that friend will get a configured DNS server address=20=

just like every other device on that network. LLMNR is next to useless=20=

at that point. If the laptop is configured to respond to a name such as=20=

joe.example.com, LLMNR will never query for that name because there is=20=

already a DNS name joe.example.com. The only name that would work with=20=

LLMNR is one that gives an error when sending the query to a normal DNS=20=

server. Maybe "joe." gives an error today. That might change in time.=20
Suddenly things stop working. The user has to come up with an easy to=20
remember name that will always fail when sent to DNS to get LLMNR to=20
work.

LLMNR could have been used for new devices introduced on the network.=20
Headless devices like ethernet cameras have complicated manuals for=20
configuring the device the first time. The manual usually requires the=20=

user to set their computer to an address in a specific subnet and then=20=

connect to the device at a specific address on that subnet. With LLMNR,=20=

the device could instead use DHCP or IPv4LL to acquire an address and=20
advertise the name with LLMNR. Configuration would be as simple as=20
launching a browser and typing in the LLMNR name of the device. What=20
LLMNR name could such a device use? It's not clear.

Using Apple's mDNS protocol, I have solutions to all three scenarios.=20
Using LLMNR, I don't have a solution to any of these scenarios. Why=20
would I pick LLMNR over mDNS?

With so many failure cases and no clear way to help a user configure=20
LLMNR, who would implement LLMNR and why?

As stated in the Introduction "The goal of LLMNR is to enable name=20
resolution in scenarios in which conventional DNS name resolution is=20
not possible.". I think LLMNR fails to meet this goal.

-josh

On Oct 21, 2003, at 12:24 PM, =D3lafur Gudmundsson/DNSEXT co-chair =
wrote:

>
> This last call has concluded.
> There was been extensive discussion about this draft.
> A number of new issues raised and closed. The most new document
> version (-24) reflects all the issues raised and closed in the
> working group last call.
>
> Summary: the working group has reached consensus to advance this
> document as a standards track document.
>
> This document is of high quality and the process that lead to this=20
> state
> is well documented on the document issues
> tracker website: =
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html.
>
> Some issues raised during the last call that where rejected.  This is
> normal and expected. This even holds for objections based on
> shipping code tailored to an older version of this document, as no
> specification is to be considered final until after publication as an=20=

> RFC.
> In particular there was extensive discussion about the TTL=3D=3D[1 or =
255]
> in this case the WG decided that it had made the right choice by
> selecting 1, see
> http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 47
> http://psg.com/lists/namedroppers/namedroppers.2003/msg01609.html
>
>         Olafur=20=

--Apple-Mail-14-415601979
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMTIwNTM1MVowIwYJKoZIhvcNAQkEMRYEFFMK
CjSCueM6mAKCRHkPu919RLq/MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAJ75
R28QezcOnsC1mFDzQRfrkrAeHPIbKYQeFlRC6TLoymyj9hN0JVTDj9SS4Nb1zuXbxDbRD4qN9QGZ
bWrRnYu0Jh5MDqJH/xzrgTv2S9vR237t+frgW/Ms2IeSjwsYVhTbQcDGk3hpqnqmO1Wc53WZKObN
kMk5XSso5L8oI6M9NSi8s//rOuc7+DWVrCF0LJyvmz2HHOsT5Q544RAq0wZ/PChoat0o0ZiezK9Q
kmYof9Ip8iKutfFLeF9ijqDVfUcj28O2HMUFB9ZdCuC4o4y8BfYWCOtAXFxqP/1LRhH1ao7NpBQu
vI158TxqH1Q9SrUigqh69yi0s+3gJ9FDeIoAAAAAAAA=

--Apple-Mail-14-415601979--


--
to 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:42 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Tue, 21 Oct 2003 21:15:24 +0000
Lines: 12
Sender: owner-namedroppers@ops.ietf.org
References: <jgraessley@apple.com>
X-From: owner-namedroppers@ops.ietf.org Tue Oct 21 23:24:54 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Joshua Graessley <jgraessley@apple.com> 
	of "Tue, 21 Oct 2003 13:53:51 MST."
	<ACEF6C00-0408-11D8-8EA7-000A95B9474C@apple.com> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

i have no comments for or against the quality of either the document or
the protocol for either mDNS or LLMNR.  however, i will echo one of
joshua's concerns, which is that the document that will be advanced
seems to be a compromise which will please nobody.  i very much wish
that there had been a design team, and community buy-in at the vision
level, rather than the fragmented market that will apparently now exist.

--
to 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:42 2006
From: itojun@itojun.org (Jun-ichiro itojun Hagino)
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 06:52:51 +0900 (JST)
Lines: 24
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031021103604.02697e50@localhost>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 22 00:08:26 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: ogud@ogud.com
In-Reply-To: Your message of "Tue, 21 Oct 2003 15:24:04 -0400"
	<6.0.0.22.2.20031021103604.02697e50@localhost>
X-Mailer: Cue version 0.6 (031002-0709/itojun)
Precedence: bulk

> This last call has concluded.
> There was been extensive discussion about this draft.
> A number of new issues raised and closed. The most new document
> version (-24) reflects all the issues raised and closed in the
> working group last call.
> 
> Summary: the working group has reached consensus to advance this
> document as a standards track document.
> 
> This document is of high quality and the process that lead to this state
> is well documented on the document issues
> tracker website: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html.

	document quality might be high, but if it does not interoperate with
	major implementation out there (i.e. Apple Rendezvous/mDNS) the
	document would be useless.

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:42 2006
From: Mark Baker <distobj@acm.org>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Tue, 21 Oct 2003 20:33:06 -0400
Lines: 23
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031021103604.02697e50@localhost> <20031021215251.70C2C91@coconut.itojun.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Wed Oct 22 02:44:52 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20031021215251.70C2C91@coconut.itojun.org>; from itojun@itojun.org on Wed, Oct 22, 2003 at 06:52:51AM +0900
Precedence: bulk

On Wed, Oct 22, 2003 at 06:52:51AM +0900, Jun-ichiro itojun Hagino wrote:
> 	document quality might be high, but if it does not interoperate with
> 	major implementation out there (i.e. Apple Rendezvous/mDNS) the
> 	document would be useless.

I concur.

I hope the WG appreciates what a mess it's creating.  Is the TTL issue
really *that* important?  I don't really know (I'm more an apps guy),
but the fact that the group has, at various times, held both positions,
suggests to me that it isn't.

Very disappointing ...

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

--
to 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:42 2006
From: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 09:37:24 +0900
Lines: 76
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031021103604.02697e50@localhost> <ACEF6C00-0408-11D8-8EA7-000A95B9474C@apple.com>
Mime-Version: 1.0
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 Wed Oct 22 02:45:27 2003
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: Joshua Graessley <jgraessley@apple.com>
In-Reply-To: <ACEF6C00-0408-11D8-8EA7-000A95B9474C@apple.com>
Precedence: bulk

Josh;

> A brilliant move by the working group. My congratulations to those 
> involved. By refusing to interoperate to punish a vendor for shipping a 
> product in a timely manner, the document this working group has produced 
> will now have to compete with that vendor. It's a good thing the IETF 
> exists to help fragment the market.
> 
> LLMNR as defined in draft 24 is useless in my opinion.

I tend to agree, but, with reasons different from yours.

If LLMNR is useless, it is not because of the way it was
standardized but because its purpose is meaningless.

> In order to 
> satisfy everyone, compromises were made. So many compromises that the 
> protocol is nearly useless. I see no reason why any vendor would 
> implement it, it doesn't seem to solve any problems.

Vendors, especially biggest ones, have been having no
trouble implementing useless protocols solving no
problems.

> I am interested in a solution to the problem of ad-hoc networks. Two 
> people meet and use a cross over cable. LLMNR does not address that 
> scenario because there is no guidance on what name a device would have. 
> While many on this working group are probably responsible for a domain 
> or know someone who is, there are many people that use nothing but 
> dial-up and DSL. Many of those people have NATs, where their machines 
> have private addresses. Their computers don't really have a host name 
> they can call their own. In the ad-hoc scenario, such a user would have 
> no idea what name to use for their laptop. For this reason, LLMNR does 
> not address my needs for the ad-hoc solution.

Wrong.

You can give a globally unique domain name for anything which
may or may not be connected to the Internet.

For example, a vendor can, at factory, assign its products globally
unique domain names such as:

	abcd1234.pc.apple.com

or

	abcd1234.camera.apple.com

which is no more difficult than assigning MAC addresses for NIC
cards. The vendor can, like NSI, even sell premium names.

Thus, you have no trouble to use the globally unique (no worrying
about name conflict) domain name in ad-hoc networks.

Of course, if we don't have access to DNS, we may have alternative
protocol, which may or may not be LLMNR.

> As stated in the Introduction "The goal of LLMNR is to enable name 
> resolution in scenarios in which conventional DNS name resolution is not 
> possible.". I think LLMNR fails to meet this goal.

I think it does, though I'm not sure the goal is meaningful.

						Masataka Ohta

PS

I'm not actively for or against LLMNR.


--
to 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:42 2006
From: Bernard Aboba <aboba@internaut.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Tue, 21 Oct 2003 19:10:48 -0700 (PDT)
Lines: 99
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 Oct 22 05:11:38 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Precedence: bulk

On Wed, Oct 22, 2003 Mark Baker said:

>I concur.

>I hope the WG appreciates what a mess it's creating.  Is the TTL issue
>really *that* important?

Yes, it is.

If there is one critical achievement that is most important about the
Internet it is the ability of hosts from different vendors to interoperate
with TCP/IP.  Today it is possible to take two hosts from almost
any TCP/IP implementation and do things like transfer files (FTP).  We've
gotten so used to doing this that at times we don't appreciate how
valuable this is -- or how easily this basic interoperability can be
broken.

Whatever else we do in the IETF, there is one thing that a specification
must never do -- that is to break the basic interoperability of TCP/IP.
If a new IETF specification can somehow make it impossible
for two hosts which formerly interoperated to transfer a file that
specification is fundamentally broken. It's one thing to create useless
specifications -- but it's another thing to break fundamental aspects
of the Internet architecture.  The most important task of any IETF WG is
to "do no harm".

There are times when a poorly designed protocol, if deployed on a small
scale,  will not be harmful, but when deployed on a wide scale, can have
large undesirable effects.  The standardization of such a protocol cannot
be justified purely on the basis of its immediate usefulness -- in fact it is
precisely those protocols that are thought to be most useful which can
create the biggest problems.  So the issue here is not 'why doesn't the
IETF bless this cool thing', but rather "what are the implications
if this 'cool thing' were to be ubiquitously deployed on the Internet?"
As IETF participants, we have the obligation to look beyond the short
term to the long-term implications.

The reality is that the early IPv4 Link-Local and mDNS specifications,
were they to be widely deployed, have the potential to do serious damage.

In IPv4 Link-Local, setting TTL=255 in IPv4 and testing for this breaks
basic TCP/IP interoperability.  Most IPv4 hosts today do not set TTL=255,
and therefore any IPv4 host which requires TTL=255 in received packets
will be unable to communicate with most existing hosts.  If a host with a
routable IPv4 address does not use this when available, and sets and tests
for TTL=255, then it is possible for two hosts which both have routable
addresses and formerly were able to communicate will be unable to talk to
each other.

This behavior was considered so problematic that when the IPv4 Link-Local
specification went to IETF last call, there was an outpouring of concern
about the consequences of its ill-considered design.  As a result, the
ZEROCONF WG has had to spend the last year rewriting the IPv4 Link-Local
specification so as to "do no harm".  The current specification no longer
mandates a test for a TTL value, and prefers a routable address when
available.  It is perhaps not as "useful" as the early versions -- but it
also does not break the basic interoperability of TCP/IP.

Similar considerations arose in the design of the LLMNR protocol.  In
order to "do no harm" it was necessary to avoid adding new saddlebags to
an old hourse -- such as trying to use DNS as a global service discovery
mechanism, as DNS-SD does. It's one thing to ship something like this on a
small proportion of Internet hosts -- but it's another thing entirely to
attempt deploy something like that on a global scale.  Making major
modifications to protocols that form the fundamental underpinings of the
Internet (such as DNS and BGP) is not just another "bad idea" -- it has
the potential to cause major problems with the Internet architecture.

The DNSEXT WG wisely decided that going down this road was inappropriate.
It also decided that to avoid the potential for multicast storms it was
necessary to restrict use of mDNS to link-scope.  Furthermore, it was
critical to enforce port and cache separation so that LLMNR could not be
used to pollute the DNS cache and vice versa.

To "do no harm" LLMNR needs to guarantee that it will come up with the
same answer to a query as DNS would if the RRs are available, so that in
normal use the results of a gethostbyname() call do not depend on which
mechanism is used.  To avoid leaking IPv4 Link-Local addresses beyond
their scope, it is necessary for LLMNR to only return addresses and
names valid on the interface on which the query was received and also
to preferrentially return routable addresses when they are available.
As the issues list shows, each of these issues resulted in changes being
made to the LLMNR specification that caused it to diverge from the early
mDNS specifications, but each change was carefully considered and thought through.
While LLMNR has been a journey of a thousand steps, it is far from a
random walk.

While many of these decisions made LLMNR somewhat less 'useful' -- at the
same time, they also made major problems less likely.  The  Internet is no
longer an experiment today -- it's mission-critical infrastructure that
millions of people rely on every day.  That implies a higher level of due
diligence.


--
to 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:42 2006
From: Joshua Graessley <jgraessley@apple.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 00:34:56 -0700
Lines: 232
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310211906450.14250@internaut.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-454067525; protocol="application/pkcs7-signature"
X-From: owner-namedroppers@ops.ietf.org Wed Oct 22 09:49:54 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <Pine.LNX.4.56.0310211906450.14250@internaut.com>
To: namedroppers@ops.ietf.org
X-Mailer: Apple Mail (2.606)
Precedence: bulk


--Apple-Mail-2-454067525
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

On Oct 21, 2003, at 7:10 PM, Bernard Aboba wrote:

> On Wed, Oct 22, 2003 Mark Baker said:
>
>> I concur.
>
>> I hope the WG appreciates what a mess it's creating.  Is the TTL issue
>> really *that* important?
>
> Yes, it is.
>
> If there is one critical achievement that is most important about the
> Internet it is the ability of hosts from different vendors to 
> interoperate
> with TCP/IP.  Today it is possible to take two hosts from almost
> any TCP/IP implementation and do things like transfer files (FTP).  
> We've
> gotten so used to doing this that at times we don't appreciate how
> valuable this is -- or how easily this basic interoperability can be
> broken.
>
> Whatever else we do in the IETF, there is one thing that a 
> specification
> must never do -- that is to break the basic interoperability of TCP/IP.
> If a new IETF specification can somehow make it impossible
> for two hosts which formerly interoperated to transfer a file that
> specification is fundamentally broken. It's one thing to create useless
> specifications -- but it's another thing to break fundamental aspects
> of the Internet architecture.  The most important task of any IETF WG 
> is
> to "do no harm".

At the end of the discussion listed for issue 2 "TTL=255 on send, check 
on receive?", the following suggests that the working group did not 
seem concerned with the issue of breaking things by using TTL 255.

"[BA] -

At IETF 56, the discussion seemed to indicate that sending with TTL=255
and checking on receipt would "do no harm" so that it was ok. The major
issues encountered in Zeroconf WG with IPv4LL don't seem to apply here,
since there are no legacy LLMNR implementations out there that set TTL 
to
something other than 255, so we have a clean slate. Also, even if the
IPv4LL draft doesn't specify setting or checking of TTL, an application
can still do so. So I'd like to recommend that we keep the existing -14
text that mandates setting TTL=255 and checking it."

I'm going to assume [BA] is short for Bernard Aboba.

I can find no argument on the issues page that TTL 255 would do harm. 
The first mention of using a TTL of 1 is in Issue 33: PTR via Unicast. 
That suggestion was that PTR queries be sent unicast and a TTL of 1 be 
used. Issue 34 "Unicast Query Transport Issues" suggests sending 
unicast queries using TCP and setting the TTL to 1. This isn't 
recommended because TTL 255 breaks anything, it is recommended in an 
attempt to make the responses more difficult to spoof.

The question of using some special domain such as ".local" surfaced a 
number of times. Use of a special domain such as dot-local would 
address many of the issues I brought up in my last email. The dot-local 
solution was always shot down with the response "use unqualified 
names". See issue #1. During the last call, Issue 45 was brought up, 
"Handling of Unqualified Names". The resolution was the removal of all 
references to unqualified names. The end result is no solution to Issue 
#1. A side effect of this is that Apple chose to use the top level 
domain 'local', being unable to get input other than "don't do that" 
from the working group. Instead of picking a domain that was likely to 
be unused and getting blessing so that everyone could coordinate and 
avoid using that domain, we picked a domain that was mostly unused and 
ran in to a few problems with sites that were using local as an 
internal domain. My impression is that the IETF exists to solve 
problems like that, not by ignoring them but by working through them.

The resolution to each of the LLMNR issues on their own may have made 
sense when only that issue was examined. The combination of the 
resolutions to each of these issues is a document that, while 
technically correct, has lost it's purpose.

I'm not sure what is to be done at this point. As one can see by 
reading the issues page 
<http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html>, the working 
group has spun on many of these issues a number of times. I do know 
that the draft, as it stands, is not useful.

> Similar considerations arose in the design of the LLMNR protocol.  In
> order to "do no harm" it was necessary to avoid adding new saddlebags 
> to
> an old hourse -- such as trying to use DNS as a global service 
> discovery
> mechanism, as DNS-SD does. It's one thing to ship something like this 
> on a
> small proportion of Internet hosts -- but it's another thing entirely 
> to
> attempt deploy something like that on a global scale.  Making major
> modifications to protocols that form the fundamental underpinings of 
> the
> Internet (such as DNS and BGP) is not just another "bad idea" -- it has
> the potential to cause major problems with the Internet architecture.
>
> The DNSEXT WG wisely decided that going down this road was 
> inappropriate.
> It also decided that to avoid the potential for multicast storms it was
> necessary to restrict use of mDNS to link-scope.  Furthermore, it was
> critical to enforce port and cache separation so that LLMNR could not 
> be
> used to pollute the DNS cache and vice versa.

I never made any mention of DNS-SD. I never suggested that we use 
multicast beyond the local link for mDNS. I'm not sure where the 
discussion about separation of caches came in to play. mDNS does a 
better job of keeping things separate. mDNS does not resolve any query 
unless the name ends in dot-local. An mDNS answer will not overwrite 
any DNS entry unless that DNS entry ends in dot-local.

> To "do no harm" LLMNR needs to guarantee that it will come up with the
> same answer to a query as DNS would if the RRs are available, so that 
> in
> normal use the results of a gethostbyname() call do not depend on which
> mechanism is used.  To avoid leaking IPv4 Link-Local addresses beyond
> their scope, it is necessary for LLMNR to only return addresses and
> names valid on the interface on which the query was received and also
> to preferrentially return routable addresses when they are available.
> As the issues list shows, each of these issues resulted in changes 
> being
> made to the LLMNR specification that caused it to diverge from the 
> early
> mDNS specifications, but each change was carefully considered and 
> thought through.

I'm not sure I follow. You say that it must "come up with the same 
answer to a query as DNS would". You also mention issues of leaking 
link-local addresses beyond their scope. Link-local addresses are not 
supposed to be in DNS records. In the case where LLMNR is used, it does 
make sense to respond with link-local addresses that are relevant on 
that network. That's precisely what mDNS does. mDNS doesn't pretend to 
attempt to give the same answers DNS would.

> While LLMNR has been a journey of a thousand steps, it is far from a
> random walk.
>
> While many of these decisions made LLMNR somewhat less 'useful' -- at 
> the
> same time, they also made major problems less likely.  The  Internet 
> is no
> longer an experiment today -- it's mission-critical infrastructure that
> millions of people rely on every day.  That implies a higher level of 
> due
> diligence.

Reading again through the list of issues and the resolutions, I don't 
see due diligence. I do see a pattern. The working group constantly 
goes back and forth on a number of issues, never really settling on one 
solution for very long. It seems more like the spec is what it is 
because it ended up in last call when it did. If we had gone on for 
another month or stopped a month earlier, who's to say it wouldn't be 
drastically different?

I don't know how to solve this problem. The same arguments will 
probably continue to play out. We could publish LLMNR as it is, and it 
would be largely useless. We could attempt to address some of the 
issues, but we might just get stuck spinning again. How do we solve 
this?

-josh


--Apple-Mail-2-454067525
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMjA3MzQ1N1owIwYJKoZIhvcNAQkEMRYEFHkx
StOyxJLloVYXwXfoy3+nn3cyMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAAzd
X5yjS2116141pbyf03sYIb4IkbMQM/0KzozAwxx61XVLO82fkJuyhj1pAXLDB9rVDTcoYZIulQcn
Tmq6o2mmWu/xgTtMLioIflMlil2hJ4zWNmGgunCBnV+G5f3/18A1b0LEpK+6kOaH3/G+5mpo08Sg
AsXBw3iDI/mgPyMtdamu3XhrqQ5cUGB8wq8eBq2+TVqZ91XBp6eKuhgCVCiuUS/XIClbZeer6g7Z
SyrZ8FALLnxW+3q6H5ze0nI0TySPGZlLPJI3ftl5EYWvntY5xXZ//fAIEmBg8KwvpxF88GufpKJ2
eLItLgXqWl/SbyWBJ3yk5e9rka/sjsADfGUAAAAAAAA=

--Apple-Mail-2-454067525--


--
to 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:42 2006
From: Bernard Aboba <aboba@internaut.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 09:04:11 -0700 (PDT)
Lines: 95
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 Oct 22 19:12:17 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Precedence: bulk

>At the end of the discussion listed for issue 2 "TTL=255 on send, check
>on receive?", the following suggests that the working group did not seem
>concerned with the issue of breaking things by using TTL 255.

It's worth understanding the history here.  The decision to set TTL=255
and check it on reception within mDNS was largely based on this same
technique being use in early IPv4 Link-Local versions.  However, doing
this in IPv4 Link-Local breaks TCP/IP interoperabilty and so the ZEROCONF
WG chose to overturn this.  Since the only existing hosts setting TTL=255
and checking it in mDNS are also doing this within IPv4 Link-Local, those
hosts are unable to communicate with the majority of existing TCP/IP
hosts.

It's not possible to achieve "backward compatibility" with an
implementation that is not interoperable with TCP/IP.  What use is it to
be able to resolve the name of a host that will drop all packets sent
to it because they don't have TTL=255?  That's just a recipe for user
frustration. If no real interoperability is achievable, then at least we
need to ensure that the separate flavors of TCP/IP do not interfere
with one another.  That's why LLMNR operates on a separate port and
multicast address than mDNS.

>The question of using some special domain such as ".local" surfaced a
>number of times. Use of a special domain such as dot-local would address
>many of the issues I brought up in my last email.

As detailed in Issue #22, this was extensively debated and no real
benefits were found to using the ".local" domain.  If two machines are
trying to communicate, one named erik.sun.com and another named
bernard.microsoft.com, then for names to be resolved it is
necessary to add ".local" to the searchlist, so that a query for
erik.sun.com.local can be made. But this just results in additional
packets on the wire for no real benefit.

>The resolution to each of the LLMNR issues on their own may have made
>sense when only that issue was examined. The combination of the
>resolutions to each of these issues is a document that, while technically
>correct, has lost it's purpose.

The "purpose" that you're referring to is service discovery, not name
resolution.  LLMNR focusses only on name resolution -- but since there was
never IETF consensus on use of mDNS for service discovery, it's hard to
argue that this purpose was "lost".  LLMNR *does* solve the link-scope
name resolution problem.

>I'm not sure what is to be done at this point. As one can see by reading
>the issues page <http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html>,
>the working group has spun on many of these issues a number of times.

It's true that there has been a lot of debate and reversal of positions. I
attribute this to a lack of an appreciation of the difficulties involved
in touching fundamental aspects of the Internet architecture -- IPv4 and
name resolution.  That kind of tinkering simply cannot proceed except with
extreme caution.  The early versions of the IPv4 Link-Local and mDNS
specifications did not exhibit the required due diligence. I fear we will
be dealing with the damage they created for years to come.

>In the case where LLMNR is used, it does make sense to
>respond with link-local addresses that are relevant on that network.

Sure, but not in preference to routable addresses if available.  In order
to "do no harm" it is necessary for two hosts with routable addresses to
be able to continue to interoperate with TCP/IP, even if they differ in
their implementation of IPv4 Link-Local.  For that to work, routable
addresses need to be preferred.

>That's precisely what mDNS does. mDNS doesn't pretend to attempt to give
>the same answers DNS would.

This causes breakage where the IPv4 Link-Local implementations are not
interoperable (as they are not today).

> If we had gone on for another month or stopped a month earlier, who's to
> say it wouldn't be drastically different?

Both the IPv4 Link-Local and LLMNR specifications have changed a lot in
the last year, but they have changed consistently as the result of a
better understanding of the problems caused by the early IPv4 LL and mDNS
specifications.  The consistent justification for the changes has been a
concern for maintaining basic TCP/IP interoperability, which is the
foundation of the Internet as we know it.

>We could attempt to address some of the issues, but we
>might just get stuck spinning again. How do we solve this?

If there were interest in a genuine solution, it would start by giving up
on the TTL=255 check in IPv4 Link-Local implementations, and preferring
routable addresses where available.  If that were done, at least basic
TCP/IP interoperability could be maintained.

--
to 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:42 2006
From: Joshua Graessley <jgraessley@apple.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 13:58:02 -0700
Lines: 242
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310220822010.28222@internaut.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-502252740; protocol="application/pkcs7-signature"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 22 23:12:50 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <Pine.LNX.4.56.0310220822010.28222@internaut.com>
To: Bernard Aboba <aboba@internaut.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk


--Apple-Mail-9-502252740
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


On Oct 22, 2003, at 9:04 AM, Bernard Aboba wrote:

>> At the end of the discussion listed for issue 2 "TTL=255 on send, 
>> check
>> on receive?", the following suggests that the working group did not 
>> seem
>> concerned with the issue of breaking things by using TTL 255.
>
> It's worth understanding the history here.  The decision to set TTL=255
> and check it on reception within mDNS was largely based on this same
> technique being use in early IPv4 Link-Local versions.  However, doing
> this in IPv4 Link-Local breaks TCP/IP interoperabilty and so the 
> ZEROCONF
> WG chose to overturn this.  Since the only existing hosts setting 
> TTL=255
> and checking it in mDNS are also doing this within IPv4 Link-Local, 
> those
> hosts are unable to communicate with the majority of existing TCP/IP
> hosts.

Part of that history is that the IPv4LL working group got this idea 
from IPv6 Neighbor Discovery. IPv6 Neighbor Discovery uses TTL 255. It 
is not encumbered with the need to interoperate with legacy clients. 
You said:

"At IETF 56, the discussion seemed to indicate that sending with TTL=255
and checking on receipt would "do no harm" so that it was ok. The major
issues encountered in Zeroconf WG with IPv4LL don't seem to apply here,
since there are no legacy LLMNR implementations out there that set TTL 
to
something other than 255, so we have a clean slate."

Mac OS X is not the only thing shipping with mDNS support. In addition, 
there is no problem with communicating with other hosts using TCP/IP 
whether or not an IPv4LL address is used. The check is not actually 
performed for IPv4LL traffic. I'm not sure why you keep bringing up 
IPv4LL.

> It's not possible to achieve "backward compatibility" with an
> implementation that is not interoperable with TCP/IP.  What use is it 
> to
> be able to resolve the name of a host that will drop all packets sent
> to it because they don't have TTL=255?  That's just a recipe for user
> frustration. If no real interoperability is achievable, then at least 
> we
> need to ensure that the separate flavors of TCP/IP do not interfere
> with one another.  That's why LLMNR operates on a separate port and
> multicast address than mDNS.

The interoperability problem lies in implementations of IPv4LL that 
check for TTL 255. This has nothing to do with LLMNR or mDNS. LLMNR and 
mDNS can be used wether the hosts have IPv4LL addresses or any other 
address (IPv4 or IPv6).

>> The question of using some special domain such as ".local" surfaced a
>> number of times. Use of a special domain such as dot-local would 
>> address
>> many of the issues I brought up in my last email.
>
> As detailed in Issue #22, this was extensively debated and no real
> benefits were found to using the ".local" domain.  If two machines are
> trying to communicate, one named erik.sun.com and another named
> bernard.microsoft.com, then for names to be resolved it is
> necessary to add ".local" to the searchlist, so that a query for
> erik.sun.com.local can be made. But this just results in additional
> packets on the wire for no real benefit.

You have hosts with names like erik.sun.com and bernard.microsoft.com, 
therefore, you see no benefit. If someone has a host with a private 
address, a very common scenario in homes and small offices thanks to 
the evils of NAT, their host has no name. They can't use LLMNR. 
Originally, it was proposed that people use unqualified names. As noted 
in Issue 45, there is no such thing as an unqualified name, so 
resolving unqualified names using LLMNR made no sense and was stripped 
out of the document. This is my major gripe with this document as it 
stands. My first email didn't even mention the TTL issue.

>> The resolution to each of the LLMNR issues on their own may have made
>> sense when only that issue was examined. The combination of the
>> resolutions to each of these issues is a document that, while 
>> technically
>> correct, has lost it's purpose.
>
> The "purpose" that you're referring to is service discovery, not name
> resolution.  LLMNR focusses only on name resolution -- but since there 
> was
> never IETF consensus on use of mDNS for service discovery, it's hard to
> argue that this purpose was "lost".  LLMNR *does* solve the link-scope
> name resolution problem.

When have I mentioned service discovery. None of the three examples I 
listed in the first email were related to service discovery. Masataka 
Ohta pointed out a solution to one of the three scenarios in his 
response. The other two have no solution with LLMNR. LLMNR doesn't 
solve name resolution in ad-hoc networks because there is no way that a 
host can know what name to use. LLMNR also fails in situations such as 
home networks were private addresses are used with a NAT. It would be 
convenient to use name resolution to look up the name of other hosts on 
the private network. There is no suggestion on what sorts of names a 
host on these networks should use to avoid conflicting with names in 
DNS.

>> I'm not sure what is to be done at this point. As one can see by 
>> reading
>> the issues page 
>> <http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html>,
>> the working group has spun on many of these issues a number of times.
>
> It's true that there has been a lot of debate and reversal of 
> positions. I
> attribute this to a lack of an appreciation of the difficulties 
> involved
> in touching fundamental aspects of the Internet architecture -- IPv4 
> and
> name resolution.  That kind of tinkering simply cannot proceed except 
> with
> extreme caution.  The early versions of the IPv4 Link-Local and mDNS
> specifications did not exhibit the required due diligence. I fear we 
> will
> be dealing with the damage they created for years to come.

I don't know why you keep going back to IPv4LL, that is irrelevant to 
LLMNR, except with respect to how such addresses should be handled when 
responding to an LLMNR query.

>> In the case where LLMNR is used, it does make sense to
>> respond with link-local addresses that are relevant on that network.
>
> Sure, but not in preference to routable addresses if available.  In 
> order
> to "do no harm" it is necessary for two hosts with routable addresses 
> to
> be able to continue to interoperate with TCP/IP, even if they differ in
> their implementation of IPv4 Link-Local.  For that to work, routable
> addresses need to be preferred.

I'm in complete agreement. I don't really know what this has to do with 
the usefulness of LLMNR or how it compares to mDNS.

>> That's precisely what mDNS does. mDNS doesn't pretend to attempt to 
>> give
>> the same answers DNS would.
>
> This causes breakage where the IPv4 Link-Local implementations are not
> interoperable (as they are not today).
>
>> If we had gone on for another month or stopped a month earlier, who's 
>> to
>> say it wouldn't be drastically different?
>
> Both the IPv4 Link-Local and LLMNR specifications have changed a lot in
> the last year, but they have changed consistently as the result of a
> better understanding of the problems caused by the early IPv4 LL and 
> mDNS
> specifications.  The consistent justification for the changes has been 
> a
> concern for maintaining basic TCP/IP interoperability, which is the
> foundation of the Internet as we know it.

LLMNR has nothing to do with TCP/IP interoperability. I don't know why 
you keep confusing the two issues. These are two separate issues. 
IPv4LL has nothing to do with this discussion.

>> We could attempt to address some of the issues, but we
>> might just get stuck spinning again. How do we solve this?
>
> If there were interest in a genuine solution, it would start by giving 
> up
> on the TTL=255 check in IPv4 Link-Local implementations, and preferring
> routable addresses where available.  If that were done, at least basic
> TCP/IP interoperability could be maintained.

Isn't this an issue for the zeroconf working group to tackle with the 
IPv4LL draft?

-josh
--Apple-Mail-9-502252740
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMjIwNTgwMlowIwYJKoZIhvcNAQkEMRYEFNXV
onSChE7rycxYK433osZS40saMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAEdQ
uNsN0t+Ml0kee/xrh6b+5mfSCIa0OSXXk+uDYJGtkaeYYMLutLqBYoudfrp3UCjyCvaZD+TN2iXy
sy3foovy0vY2Rl9YflLKd6B/3uATEan7lvgSae9ggB+2wWY2qBXA0xTXImGTgxcLgp6ulkx8lwq5
J7kzP4ROojdiLV4BGl+iPRNYIam3pkggQLYulMBj3JWa8jzPQTdk1lyaiZOVFWVoBXWkFk7onT1D
y7J412NtZtFwZmxMmNLk/Rv9kNncaA0cQ5Zq7WldxHWqAw7txaKlKrmpu2KGv9LPpNRivYXL6/1P
uWyenn32afpoCNZhDk3LH0/zaUQfixxBHYAAAAAAAAA=

--Apple-Mail-9-502252740--


--
to 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:42 2006
From: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Thu, 23 Oct 2003 07:42:44 +0900
Lines: 34
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310220822010.28222@internaut.com> <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bernard Aboba <aboba@internaut.com>,  namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 00:59:33 2003
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: Joshua Graessley <jgraessley@apple.com>
In-Reply-To: <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com>
Precedence: bulk

Joshua;

> When have I mentioned service discovery. None of the three examples I 
> listed in the first email were related to service discovery. Masataka 
> Ohta pointed out a solution to one of the three scenarios in his 
> response. The other two have no solution with LLMNR. LLMNR doesn't solve 
> name resolution in ad-hoc networks because there is no way that a host 
> can know what name to use.

What's wrong with a globally unique domain name configured at
factory?

> LLMNR also fails in situations such as home 
> networks were private addresses are used with a NAT. It would be 
> convenient to use name resolution to look up the name of other hosts on 
> the private network.

Can I assume that the only DHCP and the only DNS servers of the
home network is collocated on the NAT box?

Then, a host can tell its domain name to the box through DHCP
and the DNS server of the box can synthesis appropriate mapping.

That is, we don't need multicast.

						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:42 2006
From: Joshua Graessley <jgraessley@apple.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 15:56:29 -0700
Lines: 111
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310220822010.28222@internaut.com> <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> <3F9707E4.7020104@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-509359977; protocol="application/pkcs7-signature"
Cc: Bernard Aboba <aboba@internaut.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 01:07:36 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <3F9707E4.7020104@necom830.hpcl.titech.ac.jp>
To: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
X-Mailer: Apple Mail (2.606)
Precedence: bulk


--Apple-Mail-3-509359977
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


On Oct 22, 2003, at 3:42 PM, masataka ohta wrote:

> Joshua;
>
>> When have I mentioned service discovery. None of the three examples I 
>> listed in the first email were related to service discovery. Masataka 
>> Ohta pointed out a solution to one of the three scenarios in his 
>> response. The other two have no solution with LLMNR. LLMNR doesn't 
>> solve name resolution in ad-hoc networks because there is no way that 
>> a host can know what name to use.
>
> What's wrong with a globally unique domain name configured at
> factory?

I think the point of having a name is that it's easier to remember than 
an address. This is especially important when using IPv6LL addresses in 
an ad-hoc environment. Having to remember the name 
pbg4-b9-47-4c.names.apple.com would not be very useful. Being able to 
use a name like "joshs-powerbook" or "joshs-powerbook.llmnr." would 
make life simpler. Of course, this relies on good conflict detection, 
but a lot of that was stripped out of the document, assuming more that 
those who control the DNS name space will be responsible for handing 
out the names that are used with LLMNR.

>> LLMNR also fails in situations such as home networks were private 
>> addresses are used with a NAT. It would be convenient to use name 
>> resolution to look up the name of other hosts on the private network.
>
> Can I assume that the only DHCP and the only DNS servers of the
> home network is collocated on the NAT box?
>
> Then, a host can tell its domain name to the box through DHCP
> and the DNS server of the box can synthesis appropriate mapping.
>
> That is, we don't need multicast.

There are no NAT boxes, to the best of my knowledge, that do this 
today. If an implementation of LLMNR existed, and it was made to be 
useful in these scenarios, one could simply install LLMNR on the 
devices on the network without having to upgrade the NAT box.

Even if NAT boxes did this, what domain name would the host tell the 
box it has?

-josh
--Apple-Mail-3-509359977
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMjIyNTYyOVowIwYJKoZIhvcNAQkEMRYEFCiH
3gmXjL+88lRcQrk41Pbam8E6MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAA7d
HligrSjP+iC+3WpIu+Z7rpn6LQIXOJ5Qd+XCjSjx7pXrF7JJrn3zJ3T7LphRKOA1vDJGhkGCA215
cxjm9qIhnQd0KlOqzCotQ51ju7XmQf06EnvtXIU4uF0FAwzNDApcyKXB2ID3lWY0sH7NB8ufcd5k
McsMsUj2+vslebO/qyXmcH2nOGXGKSJr699fwgRf4CPZsIJRyZbvJ20EK9WMxqBVWebnk5yB+V6J
g9F48I8DlY9IjczSkZl65XUEP+k6sDFKnISMeELPBYq4MXI5JtJxAvNPdozkVrKhZ5b1ceLL7Zqx
Vv9P4APq6lXH8gAF9nC8Uf1TXcfZSDhMd74AAAAAAAA=

--Apple-Mail-3-509359977--


--
to 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:42 2006
From: Bernard Aboba <aboba@internaut.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 19:57:46 -0700 (PDT)
Lines: 56
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 Oct 23 05:48:25 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Precedence: bulk

>You have hosts with names like erik.sun.com and bernard.microsoft.com,
>therefore, you see no benefit. If someone has a host with a private
>address, a very common scenario in homes and small offices thanks to the
>evils of NAT, their host has no name.

Why does their host not have a name? The hostname need not be dependent on
the address.

> They can't use LLMNR.

Sure they can.  LLMNR doesn't care what the host's IP address is.

> LLMNR doesn't provide a way to name a host.

Why does a name resolution protocol need to take care of selection of host
names?  In many cases today the hostname is selected by the OEM and ships
with the PC or device.

> Originally, it was proposed that people use unqualified names.

In -24 LLMNR can be used to query any RR for any name.  So
there's no need to care about the definition of an "unqualified name".

>The interoperability problem lies in implementations of IPv4LL that check
>for TTL 255. This has nothing to do with LLMNR or mDNS.

It does, because it has been suggested that if LLMNR were to adopt
set TTL=255, check on reception, then interoperability would result. On
August 30, 2003 the DNSEXT WG Co-Chair Olaf Kolkman asked for a list of
*all* the changes that would be required beyond just the TTL change:

http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01628.html

To this day there has been no response to this question.  I believe it is
accurate to say that just making the TTL change would not generate any
useful interoperability scenarios, because an LLMNR responder still would
not respond to a query for a ".local" name.

Even if it were to do that (for backward compatibility sake), we *still*
wouldn't have interoperability if the LLMNR host also didn't implement
DNS-SD.  And even if it did that, we wouldn't have interoperability where
IPv4 Link-Local addresses were used unless the LLMNR host also set
TTL=255 on send.

Given this, it's hard for me to conclude that the requested TTL change
has any purpose beyond producing "PowerPoint interoperability" -- the
ability to claim conformance without real interoperability.

If this is wrong, please enlighten us with the details of what changes are
needed in order to achieve some useful level of interoperability.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: Ted Lemon <mellon@nominum.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 22:52:52 -0500
Lines: 42
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310221936260.2530@internaut.com>
Mime-Version: 1.0 (Apple Message framework v552)
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 Oct 23 05:59:26 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Bernard Aboba <aboba@internaut.com>
In-Reply-To: <Pine.LNX.4.56.0310221936260.2530@internaut.com>
X-Mailer: Apple Mail (2.552)
Precedence: bulk

On Wednesday, October 22, 2003, at 09:57  PM, Bernard Aboba wrote:
> Why does their host not have a name? The hostname need not be 
> dependent on
> the address.

My computer's name right now is "mdzadpa".   When I got it, it didn't 
have a name.   It chose a name when I customized it - the name it chose 
was "Ted Lemon's Computer".   This is very like what Microsoft's own 
software does, although I think it would have chosen the name 
"TEDLEMON".

Now, how does my computer go from here to having a fully-qualified 
name?   I bought it to use at home.   It doesn't belong to my employer. 
   It's not "mdzadpa.nominum.com."   It doesn't belong to my ISP.   It's 
not "mdzadpa.speakeasy.net."  For the average user, this is not going 
to change.   It really doesn't make sense for the computer to identify 
itself as either of the two fully-qualified names I just suggested, 
and, indeed, my ISP wouldn't let me identify my computer that way.

So for my computer to go around claiming to be "mdzadpa.speakeasy.net." 
would be incorrect behavior.   That is not its name.   This is true 
whether my computer is a Mac or a PC.   Unix machines, maybe less true. 
   Linux, I don't know.   Cell phones, all bets are off.   But for the 
vast majority of the computers that are presently connected to the 
network and that could benefit from LLMNR, there is no correct FQDN to 
assign them.   So if you don't have a rule for producing an FQDN based 
on the unqualified name the user chose, that computer simply is not 
going to be able to identify itself using LLMNR.   This means that 
LLMNR is effectively useless for the vast majority of all computers on 
which it's ever likely to be implemented, unless the LLMNR 
implementation does something extra-protocular to generate an FQDN.

Perhaps the right thing is to specify the protocol by which this name 
is derived separately, but if so, we should say that that's the answer, 
not pretend that the problem need not be solved.


--
to 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:42 2006
From: Bernard Aboba <aboba@internaut.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Wed, 22 Oct 2003 21:02:09 -0700 (PDT)
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 06:47:59 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Ted Lemon <mellon@nominum.com>
In-Reply-To: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com>
Precedence: bulk

> that computer simply is not going to be able to identify itself using
> LLMNR.

I'm not sure how you conclude this.  LLMNR doesn't care whether the
name is an FQDN or not.  If you type "ping tedlemon" then the host will
send an LLMNR query for "tedlemon".  If you type "ping
tedlemon.nominum.com" then if the configured DNS server doesn't answer the
query or responds with "no such name" then an LLMNR query will be sent for
"tedlemon.nominum.com"

> implementation does something extra-protocular to generate an FQDN.

Nope. LLMNR can send a query for any name.

> Perhaps the right thing is to specify the protocol by which this name
> is derived separately, but if so, we should say that that's the answer,

All LLMNR needs to work is for a responder to have a name, any name. If it
hears a query for that name, it will respond.

--
to 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:42 2006
From: Mika Liljeberg <mika.liljeberg@welho.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Thu, 23 Oct 2003 13:37:09 +0300
Lines: 69
Sender: owner-namedroppers@ops.ietf.org
References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com>
	 <Pine.LNX.4.56.0310222057050.7108@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: Ted Lemon <mellon@nominum.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 12:53:51 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Bernard Aboba <aboba@internaut.com>
In-Reply-To: <Pine.LNX.4.56.0310222057050.7108@internaut.com>
X-Mailer: Ximian Evolution 1.4.5 
Precedence: bulk

I have to say that, to some extent, I share Joshua's concern with regard
to naming devices in an ad-hoc fashion. While it is true that LLMNR can
be used to query any name, the implicit assumption seems to be that the
naming must be consistent with DNS. 

In ad-hoc scenarios users need to be able to nickname their devices with
something that is easy to type and remember (and fits on a single line
on a cell phone display, for instance). Users like simple names such as
"phone", "headset", "pc", or "vcr". It's not acceptable to have
something like "mdzadpa". Who can remember that? In case of conflict, I
might want to use a longer name like "phone.mika". So instead of having
a single nickname my device might have multiple nicknames.

How could I resolve the inevitable conflict using LLMNR? In real life
users deal with naming conflicts all the time and think nothing of it.
People sometimes have the same first names, so we qualify what we mean
by adding a surname or narrow the context in some other manner. Suppose
Ted's phone also has names like "phone" and "phone.ted". My query for
"phone" returns IP addresses for both my phone and Ted's phone. Since I
got responses from more than one device a conflict has occurred. My
application might try to resolve this by doing a reverse query for both
IP addresses and receive the names "phone.mika" and "phone.ted" (or it
might use some other protocol to get a better description of each
device), which in turn would be presented to me in a selection dialog. I
would then be able to qualify which one I meant by selecting one of the
presented choises.

There are various ways to implement the above but it seems clear to me
that we can't do something like this in a manner that will satisfy the
users if the naming is required to be consistent with DNS. Being able to
pick any name you want is important. That being the case, I can see a
need for a reserved TLD name for ad-hoc use, guaranteed never to appear
in the global DNS. That doesn't mean LLMNR should not respond to queries
for its DNS names as well. It just means that the names picked by the
users themselves would be placed in a separate name space.

	MikaL

On Thu, 2003-10-23 at 07:02, Bernard Aboba wrote:
> > that computer simply is not going to be able to identify itself using
> > LLMNR.
> 
> I'm not sure how you conclude this.  LLMNR doesn't care whether the
> name is an FQDN or not.  If you type "ping tedlemon" then the host will
> send an LLMNR query for "tedlemon".  If you type "ping
> tedlemon.nominum.com" then if the configured DNS server doesn't answer the
> query or responds with "no such name" then an LLMNR query will be sent for
> "tedlemon.nominum.com"
> 
> > implementation does something extra-protocular to generate an FQDN.
> 
> Nope. LLMNR can send a query for any name.
> 
> > Perhaps the right thing is to specify the protocol by which this name
> > is derived separately, but if so, we should say that that's the answer,
> 
> All LLMNR needs to work is for a responder to have a name, any name. If it
> hears a query for that name, it will respond.
> 
> --
> to 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:42 2006
From: "Eric A. Hall" <ehall@ehsco.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Thu, 23 Oct 2003 08:58:25 -0500
Lines: 27
Sender: owner-namedroppers@ops.ietf.org
References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com>	 <Pine.LNX.4.56.0310222057050.7108@internaut.com> <1066905429.798.88.camel@hades>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: Bernard Aboba <aboba@internaut.com>, Ted Lemon <mellon@nominum.com>, 
 namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 16:14:13 2003
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-US,en
To: Mika Liljeberg <mika.liljeberg@welho.com>
In-Reply-To: <1066905429.798.88.camel@hades>
Precedence: bulk


on 10/23/2003 5:37 AM Mika Liljeberg wrote:

> There are various ways to implement the above but it seems clear to me
> that we can't do something like this in a manner that will satisfy the
> users if the naming is required to be consistent with DNS.

Well, since there are various ways to do it, there's no real restriction
or requirement. An RR with an owner name of the device and textual data
would provide friendly long names indexed to short (DNS) names. Having the
systems include these RRs in the ~authority section of the question
message would provide the advertisement and collision detection
mechanisms. Due to the absence of an authoritative delegation hierarchy
(this includes the absence of a .local, but also includes the absence of
naming authority at the leaf-node), the short names must be kept separate
from "real" DNS names anyway.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/


--
to 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:42 2006
From: Bernard Aboba <aboba@internaut.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Thu, 23 Oct 2003 07:03:26 -0700 (PDT)
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> 
 <Pine.LNX.4.56.0310222057050.7108@internaut.com> <1066905429.798.88.camel@hades>
 <3F97DE81.2060100@ehsco.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 16:50:17 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <3F97DE81.2060100@ehsco.com>
Precedence: bulk

> There are various ways to implement the above but it seems clear to me
> that we can't do something like this in a manner that will satisfy the
> users if the naming is required to be consistent with DNS.

There's no requirement that an LLMNR responder register its name in DNS;
however, if it does, then it will also respond to LLMNR queries for
the name it registers.  An LLMNR responder can choose to respond to the
name "joe" or "joe.example.com".

In terms of *attributes* of the host, such as a "friendly description", an
icon, a sound, etc. these are all orthogonal issues to name resolution.
Service discovery protocols (including uPnP, SLPv2, etc.) are typically
extensible and can provide this kind of richness.  There is no need
to overload DNS to handle this.  If the desire is merely to discover
services and present them on the desktop in a pleasing way, I'd argue
that name resolution is not required.  Send a service discovery query,
collate the results (which can include a naming attribute, by the way)
and display them.  If anything, the problem is that we have too many
protocols that can handle this.

--
to 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:42 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: Any decision on wildcard CNAME ?
Date: Thu, 23 Oct 2003 17:35:05 +0200
Organization: RIPE NCC
Lines: 32
Sender: owner-namedroppers@ops.ietf.org
References: <11723.1065903183@munnari.OZ.AU>
	<20031021133406.7a9bc890.olaf@ripe.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: ogud@ogud.com
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 17:55:01 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20031021133406.7a9bc890.olaf@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.051619
X-RIPE-Signature: 1eb5d0b444963061ebd74dbaf1d402bc
Precedence: bulk


namedroppers,

I recently wrote:
> Personally I have a preference for a small I-D, since there is
> already consensus on the content it should be a trivial thing to get
> through the WG. 
> 
> Any takers?
> 

Putting money where my mouth is but missing the 'initial submission
deadline' I have something ready to be published shortly after the
IETF.

If you want to read and comment upon it:
http://www.ripe.net/DISI/Notes/draft-kolkman-wcard-cname-processing-00.html
or alternatively
http://www.ripe.net/DISI/Notes/draft-kolkman-wcard-cname-processing-00.txt


-- 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:42 2006
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Thu, 23 Oct 2003 13:17:22 -0400
Lines: 66
Sender: owner-namedroppers@ops.ietf.org
References: <3F97DE81.2060100@ehsco.com>
 <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com>
 <Pine.LNX.4.56.0310222057050.7108@internaut.com>
 <1066905429.798.88.camel@hades>
 <3F97DE81.2060100@ehsco.com> <Pine.LNX.4.56.0310230652360.9581@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 19:36:13 2003
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.0310230652360.9581@internaut.com>
References: <3F97DE81.2060100@ehsco.com>
 <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com>
 <Pine.LNX.4.56.0310222057050.7108@internaut.com>
 <1066905429.798.88.camel@hades>
 <3F97DE81.2060100@ehsco.com>
Precedence: bulk

I've been reviewing draft-ietf-dnsext-mdns-24.txt, and I found that I don't
think I would know how to implement LLMNR based on this document.  In
particular, the description of some terms like hostname, current domain, as
well as the behavior of senders and responders regarding unqualified names,
needs to be clarified.

One problem I have is the ambiguity between current host implementations of
these concepts and the way the terms are used in the document.  I think it
would be useful to give concrete, implementation-independent definitions of
the following terms in the terminology section:

hostname - in section 2.2, the third paragraph begins with the sentence: 'As
an example, a computer "host.example.com." ...'  I don't know what this
means in an implementation; is this a configured character string or a
one-component name with the current domain appended or ???  I suggest that
something like "hostname" be defined and used throughout the document for
clarity.

current domain - in section 3.1, the first item in the implicit search order
is "...the name with the current domain appended".  What, exactly, is the
"current domain"?  Is it the domain search list?  I don't think that term is
defined in RFC 1536, which is given as a reference to the list.

authoritative - this term seems to be used in a different way than in DNS,
and is defined by example rather than by a sentence or phrase

owned by - in the fifth paragraph of section 2.2, what are "RRSets owned by
the host"?

(other DNS terms) - it might be good to say something in section 1.2 to the
effect of "Other terminology from DNS is defined in RFC 1034 or RFC 1035
(whichever is appropriate).  In fact, it might be good to explicitly state
that the reader should be familiar with the concepts from DNS in RFC 1034
and RFC 1035.

Regarding unqualified names, I'm trying to relate the protocol described in
draft-ietf-dnsext-mdns-24.txt to the scenario I imagine I would use at home,
where I have a couple of computers using private addressing behind NAT,
which are configured with a list of DNS recursive name servers through DHCP.
  Each computer is configured with an unqualified name, say "den" and
"laptop" and does not have a domain search list.  I'd like to be able to be
able to enter, for example, http://den/some-random-page.html

So, the target of this URL is configured with the unqualified name "den".
The sender presumably first sends a request to the each of the DNS servers
in the configured list of servers, and gets no response or a negative
response.  According to section 3.1, the sender skips step 1 (no current
domain or domain search list configured) and sends a request for the name
with the root domain appended: "den."  If the target is configured with the
unqualified name "den", does it also respond to requests for the name
"den."?  Or, does the hostname always have to be a FQDN, so that if the user
enters "den" as the "computer name", the hostname is then "den."?

By the way, I found the description (section 3, first para) of when to use
LLMNR to be confusing.  Could that description be rewritten as a list of
conditions or steps to take?


- 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:42 2006
From: Joshua Graessley <jgraessley@apple.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Thu, 23 Oct 2003 10:44:52 -0700
Lines: 114
Sender: owner-namedroppers@ops.ietf.org
References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> <Pine.LNX.4.56.0310222057050.7108@internaut.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-577062929; protocol="application/pkcs7-signature"
X-From: owner-namedroppers@ops.ietf.org Thu Oct 23 19:58:10 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <Pine.LNX.4.56.0310222057050.7108@internaut.com>
To: namedroppers@ops.ietf.org
X-Mailer: Apple Mail (2.606)
Precedence: bulk


--Apple-Mail-8-577062929
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


On Oct 22, 2003, at 9:02 PM, Bernard Aboba wrote:

>> that computer simply is not going to be able to identify itself using
>> LLMNR.
>
> I'm not sure how you conclude this.  LLMNR doesn't care whether the
> name is an FQDN or not.  If you type "ping tedlemon" then the host will
> send an LLMNR query for "tedlemon".  If you type "ping
> tedlemon.nominum.com" then if the configured DNS server doesn't answer 
> the
> query or responds with "no such name" then an LLMNR query will be sent 
> for
> "tedlemon.nominum.com"

This is only true if the computer performing the lookup doesn't have a 
list of search domains or there is no tedlemon.<search domain(s) here>. 
Example: User has DSL and NAT. Their ISP has told them to use the 
search domain example.net and use "mail" as the mail server name. This 
is a really stupid way to set things up, but it is fairly common. There 
exists a tedlemon.example.net. Ted Lemon visits, and hooks up his 
laptop. He's using the name "tedlemon". He tells Joe to connect to his 
web server (http://tedlemon/). Joe types it in, hits return. Joe gets a 
connection error because tedlemon.example.net resolved and isn't 
running a web server. Joe can not use a name to access Ted Lemon's 
computer.

>> implementation does something extra-protocular to generate an FQDN.
>
> Nope. LLMNR can send a query for any name.

LLMNR _can_ send a query for any name. It is not likely to send a query 
for most names unless DNS is available. When a DNS server is available, 
a user will be unable to determine which names can be used with LLMNR 
and which names can not. What works in one situation may not work in 
another.

>> Perhaps the right thing is to specify the protocol by which this name
>> is derived separately, but if so, we should say that that's the 
>> answer,
>
> All LLMNR needs to work is for a responder to have a name, any name. 
> If it
> hears a query for that name, it will respond.

There's no point in listening for a name if no one will ever us LLMNR 
to ask for it.

-josh
--Apple-Mail-8-577062929
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMzE3NDQ1MlowIwYJKoZIhvcNAQkEMRYEFM0P
QJnRXDK4J/RZJK0+lkdm+wReMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAM2z
BpA1SpXfuEIrnv53vB8exUYRuHzvvqqSHrq9PWCTji03MpUFHojvi21onFVf1LrWrxxeQuFXErWj
QyAY7+Oqw2vAflAvvM3omw5pPw0dscb89oqDJZHkLwvdZK1q/xYUv83IKcxdrgbar+cwj4E3S6P1
x3GWTPIxJ4efVoIEwaxxhw+mje7ko1oBYIOoScUoxg87pV+8TLJapuf8BM8lHB6QfVdGkDaAs0Ny
njgstNwk2G/mypRsnwrpYqE/1OTtACEe/RwXZwkOHGgqREVKiNWNq7dOCWrZysC0tqYFCxsLJyjT
alpR5+/ibLEE6JKDlfXpZHws5R6/kIf644IAAAAAAAA=

--Apple-Mail-8-577062929--


--
to 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:42 2006
From: Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au>
Subject: Draft: non-wildcard bit.
Date: Thu, 23 Oct 2003 22:38:18 +0200 (CEST)
Lines: 32
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 Oct 23 22:59:29 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: bc@x53.ripe.net
To: namedroppers@ops.ietf.org
X-RIPE-Spam-Level: 
X-RIPE-Spam-Status: N 0.384122
X-RIPE-Signature: bd60467677fc2e959809a834d6f7fe30
Precedence: bulk


With all the fuss on the unannounced addition of a wildcard record to the
.com and .net zones, it is obvious that many applications need a clear and
reliable method of knowing whether a response is 'real', or whether it has
been synthesised.

I'd like to put forward the following draft (submitted before the
deadline, but currently in rfc-editor pre-meeting limbo) as _a_ solution
to this problem, and see any on-list discussion on this solution before
Minnie.

   http://www.ripe.net/home/bruce/draft-bcampbell-dns-non-wildcard-00.txt

   This document intends to describe a method of detecting the presence
   of a synthesised answer to a DNS query by the usage of a flag bit.
   It also suggests that the same flag be used to request that a
   synthesised answer not be returned.

Note that 'flag bit' would either be the currently reserved header bit 9,
or an EDNS option.

-- 
                             Bruce Campbell         I speak for myself.

( Of course, a perhaps far better, solution would be to have the zones
  signed and widespread deployment of DNSSEC-aware resolvers. )

--
to 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:42 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Draft: non-wildcard bit.
Date: Thu, 23 Oct 2003 21:58:56 +0000
Lines: 12
Sender: owner-namedroppers@ops.ietf.org
References: <bc-namedroppers@vicious.dropbear.id.au>
X-From: owner-namedroppers@ops.ietf.org Fri Oct 24 00:11:53 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au> 
	of "Thu, 23 Oct 2003 22:38:18 +0200."
	<Pine.LNX.4.58.0310232205460.25722@x53.ripe.net> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> With all the fuss on the unannounced addition of a wildcard record to the
> .com and .net zones, it is obvious that many applications need a clear and
> reliable method of knowing whether a response is 'real', or whether it has
> been synthesised.

that's not obvious at all.

--
to 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:42 2006
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: Draft: non-wildcard bit.
Date: 23 Oct 2003 22:45:11 -0000
Lines: 17
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.58.0310232205460.25722@x53.ripe.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Fri Oct 24 00:54:31 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
Precedence: bulk

Bruce Campbell writes:
> With all the fuss on the unannounced addition of a wildcard record to the
> .com and .net zones, it is obvious that many applications need a clear and
> reliable method of knowing whether a response is 'real'

Exactly which applications are you talking about? What exactly is the
definition of a ``real'' DNS record? What exactly do you want these
applications to do with non-``real'' records?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:42 2006
From: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Fri, 24 Oct 2003 08:56:27 +0900
Lines: 60
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310220822010.28222@internaut.com> <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> <3F9707E4.7020104@necom830.hpcl.titech.ac.jp> <F90EB21F-04E2-11D8-B5ED-000A95B9474C@apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bernard Aboba <aboba@internaut.com>,  namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 24 02:07:46 2003
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: Joshua Graessley <jgraessley@apple.com>
In-Reply-To: <F90EB21F-04E2-11D8-B5ED-000A95B9474C@apple.com>
Precedence: bulk

Josh;

>>> When have I mentioned service discovery. None of the three examples I 
>>> listed in the first email were related to service discovery. Masataka 
>>> Ohta pointed out a solution to one of the three scenarios in his 
>>> response. The other two have no solution with LLMNR. LLMNR doesn't 
>>> solve name resolution in ad-hoc networks because there is no way that 
>>> a host can know what name to use.

>> What's wrong with a globally unique domain name configured at
>> factory?

> I think the point of having a name is that it's easier to remember than 
> an address. This is especially important when using IPv6LL addresses in 
> an ad-hoc environment. Having to remember the name 
> pbg4-b9-47-4c.names.apple.com would not be very useful.

No, it is not, though your example is only as bad as raw IPv4
addresses. Wise vendors will use names more friendly to users.

> Being able to 
> use a name like "joshs-powerbook" or "joshs-powerbook.llmnr." would make 
> life simpler. Of course, this relies on good conflict detection,

What can you do if there is a conflict on "joshs-camera"? Note
that cameras have no keyboard.

Note also that a vendor can configure a camera of a registere
user as:

	"camera0.josh-12.apple.com"

>> Can I assume that the only DHCP and the only DNS servers of the
>> home network is collocated on the NAT box?
>>
>> Then, a host can tell its domain name to the box through DHCP
>> and the DNS server of the box can synthesis appropriate mapping.
>>
>> That is, we don't need multicast.

> There are no NAT boxes, to the best of my knowledge, that do this today.

Tell NAT box vendors to do so, then.

That NAT boxes do or do not do something is not a valid reasoning
to affect protocol development over the Internet.
 
> Even if NAT boxes did this, what domain name would the host tell the box 
> it has?

See above.

							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:42 2006
From: Bernard Aboba <aboba@internaut.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Thu, 23 Oct 2003 21:10:21 -0700 (PDT)
Lines: 34
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310220822010.28222@internaut.com>
 <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> <3F9707E4.7020104@necom830.hpcl.titech.ac.jp>
 <F90EB21F-04E2-11D8-B5ED-000A95B9474C@apple.com> <3F986AAB.3030006@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Fri Oct 24 07:05:19 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <3F986AAB.3030006@necom830.hpcl.titech.ac.jp>
Precedence: bulk

>This is only true if the computer performing the lookup doesn't have a
>list of search domains or there is no tedlemon.<search domain(s) here>.
>Example: User has DSL and NAT. Their ISP has told them to use the search
>domain example.net and use "mail" as the mail server name. This is a
>really stupid way to set things up, but it is fairly common. There exists
>a tedlemon.example.net. Ted Lemon visits, and hooks up his laptop. He's
>using the name "tedlemon". He tells Joe to connect to his web server
>(http://tedlemon/). Joe types it in, hits return. Joe gets a connection
>error because tedlemon.example.net resolved and isn't running a web
>server. Joe can not use a name to access Ted Lemon's computer.

Nope.  LLMNR was explicitly designed to work in this scenario. Section 3
says:

"By default, LLMNR requests SHOULD be sent only when no manual or
automatic DNS configuration has been performed, when DNS servers do not respond, or
when they respond to a query with RCODE=3 (Authoritative Name Error) or
RCODE=0, and an empty answer section."

Also:

"[1] If a DNS query does not receive a response, prior to falling
    back to LLMNR, the query SHOULD be retransmitted at least
    once.

So the LLMNR sender would try "tedlemon.example.net" and would get back
and error and then it would fall back to an LLMNR query for "tedlemon"
eventually.

--
to 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:42 2006
From: Chris Yarnell <namedroppers-in@kooks.net>
Subject: Re: Draft: non-wildcard bit.
Date: Thu, 23 Oct 2003 22:22:22 -0700 (PDT)
Lines: 10
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.58.0310232205460.25722@x53.ripe.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 24 07:30:58 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au>
In-Reply-To: <Pine.LNX.4.58.0310232205460.25722@x53.ripe.net>
Precedence: bulk

> .com and .net zones, it is obvious that many applications need a clear and
> reliable method of knowing whether a response is 'real', or whether it has

it is?  please explain.

--
to 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:42 2006
From: Joshua Graessley <jgraessley@apple.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Thu, 23 Oct 2003 23:24:09 -0700
Lines: 109
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310220822010.28222@internaut.com> <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> <3F9707E4.7020104@necom830.hpcl.titech.ac.jp> <F90EB21F-04E2-11D8-B5ED-000A95B9474C@apple.com> <3F986AAB.3030006@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.56.0310232008220.23077@internaut.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17-622619927; protocol="application/pkcs7-signature"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 24 08:32:18 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <Pine.LNX.4.56.0310232008220.23077@internaut.com>
To: Bernard Aboba <aboba@internaut.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk


--Apple-Mail-17-622619927
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


On Oct 23, 2003, at 9:10 PM, Bernard Aboba wrote:

>> This is only true if the computer performing the lookup doesn't have a
>> list of search domains or there is no tedlemon.<search domain(s) 
>> here>.
>> Example: User has DSL and NAT. Their ISP has told them to use the 
>> search
>> domain example.net and use "mail" as the mail server name. This is a
>> really stupid way to set things up, but it is fairly common. There 
>> exists
>> a tedlemon.example.net. Ted Lemon visits, and hooks up his laptop. 
>> He's
>> using the name "tedlemon". He tells Joe to connect to his web server
>> (http://tedlemon/). Joe types it in, hits return. Joe gets a 
>> connection
>> error because tedlemon.example.net resolved and isn't running a web
>> server. Joe can not use a name to access Ted Lemon's computer.
>
> Nope.  LLMNR was explicitly designed to work in this scenario. Section 
> 3
> says:
>
> "By default, LLMNR requests SHOULD be sent only when no manual or
> automatic DNS configuration has been performed, when DNS servers do 
> not respond, or
> when they respond to a query with RCODE=3 (Authoritative Name Error) or
> RCODE=0, and an empty answer section."
>
> Also:
>
> "[1] If a DNS query does not receive a response, prior to falling
>     back to LLMNR, the query SHOULD be retransmitted at least
>     once.
>
> So the LLMNR sender would try "tedlemon.example.net" and would get back
> and error and then it would fall back to an LLMNR query for "tedlemon"
> eventually.

In the case stated above, there is DNS configured and there is a 
tedlemon.example.net. LLMNR would never be used. DNS would receive a 
response and never fall back to LLMNR.

-josh
--Apple-Mail-17-622619927
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyNDA2MjQwOVowIwYJKoZIhvcNAQkEMRYEFPib
ipgdddbgvkljF64+dTZ8ZcyZMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBADbC
CrhV2k6ecBJLn6RQ1Kcr8TACfl5RB4iXveUwzmuqScQ+JqFhC4rg0InUJN8YTn1HibcNEzxKUnXz
gR3QNYwqnf5OXMF5CLopQ4ZU/zcR0Z1WDTVwTHw1aCMT8vO2LZBVKZh5+1ao3vTAKmciSihuelng
IFW1EDfV9od/VZYOzAxQCBpqhEAovQ0CY44WsuohmR+p7Q8RyH8x4RkOrofzO32JeV08RWF/1oKO
Hhl6Ka3g2N7Ekvsv02TtdPDOaF87m0hLtjCccj1sYhVmtOlt4H7ewnxgVqYfxuTxJ/fyVfAqeBYG
gppX+hqlZ59B3/wgJbpG7uxcsbfF+d+ULt0AAAAAAAA=

--Apple-Mail-17-622619927--


--
to 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:42 2006
From: Ted Lemon <mellon@fugue.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Fri, 24 Oct 2003 00:49:37 -0500
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.56.0310232008220.23077@internaut.com>
Mime-Version: 1.0 (Apple Message framework v552)
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 Fri Oct 24 13:15:24 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <Pine.LNX.4.56.0310232008220.23077@internaut.com>
To: Bernard Aboba <aboba@internaut.com>
Precedence: bulk

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

On Thursday, October 23, 2003, at 11:10  PM, Bernard Aboba wrote:
> So the LLMNR sender would try "tedlemon.example.net" and would get back
> and error and then it would fall back to an LLMNR query for "tedlemon"
> eventually.

Only if there is no tedlemon.example.net.   If there is one, it will 
get the wrong answer.   This is because there is no way to say "I mean 
LLMNR."   I can't say "ping tedlemon.llmnr" - all I can do is say "ping 
tedlemon", which is ambiguous.




--
to 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:42 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Fri, 24 Oct 2003 21:07:02 +0700
Lines: 52
Sender: owner-namedroppers@ops.ietf.org
References: <DA41EACF-05E5-11D8-99FC-000A95D9C74C@fugue.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Bernard Aboba <aboba@internaut.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 24 16:20:46 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Ted Lemon <mellon@fugue.com>
In-Reply-To: <DA41EACF-05E5-11D8-99FC-000A95D9C74C@fugue.com> 
Precedence: bulk

    Date:        Fri, 24 Oct 2003 00:49:37 -0500
    From:        Ted Lemon <mellon@fugue.com>
    Message-ID:  <DA41EACF-05E5-11D8-99FC-000A95D9C74C@fugue.com>

  | Only if there is no tedlemon.example.net.   If there is one, it will 
  | get the wrong answer.   This is because there is no way to say "I mean 
  | LLMNR."   I can't say "ping tedlemon.llmnr" - all I can do is say "ping 
  | tedlemon", which is ambiguous.

What happened to "ping tedlemon." ?

If the names are actually different, then there's never going to be a problem.

If the names are the same, then there's nothing rational that can be done.
The ambiguity exists, the very best that can be done is to at least provide
a well defined reconciliation rule.

Appending a constant to a name and hoping to improve things is essentially the
same as adding a constant to a pseudo-random number and hoping to improve it.

If you want your local-only system to have a name that cannot possibly be 
confused with a DNS name, giving it a name in a fake TLD (like llmnr or local)
will work just fine to allow you to reach that one safely by name (assuming
there isn't another one on the LAN of course).

Attempting to do this automatically simply doesn't help - that is, if you
expect the system to be known as "tedlemon" and you believe that by doing the
LLMNR lookup using "tedlemon.llmnr" automatically (and the node making itself
known there that way automatically) then you're mistaken.

The user still does "ping tedlemon" and gets an answer - from the "other"
host with the same name - there's no indication that it isn't the one that
was wanted.

There's unquestionably a difficult naming issue here - applications want to
"simply work" - that is, use a standard API to translate name->address, and
be able to use the address with some kind of confidence.   Having that able
to work in a mixed environment of registered names, and "made up" names is
really not easy.   Appletalk provides no guidance, as it never had an 
environment like this to work in.   The various attempts to solve this by
fiddling with bits in the lookup format are sadly misguided (and adding a
constant string to the name being sought is just fiddling with bits in the
packet format).

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:42 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: DNSEXT WGLC Summary: LLMNR - Using root name servers in LLMNR
Date: Sat, 25 Oct 2003 00:51:35 +0700
Lines: 27
Sender: owner-namedroppers@ops.ietf.org
References: <82316728-063D-11D8-99FC-000A95D9C74C@fugue.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 Fri Oct 24 20:21:29 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Ted Lemon <mellon@fugue.com>
In-Reply-To: <82316728-063D-11D8-99FC-000A95D9C74C@fugue.com> 
Precedence: bulk

    Date:        Fri, 24 Oct 2003 11:17:05 -0500
    From:        Ted Lemon <mellon@fugue.com>
    Message-ID:  <82316728-063D-11D8-99FC-000A95D9C74C@fugue.com>

  | Then you get a query to the root: "who has the top-level domain 
  | 'tedlemon'?".   I think maybe the owners of the root name servers would 
  | rather not see queries like that.   Maybe I'm wrong.

I'm sure that they wouldn't, but then again they get this stuff now, and
this isn't going to increase it much.   This use of the '.' isn't going to be
very common - remember here we're imagining the rather fanciful case of
the same name being used for something registered in the DNS in the search
domains, and happening to have just turned up as an unregistered local
node that we want to contact (note: not that wants to contact us).

I'm not a root server operator, but even if I were, simple typos, and people
who want to treat the DNS as a directory service, would bother me far more
than this.

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:42 2006
From: Joshua Graessley <jgraessley@apple.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Fri, 24 Oct 2003 11:47:13 -0700
Lines: 80
Sender: owner-namedroppers@ops.ietf.org
References: <DA41EACF-05E5-11D8-99FC-000A95D9C74C@fugue.com> <26345.1067004422@munnari.OZ.AU>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-23-667204344; protocol="application/pkcs7-signature"
X-From: owner-namedroppers@ops.ietf.org Fri Oct 24 21:02:40 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <26345.1067004422@munnari.OZ.AU>
To: namedroppers@ops.ietf.org
X-Mailer: Apple Mail (2.606)
Precedence: bulk


--Apple-Mail-23-667204344
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


My apologies to the working group for wasting their time. It is 
apparent I am in the minority here. It seems the worry of conflicting 
with a name in DNS and being unable to use LLMNR is not an important 
issue to most folks. This is reflected in the draft. It is also quite 
apparent that LLMNR and mDNS solve completely different problems.

LLMNR does not appear to solve any problems important to me or the 
vendor I work for. Maybe this working group will have luck finding 
someone that is interested in LLMNR.

Best wishes,
good luck!

-josh
--Apple-Mail-23-667204344
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyNDE4NDcxNFowIwYJKoZIhvcNAQkEMRYEFFxF
3N6TqsVEjpj8SpGq80ap+ngMMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAI5a
v3FUQpRujhWQpEt4k5VUbyNcGyvvdmm+8kZrvkOvi4wdaiMuosbEe+l6RGAFlE8LLmgyhZXivKz9
KNEHMAQ2lmb8APOLA9xnvjlm1rMkDAYuIgQzyFFYHw4Csgna5lW6lfdoAMMYwYpXdSii0ih6N4hq
IAp6yAyTKox7VFnN/CYW2TxWOXS9VjKZ57PE5YY7C5GFWzWHYlhwP11BF4jywJi5sgsGNB6XCrNy
q25NgTAn6BwU4P9hXz+nQ9aZGHJGSQdn3U2wEzIKr4AGfQTwbWYfbjlvxSEEXk9VN1cOFDVFCcHF
qj0bAtey4QkN0aDHR5JCnSqsQNrabqB4AdQAAAAAAAA=

--Apple-Mail-23-667204344--


--
to 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:42 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Wildcard NS and DNSSEC
Date: Fri, 24 Oct 2003 17:09:05 -0400
Organization: Verisign, Inc.
Lines: 64
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 Oct 24 23:22:24 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
User-Agent: KMail/1.5.3
Content-Disposition: inline
Precedence: bulk

I think that there is a conflict between the wildcard clarify and
DNSSEC.  Section 6.2 of wildcard-clarify says (essentially):

   Is it not a protocol error to have a NS RR owned by a wild card
   domian name, complimentary to the case of a SOA RR.  However, for
   this to work, an implementation has to know how to synthesize a
   zone.

In other words, wildcard NS records are technically legal.  I am
not taking a position on whether or not they should be legal.

However, I cannot see how they work with DNSSEC.  Imagine your fancy
zone, example.net:

   example.net IN SOA ....
   example.net IN RRSIG SOA ...
   ...
   *.example.net IN NS ns1.super-wcard.example.com.
   *.example.net IN NS ns2.super-wcard.example.com.

(ns1 & ns2 are nameservers that can synthesize entire zones ending
with example.net).

Continue to imagine that example.net is signed.  And now imagine a
referral generated by this wacky wildcard:

  QUESTION
     foo.example.net  IN A
  ANSWER
  AUTHORITY
     foo.example.net IN NS ns1.super-wcard.example.com.
     foo.example.net IN NS ns2.super-wcard.example.com.
     f.example.net IN NSEC g.example.net A RRSIG NSEC
  ADDITIONAL
     ...

Ok, so like a normal positive wildcard match, a NSEC record is
included to show that there wasn't a non-wildcard record that should
have matched or blocked.  BUT, since delegation NS sets aren't signed,
there is no RRSIG for the referral itself.

For starters, I know for certain that this will not validate.  It
looks just like an Opt-In response (except for the NSEC bit on the
NSEC record), and we have some experience with unaware validators
choking on this sort of response.  Additionally, you might be able to
see that part of the standard wildcard validation is missing: proof
that (at least) the wildcard actually exists.  This is, IMHO, because
a wildcard NS RRset is a truly odd thing: the zone is synthesizing
records for which it isn't even authoritative.

I suppose that it might be possible to handle this by adding another
NSEC record for the wildcard, which may solve some nagging security
issues, but would be a pretty odd special case.

-- 
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:42 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: DNSEXT WGLC Summary: LLMNR
Date: Sat, 25 Oct 2003 04:53:29 +0000
Lines: 13
Sender: owner-namedroppers@ops.ietf.org
References: <jgraessley@apple.com>
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sat Oct 25 07:12:14 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Joshua Graessley <jgraessley@apple.com>
In-Reply-To: Message from Joshua Graessley <jgraessley@apple.com> 
	of "Fri, 24 Oct 2003 11:47:13 MST."
	<7BA1B83C-0652-11D8-B5ED-000A95B9474C@apple.com> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> LLMNR does not appear to solve any problems important to me or the vendor I
> work for. Maybe this working group will have luck finding someone that is
> interested in LLMNR.

i think that the llmnr document, or another to be advanced at the same time,
should give implementation guidance to vendors who also implement dns and
mdns.

--
to 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:42 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Wildcard NS and DNSSEC
Date: Sat, 25 Oct 2003 15:25:17 +0000
Lines: 21
Sender: owner-namedroppers@ops.ietf.org
References: <davidb@verisignlabs.com>
X-From: owner-namedroppers@ops.ietf.org Sat Oct 25 17:43:20 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> 
	of "Fri, 24 Oct 2003 17:09:05 -0400."
	<200310241709.05520.davidb@verisignlabs.com> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> ...  Section 6.2 of wildcard-clarify says (essentially):
> 
>    Is it not a protocol error to have a NS RR owned by a wild card
>    domian name, complimentary to the case of a SOA RR.  However, for
>    this to work, an implementation has to know how to synthesize a
>    zone.
> 
> In other words, wildcard NS records are technically legal.  I am
> not taking a position on whether or not they should be legal.

fwiw, i am.  the above wording gives no guidance to implementors and
should be struck from the document.  the proper wording is simply that
"Having an NS RRset owned by a wild card domain name is undefined" which
in terms of guidance to implementors is very much clearer.  Either set
of wording leaves open the possibility of later defining 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:42 2006
From: bmanning@karoshi.com
Subject: Re: Wildcard NS and DNSSEC
Date: Sun, 26 Oct 2003 03:11:16 -0800 (PST)
Lines: 50
Sender: owner-namedroppers@ops.ietf.org
References: <200310241709.05520.davidb@verisignlabs.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 Sun Oct 26 12:30:31 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: davidb@verisignlabs.com (David Blacka)
In-Reply-To: <200310241709.05520.davidb@verisignlabs.com> from "David Blacka" at Oct 24, 2003 05:09:05 PM
X-Mailer: ELM [version 2.5 PL6]
Precedence: bulk

> In other words, wildcard NS records are technically legal.  I am
> not taking a position on whether or not they should be legal.

	perhaps this is the distinction btwn
	"newtonian DNS" and "quantum DNS" ... :)

>    *.example.net IN NS ns1.super-wcard.example.com.
>    *.example.net IN NS ns2.super-wcard.example.com.
> 
> (ns1 & ns2 are nameservers that can synthesize entire zones ending
> with example.net).

	what would the zone "*.example.net" look like?
	specifically the SOA.

 
> choking on this sort of response.  Additionally, you might be able to
> see that part of the standard wildcard validation is missing: proof
> that (at least) the wildcard actually exists.  This is, IMHO, because
> a wildcard NS RRset is a truly odd thing: the zone is synthesizing
> records for which it isn't even authoritative.

	again.. what are the contents fo the "wildcard zone"

> I suppose that it might be possible to handle this by adding another
> NSEC record for the wildcard, which may solve some nagging security
> issues, but would be a pretty odd special case.

	-IF- we go this far, then an NSEC rr for the wildcard 
	would be useful.


> 
> -- 
> 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/>
> 


--
to 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:42 2006
From: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: Wildcard NS and DNSSEC
Date: Sun, 26 Oct 2003 21:35:46 +0900
Lines: 39
Sender: owner-namedroppers@ops.ietf.org
References: <200310241709.05520.davidb@verisignlabs.com>
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 Sun Oct 26 13:43:23 2003
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: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <200310241709.05520.davidb@verisignlabs.com>
Precedence: bulk

David Blacka;

> I think that there is a conflict between the wildcard clarify and
> DNSSEC.  Section 6.2 of wildcard-clarify says (essentially):
> 
>    Is it not a protocol error to have a NS RR owned by a wild card
>    domian name, complimentary to the case of a SOA RR.  However, for
>    this to work, an implementation has to know how to synthesize a
>    zone.
> 
> In other words, wildcard NS records are technically legal.  I am
> not taking a position on whether or not they should be legal.

Hmmmmm, after rereading the paragraph, it seems to me that
the draft says something on a wildcarded authoritative NS (and
SOA), but perhaps not on a wildcarded referal NS.

However, the wildcarded authoritative NS (and SOA) is, IMHO,
illegal, or, at least, meaningless.

The problem is that SOA and authoritative NS must appear
at the root, and nowhere else, of a zone, which makes
wildcarding, which makes the RRs appear at lower nodes
of the zone, meaningless.

On the other hand, it seems to me that referral NS, which
seems to be useful (at least for NSI, maybe), is not
considered explicitely in the draft but, IMHO, should be
legislated more explicitely.

						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:42 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Re: Wildcard NS and DNSSEC
Date: Sun, 26 Oct 2003 15:11:59 -0500
Organization: Verisign, Inc.
Lines: 42
Sender: owner-namedroppers@ops.ietf.org
References: <200310261111.h9QBBGi29357@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 Sun Oct 26 21:23:49 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
User-Agent: KMail/1.5
In-Reply-To: <200310261111.h9QBBGi29357@karoshi.com>
Content-Disposition: inline
Precedence: bulk

On Sunday 26 October 2003 06:11 am, bmanning@karoshi.com wrote:
> > In other words, wildcard NS records are technically legal.  I am
> > not taking a position on whether or not they should be legal.
>
> 	perhaps this is the distinction btwn
> 	"newtonian DNS" and "quantum DNS" ... :)
>
> >    *.example.net IN NS ns1.super-wcard.example.com.
> >    *.example.net IN NS ns2.super-wcard.example.com.
> >
> > (ns1 & ns2 are nameservers that can synthesize entire zones ending
> > with example.net).
>
> 	what would the zone "*.example.net" look like?
> 	specifically the SOA.

Why does this matter?

In my mind, the zones are not necessarily represented by a bunch of wildcard 
records.  It would be sufficient to write a special authoritative server that 
just had rules for generating the correct responses base on the query.

> > I suppose that it might be possible to handle this by adding another
> > NSEC record for the wildcard, which may solve some nagging security
> > issues, but would be a pretty odd special case.
>
> 	-IF- we go this far, then an NSEC rr for the wildcard
> 	would be useful.

-IF- we went this far, the validator wouldn't just need the NSEC record, it 
would need to know what to do with it.

-- 
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:42 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Re: Wildcard NS and DNSSEC
Date: Sun, 26 Oct 2003 15:29:28 -0500
Organization: Verisign, Inc.
Lines: 54
Sender: owner-namedroppers@ops.ietf.org
References: <200310241709.05520.davidb@verisignlabs.com> <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sun Oct 26 21:40:33 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
User-Agent: KMail/1.5
In-Reply-To: <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp>
Content-Disposition: inline
Precedence: bulk

On Sunday 26 October 2003 07:35 am, masataka ohta wrote:
> David Blacka;
>
> > I think that there is a conflict between the wildcard clarify and
> > DNSSEC.  Section 6.2 of wildcard-clarify says (essentially):
> >
> >    Is it not a protocol error to have a NS RR owned by a wild card
> >    domian name, complimentary to the case of a SOA RR.  However, for
> >    this to work, an implementation has to know how to synthesize a
> >    zone.
> >
> > In other words, wildcard NS records are technically legal.  I am
> > not taking a position on whether or not they should be legal.
>
> Hmmmmm, after rereading the paragraph, it seems to me that
> the draft says something on a wildcarded authoritative NS (and
> SOA), but perhaps not on a wildcarded referal NS.

Interesting.  I came to the opposite conclusion.  The earlier paragraphs in 
the section seem to be talking about delegation NS RRsets.

If you and I can disagree on this, then it is clear that 6.2 isn't clear.

> However, the wildcarded authoritative NS (and SOA) is, IMHO,
> illegal, or, at least, meaningless.
>
> The problem is that SOA and authoritative NS must appear
> at the root, and nowhere else, of a zone, which makes
> wildcarding, which makes the RRs appear at lower nodes
> of the zone, meaningless.

I didn't follow that.  It is perfectly valid to have a zone that only has 
records at the apex.  In fact, I imagine that is how this whole situation 
would have to work: synthesized zones with only records at the apex.

> On the other hand, it seems to me that referral NS, which
> seems to be useful (at least for NSI, maybe), is not
> considered explicitely in the draft but, IMHO, should be
> legislated more explicitely.

My main point is that 2535bis and wcard-clarify are, IMO, in conflict, and, 
since 2535bis has a normative reference to wcard-clarify, that is definitely 
a problem.

-- 
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:42 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Wildcard NS and DNSSEC
Date: Sun, 26 Oct 2003 16:01:04 -0500
Lines: 21
Sender: owner-namedroppers@ops.ietf.org
References: <200310241709.05520.davidb@verisignlabs.com>
	<3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp>
	<200310261529.28671.davidb@verisignlabs.com>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Sun Oct 26 22:13:05 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <200310261529.28671.davidb@verisignlabs.com>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

At Sun, 26 Oct 2003 15:29:28 -0500, David Blacka wrote:
> ...
> My main point is that 2535bis and wcard-clarify are, IMO, in
> conflict, and, since 2535bis has a normative reference to
> wcard-clarify, that is definitely a problem.

Ignoring the rest of the conversation for the moment, thanks for
pointing this out.  This was a normative reference up through
dnssec-protocol-02, but since wcard-clarify no longer contains any
text about DNSSEC (bis or classic), the citations that made this a
normative reference will be gone in dnssec-protocol-03.

I'll make wcard-clarify an informative reference in dnssec-protocol-03
(which we'll be dropping into the I-D queue before the gate slams shut
tomorow morning).  What to do from there is, of course, up to the WG.

--
to 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:42 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Wildcard NS and DNSSEC
Date: Sun, 26 Oct 2003 16:14:12 -0500
Lines: 10
Sender: owner-namedroppers@ops.ietf.org
References: <200310241709.05520.davidb@verisignlabs.com>
	<3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp>
	<200310261529.28671.davidb@verisignlabs.com>
	<20031026210104.CA90218E2@thrintun.hactrn.net>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Sun Oct 26 22:22:03 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20031026210104.CA90218E2@thrintun.hactrn.net>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

Correcting my own misstatement to save the rest of you the trouble:
wcard-clarify was incorrectly listed as an informative reference in
dnssec-protocol-02, but the reference was in fact normative.  That's
been fixed.  Sorry for the confusion.

--
to 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:42 2006
From: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: Wildcard NS and DNSSEC
Date: Mon, 27 Oct 2003 08:24:45 +0900
Lines: 39
Sender: owner-namedroppers@ops.ietf.org
References: <200310241709.05520.davidb@verisignlabs.com> <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp> <200310261529.28671.davidb@verisignlabs.com>
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 Mon Oct 27 00:32:58 2003
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: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <200310261529.28671.davidb@verisignlabs.com>
Precedence: bulk

David Blacka;

>>The problem is that SOA and authoritative NS must appear
>>at the root, and nowhere else, of a zone, which makes
>>wildcarding, which makes the RRs appear at lower nodes
>>of the zone, meaningless.
> 
> 
> I didn't follow that.  It is perfectly valid to have a zone that only has 
> records at the apex.

Yes.

> In fact, I imagine that is how this whole situation 
> would have to work: synthesized zones with only records at the apex.

Yes, syhthesis is fine.

But, it is enough to have wildcard notation in zone files
internal to a name server only without having it with the
protocol. In addition, to do so, wildcarded referral NS
is just enough.

Note that wildcarded authoritative NS and SOA does not appear
on the wire even with "*" query. Or, can you show me a
conter example?

Note also that zone transfer of a zone with wildcarded SOA is
impossible.

						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:42 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: New versions of DNSSECbis drafts available
Date: Mon, 27 Oct 2003 04:58:03 -0500
Lines: 24
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Mon Oct 27 11:10:52 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

The DNSSEC document editors just submitted the latest revisions of the
drafts to the Internet-Drafts admin.  Copies are also posted at:

  http://www.hactrn.net/ietf/dns/dnssec-editors/

Please review.  Please review.  Please review.

Along with addressing questions resolved since Vienna, we also
reorganized and rewrote portions of the protocol document and added a
bunch of new examples.  As always, send little stuff to the
dnssec-editors list, send anything major to namedroppers.

And, oh yeah, did we mention that we'd appreciate it if you'd review
the drafts?

Thanks.

--Rob (on behalf of your friendly neighborhood DNSSEC doc editors)

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au>
Subject: Re: Draft: non-wildcard bit.
Date: Mon, 27 Oct 2003 14:07:54 +0100 (CET)
Lines: 66
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.58.0310232205460.25722@x53.ripe.net>
 <20031023224511.20329.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Mon Oct 27 14:23:36 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: bc@x53.ripe.net
To: namedroppers@ops.ietf.org
In-Reply-To: <20031023224511.20329.qmail@cr.yp.to>
X-RIPE-Spam-Level: 
X-RIPE-Spam-Status: N 0.499998
X-RIPE-Signature: 381efa09e86ca48bdc7b8beeb6a38082
Precedence: bulk


Last week, various people wrote:

> Bruce Campbell writes:
> > With all the fuss on the unannounced addition of a wildcard record to the
> > .com and .net zones, it is obvious that many applications need a clear and
> > reliable method of knowing whether a response is 'real'

vix> that's not obvious at all.

A lot of the complaints regarding the wildcard deployment can be summed up
as 'people do not trust' (verisign).  Hence, there is a need for people to
have an assurance[1] that they are getting a response that does not point
back to a service which is unsuited to their application/customer
base/personal preference.

( Or, while wildcards and other synthesis methods are great ways of
  shooting off feet, one single entity should not be able to make the
  world dance. )

djb> Exactly which applications are you talking about?

I don't think that an 'exact' answer is possible, as the effects of this
wildcard deployment has not been understood on all applications.  In
general terms, I'm presuming that administrators of applications want
their applications to either talk only to the expected end host, or fail
immediately if a non-existing end host is supplied.  They do not want to
talk to an arbitary man in the middle in the latter case.

( Or, 'did you mean' is absolutely useless to most services except for
  those where human eyeballs are involved (web). )

djb> What exactly is the definition of a ``real'' DNS record?

In the draft, I've referred to 'real' DNS records as being
'non-synthesised'.  In more specific terms, a 'real' DNS record is one
which the nameserver software has done a straight read from the zone
file/database/etc to find the relevant label, and has not applied any
synthesis rules (wildcard processing or something else) to generate the
result.

( Or, if someone has manually put it into a file, its real )

djb> What exactly do you want these applications to do with non-``real''
djb> records?

'It depends'.

It depends on two things.  The specific application in use (eg, user
authentication vs random web browsing), and the location in the tree where
the wildcard has been detected (*.example.com is ok, *.com.au is not ok).
See section 5 of the draft for further commentary on this.

In short, for each application, there are good and bad locations for a
wildcard, and it is up to each site to define them.

-- 
                             Bruce Campbell          I speak for myself

[1] Another way of getting that assurance is to follow the DNSSEC path.

--
to 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:43 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Wildcard NS and DNSSEC
Date: Mon, 27 Oct 2003 09:16:11 -0500 (EST)
Lines: 24
Sender: owner-namedroppers@ops.ietf.org
References: <200310241709.05520.davidb@verisignlabs.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Oct 27 15:26:46 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <200310241709.05520.davidb@verisignlabs.com>
Precedence: bulk

> Additionally, you might be able to see that part of the standard
> wildcard validation is missing: proof that (at least) the wildcard
> actually exists.

Put simply, the parent has no RRSIG on the NS set, and the RRSIG is an
integral part of a wildcard proof.

> I suppose that it might be possible to handle this by adding another
> NSEC record for the wildcard, which may solve some nagging security
> issues, but would be a pretty odd special case.

Ick.  Let's just forbid it and move along.  If someone really wants to
synthesize delegations, they can sign answers on the fly.

To clarify, should a literal * delegation be allowed?  (Not a wildcard
to be synthesized, just a literal *.example NS?)

-- 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:43 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-11.txt
Date: Mon, 27 Oct 2003 09:14:47 -0500
Lines: 95
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 Mon Oct 27 15:26:47 2003
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		: KEY RR Secure Entry Point Flag
	Author(s)	: O. Kolkman, J. Schlyter, E. Lewis
	Filename	: draft-ietf-dnsext-keyrr-key-signing-flag-11.txt
	Pages		: 10
	Date		: 2003-10-24
	
With the Delegation Signer (DS) resource record the concept of a key
acting as a secure entry point has been introduced. During
key-exchanges with the parent there is a need to differentiate secure
entry point keys from other keys in the KEY resource record (RR) set.
A flag bit in the KEY RR is defined to indicate that KEY is to be
used as a secure entry point. The flag bit is intended to assist in
operational procedures to correctly generate DS resource records, or
to indicate what keys are intended for static configuration. The flag
bit is not to be used in the DNS verification protocol. This document
updates RFC 2535 and RFC 3445.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-keyrr-key-signing-flag-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-24160219.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-keyrr-key-signing-flag-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-24160219.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:43 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-07.txt
Date: Mon, 27 Oct 2003 09:19:07 -0500
Lines: 93
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 Mon Oct 27 15:26:50 2003
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		: A DNS RR for encoding DHCP information (DHCID RR)
	Author(s)	: M. Stapp, T. Lemon, A. Gustafsson
	Filename	: draft-ietf-dnsext-dhcid-rr-07.txt
	Pages		: 10
	Date		: 2003-10-24
	
It is possible for multiple DHCP clients to attempt to update the
same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
the clients themselves perform the DNS updates, conflicts can arise.
To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1]
proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients to which they refer.
This memo defines a distinct RR type for this purpose for use by
DHCP clients and servers, the 'DHCID' RR.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dhcid-rr-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-24165651.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-dhcid-rr-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-24165651.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:43 2006
From: Miek Gieben <miekg@atoom.net>
Subject: Re: Wildcard NS and DNSSEC
Date: Mon, 27 Oct 2003 15:24:04 +0100
Lines: 23
Sender: owner-namedroppers@ops.ietf.org
References: <200310241709.05520.davidb@verisignlabs.com>
 <Pine.GSO.4.55.0310270904430.14968@filbert>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Mon Oct 27 15:33:52 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-reply-to: <Pine.GSO.4.55.0310270904430.14968@filbert>
To: namedroppers@ops.ietf.org
Mail-followup-to: 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

[On 27 Oct, @15:16, Samuel wrote in "Re: Wildcard NS and DNSSEC ..."]
> > Additionally, you might be able to see that part of the standard
> > wildcard validation is missing: proof that (at least) the wildcard
> > actually exists.
> 
> Put simply, the parent has no RRSIG on the NS set, and the RRSIG is an
> integral part of a wildcard proof.
> 
> > I suppose that it might be possible to handle this by adding another
> > NSEC record for the wildcard, which may solve some nagging security
> > issues, but would be a pretty odd special case.
> 
> Ick.  Let's just forbid it and move along.  If someone really wants to

I'm in favor of doing that also,

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:43 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Draft: non-wildcard bit.
Date: Mon, 27 Oct 2003 14:42:03 +0000
Lines: 41
Sender: owner-namedroppers@ops.ietf.org
References: <bc-namedroppers@vicious.dropbear.id.au>
X-From: owner-namedroppers@ops.ietf.org Mon Oct 27 15:50:44 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au> 
	of "Mon, 27 Oct 2003 14:07:54 +0100."
	<Pine.LNX.4.58.0310271333480.898@x53.ripe.net> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> > > With all the fuss on the unannounced addition of a wildcard record
> > > to the .com and .net zones, it is obvious that many applications
> > > need a clear and reliable method of knowing whether a response is
> > > 'real'
> 
> vix> that's not obvious at all.

about twice a year since 1994 i have begun planning an rfc called "what
the dns is not".  the opening paragraph always has these words: "DNS is
a distributed, hierarchical, reliable, autonomous database.  DNS deals
in facts, not values, and data carried in the DNS are facts, not opinions."

but then i always calm down before i can get the full rant figured, which
would include diatribes against DNS NAT and "middleboxes" of all kinds,
especially DNS-based load balancing appliances.

> A lot of the complaints regarding the wildcard deployment can be
> summed up as 'people do not trust' (verisign).  Hence, there is a need
> for people to have an assurance[1] that they are getting a response
> that does not point back to a service which is unsuited to their
> application/customer base/personal preference.

if the world doesn't trust verisign then the world ought to negotiate a
better contract or find a different registry.  it's bad enough that BIND
now has a feature which allows client-side content editing (delegation-only)
but let's not make our situation even worse by complicating the protocol
itself to cope with what's actually a layer 9 problem.

> In short, for each application, there are good and bad locations for a
> wildcard, and it is up to each site to define them.

an application should not behave differently because synthesis was used,
even if a more robust protocol would in fact move the act of synthesis
into the client-side for a number of unrelated but perfectly valid
reasons.

--
to 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:43 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Draft: non-wildcard bit.
Date: Mon, 27 Oct 2003 14:43:29 +0000 (Africa/Tunis)
Lines: 18
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.LNX.4.58.0310232205460.25722@x53.ripe.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Oct 27 15:53:34 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au>
In-Reply-To: <Pine.LNX.4.58.0310232205460.25722@x53.ripe.net>
Precedence: bulk

> it is obvious that many applications need a clear and reliable
> method of knowing whether a response ... has been synthesised.

If zone owners really want to mark synthesized records, the protocol
already has a technique for doing that -- it's called signing the
zone.  I'm not inclined to spend more time developing another one.

If there's really demand for flagging synthesized answers, then
perhaps we should put forth a document requiring that any zone with
wildcards be signed.

-- 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:43 2006
From: "Scott Rose" <scottr@nist.gov>
Subject: comment on "DNSSEC Operational Practices" Term
Date: Mon, 27 Oct 2003 10:51:25 -0500
Lines: 25
Sender: owner-namedroppers@ops.ietf.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 Oct 27 17:03:06 2003
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

There is one disagreement between the DNSSEC Operational Practices draft and
the DNSSECbis Protocol draft.  That is how to classify and handle "BAD" RR
sets in responses.

The Appendix in the operational draft states that "BAD data is not cached."
However, the proto doc states that a resolver may want to have a "BAD" data
cache for various reasons.  Under normal circumstances, a resolver will not
want to cache proven BAD data (however you want to define BAD), but there
are cases where it might be useful for the resolver to have a BAD data
cache.

The punchline:  Everyone read the protocol draft and see if you agree with
the current wording on sections 3 and 4 regarding caching nameservers and
resolvers (please).  And read the operational practices draft (please. It is
another needed draft IMHO).

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/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-07.txt
Date: Mon, 27 Oct 2003 15:28:23 -0500
Lines: 92
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 Mon Oct 27 21:43:56 2003
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		: DNS Security Introduction and Requirements
	Author(s)	: R. Arends, R. Austein, D. Massey, M. Larson, S. Rose
	Filename	: draft-ietf-dnsext-dnssec-intro-07.txt
	Pages		: 24
	Date		: 2003-10-27
	
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System.  This
document introduces these extensions, and describes their
capabilities and limitations.  This document also discusses the
services that the DNS security extensions do and do not provide.
Last, this document describes the interrelationships between the
group of documents that collectively describe DNSSEC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dnssec-intro-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27154530.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-dnssec-intro-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27154530.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:43 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-03.txt
Date: Mon, 27 Oct 2003 15:28:37 -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 Mon Oct 27 21:44:23 2003
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		: Protocol Modifications for the DNS Security Extensions
	Author(s)	: R. Arends
	Filename	: draft-ietf-dnsext-dnssec-protocol-03.txt
	Pages		: 55
	Date		: 2003-10-27
	
This document is part of a family of documents which describes the
DNS Security Extensions (DNSSEC).  The DNS Security Extensions are a
collection of new resource records and protocol modifications which
add data origin authentication and data integrity to the DNS.  This
document describes the DNSSEC protocol modifications.  This document
defines the concept of a signed zone, along with the requirements for
serving and resolving using DNSSEC.  These techniques allow a
security-aware resolver to authenticate both DNS resource records and
authoritative DNS error indications.
This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dnssec-protocol-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27154546.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-dnssec-protocol-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27154546.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:43 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-05.txt
Date: Mon, 27 Oct 2003 15:34:34 -0500
Lines: 95
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 Mon Oct 27 21:48:21 2003
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		: Resource Records for DNS Security Extensions
	Author(s)	: R. Arends
	Filename	: draft-ietf-dnsext-dnssec-records-05.txt
	Pages		: 36
	Date		: 2003-10-27
	
This document is part of a family of documents that describes the DNS
Security Extensions (DNSSEC).  The DNS Security Extensions are a
collection of resource records and protocol modifications that
provide source authentication for the DNS. This document defines the
public key (DNSKEY), delegation signer (DS), resource record digital
signature (RRSIG), and authenticated denial of existance (NSEC)
resource records.  The purpose and format of each resource record is
described in detail, and an example of each resource record is given.
This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dnssec-records-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27155331.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-dnssec-records-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27155331.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:43 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-04.txt
Date: Mon, 27 Oct 2003 15:36:53 -0500
Lines: 94
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 Mon Oct 27 21:49:25 2003
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		: Threat Analysis Of The Domain Name System
	Author(s)	: D. Atkins, R. Austein
	Filename	: draft-ietf-dnsext-dns-threats-04.txt
	Pages		: 15
	Date		: 2003-10-27
	
Although the DNS Security Extensions (DNSSEC) have been under
development for most of the last decade, the IETF has never written
down the specific set of threats against which DNSSEC is designed to
protect.  Among other drawbacks, this cart-before-the-horse situation
has made it difficult to determine whether DNSSEC meets its design
goals, since its design goals are not well specified.  This note
attempts to document some of the known threats to the DNS, and, in
doing so, attempts to measure to what extent (if any) DNSSEC is a
useful tool in defending against these threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dns-threats-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dns-threats-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27155827.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-dns-threats-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-dns-threats-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27155827.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:43 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-07.txt
Date: Mon, 27 Oct 2003 17:08:41 -0500
Lines: 93
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 Mon Oct 27 23:23:20 2003
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		: A DNS RR for encoding DHCP information (DHCID RR)
	Author(s)	: M. Stapp, T. Lemon, A. Gustafsson
	Filename	: draft-ietf-dnsext-dhcid-rr-07.txt
	Pages		: 10
	Date		: 2003-10-24
	
It is possible for multiple DHCP clients to attempt to update the
same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
the clients themselves perform the DNS updates, conflicts can arise.
To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1]
proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients to which they refer.
This memo defines a distinct RR type for this purpose for use by
DHCP clients and servers, the 'DHCID' RR.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dhcid-rr-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27170849.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-dhcid-rr-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27170849.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:43 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-11.txt
Date: Mon, 27 Oct 2003 17:08:47 -0500
Lines: 95
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 Mon Oct 27 23:23:21 2003
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		: KEY RR Secure Entry Point Flag
	Author(s)	: O. Kolkman, J. Schlyter, E. Lewis
	Filename	: draft-ietf-dnsext-keyrr-key-signing-flag-11.txt
	Pages		: 10
	Date		: 2003-10-24
	
With the Delegation Signer (DS) resource record the concept of a key
acting as a secure entry point has been introduced. During
key-exchanges with the parent there is a need to differentiate secure
entry point keys from other keys in the KEY resource record (RR) set.
A flag bit in the KEY RR is defined to indicate that KEY is to be
used as a secure entry point. The flag bit is intended to assist in
operational procedures to correctly generate DS resource records, or
to indicate what keys are intended for static configuration. The flag
bit is not to be used in the DNS verification protocol. This document
updates RFC 2535 and RFC 3445.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-keyrr-key-signing-flag-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27170857.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dnsext-keyrr-key-signing-flag-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27170857.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:43 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: comment on "DNSSEC Operational Practices" Term
Date: Tue, 28 Oct 2003 09:49:04 +0100
Organization: RIPE NCC
Lines: 28
Sender: owner-namedroppers@ops.ietf.org
References: <045b01c39ca2$2d3292f0$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 Tue Oct 28 10:06:20 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Scott Rose" <scottr@nist.gov>
In-Reply-To: <045b01c39ca2$2d3292f0$b9370681@barnacle>
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.000131
X-RIPE-Signature: 9397e894ee07f4b1842fbc49d519a502
Precedence: bulk

On Mon, 27 Oct 2003 10:51:25 -0500
"Scott Rose" <scottr@nist.gov> wrote:


> The punchline:  Everyone read the protocol draft and see if you agree with
> the current wording on sections 3 and 4 regarding caching nameservers and
> resolvers (please).  And read the operational practices draft (please. It is
> another needed draft IMHO).


FYI that draft is: 
    draft-ietf-dnsop-dnssec-operational-practices-00.txt
It is under review in DNSOP.

The practices document will need to be in sync with whatever proto sais, not 
the other way around.

-- 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:43 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: DNSSEC nearing last call.
Date: Tue, 28 Oct 2003 15:54:22 +0100
Organization: RIPE NCC
Lines: 139
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 Oct 28 16:13:50 2003
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.499797
X-RIPE-Signature: 9d84b8fff036c3c7412df0ed156d6c93
Precedence: bulk


namedroppers,

Some time ago I mailed a list with open questions to the list
(http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01532.html).
That list of questions clarified what would be taken as consensus position
of the working group if no further discussion took place. 

I went to the list and marked a large number of questions as resolved
because consensus was reached on them; For those questions for which I
think their may be confusion on why consensus was called I added a
small explanation.

One question (Q15) is still open, but has text in the current document
set that reflects where I think consensus is going. If no further
comments are received on this question it will be marked as resolved
shortly after IETF58.


Since the intro and records document have been stable for a while I
think they are ready for a last call.  I'll wait for some feedback on
this mail but plan to start a WG Last Call on 'intro' and 'records'
before the IETF.  The proto document may have some minor nits to be
fixed but is good for thorough review. We will decide if proto 03 is
ready for last call during IETF58.


Comments about the text (spelling, style) can be mailed to
dnssec-editors@east.isi.edu. Comments about protocol need to go to the
list.


   !!!!!!!!!    Credit goes to the dnssec editors team.  !!!!!!!!!!!!


For clarity the current document-set is:
   draft-ietf-dnsext-dnssec-intro-07.txt
   draft-ietf-dnsext-dnssec-records-05.txt
   draft-ietf-dnsext-dnssec-protocol-03.txt



--Olaf Kolkman
  DNSEXT Co-chair




The list of questions. 
 
 Q1 - resolved
 Q2 - resolved
 Q3 - resolved
 Q4 - mistake in numbering, there is no Q4
 Q5 - resolved (Handled in TCR draft)

 Q6 - Started as "Should sec-aware resolvers cache known "BAD" data"?
      But now encompasses how servers/resolvers should interpret the
      CD bit in the DNS header.  

      resolved, for completeness, the new text in -proto draft
      describes how a caching resolver can have a BAD data cache, and
      when it is appropriate to use it.


 Q7 - resolved
 Q8 - resolved 
 Q9 - resolved

 Q10 - Since there was no response to my message in which I requested
       alternative text
       (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01851.html)
       this item is resolved and the text remained as in proto-2


 Q11 - resolved

       DNSKEY RRs allowed at delegation points.

       After rereading the original threat on this issue we decided
       that the working group consensus is that DNSKEY RRs not allowed
       at delegation points.  

       This is reflected in the last line of proto section 2.1.
 


 Q12 - resolved

 Q13 - resolved
  
       The silence on the list has been interpreted as consensus for
       keeping the advice that caching should be atomic (i.e. entire
       response keyed to a single <sname,sclass,stype>) is discussed in
       protocol draft (as a SHOULD).

 Q14 - resolved

 Q15 - Open

        Should a security-aware stub resolver be allowed to set the CD
        bit on queries or should this behavior be prohibited?

        The -proto document now reflects:
       *It should remain SHOULD NOT. security risk given to state why
        it is a bad idea for general operation*

        This will be taken as the consensus position if no further comments
        are received by the end of IETF58.

 Q16 - resolved

       What should a recursive nameserver do if query has flags CD=1, and
       DO=0? Suggest

       Text suggested in the original question
       (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01559.html).
       suggested a change in protocol. Working group concensus is against this.

       In proto the two bits are treated separately and their behavior is
       'orthogonal'.


 Q17 - resolved
      (the TCR document handles this)



-- 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:43 2006
From: bmanning@karoshi.com
Subject: Re: comment on "DNSSEC Operational Practices" Term
Date: Tue, 28 Oct 2003 07:36:39 -0800 (PST)
Lines: 21
Sender: owner-namedroppers@ops.ietf.org
References: <045b01c39ca2$2d3292f0$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 Tue Oct 28 16:48:04 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: scottr@nist.gov (Scott Rose)
In-Reply-To: <045b01c39ca2$2d3292f0$b9370681@barnacle> from "Scott Rose" at Oct 27, 2003 10:51:25 AM
X-Mailer: ELM [version 2.5 PL6]
Precedence: bulk

> 
> There is one disagreement between the DNSSEC Operational Practices draft and
> the DNSSECbis Protocol draft.  That is how to classify and handle "BAD" RR
> sets in responses.
> 
> The Appendix in the operational draft states that "BAD data is not cached."
> However, the proto doc states that a resolver may want to have a "BAD" data
> cache for various reasons.  Under normal circumstances, a resolver will not
> want to cache proven BAD data (however you want to define BAD), but there
> are cases where it might be useful for the resolver to have a BAD data
> cache.

	the protocol draft has it right.

--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:43 2006
From: Miek Gieben <miekg@atoom.net>
Subject: Re: comment on "DNSSEC Operational Practices" Term
Date: Tue, 28 Oct 2003 16:47:42 +0100
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <045b01c39ca2$2d3292f0$b9370681@barnacle>
 <200310281536.h9SFadm27709@karoshi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Oct 28 16:58:46 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-reply-to: <200310281536.h9SFadm27709@karoshi.com>
To: bmanning@karoshi.com
Mail-followup-to: bmanning@karoshi.com, Scott Rose <scottr@nist.gov>,
 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

[On 28 Oct, @16:36, bmanning wrote in "Re: comment on "DNSSEC Operati ..."]
> > 
> > There is one disagreement between the DNSSEC Operational Practices draft and
> > the DNSSECbis Protocol draft.  That is how to classify and handle "BAD" RR
> > sets in responses.
> > 
> > The Appendix in the operational draft states that "BAD data is not cached."
> > However, the proto doc states that a resolver may want to have a "BAD" data
> > cache for various reasons.  Under normal circumstances, a resolver will not
> > want to cache proven BAD data (however you want to define BAD), but there
> > are cases where it might be useful for the resolver to have a BAD data
> > cache.
> 
> 	the protocol draft has it right.

ok, to stop this from lingering on, I changed to ops-draft already. Change wil
be in 01.

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:43 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 14:02:41 -0500
Organization: Verisign, Inc.
Lines: 44
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 Oct 28 20:21:54 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
User-Agent: KMail/1.5.3
Content-Disposition: inline
Precedence: bulk

Currently the NSEC record (nee NXT) can only support typecodes up to
127 (dnssec-records-05, section 4.1.2).  However, the type field in
DNS is actually 16 bits long.

While this situation has been true for as long as I've been looking at
DNSSEC, and presumably since its inception, this is an issue that
seems to have been totally ignored by this WG.

I would like to know:

  * How can we consider DNSSEC complete while it ignores 9 of the 16
    bits in the typecode field?

  * What happens when (or if), after this current DNSSEC spec is
    widely deployed, we want to define typecode 128?  Do we do another
    typecode rollover? Move the DO bit? add another EDNS flag?

In the current form, I feel that DNSSEC will artificially constrain
DNS typecodes to no larger than 127, simply because existing
implementations of DNSSEC-aware DNS software will not be able to
handler larger typecodes, and we all know how much of a PITA getting
everyone to roll out new DNS software is.

  * If the intention is the constrain the typecode field to 7
    effective bits, then please explain why.  Is the intent to reserve
    the remaining 65407 types for psuedo types?

  * Why haven't we already defined the alternate format of the NSEC
    typecode field?  Are we waiting for some future breakthrough that
    will allow us to handle these giant numbers between 128 and 65535?

This WG has spent a fair amount of time on other issues of forward
compatibility, but why not this?

-- 
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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 15:38:09 -0500
Lines: 64
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Tue Oct 28 21:52:17 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <200310281402.41950.davidb@verisignlabs.com>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

At Tue, 28 Oct 2003 14:02:41 -0500, David Blacka wrote:
>...
>   * What happens when (or if), after this current DNSSEC spec is
>     widely deployed, we want to define typecode 128?  Do we do another
>     typecode rollover? Move the DO bit? add another EDNS flag?

According to RFC 2335, which DNSSECbis hasn't changed in this regard,
we set bit zero of the typecode "bitvector" to one.  I put "bitvector"
in quotes because I strongly suspect that the actual representation at
that point would not be a bitvector.

I don't much like this either, but the WG has not chosen to rip the
covers off of this particular piece of 2535.

> In the current form, I feel that DNSSEC will artificially constrain
> DNS typecodes to no larger than 127, simply because existing
> implementations of DNSSEC-aware DNS software will not be able to
> handler larger typecodes, and we all know how much of a PITA getting
> everyone to roll out new DNS software is.

Fair point.

>   * If the intention is the constrain the typecode field to 7
>     effective bits, then please explain why.  Is the intent to reserve
>     the remaining 65407 types for psuedo types?

I don't think there was any such intention.  For historical reasons
(having to do with the fact that DNS types and classes were only 8-bit
values in the earliest DNS specs), the typecodes allocated so far all
happen to fit the bitvector encoding hack proposed in the original
DNSSEC specs.  The WG chose to go for this hack.

>   * Why haven't we already defined the alternate format of the NSEC
>     typecode field?  Are we waiting for some future breakthrough that
>     will allow us to handle these giant numbers between 128 and 65535?

Ok, fair enough.  With the understanding that I am -not- taking a
position on whether the WG should do anything about this at this time,
here's a proposed encoding for you to use as a strawcritter.

- Bit zero of "bitvector" is a flag bit as described in RFC 2535 and
  DNSSECbis drafts

- Remainder of first octet of "bitvector" is a version number for this
  encoding format (unless somebody can think of a more important use
  for those seven bits).  This email message defines format zero (ie,
  all seven of those bits must be zero).

- Rest of "bitvector" is an ordered list of 16-bit bigendian unsigned
  integers.  Each integer represents one type present at the owner
  name.  The list must be sorted into ascending order (not strictly
  necessary, but might simplify some operations and is easy to do).

So the "bitvector" would be 2*N+1 octets for a name with N distinct RR
types.  Not a particularly compact encoding.  If the WG decides that
it's interested in this subject, somebody should do the numbers to see
what this does to typical response sizes, but recall that DNSSECbis
requires EDNS0, so we're not limited to 512-octet packets.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 16:47:45 -0500
Organization: Verisign, Inc.
Lines: 60
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com> <20031028203810.7A1BB18E2@thrintun.hactrn.net>
Mime-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Tue Oct 28 23:07:26 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
User-Agent: KMail/1.5.3
In-Reply-To: <20031028203810.7A1BB18E2@thrintun.hactrn.net>
Content-Disposition: inline
Precedence: bulk

On Tuesday 28 October 2003 03:38 pm, Rob Austein wrote:

> I don't much like this either, but the WG has not chosen to rip the
> covers off of this particular piece of 2535.

I guess I'm in the position of arguing that it needs to.

> I don't think there was any such intention.  For historical reasons
> (having to do with the fact that DNS types and classes were only 8-bit
> values in the earliest DNS specs), the typecodes allocated so far all
> happen to fit the bitvector encoding hack proposed in the original
> DNSSEC specs.  The WG chose to go for this hack.

At this point, having read through long threads discussion what we might 
have to do if RSA is broken, I am at a loss to understand why this issue 
hasn't been considered important.  Actually, I am at a loss to understand 
why it wasn't an issue in the first place.  It isn't like types where only 
8 bits then.

> >   * Why haven't we already defined the alternate format of the NSEC
> >     typecode field?  Are we waiting for some future breakthrough that
> >     will allow us to handle these giant numbers between 128 and 65535?
> 
> Ok, fair enough.  With the understanding that I am -not- taking a
> position on whether the WG should do anything about this at this time,
> here's a proposed encoding for you to use as a strawcritter.

Why not take a position?  I'll take a position: DNSSEC is not complete 
without the ability to handle types > 127.  Just because there aren't any 
now is no excuse.

> - Remainder of first octet of "bitvector" is a version number for this
>   encoding format (unless somebody can think of a more important use
>   for those seven bits).  This email message defines format zero (ie,
>   all seven of those bits must be zero).

If you define format version, it will either be useless or near-useless due 
to the difficulty in globally updating DNS software.  Unless we go further 
and define good behavior for when a validator sees an NSEC format it 
doesn't recognize.  But I'm not exactly certain why we would need multiple 
formats anyway.  It isn't like we don't understand this namespace.

Here is an alternative strawcritter:

- use the remaining 7 bits in the first octet as a count of single-byte 
typecodes, called N.  The next N octets are an ordered list of 8-bit 
integers representing typecodes <= 255.  The remaining RDATA is an ordered 
list of 16-bit big-endian unsigned integers, each representing one type 
present.

-- 
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:43 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 21:51:12 +0000
Lines: 20
Sender: owner-namedroppers@ops.ietf.org
References: <sra+namedroppers@hactrn.net>
X-From: owner-namedroppers@ops.ietf.org Tue Oct 28 23:10:05 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Rob Austein <sra+namedroppers@hactrn.net> 
	of "Tue, 28 Oct 2003 15:38:09 EST."
	<20031028203810.7A1BB18E2@thrintun.hactrn.net> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> I don't much like this either, but the WG has not chosen to rip the
> covers off of this particular piece of 2535.

and yet, can serious deployment (burning of roms containing the software)
begin without a defined solution for typecodes above 127?

> Ok, fair enough.  With the understanding that I am -not- taking a
> position on whether the WG should do anything about this at this time,
> here's a proposed encoding for you to use as a strawcritter.

michael graff and i here at isc have also experimented with several
encodings that would support typecodes above 127.  is it time for a
bake-off?  perhaps so, if olaf is rattling the WGLC sabre...


--
to 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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 17:07:07 -0500
Lines: 22
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<20031028203810.7A1BB18E2@thrintun.hactrn.net>
	<200310281647.45423.davidb@verisignlabs.com>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Tue Oct 28 23:18:52 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <200310281647.45423.davidb@verisignlabs.com>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

At Tue, 28 Oct 2003 16:47:45 -0500, David Blacka wrote:
> 
> Why not take a position?

Waiting to hear what other people have to say, for which reason I'll
shut up on this subject for a while after this message.

> Here is an alternative strawcritter:
> 
> - use the remaining 7 bits in the first octet as a count of single-byte 
> typecodes, called N.  The next N octets are an ordered list of 8-bit 
> integers representing typecodes <= 255.  The remaining RDATA is an ordered 
> list of 16-bit big-endian unsigned integers, each representing one type 
> present.

Your strawcritter is better than mine.

--
to 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:43 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 22:10:46 +0000
Lines: 21
Sender: owner-namedroppers@ops.ietf.org
References: <davidb@verisignlabs.com>
X-From: owner-namedroppers@ops.ietf.org Tue Oct 28 23:24:45 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> 
	of "Tue, 28 Oct 2003 16:47:45 EST."
	<200310281647.45423.davidb@verisignlabs.com> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> > I don't much like this either, but the WG has not chosen to rip the
> > covers off of this particular piece of 2535.
> 
> I guess I'm in the position of arguing that it needs to.

i agree.  and just to make sure my position is unambiguously clear:

> ...  I'll take a position: DNSSEC is not complete without the ability
> to handle types > 127.  Just because there aren't any now is no excuse.

i agree with this too.

> Here is an alternative strawcritter:

sounds like a bakeoff is in order.  mister graff, you may fire when ready.

--
to 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:43 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 23:56:12 +0100 (CET)
Lines: 49
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
 <20031028203810.7A1BB18E2@thrintun.hactrn.net> <200310281647.45423.davidb@verisignlabs.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 Oct 29 00:17:33 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <200310281647.45423.davidb@verisignlabs.com>
Precedence: bulk

<panic>
NOOOOOOOOOO!!!!!!!
</panic>

> ... having read through long threads discussion what we might
> have to do if RSA is broken, ...

We tackled "having space to deal with RSA being broken" even though
we don't have good alternatives to replace it.  We needed to make sure
that "safe" failure modes exist and that phase-in of a new algorithm
would be possible.

In this case, we already have a provision for dealing with bigger
typecodes.  We don't know how we'll deal with them, but at least the
provision is there.

> Unless we go further and define good behavior for when a validator
> sees an NSEC format it doesn't recognize.

Yup -- we need to do that.  How's this: If you see the zero bit set
AND THE NSEC VALIDATES, treat this name as unsecured unless you have
evidence to the contrary (ie. a validated RRset)?  Treating the entire
name as non-existing is too harsh.  This means that a name with that
bit set can have its RRs spoofed away, but at least bad data can't be
substituted.

Paul asks:
> can serious deployment (burning of roms containing the software)
> begin without a defined solution for typecodes above 127?

I think we can get away with putting this off -- we have the extension
mechanism in place and can deal with it later.  With the current
typecode burn rate, the current format will outlast a resolver
replacement cycle.  Maybe two.

But if folks really insist, let's get it done quickly.  I'm sure we
can settle on a format.  Can we get multiple interoperable
implementations out the door before Minneapolis?  Seriously -- I want
to get this rev out.  I suggest that the chairs decline the change
unless we have two pieces of interoperable code within some short
amount of time, perferably pre-MSP.

-- 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:43 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 18:48:26 -0500
Organization: Verisign, Inc.
Lines: 81
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <Pine.GSO.4.55.0310282333050.4801@filbert>
Mime-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 01:07:01 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
User-Agent: KMail/1.5.3
In-Reply-To: <Pine.GSO.4.55.0310282333050.4801@filbert>
Content-Disposition: inline
Precedence: bulk

On Tuesday 28 October 2003 05:56 pm, Samuel Weiler wrote:
> <panic>
> NOOOOOOOOOO!!!!!!!
> </panic>
> 
> > ... having read through long threads discussion what we might
> > have to do if RSA is broken, ...
> 
> We tackled "having space to deal with RSA being broken" even though
> we don't have good alternatives to replace it.  We needed to make sure
> that "safe" failure modes exist and that phase-in of a new algorithm
> would be possible.

Yes, I agree.

> In this case, we already have a provision for dealing with bigger
> typecodes.  We don't know how we'll deal with them, but at least the
> provision is there.

What provision? What we have now is an undefined format, which isn't worth 
anything.  What happens when a validator sees a NSEC record with bit 0 set 
to one?  Who knows? It is "undefined".

> > Unless we go further and define good behavior for when a validator
> > sees an NSEC format it doesn't recognize.
> 
> Yup -- we need to do that.  How's this: If you see the zero bit set
> AND THE NSEC VALIDATES, treat this name as unsecured unless you have
> evidence to the contrary (ie. a validated RRset)?  Treating the entire
> name as non-existing is too harsh.  This means that a name with that
> bit set can have its RRs spoofed away, but at least bad data can't be
> substituted.

We could do this, and it would work.  It is why I mentioned this 
possibility in the first place.  And I think that defining a rule like 
this is maybe the minimum we can do right now.  But it would have to be 
defined in the DNSSECbis documents.  It currently isn't.

IMHO, it would be easier to define the alternative format than to work 
through the security implications of a NSEC RR with an unknown type 
format.  This isn't rocket science.  Honestly, I'm baffled that no one has 
handled this before now.

> Paul asks:
> > can serious deployment (burning of roms containing the software)
> > begin without a defined solution for typecodes above 127?
> 
> I think we can get away with putting this off -- we have the extension
> mechanism in place and can deal with it later.  With the current
> typecode burn rate, the current format will outlast a resolver
> replacement cycle.  Maybe two.

Well, we don't have the extension mechanism in place, which is partially my 
point.

While I may personally believe that we are likely to go through multiple 
flag-days with DNSSEC, it would be stupid to proceed with that 
expectation.  And who knows what the future "burn rate" on typecodes is?

> But if folks really insist, let's get it done quickly.  I'm sure we
> can settle on a format.  Can we get multiple interoperable
> implementations out the door before Minneapolis?  Seriously -- I want
> to get this rev out.  I suggest that the chairs decline the change
> unless we have two pieces of interoperable code within some short
> amount of time, perferably pre-MSP.

Yes, I apologize for not bringing this up three years ago.

I understand the desire for closure on DNSSEC, but I suggest that we not 
advance obviously deficient documents.

-- 
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:43 2006
From: Mark.Andrews@isc.org
Subject: Re: Wildcard NS and DNSSEC
Date: Wed, 29 Oct 2003 10:52:18 +1100
Lines: 36
Sender: owner-namedroppers@ops.ietf.org
References: <20031027142404.GB15077@atoom.net>
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 01:07:14 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Mail-Followup-To: namedroppers@ops.ietf.org 
In-reply-to: Your message of "Mon, 27 Oct 2003 15:24:04 BST."
             <20031027142404.GB15077@atoom.net> 
Precedence: bulk


> [On 27 Oct, @15:16, Samuel wrote in "Re: Wildcard NS and DNSSEC ..."]
> > > Additionally, you might be able to see that part of the standard
> > > wildcard validation is missing: proof that (at least) the wildcard
> > > actually exists.
> > 
> > Put simply, the parent has no RRSIG on the NS set, and the RRSIG is an
> > integral part of a wildcard proof.
> > 
> > > I suppose that it might be possible to handle this by adding another
> > > NSEC record for the wildcard, which may solve some nagging security
> > > issues, but would be a pretty odd special case.
> > 
> > Ick.  Let's just forbid it and move along.  If someone really wants to
> 
> I'm in favor of doing that also,
> 
> grtz Miek

  As am I.

> 
> --
> to 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, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: Section 2 of draft-ietf-dnsext-dnssec-protocol-03
Date: Tue, 28 Oct 2003 20:11:50 -0500
Lines: 111
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 Wed Oct 29 02:29:19 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: stjohns@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: namedroppers@ops.ietf.org
Precedence: bulk

I was originally just going to send these to the editor, but I think there 
are still a few substantive problems here.   (Obviously, these are opinions 
rather than directives, but its easier to write protocol stuff as 
directive...:-)

Meta comment - much of the language in this section describes operational 
constraints rather than protocol constraints.  This document really needs 
to describe the behavior of the protocol (e.g. "if the RRSIG is missing 
then..."), rather than trying to abscribe MUSTs and SHOULDs to the 
operators (e.g. "the zone must contain an RRSIG for every...").

These are in section order rather than order of importance...

2.1, first para, second sentence beginning:  "For each private 
key...".  Instead how about:  "For each RRSIG there MUST be a corresponding 
zone DNSKEY RR.  Orphan RRSIG RRs (e.g. those without corresponding DNSKEY 
RRs) are considered extraneous information and MUST be ignored."

2.1, 1para, 3rd sentence beginning "A zone key..." - delete "to one" - nit 
- flags are either set or cleared.

2.1 1para, last sentence - replace with "Public keys stored in DNSKEY RRs 
marked as zone keys SHOULD NOT be used for purposes other than DNS 
operations.  However, enforcement of this restriction is properly left up 
to the standards which describe those other purposes."

2.1 2nd para, last sentence beginning "This DNSKEY RR..." - DNSKEY signing 
key doesn't actually appear to be defined in the reference.

2.2, pg 7, 2nd para after the bullets at top beginning "An RRSIG 
RR...".  Replace entirely with:
"An RRSIG RR itself SHOULD NOT be signed since signing an RRSIG RR would 
add no value.  RRSIG RRs with a covered type of RRSIG are considered 
extraneous and MUST be ignored."

2.2 pg 7, 3rd para after bullets.  Insert after first sentence:  "Zones 
where the the apex NS RRSet is not validly signed (and should have been 
based on a validated DS in the parent zone) are considered bogus."

[Commentary - there are notionally three states for zones, insecure, secure 
and bogus.  The latter applies only to zones where the resolver was 
expecting to receive a secure result and did not.  Bogus results come from 
bad signatures, missing signatures, or broken chains from a trust anchor.  ]

2.2 pg7, 4th para after bullets beginning "There MUST be..."  This 
continues to feel like the tail wagging the dog.  The DS RR was added to 
prevent the requirement for close consultation between parent and child and 
this seems to have way too close coordination between parent and child.  It 
also seems strange to require every RRset in a zone to be signed by ALL 
algorithms...

How about:

"1) The apex DNSKEY RRset SHOULD be signed by all apex DNSKEYs with both 
the zone key and SEP key flags set. [General definition of a SEP key is 
that it signs the zone DNSKEY RRSet]

2) The apex DNSKEY RRSet SHOULD include at least one non-SEP zone DNSKEY 
with a matching algorithm for each algorithm in the SEP set at the apex. 
[Need this for flow through since these sign all the non-DNSKEY rrsets]

3) All DS RRsets in a zone SHOULD be signed by at least one non-SEP zone 
DNSKEY for each algorithm in the apex SEP zone DNSKEY set. [The maintains 
the algorithm consistency from root to leaf in each zone without requiring 
all the elements of the zone to be signed by all algorithms.]

4) The DS RRset in the parent SHOULD include pointers to all child apex 
DNSKEYs with both the zone key and SEP key flags set.

5) The above represents guidance which should be enforced by the tools 
designed to sign and maintain zones. Failure to enforce these criteria will 
generally result in the inability to verify the security of a zone. The 
actual impact of failure to follow such guidance is described later in 
sections 4 and 5.

6) All resolvers MUST be able to verify RSA and DSA signatures.  Signing 
tools MUST support RSA signatures and MAY support DSA signatures [is this 
the right order? I forget]"

 >>>>General comment: the most important thing is that the resolvers know 
how to resolve all the signature types.  If we add additional sig 
algorithms we will need to update the resolver requirement (6 above) but 
not the resolution process.  Its way too hard to try and enforce the 
numbers and types of signatures in the actual DNS.  Its more than hard to 
try and do the enforcement between parent and child.  The other thing we 
want to prevent is requiring a parent to do more signatures just because a 
child does them.

But, we still need language in section 5 addressing whether data signed by 
an algorithm you don't understand is either bogus or insecure - I argue for 
the latter.

Section 2.3 - There's some confusion here.  A "glue" address record can be 
a real record in the zone -  e.g. zone example.com,  bar.example.com ns 
foo.example.com, foo.example.com A 1.1.1.1.  Given that this is a real A 
record, I *think* it gets an NSEC RR, but the language in this section 
suggests otherwise.  [I think the fallacious assumption is that zones are 
either delegation-only, or non-delegation.]

Section 2.4 - This should reflect my comment above - item (4) that the DS 
RRSet should include pointers to all of the SEP keys.





--
to 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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03
Date: Tue, 28 Oct 2003 20:52:11 -0500
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 03:05:59 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <6.0.0.22.2.20031028183020.032a6d10@localhost>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

At Tue, 28 Oct 2003 20:11:50 -0500, Michael StJohns wrote:
> ...
> Section 2.3 - There's some confusion here.  A "glue" address record can be 
> a real record in the zone -  e.g. zone example.com,  bar.example.com ns 
> foo.example.com, foo.example.com A 1.1.1.1.  Given that this is a real A 
> record, I *think* it gets an NSEC RR, but the language in this section 
> suggests otherwise.

If foo.example.com is delegated, then the A RRset for foo.example.com
in the example.com zone is glue, and doesn't show up in the NSEC RR at
foo.example.com in the example.com zone.

If foo.example.com isn't delegated, then the A RRset for
foo.example.com isn't glue, and does show up in the NSEC RR.

> [I think the fallacious assumption is that zones are either
> delegation-only, or non-delegation.]

No such assumption.  You're just paying the word "glue" extra :).

--
to 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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Wildcard NS and DNSSEC
Date: Tue, 28 Oct 2003 20:28:22 -0500
Lines: 7
Sender: owner-namedroppers@ops.ietf.org
References: <20031027142404.GB15077@atoom.net>
	<200310282352.h9SNqI8Y001833@drugs.dv.isc.org>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 03:07:44 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <200310282352.h9SNqI8Y001833@drugs.dv.isc.org>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

just forbid wildcard ns and move along, aye.

--
to 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:43 2006
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03
Date: Tue, 28 Oct 2003 21:49:13 -0500
Lines: 52
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
 <20031029015211.C24B618DD@thrintun.hactrn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 04:05:26 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: stjohns@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: Rob Austein <sra+namedroppers@hactrn.net>,
	namedroppers@ops.ietf.org
In-Reply-To: <20031029015211.C24B618DD@thrintun.hactrn.net>
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
 <20031029015211.C24B618DD@thrintun.hactrn.net>
Precedence: bulk




At 08:52 PM 10/28/2003, Rob Austein wrote:
>At Tue, 28 Oct 2003 20:11:50 -0500, Michael StJohns wrote:
> > ...
> > Section 2.3 - There's some confusion here.  A "glue" address record can be
> > a real record in the zone -  e.g. zone example.com,  bar.example.com ns
> > foo.example.com, foo.example.com A 1.1.1.1.  Given that this is a real A
> > record, I *think* it gets an NSEC RR, but the language in this section
> > suggests otherwise.
>
>If foo.example.com is delegated, then the A RRset for foo.example.com
>in the example.com zone is glue, and doesn't show up in the NSEC RR at
>foo.example.com in the example.com zone.

Right, but the zone that was delegated in my example was 
bar.example.com.  The A records for one of the name servers actually are in 
example.com (at foo.example.com) rather than being in the delegated domain 
(bar.example.com)

The problem is the term "glue" I think.  When I think of glue, I think of A 
records not in the zone, in which case its pretty clear that an NSEC record 
for that type of record shouldn't exist here.  The problem is the language 
at 2.4:

"Each owner name IN THE ZONE MUST have an NSEC resource record, except for 
the owner names of any glue address RRsets."  (emphasis mine)

E.g. is a true "glue address RRset" in the zone?



>If foo.example.com isn't delegated, then the A RRset for
>foo.example.com isn't glue, and does show up in the NSEC RR.
>
> > [I think the fallacious assumption is that zones are either
> > delegation-only, or non-delegation.]
>
>No such assumption.  You're just paying the word "glue" extra :).
>
>--
>to 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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03
Date: Tue, 28 Oct 2003 22:09:40 -0500
Lines: 49
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
	<20031029015211.C24B618DD@thrintun.hactrn.net>
	<6.0.0.22.2.20031028214004.03478d18@localhost>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 04:28:53 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <6.0.0.22.2.20031028214004.03478d18@localhost>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

At Tue, 28 Oct 2003 21:49:13 -0500, Michael StJohns wrote:
>
> Right, but the zone that was delegated in my example was 
> bar.example.com.

You said that bar.example.com was delegated.  You didn't way whether
foo.example.com was delegated or not, so I answered it both ways.

> The A records for one of the name servers actually are in
> example.com (at foo.example.com) rather than being in the delegated
> domain (bar.example.com)

So foo.example.com isn't delegated, so it's not glue, hence 2.4 says
it should have an NSEC RR.

> The problem is the term "glue" I think.  When I think of glue, I think of A 
> records not in the zone, in which case its pretty clear that an NSEC record 
> for that type of record shouldn't exist here.  The problem is the language 
> at 2.4:
> 
> "Each owner name IN THE ZONE MUST have an NSEC resource record, except for 
> the owner names of any glue address RRsets."  (emphasis mine)

After reviewing RFC 2181, I'm inclined to agree that we should just
lose the word "glue" entirely here, albiet for slightly different
reasons.

For the purposes discussed in this section, there are three catagories
of data in a zone:

- Authoritative data;

- Nonauthoritative NS RRsets (the delegations themselves)

- All other nonauthoritative data (normally only addresses)

RFC 2181 5.4.1 refers to all non-authoritative data in a zone as
"glue", including the delegation NS RRsets.  So let's just punt the
term entirely as too blunt an instrument for this nitpicky level of
protocol detail.  How about:

"Every authoritative RRset or delegation point NS RRset in the zone
MUST have an NSEC resource record."

--
to 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:43 2006
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03
Date: Tue, 28 Oct 2003 23:09:20 -0500
Lines: 49
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
 <20031029015211.C24B618DD@thrintun.hactrn.net>
 <6.0.0.22.2.20031028214004.03478d18@localhost>
 <20031029030940.2E90118E1@thrintun.hactrn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 05:21:35 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: stjohns@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: Rob Austein <sra+namedroppers@hactrn.net>,
	namedroppers@ops.ietf.org
In-Reply-To: <20031029030940.2E90118E1@thrintun.hactrn.net>
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
 <20031029015211.C24B618DD@thrintun.hactrn.net>
 <6.0.0.22.2.20031028214004.03478d18@localhost>
 <20031029030940.2E90118E1@thrintun.hactrn.net>
Precedence: bulk

At 10:09 PM 10/28/2003, Rob Austein wrote:
Thanks for reparsing this...


> >
> > "Each owner name IN THE ZONE MUST have an NSEC resource record, except for
> > the owner names of any glue address RRsets."  (emphasis mine)
>
>After reviewing RFC 2181, I'm inclined to agree that we should just
>lose the word "glue" entirely here, albiet for slightly different
>reasons.
>
>For the purposes discussed in this section, there are three catagories
>of data in a zone:
>
>- Authoritative data;
>
>- Nonauthoritative NS RRsets (the delegations themselves)
>
>- All other nonauthoritative data (normally only addresses)
>
>RFC 2181 5.4.1 refers to all non-authoritative data in a zone as
>"glue", including the delegation NS RRsets.  So let's just punt the
>term entirely as too blunt an instrument for this nitpicky level of
>protocol detail.  How about:
>
>"Every authoritative RRset or delegation point NS RRset in the zone
>MUST have an NSEC resource record."

I hate terminology... in this case a DS RRset is authoritative because it 
belongs to the parent even though the name is the apex name of the child 
zone...right..  I think that's more precise than what's there and less 
subject to confusion.

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/>


--
to 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:43 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 12:00:26 +0100
Organization: RIPE NCC
Lines: 44
Sender: owner-namedroppers@ops.ietf.org
References: <20031028203810.7A1BB18E2@thrintun.hactrn.net>
	<20031028215112.DD1351394C@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 12:16:00 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20031028215112.DD1351394C@sa.vix.com>
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.064613
X-RIPE-Signature: 707a96bdc37b9cfdb36ff04aa362202e
Precedence: bulk


> bake-off?  perhaps so, if olaf is rattling the WGLC sabre...

As the sabre is being polished we see yet another stain *sigh* (I am
tempted to use much bloodier metaphors, but refrain)

Sam wrote:
> I suggest that the chairs decline the change
>  unless we have two pieces of interoperable code within some short
>  amount of time, preferably pre-MSP.


Chairs can decline _topics_ out of scope e.g. if they have been
discussed at length and declined by the WG before. Hoping my memory is
not selective I think that this topic is _not_ out of scope.

We need specs, rather before than after IETF58. Running code as proof
of concept surely helps to convince the WG.

Remember, the RFC2535bis document-set is not intended to change the
protocol, it should only clarify, changes go through the IETF
seperatly. I think that we can argue that Sam's suggestion is actually
a clarification rather than a protocol change so that can go into the
documents directly, it describes what to do in the failure state, an
omission in 2535,


I'll be following this thread with this question in mind:
  Can the working group consent with Sam's clarification on how to
  handle when the validated NSEC zero bit is set or is there consent
  for alternative encoding.



-- Olaf 
   DNSEXT Co-Chair.



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: "Scott Rose" <scottr@nist.gov>
Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03
Date: Wed, 29 Oct 2003 10:03:52 -0500
Lines: 140
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 16:23:17 2003
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: "Mike StJohns" <Mike.StJohns@nominum.com>
To: <namedroppers@ops.ietf.org>
Sent: Tuesday, October 28, 2003 8:11 PM
Subject: Section 2 of draft-ietf-dnsext-dnssec-protocol-03


> I was originally just going to send these to the editor, but I think there
> are still a few substantive problems here.   (Obviously, these are
opinions
> rather than directives, but its easier to write protocol stuff as
> directive...:-)
>
> Meta comment - much of the language in this section describes operational
> constraints rather than protocol constraints.  This document really needs
> to describe the behavior of the protocol (e.g. "if the RRSIG is missing
> then..."), rather than trying to abscribe MUSTs and SHOULDs to the
> operators (e.g. "the zone must contain an RRSIG for every...").
>
> These are in section order rather than order of importance...
>
> 2.1, first para, second sentence beginning:  "For each private
> key...".  Instead how about:  "For each RRSIG there MUST be a
corresponding
> zone DNSKEY RR.  Orphan RRSIG RRs (e.g. those without corresponding DNSKEY
> RRs) are considered extraneous information and MUST be ignored."
>

It is possible to have RRSIGs in a zone and the DNSKEY statically
configured, and not in the zone.  It is silly, but for some private DNS, it
might be desired.

> 2.1, 1para, 3rd sentence beginning "A zone key..." - delete "to one" - nit
> - flags are either set or cleared.
>
> 2.1 1para, last sentence - replace with "Public keys stored in DNSKEY RRs
> marked as zone keys SHOULD NOT be used for purposes other than DNS
> operations.  However, enforcement of this restriction is properly left up
> to the standards which describe those other purposes."
>

ack.


> 2.1 2nd para, last sentence beginning "This DNSKEY RR..." - DNSKEY signing
> key doesn't actually appear to be defined in the reference.
>
The def is for "key Signing key" - a more general definition.

> 2.2, pg 7, 2nd para after the bullets at top beginning "An RRSIG
> RR...".  Replace entirely with:
> "An RRSIG RR itself SHOULD NOT be signed since signing an RRSIG RR would
> add no value.  RRSIG RRs with a covered type of RRSIG are considered
> extraneous and MUST be ignored."
>

"MUST be ignored" is the phrase that I have a problem with.  Ignored by the
resolver, or the name server?  Forbidding RRSIGs from being signed gets the
point across in my opinion.


> 2.2 pg 7, 3rd para after bullets.  Insert after first sentence:  "Zones
> where the the apex NS RRSet is not validly signed (and should have been
> based on a validated DS in the parent zone) are considered bogus."
>
> [Commentary - there are notionally three states for zones, insecure,
secure
> and bogus.  The latter applies only to zones where the resolver was
> expecting to receive a secure result and did not.  Bogus results come from
> bad signatures, missing signatures, or broken chains from a trust
nchor.  ]
>
> 2.2 pg7, 4th para after bullets beginning "There MUST be..."  This
> continues to feel like the tail wagging the dog.  The DS RR was added to
> prevent the requirement for close consultation between parent and child
and
> this seems to have way too close coordination between parent and child.
It
> also seems strange to require every RRset in a zone to be signed by ALL
> algorithms...
>

I believe that was to be "every algorithm /present/..." not necessary every
algorithm defined for DNSSEC.  The child MUST have a RRSIG generated using
the same algos as found in the DS set in the parent, plus any other algos
found in the child apex and not in the parent's DS set.

> How about:
>
> "1) The apex DNSKEY RRset SHOULD be signed by all apex DNSKEYs with both
> the zone key and SEP key flags set. [General definition of a SEP key is
> that it signs the zone DNSKEY RRSet]
>
> 2) The apex DNSKEY RRSet SHOULD include at least one non-SEP zone DNSKEY
> with a matching algorithm for each algorithm in the SEP set at the apex.
> [Need this for flow through since these sign all the non-DNSKEY rrsets]
>
> 3) All DS RRsets in a zone SHOULD be signed by at least one non-SEP zone
> DNSKEY for each algorithm in the apex SEP zone DNSKEY set. [The maintains
> the algorithm consistency from root to leaf in each zone without requiring
> all the elements of the zone to be signed by all algorithms.]
>
> 4) The DS RRset in the parent SHOULD include pointers to all child apex
> DNSKEYs with both the zone key and SEP key flags set.
>

Not sure what you mean here with 4): Both the zone key and the SEP key?
That nullifies the idea of having a SEP key different than the zone key.  Or
all DNSKEY RRs with both the zone and SEP bits set?


> 5) The above represents guidance which should be enforced by the tools
> designed to sign and maintain zones. Failure to enforce these criteria
will
> generally result in the inability to verify the security of a zone. The
> actual impact of failure to follow such guidance is described later in
> sections 4 and 5.
>
> 6) All resolvers MUST be able to verify RSA and DSA signatures.  Signing
> tools MUST support RSA signatures and MAY support DSA signatures [is this
> the right order? I forget]"

RSA/SHA1 is mandatory, DSA is recommended.  The records draft states this,
but maybe it could be repeated here.  I don't think it is a good idea to
designate algorithms by name, since RSA/DSA/ECC/ROT13 might be dropped for
some reason in the future.



Thanks for the input

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/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: Matt Larson <mlarson@verisign.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 10:41:41 -0500
Lines: 23
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <Pine.GSO.4.55.0310282333050.4801@filbert> <200310281848.26163.davidb@verisignlabs.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 Oct 29 16:53:52 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: David Blacka <davidb@verisignlabs.com>
Content-Disposition: inline
In-Reply-To: <200310281848.26163.davidb@verisignlabs.com>
User-Agent: Mutt/1.5.4i
Precedence: bulk

On Tue, 28 Oct 2003, David Blacka wrote:
> IMHO, it would be easier to define the alternative format than to work 
> through the security implications of a NSEC RR with an unknown type 
> format.  This isn't rocket science.

I agree.  The incremental work of defining an encoding can't be much
more than punting with language about undefined states, treating as
unsecure, etc.

> I understand the desire for closure on DNSSEC, but I suggest that we not 
> advance obviously deficient documents.

What Dave said....  Let's define something (sounds like Mr. Graff has
a proposal already), put it in the docs and move on.

Matt


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03
Date: Wed, 29 Oct 2003 11:25:05 -0500
Lines: 192
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
 <01b801c39e2d$de040c30$b9370681@barnacle>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 17:40:18 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: stjohns@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: "Scott Rose" <scottr@nist.gov>, <namedroppers@ops.ietf.org>
In-Reply-To: <01b801c39e2d$de040c30$b9370681@barnacle>
References: <6.0.0.22.2.20031028183020.032a6d10@localhost>
 <01b801c39e2d$de040c30$b9370681@barnacle>
Precedence: bulk

At 10:03 AM 10/29/2003, Scott Rose wrote:

>----- Original Message -----
>From: "Mike StJohns" <Mike.StJohns@nominum.com>
>To: <namedroppers@ops.ietf.org>
>Sent: Tuesday, October 28, 2003 8:11 PM
>Subject: Section 2 of draft-ietf-dnsext-dnssec-protocol-03
>
>
> > I was originally just going to send these to the editor, but I think there
> > are still a few substantive problems here.   (Obviously, these are
>opinions
> > rather than directives, but its easier to write protocol stuff as
> > directive...:-)
> >
> > Meta comment - much of the language in this section describes operational
> > constraints rather than protocol constraints.  This document really needs
> > to describe the behavior of the protocol (e.g. "if the RRSIG is missing
> > then..."), rather than trying to abscribe MUSTs and SHOULDs to the
> > operators (e.g. "the zone must contain an RRSIG for every...").
> >
> > These are in section order rather than order of importance...
> >
> > 2.1, first para, second sentence beginning:  "For each private
> > key...".  Instead how about:  "For each RRSIG there MUST be a
>corresponding
> > zone DNSKEY RR.  Orphan RRSIG RRs (e.g. those without corresponding DNSKEY
> > RRs) are considered extraneous information and MUST be ignored."
> >
>
>It is possible to have RRSIGs in a zone and the DNSKEY statically
>configured, and not in the zone.  It is silly, but for some private DNS, it
>might be desired.

Let's just say no.  The DNSKEY needs to be in the DNS. the static 
configuration of the trust anchor can refer to that DNSKEY, but can't 
synthesize it.   Reason: Referential integrity.  Reason: Simpler if less 
special cases in the resolver.


> > 2.1, 1para, 3rd sentence beginning "A zone key..." - delete "to one" - nit
> > - flags are either set or cleared.
> >
> > 2.1 1para, last sentence - replace with "Public keys stored in DNSKEY RRs
> > marked as zone keys SHOULD NOT be used for purposes other than DNS
> > operations.  However, enforcement of this restriction is properly left up
> > to the standards which describe those other purposes."
> >
>
>ack.
>
>
> > 2.1 2nd para, last sentence beginning "This DNSKEY RR..." - DNSKEY signing
> > key doesn't actually appear to be defined in the reference.
> >
>The def is for "key Signing key" - a more general definition.

Yup - agreed, but these two need to use the exact same phrase to make sure 
the link is made.  E.g. use "DNSKEY key signing key" instead.


> > 2.2, pg 7, 2nd para after the bullets at top beginning "An RRSIG
> > RR...".  Replace entirely with:
> > "An RRSIG RR itself SHOULD NOT be signed since signing an RRSIG RR would
> > add no value.  RRSIG RRs with a covered type of RRSIG are considered
> > extraneous and MUST be ignored."
> >
>
>"MUST be ignored" is the phrase that I have a problem with.  Ignored by the
>resolver, or the name server?  Forbidding RRSIGs from being signed gets the
>point across in my opinion.

Forbidding RRSIGs signatures is an operational constraint - this document 
needs to describe what happens if some irrational zone manager actually 
manages to populate their zone with RRSIG RRSIGs.  "MUST be ignored" 
applies both to the name server and the resolver IMHO.  The name server 
probably shouldn't serve the data (but I don't know that that is a 
reasonable restriction), but if it does, the resolver shouldn't validate it 
or cache it.

> > 2.2 pg 7, 3rd para after bullets.  Insert after first sentence:  "Zones
> > where the the apex NS RRSet is not validly signed (and should have been
> > based on a validated DS in the parent zone) are considered bogus."
> >
> > [Commentary - there are notionally three states for zones, insecure,
>secure
> > and bogus.  The latter applies only to zones where the resolver was
> > expecting to receive a secure result and did not.  Bogus results come from
> > bad signatures, missing signatures, or broken chains from a trust
>nchor.  ]
> >
> > 2.2 pg7, 4th para after bullets beginning "There MUST be..."  This
> > continues to feel like the tail wagging the dog.  The DS RR was added to
> > prevent the requirement for close consultation between parent and child
>and
> > this seems to have way too close coordination between parent and child.
>It
> > also seems strange to require every RRset in a zone to be signed by ALL
> > algorithms...
> >
>
>I believe that was to be "every algorithm /present/..." not necessary every
>algorithm defined for DNSSEC.  The child MUST have a RRSIG generated using
>the same algos as found in the DS set in the parent, plus any other algos
>found in the child apex and not in the parent's DS set.

Right - but that's the wrong answer I think.  If we don't mandate the set 
of algorithms the resolver has to implement, then its possible that the 
resolver won't be able to resolve  part of the tree if its signed by an 
algorithm the resolver doesn't understand.  Mandating how the tree is 
signed is the wrong answer - because we can't control what people 
do.  Mandating how the resolver works is the right answer.

So:  "Resolvers MUST be able to validate and resolve both RSA and DSA 
signatures.  Signing tools MUST be able to sign using RSA and MAY sign 
using DSA.   Signatures using algorithms unknown by the resolver are 
considered extraneous material and MUST be ignored (e.g. treated as if they 
didn't exist).  Signatures using algorithms known by the resolver, but 
prohibited by configuration of the resolver are also considered extraneous 
material and MUST be ignored."

If we do this, then it doesn't matter who signs what and we move back from 
the realm of trying to control human behavior into the realm of controlling 
protocol behavior.

We still have the problem where we add new algorithms, delete old ones and 
haven't updated the resolvers, but that seems to be a lot less problematic 
than the current language (e.g. its a "lesser included offense"  :-)


> > How about:
> >
> > "1) The apex DNSKEY RRset SHOULD be signed by all apex DNSKEYs with both
> > the zone key and SEP key flags set. [General definition of a SEP key is
> > that it signs the zone DNSKEY RRSet]
> >
> > 2) The apex DNSKEY RRSet SHOULD include at least one non-SEP zone DNSKEY
> > with a matching algorithm for each algorithm in the SEP set at the apex.
> > [Need this for flow through since these sign all the non-DNSKEY rrsets]
> >
> > 3) All DS RRsets in a zone SHOULD be signed by at least one non-SEP zone
> > DNSKEY for each algorithm in the apex SEP zone DNSKEY set. [The maintains
> > the algorithm consistency from root to leaf in each zone without requiring
> > all the elements of the zone to be signed by all algorithms.]
> >
> > 4) The DS RRset in the parent SHOULD include pointers to all child apex
> > DNSKEYs with both the zone key and SEP key flags set.
> >
>
>Not sure what you mean here with 4): Both the zone key and the SEP key?
>That nullifies the idea of having a SEP key different than the zone key.  Or
>all DNSKEY RRs with both the zone and SEP bits set?

What is a non-zone SEP key?  Yeah, actually I meant all DNSKEY RRs [at the 
apex] with both the zone and SEP bits set.


> > 5) The above represents guidance which should be enforced by the tools
> > designed to sign and maintain zones. Failure to enforce these criteria
>will
> > generally result in the inability to verify the security of a zone. The
> > actual impact of failure to follow such guidance is described later in
> > sections 4 and 5.
> >
> > 6) All resolvers MUST be able to verify RSA and DSA signatures.  Signing
> > tools MUST support RSA signatures and MAY support DSA signatures [is this
> > the right order? I forget]"
>
>RSA/SHA1 is mandatory, DSA is recommended.  The records draft states this,
>but maybe it could be repeated here.  I don't think it is a good idea to
>designate algorithms by name, since RSA/DSA/ECC/ROT13 might be dropped for
>some reason in the future.

Correct.  But they get deprecated, before they get dropped.  We will have 
to mention them by name somewhere as mandatory/recommended.

>Thanks for the input
>
>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:43 2006
From: Michael Graff <Michael_Graff@isc.org>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 17:21:49 +0000
Lines: 293
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<200310281647.45423.davidb@verisignlabs.com>
	<Pine.GSO.4.55.0310282333050.4801@filbert>
	<200310281848.26163.davidb@verisignlabs.com>
	<20031029154141.GA27166@chinook.rgy.netsol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 18:34:02 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20031029154141.GA27166@chinook.rgy.netsol.com> (Matt Larson's
 message of "Wed, 29 Oct 2003 10:41:41 -0500")
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix)
Precedence: bulk

And here it is.  :)







   DNSEXT Working Group                                      Michael Graff
   INTERNET-DRAFT                                                      ISC
   <draft-graff-dnsext-nxt-extend.txt>                       October, 2003


                Extensions to NXT records for all rdata types


   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

   Abstract

      This document specifies a format for NXT records which allows NXT
      records to specify any rdata type as covered by the NXT, rather than
      being limited to the first 127 types.

   1 - Rationale and Scope

   1.1. Currently, NXT records can only describe the first 127 rdata types
   (1 through 127.)

   1.2. Several rdata types are in use by vendors which cannot be covered
   by existing NXT records.  Additionally, the experimental range cannot be
   covered.





   Expires April 2004                                      FORMFEED[Page 1]





   INTERNET-DRAFT                   NXT-EXT                   October, 2003


   1.3. The DNS rdata code space usage is expected to grow.  Rolling out
   new formats for rdata types is difficult operationally.  Making the NXT
   record support the future is important before widespread deployment of
   DNSSEC prevents such extensions.

   1.4. The existing NXT record format allows for extension by setting bit
   0 to one.

   2 - Affected Protocol Elements

   2.1. Bit 0 of the first byte in the NXT record rdata indicates this is
   an extended NXT record.

   3 - Compatibility with existing servers

   3.1. Older servers will not understand this format.

   3.2. This extension uses the mechanism provided in the NXT rdata format
   of RFC2535.

   4 - Extended NXT rdata format

   4.1. The extended NXT rdata begins with the high order bit set in the
   first byte and the two low-order bits indicate which format the NXT data
   is encoded using.  All other bits MUST be set to zero.

          +---+---+---+---+---+---+---+---+
      0   | 1 | R | R | R | R | R | R | F | 8
          +---+---+---+---+---+---+---+---+


   R  Reserved bits.  MUST be set to 0 when transmitting to allow
      extensions.

   F  The encoding format used.  0 indicates a simple list of 16-bit type
      codes.  1 indicates a slightly compressed type code list.

   5 - Format 0: 16 bit type code list

   5.1. The data is a simple list of 16-bit type codes, listed in
   increasing value.







   Expires April 2004                                      FORMFEED[Page 2]





   INTERNET-DRAFT                   NXT-EXT                   October, 2003


          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0   |                           RDATA_TYPE                          | 16
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


   RDATA_TYPE
      The 16-bit type codes defined in various RFCs.

   5.2.  For example, if a NXT contains SIG (24), NXT (30), A (1), TXT
   (16), MX (15), and type 0xff45 types, the 16-bit values will be encoded
   as:

            0x0001 0x000f 0x0010 0x0018 0x001e 0xff45


   6 - Format 1: compressed type code list

   6.1. This format uses a simple compression method to factor out the
   first 8 bits of a prefix code for a group of codes.  This is done by
   specifying a one-byte count, a one-byte prefix, and "count" bytes of
   low-order data.

          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0   |             COUNT             |           HIGH-ORDER          | 16
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
          |       Data...          |    ...                 |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


   COUNT
      This value indicates how many type codes follow which use the high-
      order value.  A count of 0 indicates that no "data" bytes follow but
      all 256 possible rdata type codes exist for this high-order value.
      Values between 1 and 128 indicate the types are present, and there
      are 1 to 128 octets that follow.  Values of 129 through 255 indicate
      that 256 - count octets follow, and they specify type codes NOT
      present.

   HIGH-ORDER
      The upper 8 bits of the type codes, listed in increasing value.

   Data
      "count" bytes to supply the low-order type code data, listed in
      increasing value.




   Expires April 2004                                      FORMFEED[Page 3]





   INTERNET-DRAFT                   NXT-EXT                   October, 2003


   6.2. For example, the coding for a record containing A, MX, TXT, SIG,
   NXT, and type 0xff45:

           0x05 0x00 0x01 0x0f 0x10 0x18 0x1e 0x01 0xff 0x45












































   Expires April 2004                                      FORMFEED[Page 4]





   INTERNET-DRAFT                   NXT-EXT                   October, 2003


   7 - References

   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1035, USC/Information Sciences
              Institute, November 1987.

   [RFC2535]  D. Eastlake, ``Domain Name System Security Extensions,'' RFC
              2535, IBM, March 1999.

   8 - Author's Address

                 Michael Graff
                    Internet Software Consortium
                    950 Charter Street
                    Redwood City, CA 94063
                    +1 650.423.1304
                    <Michael_Graff@isc.org>































   Expires April 2004                                      FORMFEED[Page 5]



--
to 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:43 2006
From: Michael Graff <Michael_Graff@isc.org>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 17:41:40 +0000
Lines: 10
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<200310281647.45423.davidb@verisignlabs.com>
	<Pine.GSO.4.55.0310282333050.4801@filbert>
	<200310281848.26163.davidb@verisignlabs.com>
	<20031029154141.GA27166@chinook.rgy.netsol.com>
	<s9s4qxsrmc2.fsf@farside.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 18:53:06 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Michael Graff <Michael_Graff@isc.org>
In-Reply-To: <s9s4qxsrmc2.fsf@farside.isc.org> (Michael Graff's message of
 "Wed, 29 Oct 2003 17:21:49 +0000")
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix)
Precedence: bulk

And of course, please s/NXT/NSEC/ -- this was written before the
proposed typecode roll names were set in mud.

--Michael

--
to 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:43 2006
From: Stephen Jacob <Stephen.Jacob@nominum.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 10:17:36 -0800
Organization: Nominum, Inc.
Lines: 80
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <Pine.GSO.4.55.0310282333050.4801@filbert> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <s9s4qxsrmc2.fsf@farside.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 19:29:26 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Michael Graff <Michael_Graff@isc.org>
Content-Disposition: inline
In-Reply-To: <s9s4qxsrmc2.fsf@farside.isc.org>
X-message-flag: MS Outlook sucks. If you must use Windows, try Eudora.
X-URI: http://www.nominum.com/
X-URI-Personal: http://www.sjacob.org/
User-Agent: Mutt/1.5.4i
Precedence: bulk

Hi Michael,

On Wed, Oct 29, 2003 at 05:21:49PM +0000, Michael Graff wrote:
>    4.1. The extended NXT rdata begins with the high order bit set in the
>    first byte and the two low-order bits indicate which format the NXT data
>    is encoded using.  All other bits MUST be set to zero.
> 
>           +---+---+---+---+---+---+---+---+
>       0   | 1 | R | R | R | R | R | R | F | 8
>           +---+---+---+---+---+---+---+---+
> 
> 
>    R  Reserved bits.  MUST be set to 0 when transmitting to allow
>       extensions.
> 
>    F  The encoding format used.  0 indicates a simple list of 16-bit type
>       codes.  1 indicates a slightly compressed type code list.

Is the text correct or is the diagram correct? I think the diagram
is correct, based on the subsequent text, but the text in the initial
paragraph of 4.1 says, "...the two low-order bits indicate which
format...", but it seems to be suggested elsewhere that this should
be, "...the low-order bit indicates which format...".

Actually, to me "most significant bit" and "least significant bit"
are clearer than "high[est]-order bit" or "low[est]-order bit".

>    6 - Format 1: compressed type code list
> 
>    6.1. This format uses a simple compression method to factor out the
>    first 8 bits of a prefix code for a group of codes.  This is done by
>    specifying a one-byte count, a one-byte prefix, and "count" bytes of
>    low-order data.
> 
>           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>       0   |             COUNT             |           HIGH-ORDER          | 16
>           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>           |       Data...          |    ...                 |
>           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Since the "Data..." are specifically 8-bit quantities, and not
variable bit-length quantities, it might be better to re-do this
figure. Perhaps something like:

          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0   |             COUNT             |           HIGH-ORDER          | 16
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
          |             DATA              |             DATA              |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
          |             DATA              |            ...
          +---+---+---+---+---+---+---+---+

Or perhaps better (since showing it as 16 bits wide might suggest
that there had to be an even number of data), something like:

          +---+---+---+---+---+---+---+---+
      0   |             COUNT             |   8
          +---+---+---+---+---+---+---+---+
          |           HIGH-ORDER          |
          +---+---+---+---+---+---+---+---+
          |             DATA              |
          +---+---+---+---+---+---+---+---+
          |             DATA              |
          +---+---+---+---+---+---+---+---+
          .                               .
          .                               .
          .                               .
          +---+---+---+---+---+---+---+---+

Regards,
sj
-- 
 Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051
 Nominum, Inc. | http://www.nominum.com/ | "Communication by Name"

--
to 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:43 2006
From: Michael Graff <Michael_Graff@isc.org>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 18:33:37 +0000
Lines: 29
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<200310281647.45423.davidb@verisignlabs.com>
	<Pine.GSO.4.55.0310282333050.4801@filbert>
	<200310281848.26163.davidb@verisignlabs.com>
	<20031029154141.GA27166@chinook.rgy.netsol.com>
	<s9s4qxsrmc2.fsf@farside.isc.org>
	<20031029181736.GB50160@shell-ng.nominum.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 Oct 29 19:44:12 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Stephen Jacob <Stephen.Jacob@nominum.com>
In-Reply-To: <20031029181736.GB50160@shell-ng.nominum.com> (Stephen Jacob's
 message of "Wed, 29 Oct 2003 10:17:36 -0800")
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix)
Precedence: bulk

Stephen Jacob <Stephen.Jacob@nominum.com> writes:

> Is the text correct or is the diagram correct? I think the diagram
> is correct, based on the subsequent text, but the text in the initial
> paragraph of 4.1 says, "...the two low-order bits indicate which
> format...", but it seems to be suggested elsewhere that this should
> be, "...the low-order bit indicates which format...".

The diagram is correct.  There used to be additional encodings, but
they didn't seem worth it for how complicated they became.

> Actually, to me "most significant bit" and "least significant bit"
> are clearer than "high[est]-order bit" or "low[est]-order bit".

Noted.

> Since the "Data..." are specifically 8-bit quantities, and not
> variable bit-length quantities, it might be better to re-do this
> figure. Perhaps something like:

Thanks much.  I'll see what I can do there.  :)

--Michael

--
to 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:43 2006
From: Simon Josefsson <jas@extundo.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 20:35:54 +0100
Lines: 24
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.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 Oct 29 20:51:15 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: David Blacka <davidb@verisignlabs.com>
X-Payment: hashcash 1.2 0:031029:davidb@verisignlabs.com:e273a20d16d5b43c
X-Hashcash: 0:031029:davidb@verisignlabs.com:e273a20d16d5b43c
X-Payment: hashcash 1.2 0:031029:namedroppers@ops.ietf.org:dc8f90dc6c5ea593
X-Hashcash: 0:031029:namedroppers@ops.ietf.org:dc8f90dc6c5ea593
In-Reply-To: <200310281402.41950.davidb@verisignlabs.com> (David Blacka's
 message of "Tue, 28 Oct 2003 14:02:41 -0500")
User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)
Precedence: bulk

David Blacka <davidb@verisignlabs.com> writes:

> Currently the NSEC record (nee NXT) can only support typecodes up to
> 127 (dnssec-records-05, section 4.1.2).  However, the type field in
> DNS is actually 16 bits long.
>
> While this situation has been true for as long as I've been looking at
> DNSSEC, and presumably since its inception, this is an issue that
> seems to have been totally ignored by this WG.

The now expired proposed NXT replacement draft at
<http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt> address
that problem, and a few other problems with NXT that haven't been
addressed (nor firmly acknowledged as problems, for that matter).

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:43 2006
From: Brian Wellington <Brian.Wellington@nominum.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 12:28:13 -0800 (PST)
Lines: 27
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
 <200310281647.45423.davidb@verisignlabs.com> <Pine.GSO.4.55.0310282333050.4801@filbert>
 <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com>
 <s9s4qxsrmc2.fsf@farside.isc.org> <s9soew0hrfv.fsf@farside.isc.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 21:40:46 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: incognito.ddns.nominum.com: bwelling owned process doing -bs
X-X-Sender: bwelling@incognito.ddns.nominum.com
To: Michael Graff <Michael_Graff@isc.org>
In-Reply-To: <s9soew0hrfv.fsf@farside.isc.org>
Precedence: bulk

On Wed, 29 Oct 2003, Michael Graff wrote:

> And of course, please s/NXT/NSEC/ -- this was written before the
> proposed typecode roll names were set in mud.

Given that the typecodes are being rolled, we might want to consider 
removing the old format completely, and coming up with a new, sane format 
that doesn't have any problem representing all types within the type 
code space.

The compressed format in this document seems like it does that, and it's 
fairly efficient for typical cases.

Do we really need multiple encodings, and backwards compatibility with a
record of a different type?

I propose that we standardize on this (or something better, if anyone has 
a better idea) as the only format and get rid of versioning.

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:43 2006
From: Daniel Massey <masseyd@ISI.EDU>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 15:24:41 -0500
Lines: 114
Sender: owner-namedroppers@ops.ietf.org
References: <s9s4qxsrmc2.fsf@farside.isc.org>
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Daniel Massey <masseyd@ISI.EDU>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 21:40:47 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Michael Graff <Michael_Graff@isc.org>
In-Reply-To: <s9s4qxsrmc2.fsf@farside.isc.org>
X-Mailer: Apple Mail (2.552)
Precedence: bulk


On Wednesday, October 29, 2003, at 12:21  PM, Michael Graff wrote:
>
>    3 - Compatibility with existing servers
>
>    3.1. Older servers will not understand this format.
>
>    3.2. This extension uses the mechanism provided in the NXT rdata 
> format
>    of RFC2535.
>
>    4 - Extended NXT rdata format
>
>    4.1. The extended NXT rdata begins with the high order bit set in 
> the
>    first byte and the two low-order bits indicate which format the NXT 
> data
>    is encoded using.  All other bits MUST be set to zero.
>
>

I think there is a basic problem with having multiple formats.  
Consider the following:

Query:  www.example. A
Response: NO DATA
           www.example. NSEC with zero bit set to 1 (format whatever)
           www.example. SIG(NSEC) by example DNSKEY

The SIG authenticates the NSEC, but the resolver doesn't understand the 
format....   what happens?  Note the resolver is just asking for a 
plain old A record.    The server had to use one of the alternate 
formats since some RR type > 127 is present at www.example and setting 
zero bit = 0 was not an option at the server.    The resolver has no 
way of knowing whether this response proves no A RR exists.   (it could 
be an attacker is sending the NSEC proving the A RR **does** exist, 
knowing the resolver doesn't understand the extended format).

I think what you will find is that in the current term, very few people 
implement the alternate formats for what to do if RR types > 127.   
Fewer still will have really tested these formats so we know they 
work....    As a result when someone adds the first type >127, queries 
for things like A records and DS records can stop working.  If large 
vendor X has failed to implement the >127 type map or discovers it has 
a flaw in this type second (or third or fourth) type map, what do you 
do?   the software won't even be stressed in real conditions until 
years from now...


I have yet another alternate suggestion that handles all type codes, 
but ensures that the process rules for the current types < 127 never 
change:

Type 128 is the FOO record.    The FOO record MUST be present at a name 
if any RR type greater than 128 exists at that name and this record 
lists the types greater than 128 stored at this name.  The FOO record 
MUST NOT be present at a name if no type greater than 128 exists at 
that name. The format of the FOO record is to be defined by a standards 
action if/when the RR type space exceeds 128.

If the query type < 127, do what protocol doc currently says.   If the 
query type > 127 and the answer is no data, do what the protocol do c 
currently says and also the server SHOULD include the FOO RR in the 
response.

If the NSEC zero bit is set in the response, RR types greater than 128 
are present at this name.  If these types are meaningful to the 
resolver, the FOO record indicates which types >127 are present at this 
name.   Queries for types less than 127 are still authenticated 
according the rules above.   If a query that requests types greater 
than 127 and the answer is no data, the FOO record is used to prove the 
requested type does not exist.

For the current doc set, issue done.   Anyone with strong opinions on 
how to encode the type field for types beyond 128, write a FOO record 
draft, but we don't need FOO defined to advance this doc set.   If no 
one writes the FOO record, somewhere down the road the first person to 
define a type greater than 128 is stuck with defining the FOO RR :) 
Note software that has been upgraded to understand the new type > 128 
will need to also be upgraded to understand the new FOO record.   Old 
software (ie today's stuff) will always be able to work fine for all 
types < 128 and will be backwards compatible.

For example, with the FOO RR:

Query:  www.example. A
Response: NO DATA
           www.example. NSEC with zero bit set to 1
           www.example. SIG(NSEC) by example DNSKEY

A resolver looking for the A record can doesn't care the zero bit is 
set to 1.   The current bit map indicates no A record exists.  This 
will always work regardless of what happens due to any increase in the 
type space.

Query: www.example type150
Response:  NO DATA
            www.example. NSEC with zero bit set to 1.
            www.example. SIG(NSEC) by example DNSKEY
            www.example. FOO (indicating what types > 127 exist at 
www.example)
            www.example. SIG(FOO) by example DNSKEY

A resolver looking for the type150 record needs to understand the FOO 
RR.

Dan


--
to 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:43 2006
From: Matt Larson <mlarson@verisign.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 15:41:01 -0500
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <s9s4qxsrmc2.fsf@farside.isc.org> <ED0C26DC-0A4D-11D8-A3BA-000393C783A2@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Michael Graff <Michael_Graff@isc.org>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 21:53:54 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Daniel Massey <masseyd@ISI.EDU>
Content-Disposition: inline
In-Reply-To: <ED0C26DC-0A4D-11D8-A3BA-000393C783A2@isi.edu>
User-Agent: Mutt/1.5.4i
Precedence: bulk

On Wed, 29 Oct 2003, Daniel Massey wrote:
> The SIG authenticates the NSEC, but the resolver doesn't understand the 
> format....   what happens?

I believe this issue will be taken care of by rolling the type codes
and the RFC2535bis documents.  The new documents will specify the new
behavior, which any RFC2535bis-compliant implementation will have to
follow.  We've already sacrificed any backward compatibility and a
fully specified NSEC record that can handle typecodes past 128 is just
another backward incompatibility.

> Type 128 is the FOO record.    The FOO record MUST be present at a name 
> if any RR type greater than 128 exists at that name and this record 
> lists the types greater than 128 stored at this name.

This idea is an ingenious way to cope with the current situation, but
it's a terrible hack.  Let's spend the effort to fix NSEC instead.

Matt

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: Daniel Massey <masseyd@ISI.EDU>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 15:43:32 -0500
Lines: 69
Sender: owner-namedroppers@ops.ietf.org
References: <ED0C26DC-0A4D-11D8-A3BA-000393C783A2@isi.edu>
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Michael Graff <Michael_Graff@isc.org>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 21:56:11 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Daniel Massey <masseyd@ISI.EDU>
In-Reply-To: <ED0C26DC-0A4D-11D8-A3BA-000393C783A2@isi.edu>
X-Mailer: Apple Mail (2.552)
Precedence: bulk

Hi,

After some discussions, here is a summary of the various previously 
proposed solutions for large typecodes:

fixed limit options:
a       NSEC only covers up to 127 (by fiat) [0]
b       NSEC expands bit mask to 512/1024 or some other higher number. 
[3]

order list options
c       NSEC covers 1-127 with bit mask and "ordered list" after that. 
[4]
d       NSEC with bit 0 set is turned into "ordered list" [1]
e       NSECbis has "ordered list" and replaces NSEC [2]

other extensions
f       NSEC covers types 1-127 and a FOO extends coverage for 129-n  
[5]

Historical Footnotes:
[0] The bit field was proposed for efficiency reasons.
[1] This is what Andreas proposed in 1997,
[2] This was proposed to Sam when he started the TCR draft.
[3] Original DNSSEC spec had typecode bitmap unrestricted, due to [1] 
and size concerns related to Truncation and OS vendor use of types in 
the 64xxx space, the restriction and bit 0 was put in.
[4] This was also proposed in the 1997 after [3] was put forward.
[5] This is yet another option from the previous message.

To close the records and protocol doc, consensus on one option is 
needed.   From a document editing perspective, quick consensus would be 
very very welcome.  (Note prior to this, last call seemed in sight for 
the records doc)

In my personal view....

One fundamental problem is that if there are multiple type field 
variations, it is possible implementations will not understand them all 
and it is probable that the code path for one of the type fields has a 
bug.  In particular, suppose we allow multiple type fields and someone 
implements only the 127 bit format current in records (or implements 
the other fields incorrectly, but it is not tested since types are < 
127).   Everything works great for now with types < 127, but when the 
first RR type greater than 127 is added, suddenly the altnerate NSEC RR 
formats are needed to correctly process A record queries.  types will 
roll....   My plea is we pick an encoding of the type field such that 
there is one and only one method to authenticate non-existence of the 
good old A record (as well as other current types like DS records).  
this method must work now and still work if the type space exceeds 127.

For the ordered list options, I would also hope that the ordering is 
not overly complex.   The type space may grow, but hopefully the number 
of records types at a given name will not stretch in into the thousands 
or even dozens.    A simple list is more likely be done correctly.

Under these criteria, option c, e and f work.  options a and b postpone 
the problem to when the space type space grows large.  option d creates 
multiple code paths for authenticated denial of existence for the good 
old A record.

Dan


--
to 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:43 2006
From: gson@nominum.com (Andreas Gustafsson)
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 12:52:37 -0800 (PST)
Lines: 32
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<200310281647.45423.davidb@verisignlabs.com>
	<Pine.GSO.4.55.0310282333050.4801@filbert>
	<200310281848.26163.davidb@verisignlabs.com>
	<20031029154141.GA27166@chinook.rgy.netsol.com>
	<s9s4qxsrmc2.fsf@farside.isc.org>
	<s9soew0hrfv.fsf@farside.isc.org>
	<Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 22:04:31 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
X-Mailer: VM 7.04 under Emacs 20.7.1
Precedence: bulk

Brian Wellington writes:
> Given that the typecodes are being rolled, we might want to consider 
> removing the old format completely, and coming up with a new, sane format 
> that doesn't have any problem representing all types within the type 
> code space.
> 
> The compressed format in this document seems like it does that, and it's 
> fairly efficient for typical cases.
>  [...]
> I propose that we standardize on this (or something better, if anyone has 
> a better idea) as the only format and get rid of versioning.

I agree.  Given that the RR type is changing, keeping the old format
is pointless.

There is also the issue that any scheme that allows the server to
freely choose between multiple alternative wire encodings will not
actually work.  This is because DNSSEC signatures are calculated by
hashing the wire-format data, under the assumption that every RR has a
single, unique wire encoding.  If you allow multiple alternative
encodings, you can end up with a situation where the signer calculates
the signatures using one encoding but the name server sends the NSEC
records using a different encoding, and the signatures will fail to
match.
-- 
Andreas Gustafsson, gson@nominum.com

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 23:33:28 +0100 (CET)
Lines: 15
Sender: owner-namedroppers@ops.ietf.org
References: <ED0C26DC-0A4D-11D8-A3BA-000393C783A2@isi.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Michael Graff <Michael_Graff@isc.org>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Oct 29 23:50:33 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: Daniel Massey <masseyd@ISI.EDU>
In-Reply-To: <ED0C26DC-0A4D-11D8-A3BA-000393C783A2@isi.edu>
Precedence: bulk

> Type 128 is the FOO record.    The FOO record MUST be present at a name

How do you prove that there should or shouldn't be a FOO?  And the FOO
would have to be added to wildcard proofs, too.  This is too messy.

Let's just change the NSEC format.

-- 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:43 2006
From: Daniel Massey <masseyd@ISI.EDU>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 18:22:03 -0500
Lines: 47
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.GSO.4.55.0310292328320.29730@filbert>
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Daniel Massey <masseyd@ISI.EDU>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 00:38:28 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Samuel Weiler <weiler@tislabs.com>
In-Reply-To: <Pine.GSO.4.55.0310292328320.29730@filbert>
X-Mailer: Apple Mail (2.552)
Precedence: bulk


On Wednesday, October 29, 2003, at 05:33  PM, Samuel Weiler wrote:

>> Type 128 is the FOO record.    The FOO record MUST be present at a 
>> name
>
> How do you prove that there should or shouldn't be a FOO?

this is bit zero in the NSIG.
bit zero = 1 proves there are types greater than 127 at this name (and 
proves there is a FOO RR that lists these types)
bit zero = 0 proves there are no type greater than 127 at this name 
(and proves there is no FOO RR at the name)

> And the FOO
> would have to be added to wildcard proofs, too.

the wildcard proof still relies on NSEC records.  You use the algorithm 
discussed the current protocol draft to prove whether the name 
exists/whether the wildcard applies.   At the end of the current NSEC 
proof, if the answer you seek is type > 127, you need the FOO RR to 
prove the type does/does not exist.

> This is too messy.
> Let's just change the NSEC format.
>
>
it is unquestionably ugly.   the intent is to make things work in the 
scenario that says:
   use format X if all type codes at this name are less than 127,
   use format Y if some types codes at this name are above 127,
   use format Z the zone is signed on tuesday, your master server has a 
black case, and your favorite type number is 3
this way lies madness and FOO RRs :)   but this is also the current 
approach and the FOO RR is intended only to make that madness work.

the clean fix is to scrap the existing format and define a **single** 
format for the NSEC type field that works for all RR types.

Dan


--
to 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:43 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 23:44:48 +0100 (CET)
Lines: 30
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
 <200310281647.45423.davidb@verisignlabs.com> <Pine.GSO.4.55.0310282333050.4801@filbert>
 <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com>
 <s9s4qxsrmc2.fsf@farside.isc.org> <s9soew0hrfv.fsf@farside.isc.org>
 <Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
 <200310292052.h9TKqbAp016451@guava.araneus.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 01:18:01 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: Andreas Gustafsson <gson@nominum.com>
In-Reply-To: <200310292052.h9TKqbAp016451@guava.araneus.fi>
Precedence: bulk

> There is also the issue that any scheme that allows the server to
> freely choose between multiple alternative wire encodings will not
> actually work.  This is because DNSSEC signatures are calculated by

If Andreas is right, and I think he is, then David's strawcritter:

> - use the remaining 7 bits in the first octet as a count of
> single-byte typecodes, called N.  The next N octets are an ordered
> list of 8-bit integers representing typecodes <= 255.  The remaining
> RDATA is an ordered list of 16-bit big-endian unsigned integers,
> each representing one type present.

may open the door to ambiguity -- can one set N=0 and list codes 3, 5,
and 7 in the 16-bit portion?  Micheal's format 1 may have the same
problem.

Is there anything wrong with the ordered list of 16-bit values
proposed separately by Rob and Micheal (format 0)?  Since the bits for
NSEC and RRSIG then take up space, do we want to make them implicit?
We could turn the silly-state language around and say "if either of
these typecodes is explicitly listed, treat this name as unsecured".

-- 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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 20:19:33 -0500
Lines: 29
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<200310281647.45423.davidb@verisignlabs.com>
	<Pine.GSO.4.55.0310282333050.4801@filbert>
	<200310281848.26163.davidb@verisignlabs.com>
	<20031029154141.GA27166@chinook.rgy.netsol.com>
	<s9s4qxsrmc2.fsf@farside.isc.org>
	<s9soew0hrfv.fsf@farside.isc.org>
	<Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
	<200310292052.h9TKqbAp016451@guava.araneus.fi>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 02:35:41 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <200310292052.h9TKqbAp016451@guava.araneus.fi>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

At Wed, 29 Oct 2003 12:52:37 -0800 (PST), Andreas Gustafsson wrote:
> ...
> There is also the issue that any scheme that allows the server to
> freely choose between multiple alternative wire encodings will not
> actually work.  This is because DNSSEC signatures are calculated by
> hashing the wire-format data, under the assumption that every RR has a
> single, unique wire encoding.  If you allow multiple alternative
> encodings, you can end up with a situation where the signer calculates
> the signatures using one encoding but the name server sends the NSEC
> records using a different encoding, and the signatures will fail to
> match.

You appear to be assuming some form of RDATA transcoding.  We have
that problem for certain well-known types containing DNS names due to
ancient history, but I don't understand why we would allow it here.
So long as the RRset received matches the RRset sent, the signatures
should match.

sig(2) == sig(2).  sig(ii) == sig(ii).  The fact that "2" and "ii" are
different ways of writing the number two shouldn't matter unless
somebody's translating from arabic to roman numbering en route.

At least one of us is confused.

--
to 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:43 2006
From: Brian Wellington <Brian.Wellington@nominum.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 17:52:45 -0800 (PST)
Lines: 40
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
 <200310281647.45423.davidb@verisignlabs.com> <Pine.GSO.4.55.0310282333050.4801@filbert>
 <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com>
 <s9s4qxsrmc2.fsf@farside.isc.org> <s9soew0hrfv.fsf@farside.isc.org>
 <Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
 <200310292052.h9TKqbAp016451@guava.araneus.fi> <Pine.GSO.4.55.0310292335460.29730@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 03:03:54 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: incognito.ddns.nominum.com: bwelling owned process doing -bs
X-X-Sender: bwelling@incognito.ddns.nominum.com
To: Samuel Weiler <weiler@tislabs.com>
In-Reply-To: <Pine.GSO.4.55.0310292335460.29730@filbert>
Precedence: bulk

On Wed, 29 Oct 2003, Samuel Weiler wrote:

> > There is also the issue that any scheme that allows the server to
> > freely choose between multiple alternative wire encodings will not
> > actually work.  This is because DNSSEC signatures are calculated by
> 
> If Andreas is right, and I think he is, then David's strawcritter:
> 
> > - use the remaining 7 bits in the first octet as a count of
> > single-byte typecodes, called N.  The next N octets are an ordered
> > list of 8-bit integers representing typecodes <= 255.  The remaining
> > RDATA is an ordered list of 16-bit big-endian unsigned integers,
> > each representing one type present.
> 
> may open the door to ambiguity -- can one set N=0 and list codes 3, 5,
> and 7 in the 16-bit portion?  Micheal's format 1 may have the same
> problem.

Both of the formats in Michael's proposal include the phrase 'in 
increasing value.'  This should make the representation unique, as long as 
only one format is chosen.

> Is there anything wrong with the ordered list of 16-bit values
> proposed separately by Rob and Micheal (format 0)?  Since the bits for
> NSEC and RRSIG then take up space, do we want to make them implicit?
> We could turn the silly-state language around and say "if either of
> these typecodes is explicitly listed, treat this name as unsecured".

Adding special cases for RRSIG and NSEC is confusing.  Using a 16 bit
value is fine also.  The only difference is that the compressed method
allows all combinations of the 64K type codes to be represented without
exceeding the 64K limit for rdata, not that this really matters.

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:43 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Large typecodes and DNSSEC
Date: Thu, 30 Oct 2003 01:45:43 +0000
Lines: 16
Sender: owner-namedroppers@ops.ietf.org
References: <sra+namedroppers@hactrn.net>
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 03:33:06 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Rob Austein <sra+namedroppers@hactrn.net> 
	of "Wed, 29 Oct 2003 20:19:33 EST."
	<20031030011933.2887D18F3@thrintun.hactrn.net> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> You appear to be assuming some form of RDATA transcoding.  ...

yes.

> sig(2) == sig(2).  sig(ii) == sig(ii).  The fact that "2" and "ii" are
> different ways of writing the number two shouldn't matter unless
> somebody's translating from arabic to roman numbering en route.

a cache who converted an rdata from wire format to host-byte-order and
regenerated the wire format when queried for it could have that property.

--
to 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:43 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 21:45:23 -0500
Lines: 58
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <Pine.GSO.4.55.0310282333050.4801@filbert> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <s9s4qxsrmc2.fsf@farside.isc.org> <s9soew0hrfv.fsf@farside.isc.org> <Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> <20031030011933.2887D18F3@thrintun.hactrn.net>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 03:58:45 2003
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <20031030011933.2887D18F3@thrintun.hactrn.net>
To: namedroppers@ops.ietf.org
X-Mailer: Apple Mail (2.606)
Precedence: bulk


On Oct 29, 2003, at 8:19 PM, Rob Austein wrote:

> At Wed, 29 Oct 2003 12:52:37 -0800 (PST), Andreas Gustafsson wrote:
>> ...
>> There is also the issue that any scheme that allows the server to
>> freely choose between multiple alternative wire encodings will not
>> actually work.  This is because DNSSEC signatures are calculated by
>> hashing the wire-format data, under the assumption that every RR has a
>> single, unique wire encoding.  If you allow multiple alternative
>> encodings, you can end up with a situation where the signer calculates
>> the signatures using one encoding but the name server sends the NSEC
>> records using a different encoding, and the signatures will fail to
>> match.
>
> You appear to be assuming some form of RDATA transcoding.  We have
> that problem for certain well-known types containing DNS names due to
> ancient history, but I don't understand why we would allow it here.
> So long as the RRset received matches the RRset sent, the signatures
> should match.
>
> sig(2) == sig(2).  sig(ii) == sig(ii).  The fact that "2" and "ii" are
> different ways of writing the number two shouldn't matter unless
> somebody's translating from arabic to roman numbering en route.
>
> At least one of us is confused.

I think what Andreas is talking about is this:  If there are two 
equally valid wire representations of the same record, there exists a 
possibility for say, the signer to do it one way, and the nameserver to 
encode it another.  Since the textual representation is the same either 
way, there is nothing to prevent this.

However, having multiple NSEC typecode formats is not a problem per se. 
  The issue is that all DNSSEC software must encode a particular NSEC 
record the exact same way.  This could be accomplished by saying 
something like: use format 1 when no typecodes > 127, format 2 
otherwise.

But, that being said, I can see no good reason for having more than one 
format in any case.

I think what we are looking for in a format is:

   * easy to understand.
   * easy to implement.
   * reasonably space efficient for "common" cases.

--
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:43 2006
From: gson@nominum.com (Andreas Gustafsson)
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 18:44:20 -0800 (PST)
Lines: 67
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<200310281647.45423.davidb@verisignlabs.com>
	<Pine.GSO.4.55.0310282333050.4801@filbert>
	<200310281848.26163.davidb@verisignlabs.com>
	<20031029154141.GA27166@chinook.rgy.netsol.com>
	<s9s4qxsrmc2.fsf@farside.isc.org>
	<s9soew0hrfv.fsf@farside.isc.org>
	<Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
	<200310292052.h9TKqbAp016451@guava.araneus.fi>
	<20031030011933.2887D18F3@thrintun.hactrn.net>
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 03:59:17 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Rob Austein <sra+namedroppers@hactrn.net>
In-Reply-To: <20031030011933.2887D18F3@thrintun.hactrn.net>
X-Mailer: VM 7.04 under Emacs 20.7.1
Precedence: bulk

Rob Austein writes:
> At Wed, 29 Oct 2003 12:52:37 -0800 (PST), Andreas Gustafsson wrote:
> > There is also the issue that any scheme that allows the server to
> > freely choose between multiple alternative wire encodings will not
> > actually work.  This is because DNSSEC signatures are calculated by
> > hashing the wire-format data, under the assumption that every RR has a
> > single, unique wire encoding.  If you allow multiple alternative
> > encodings, you can end up with a situation where the signer calculates
> > the signatures using one encoding but the name server sends the NSEC
> > records using a different encoding, and the signatures will fail to
> > match.
> 
> You appear to be assuming some form of RDATA transcoding.  We have
> that problem for certain well-known types containing DNS names due to
> ancient history, but I don't understand why we would allow it here.
> So long as the RRset received matches the RRset sent, the signatures
> should match.

I'm not sure what you mean by "transcoding".  The RRset received is
identical to the one sent.

The problem is that the sequence of bytes over which the DNSSEC signer
calculates the signature when signing the zone can be different from
the sequence of bytes over which the resolver calculates the signature
when validating a response.

For example, suppose we have a domain name "zz." which is the last
name in the root zone, with only an A record and (after signing) an
NSEC record. Then the DNSSEC signer will insert an NSEC record of the
form

zz. NSEC . A NSEC

Suppose the signer chooses to represent this using the classic RFC2535
bitmap representation.  Then it will internally create an NSEC RDATA
containing the bytes

  00 40 00 00 00 00 00 80

and SIG NSEC record containing the signature of those bytes.
The signer writes the NSEC and SIG NSEC records to a signed master file.

The signed master file is then loaded by a master server.  Suppose the
master server chooses to represent this same NSEC record using Michael
Graff's uncompressed 16-bit wire format.  When queried, it will send
an NSEC RR with an RDATA of

  00 80 00 01 00 30

along with a SIG NSEC record that was calculated by the signer under
the assumption that the RDATA is 00 40 00 00 00 00 00 80.  When the
resolver attempts to validate the response, it calculates a signature
over the bytes 00 80 00 01 00 30.  This signature will then fail to
match the one in the SIG NSEC.

The byte sequences in the example above were constructed by hand in a
hurry and may not have all the right bits set, but that should not
detract from my point, that the signatures calculated by different
parties of the protocol can end up being different.
-- 
Andreas Gustafsson, gson@nominum.com

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: masataka ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Reality check (was Re: Wildcard NS and DNSSEC)
Date: Thu, 30 Oct 2003 13:13:39 +0900
Lines: 25
Sender: owner-namedroppers@ops.ietf.org
References: <20031027142404.GB15077@atoom.net>	<200310282352.h9SNqI8Y001833@drugs.dv.isc.org> <20031029012822.C263718DD@thrintun.hactrn.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 Oct 30 05:30:34 2003
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: Rob Austein <sra+namedroppers@hactrn.net>
In-Reply-To: <20031029012822.C263718DD@thrintun.hactrn.net>
Precedence: bulk

Rob Austein;

> just forbid wildcard ns and move along, aye.

I do love simple approaches.

However, in this case, the complexity is not in wildcard but
in DNSSEC.

So, the proper question is

	do we need DNSSEC?

and the reality is that we don't.

Just discard DNSSEC and move along.

						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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 23:32:29 -0500
Lines: 8
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<200310281647.45423.davidb@verisignlabs.com>
	<Pine.GSO.4.55.0310282333050.4801@filbert>
	<200310281848.26163.davidb@verisignlabs.com>
	<20031029154141.GA27166@chinook.rgy.netsol.com>
	<s9s4qxsrmc2.fsf@farside.isc.org>
	<s9soew0hrfv.fsf@farside.isc.org>
	<Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
	<200310292052.h9TKqbAp016451@guava.araneus.fi>
	<20031030011933.2887D18F3@thrintun.hactrn.net>
	<200310300244.h9U2iKSx023479@guava.araneus.fi>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 06:14:47 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <200310300244.h9U2iKSx023479@guava.araneus.fi>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

Ok, I was the one who was confused.  Right, if the signer and the name
server use different encodings, it doesn't work.  Thanks.

--
to 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:43 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Thu, 30 Oct 2003 18:11:14 +0100 (CET)
Lines: 26
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
 <200310281647.45423.davidb@verisignlabs.com> <Pine.GSO.4.55.0310282333050.4801@filbert>
 <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com>
 <s9s4qxsrmc2.fsf@farside.isc.org> <s9soew0hrfv.fsf@farside.isc.org>
 <Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
 <200310292052.h9TKqbAp016451@guava.araneus.fi> <20031030011933.2887D18F3@thrintun.hactrn.net>
 <1C36E0D0-0A83-11D8-B7A1-000393A3322E@verisignlabs.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 18:32:53 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <1C36E0D0-0A83-11D8-B7A1-000393A3322E@verisignlabs.com>
Precedence: bulk

Discussion seems to have died down.  David's criteria seem reasonable:

>    * easy to understand.
>    * easy to implement.
>    * reasonably space efficient for "common" cases.

So I'll ask the following again:

1) Is there anything wrong with the ordered list of 16-bit values
proposed separately by Rob and Micheal (format 0)?

2) Since the bits for NSEC and RRSIG then take up space, do we want to
make them implicit?  (Brian has said "no", I say "yes" -- any others
want to speak up?)

3) If so, do we turn the silly-state language around and say "if
either of these typecodes is explicitly listed, treat this name as
unsecured"?

-- 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:43 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Thu, 30 Oct 2003 12:29:24 -0500
Organization: Verisign, Inc.
Lines: 39
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> <Pine.GSO.4.55.0310292335460.29730@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 Oct 30 18:44:23 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
User-Agent: KMail/1.5.3
In-Reply-To: <Pine.GSO.4.55.0310292335460.29730@filbert>
Content-Disposition: inline
Precedence: bulk

On Wednesday 29 October 2003 05:44 pm, Samuel Weiler wrote:
> > There is also the issue that any scheme that allows the server to
> > freely choose between multiple alternative wire encodings will not
> > actually work.  This is because DNSSEC signatures are calculated by
> 
> If Andreas is right, and I think he is, then David's strawcritter:
> 
> > - use the remaining 7 bits in the first octet as a count of
> > single-byte typecodes, called N.  The next N octets are an ordered
> > list of 8-bit integers representing typecodes <= 255.  The remaining
> > RDATA is an ordered list of 16-bit big-endian unsigned integers,
> > each representing one type present.
> 
> may open the door to ambiguity -- can one set N=0 and list codes 3, 5,
> and 7 in the 16-bit portion?  Micheal's format 1 may have the same
> problem.

Hah.  Now that it seems somewhat OK to ditch the bit map, I can improve my 
strawcritter:

  Use the first octet as a count of typecodes < 256, called N.  The next N 
octets are an ascending list of 8-bit integers representing typecodes < 
256.  The remaining RDATA is an ascending list of 16-bit big-endian 
unsigned integers greater than 255 representing typecodes > = 256. 

Actually, this isn't all that different from Michael's "compressed" format, 
except that it doesn't have any flag fields, and it doesn't attempt to 
compress larger typecodes, which would also probably be OK.

-- 
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:43 2006
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: Section 4 of dnssec-protocol-03
Date: Thu, 30 Oct 2003 12:36:28 -0500
Lines: 23
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 Oct 30 18:51:00 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: stjohns@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: namedroppers@ops.ietf.org
Precedence: bulk

Comments:

Section 4, page 20.  "Trusted starting point".  A more precise term might 
be "trust anchor".

Page 20, para beginning "A security-aware resolver..." delete  "MUST be 
capable....key, and" - the latter clause includes the meaning of the 
indicated clause.   Add at end of para "However, such mechanisms are out of 
scope for this document."

And the meat of the matter:  Would it make sense to add a second bit 
mirroring the DO bit to indicate a new DNSSEC query rather than an old 
DNSSEC query?   DO would indicate an old DNSSEC query, DX would indicate a 
new query.  E.g. how do we handle the legacy case?  *sigh*

Mike


--
to 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:43 2006
From: Michael Graff <Michael_Graff@isc.org>
Subject: Re: Large typecodes and DNSSEC
Date: Thu, 30 Oct 2003 19:16:51 +0000
Lines: 18
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
	<200310281647.45423.davidb@verisignlabs.com>
	<Pine.GSO.4.55.0310282333050.4801@filbert>
	<200310281848.26163.davidb@verisignlabs.com>
	<20031029154141.GA27166@chinook.rgy.netsol.com>
	<s9s4qxsrmc2.fsf@farside.isc.org> <s9soew0hrfv.fsf@farside.isc.org>
	<Pine.LNX.4.58.0310291214290.8195@incognito.ddns.nominum.com>
	<200310292052.h9TKqbAp016451@guava.araneus.fi>
	<Pine.GSO.4.55.0310292335460.29730@filbert>
	<Pine.LNX.4.58.0310291744180.8195@incognito.ddns.nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Samuel Weiler <weiler@tislabs.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 20:32:24 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Brian Wellington <Brian.Wellington@nominum.com>
In-Reply-To: <Pine.LNX.4.58.0310291744180.8195@incognito.ddns.nominum.com> (Brian
 Wellington's message of "Wed, 29 Oct 2003 17:52:45 -0800 (PST)")
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix)
Precedence: bulk

Brian Wellington <Brian.Wellington@nominum.com> writes:

> Adding special cases for RRSIG and NSEC is confusing.  Using a 16 bit
> value is fine also.  The only difference is that the compressed method
> allows all combinations of the 64K type codes to be represented without
> exceeding the 64K limit for rdata, not that this really matters.

I personally like the idea of being able to represent many types, so
I'd rather see the compressed format move forward and the 16-bit
values method go away.

--Michael

--
to 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:43 2006
From: "Scott Rose" <scottr@nist.gov>
Subject: Re: Section 4 of dnssec-protocol-03
Date: Thu, 30 Oct 2003 13:27:26 -0500
Lines: 40
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031030121608.033ec788@localhost>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 20:42:21 2003
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: "Mike StJohns" <Mike.StJohns@nominum.com>
>
> And the meat of the matter:  Would it make sense to add a second bit
> mirroring the DO bit to indicate a new DNSSEC query rather than an old
> DNSSEC query?   DO would indicate an old DNSSEC query, DX would indicate a
> new query.  E.g. how do we handle the legacy case?  *sigh*
>

The typecode draft/RFC (hopefully soon) discussed that idea.  Servers and
resolvers are supposed to ignore pre-DS DNSSEC RRs and not use them.

It would also be good not to condone a "dual world" DNSSEC.  One with
KEY/SIG/NXT and one with the new typecodes.  Right now, RFC2535 security
aware resolver wouldn't be able to verify the RRSIGs, but would not be able
to follow secure delegations anyway (DS RR).  Having the option of allowing
"2535" DNSSEC means there would have to be the same 2535-DNSSEC security
chain with parent SIGs in the child zone.

Basically, there is not a lot of danger in just ignoring the legacy case.
DNSSEC is not widely deployed to warrent a lot of backwards compatibility.
Scott


> Mike
>
>
> --
> to 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:43 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Large typecodes and DNSSEC
Date: Thu, 30 Oct 2003 18:42:11 +0000
Lines: 24
Sender: owner-namedroppers@ops.ietf.org
References: <weiler@tislabs.com>
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 21:03:42 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Samuel Weiler <weiler@tislabs.com> 
	of "Thu, 30 Oct 2003 18:11:14 +0100."
	<Pine.GSO.4.55.0310301808040.15058@filbert> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> 1) Is there anything wrong with the ordered list of 16-bit values
> proposed separately by Rob and Micheal (format 0)?

nope.

> 2) Since the bits for NSEC and RRSIG then take up space, do we want to
> make them implicit?  (Brian has said "no", I say "yes" -- any others
> want to speak up?)

implicit is bad.  the space savings is negligible compared to the size of
the signature and key blobs.  explicit is less error prone, or rather, will
lead to earlier signalling of logic/protocol errors, compared to implicit.

> 3) If so, do we turn the silly-state language around and say "if
> either of these typecodes is explicitly listed, treat this name as
> unsecured"?

no.

--
to 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:43 2006
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: Re: Section 4 of dnssec-protocol-03
Date: Thu, 30 Oct 2003 16:03:25 -0500
Lines: 50
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031030121608.033ec788@localhost>
 <061f01c39f13$78666f80$b9370681@barnacle>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 22:15:07 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: stjohns@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: "Scott Rose" <scottr@nist.gov>, <namedroppers@ops.ietf.org>
In-Reply-To: <061f01c39f13$78666f80$b9370681@barnacle>
References: <6.0.0.22.2.20031030121608.033ec788@localhost>
 <061f01c39f13$78666f80$b9370681@barnacle>
Precedence: bulk

At 01:27 PM 10/30/2003, Scott Rose wrote:

>----- Original Message -----
>From: "Mike StJohns" <Mike.StJohns@nominum.com>
> >
> > And the meat of the matter:  Would it make sense to add a second bit
> > mirroring the DO bit to indicate a new DNSSEC query rather than an old
> > DNSSEC query?   DO would indicate an old DNSSEC query, DX would indicate a
> > new query.  E.g. how do we handle the legacy case?  *sigh*
> >
>
>The typecode draft/RFC (hopefully soon) discussed that idea.  Servers and
>resolvers are supposed to ignore pre-DS DNSSEC RRs and not use them.

Actually, I think the issue is pre-DS security aware stub resolvers talking 
to post-DS resolvers or vice versa.  As it stands, a pre-DS aware resolver 
setting the DO bit can get post-DS answers that it doesn't have a clue of 
how to use.

>Basically, there is not a lot of danger in just ignoring the legacy case.
>DNSSEC is not widely deployed to warrent a lot of backwards compatibility.
>Scott

I think I mostly agree with this.  On the other hand, we changed all the 
type codes to prevent problems with legacy systems - might it not make 
sense to make the hard separation include stub to recursive resolver 
signalling?  Its one bit in the EDNS0 header.


> > Mike
> >
> >
> > --
> > to 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/>


--
to 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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Section 4 of dnssec-protocol-03
Date: Thu, 30 Oct 2003 16:31:20 -0500
Lines: 37
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031030121608.033ec788@localhost>
	<061f01c39f13$78666f80$b9370681@barnacle>
	<6.0.0.22.2.20031030153413.033ffe40@localhost>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Oct 30 22:43:45 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <6.0.0.22.2.20031030153413.033ffe40@localhost>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
Precedence: bulk

At Thu, 30 Oct 2003 16:03:25 -0500, Michael StJohns wrote:
> 
> Actually, I think the issue is pre-DS security aware stub resolvers talking 
> to post-DS resolvers or vice versa.  As it stands, a pre-DS aware resolver 
> setting the DO bit can get post-DS answers that it doesn't have a clue of 
> how to use.
> ...
> I think I mostly agree with this.  On the other hand, we changed all the 
> type codes to prevent problems with legacy systems - might it not make 
> sense to make the hard separation include stub to recursive resolver 
> signalling?  Its one bit in the EDNS0 header.

I don't feel strongly about this, but here's my take, for what it's
worth.

The primary purpose of the DO bit is to keep old buggy code from
dumping core upon seeing DNSSEC records (by keeping said buggy code
from ever seeing DNSSEC).  I have not seen this happen myself, but
I've been assured that this was a real problem for some old buggy
implementations.  Nobody ever claimed that this was anything but
broken behavior on the part of the old code, but it was a real
operational problem that stood in the way of deployment, and this
seemed the least bad answer to it.

The situation with pre-DS and post-DS DNSSEC is not analagous, unless
somebody steps forward to claim that there's code deployed now that
will is ok with pre-DS DNSSEC but dumps core upon seeing post-DS
DNSSEC.  While I suppose that's possible, it seems less likely, and I
haven't heard anybody make such a claim.

So I conclude that we probably don't need another bit.

--
to 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:43 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Section 4 of dnssec-protocol-03
Date: Thu, 30 Oct 2003 22:55:42 +0000
Lines: 12
Sender: owner-namedroppers@ops.ietf.org
References: <sra+namedroppers@hactrn.net>
X-From: owner-namedroppers@ops.ietf.org Fri Oct 31 00:40:28 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Rob Austein <sra+namedroppers@hactrn.net> 
	of "Thu, 30 Oct 2003 16:31:20 EST."
	<20031030213120.C03B318DD@thrintun.hactrn.net> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> ...
> So I conclude that we probably don't need another bit.

<AOL>
Me, too!
</AOL>

--
to 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:43 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Section 4 of dnssec-protocol-03
Date: Fri, 31 Oct 2003 16:28:44 +0100 (CET)
Lines: 23
Sender: owner-namedroppers@ops.ietf.org
References: <6.0.0.22.2.20031030121608.033ec788@localhost>
 <061f01c39f13$78666f80$b9370681@barnacle> <6.0.0.22.2.20031030153413.033ffe40@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 Oct 31 16:59:56 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: Mike StJohns <Mike.StJohns@nominum.com>
In-Reply-To: <6.0.0.22.2.20031030153413.033ffe40@localhost>
Precedence: bulk

On Thu, 30 Oct 2003, Mike StJohns wrote:

> ... we changed all the type codes to prevent problems with legacy
> systems - might it not make sense to make the hard separation
> include stub to recursive resolver signalling?  Its one bit in the
> EDNS0 header.

I find it interesting how questions that have been discussed at
length, including in last-called and IESG-approved documents (albeit
ones not yet out of the RFC editor's queue), keep getting raised.

See section 2.3 of the TCR draft, which went to IETF last call on July
16th and was approved for publication on 21 August.  If the standards
process is letting documents through with too little review, then we
have bigger problems than a header bit will fix.

-- 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:43 2006
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: Re: Section 4 of dnssec-protocol-03
Date: Fri, 31 Oct 2003 11:20:55 -0500
Lines: 101
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_390180760==.ALT"
X-From: owner-namedroppers@ops.ietf.org Fri Oct 31 17:30:32 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: stjohns@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: namedroppers@ops.ietf.org
Precedence: bulk

--=====================_390180760==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:36 AM 10/31/2003, Mike StJohns wrote:
>At 10:28 AM 10/31/2003, Samuel Weiler wrote:
>>On Thu, 30 Oct 2003, Mike StJohns wrote:
>>
>> > ... we changed all the type codes to prevent problems with legacy
>> > systems - might it not make sense to make the hard separation
>> > include stub to recursive resolver signalling?  Its one bit in the
>> > EDNS0 header.
>>
>>I find it interesting how questions that have been discussed at
>>length, including in last-called and IESG-approved documents (albeit
>>ones not yet out of the RFC editor's queue), keep getting raised.

Yup.  But this document is supposed to represent a complete compilation of 
all the little twiddles in the virtual forest of documents making up the 
DNSSEC stuff.  And a *replacement* for those documents - e.g. when 
complete, this document will represent ground truth and the other documents 
will be deprecated.  So by the normal standards process, its legitimate to 
give this a second look.  I don't mind treating it as settled though - I 
mentioned it because it seemed strange to change one thing without changing 
the other.  So leave it as is and lets move on.



>>See section 2.3 of the TCR draft, which went to IETF last call on July
>>16th and was approved for publication on 21 August.  If the standards
>>process is letting documents through with too little review, then we
>>have bigger problems than a header bit will fix.

Actually, what the current -05 version of this (-03 was what was submitted 
to the IESG) says is "
It could, though,
    be considered in addition to changing the RR type codes."
referring to adding a second DO type bit.  It didn't actually make a 
decision except by not mentioning it further.


>>-- Sam

--=====================_390180760==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
At 10:36 AM 10/31/2003, Mike StJohns wrote:<br>
<blockquote type=cite class=cite cite>At 10:28 AM 10/31/2003, Samuel
Weiler wrote:<br>
<blockquote type=cite class=cite cite>On Thu, 30 Oct 2003, Mike StJohns
wrote:<br><br>
&gt; ... we changed all the type codes to prevent problems with
legacy<br>
&gt; systems - might it not make sense to make the hard separation<br>
&gt; include stub to recursive resolver signalling?&nbsp; Its one bit in
the<br>
&gt; EDNS0 header.<br><br>
I find it interesting how questions that have been discussed at<br>
length, including in last-called and IESG-approved documents 
(albeit<br>
ones not yet out of the RFC editor's queue), keep getting
raised.</blockquote></blockquote><br>
Yup.&nbsp; But this document is supposed to represent a complete
compilation of all the little twiddles in the virtual forest of documents
making up the DNSSEC stuff.&nbsp; And a *replacement* for those documents
- e.g. when complete, this document will represent ground truth and the
other documents will be deprecated.&nbsp; So by the normal standards
process, its legitimate to give this a second look.&nbsp; I don't mind
treating it as settled though - I mentioned it because it seemed strange
to change one thing without changing the other.&nbsp; So leave it as is
and lets move on.<br><br>
<br><br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>See
section 2.3 of the TCR draft, which went to IETF last call on July<br>
16th and was approved for publication on 21 August.&nbsp; If the
standards<br>
process is letting documents through with too little review, then 
we<br>
have bigger problems than a header bit will
fix.</blockquote></blockquote><br>
Actually, what the current -05 version of this (-03 was what was
submitted to the IESG) says is &quot;<br>
<pre>It could, though,
&nbsp;&nbsp; be considered in addition to changing the RR type
codes.&quot; 
</pre>referring to adding a second DO type bit.&nbsp; It didn't actually
make a decision except by not mentioning it further.<br><br>
<br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>--
Sam </blockquote></blockquote></body>
</html>

--=====================_390180760==.ALT--


--
to 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:43 2006
From: Paul Vixie <vixie@vix.com>
Subject: Re: Section 4 of dnssec-protocol-03
Date: 31 Oct 2003 16:54:49 +0000
Lines: 16
Sender: owner-namedroppers@ops.ietf.org
References: <bnu2rg$237g$1@sf1.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Fri Oct 31 18:05:08 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <bnu2rg$237g$1@sf1.isc.org>
Lines: 10
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Precedence: bulk

> ...  But this document is supposed to represent a complete compilation of 
> all the little twiddles in the virtual forest of documents making up the 
> DNSSEC stuff.  And a *replacement* for those documents - e.g. when 
> complete, this document will represent ground truth and the other documents 
> will be deprecated.

really?  the last thing i heard from -editors was that it was all about
clarifying 2535.  apparently then, rolling up TCR et al will come later?
-- 
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:43 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Large typecodes and DNSSEC
Date: Fri, 31 Oct 2003 17:53:07 +0100 (CET)
Lines: 24
Sender: owner-namedroppers@ops.ietf.org
References: <200310281402.41950.davidb@verisignlabs.com>
 <200310292052.h9TKqbAp016451@guava.araneus.fi> <Pine.GSO.4.55.0310292335460.29730@filbert>
 <200310301229.24579.davidb@verisignlabs.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 Oct 31 18:06:24 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <200310301229.24579.davidb@verisignlabs.com>
Precedence: bulk

>   Use the first octet as a count of typecodes < 256, called N.  The next N
> octets are an ascending list of 8-bit integers representing typecodes <
> 256.  The remaining RDATA is an ascending list of 16-bit big-endian
> unsigned integers greater than 255 representing typecodes > = 256.

I like this strawcritter.

Are we completely ditching the first octet for format/reserved bits?
If so, we're breaking the "first bit set means alternate format", but
I think that's a safe thing to do, given the type code roll.

If not, we need a rule for what happens when the version is greater
than what the resolver groks.  Adapting the text I sent on Tuesday:
"If you don't have a validated positive answer and the NSEC validates
and you don't understand the NSEC format version, treat the name as
unsecured."

-- 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:43 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Large typecodes and DNSSEC
Date: Fri, 31 Oct 2003 17:55:37 +0000
Lines: 36
Sender: owner-namedroppers@ops.ietf.org
References: <weiler@tislabs.com>
Cc: David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Oct 31 19:08:14 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Samuel Weiler <weiler@tislabs.com>
In-Reply-To: Message from Samuel Weiler <weiler@tislabs.com> 
	of "Fri, 31 Oct 2003 17:53:07 +0100."
	<Pine.GSO.4.55.0310311745340.7668@filbert> 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Precedence: bulk

> >   Use the first octet as a count of typecodes < 256, called N.  The next N
> > octets are an ascending list of 8-bit integers representing typecodes <
> > 256.  The remaining RDATA is an ascending list of 16-bit big-endian
> > unsigned integers greater than 255 representing typecodes > = 256.
> 
> I like this strawcritter.

i don't.  on a strictly puritanical basis, we need a format which can
represent all rrtypes, just in case 65535 of them are ever known to
exist and all 65535 happen to be in use at a name.  the above format
is clean but since both a DNS message and an RDATA are limited to 64K
octets, and an RDATA probably shares its containing DNS message with
some other data an RDATA is probably limited to a size slightly smaller
than 64K octets.  a bit map of 64K bits would fit.  michael's compressed
format would fit, even in the corner case of every-other-typecode in use.
if we can find something clean that is also pure, then so much the better.

> Are we completely ditching the first octet for format/reserved bits?
> If so, we're breaking the "first bit set means alternate format", but
> I think that's a safe thing to do, given the type code roll.

yes.

> If not, we need a rule for what happens when the version is greater
> than what the resolver groks.  Adapting the text I sent on Tuesday:
> "If you don't have a validated positive answer and the NSEC validates
> and you don't understand the NSEC format version, treat the name as
> unsecured."

let's avoid optional behaviour and format versioning.

--
to 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:43 2006
From: "Scott Rose" <scottr@nist.gov>
Subject: Q18:  TTL values for RRSIG vs. RFC2181
Date: Fri, 31 Oct 2003 13:56:22 -0500
Lines: 49
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Fri Oct 31 20:20:02 2003
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

Q-18:  Chance for conflict with RFC 2181 and RRSIG RRs.  Should RRSIG RRs be
allowed to have TTL values different from each other, if the RR sets they
cover have different TTL values?

Background
RFC2181 section 5.2:

   "Consequently the use of differing TTLs in an RRSet is hereby
   deprecated, the TTLs of all RRs in an RRSet must be the same."

dnssec records 5 section 3
  "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
  it covers."

Now consider this zone fragment:

efnet.example.com.       300     IN A    10.14.88.25
                         300     SIG     A 5 3 300 20031128150903 (
                                         20031029150903 11576 ... )
                         3600    AAAA    2001:7b8:3:3f:201:2ff:fef6:574e
                         3600    SIG     AAAA 5 3 3600 20031128150903 (
                                         20031029150903 11576 ... )
                         3600    NXT     ega.example.com. A SIG AAAA NXT
                         3600    SIG     NXT 5 3 3600 20031128150903 (
                                         20031029150903 11576 ... )

The RRSIG RR set has different TTL values, while they cover RRsets with
different TTL values.

The proposed solution is to add text to the DNSSECbis protocol draft stating
that RRSIG RRs are different than other RR sets in that they must have the
same TTL value as the set they cover.  Even if that means different values
for the TTL for RRSIG RRs with the same owner name.  This is an exception to
the specification in RFC2181 that states that all RRs in an RRset must have
the same TTL value.

There is no proposed text as yet, but it will go along the lines of the
section above.  Hopefully in more clear text than mine.  Alternatives are
welcome, as well as any statement as to why we shouldn't allow this.

DNSSECbis editors



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:45:43 2006
From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=
  <ogud@ogud.com>
Subject: Re: Q18:  TTL values for RRSIG vs. RFC2181
Date: Fri, 31 Oct 2003 15:03:58 -0500
Lines: 38
Sender: owner-namedroppers@ops.ietf.org
References: <010e01c39fe0$ad7766c0$b9370681@barnacle>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Fri Oct 31 21:20:40 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: post@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: "Scott Rose" <scottr@nist.gov>, <namedroppers@ops.ietf.org>
In-Reply-To: <010e01c39fe0$ad7766c0$b9370681@barnacle>
References: <010e01c39fe0$ad7766c0$b9370681@barnacle>
Precedence: bulk

At 13:56 2003-10-31, Scott Rose wrote:
>Q-18:  Chance for conflict with RFC 2181 and RRSIG RRs.  Should RRSIG RRs be
>allowed to have TTL values different from each other, if the RR sets they
>cover have different TTL values?

</chair>
IMHO it is more important that the RRSIG be cached for the same time
as the RRset it is covering, than having purity among the TTL's
of all the RRSIG's for one name.


>Background
>RFC2181 section 5.2:
>
>    "Consequently the use of differing TTLs in an RRSet is hereby
>    deprecated, the TTLs of all RRs in an RRSet must be the same."
>
>dnssec records 5 section 3
>   "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
>   it covers."

How about:
The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
it covers.  Note this may lead to an apparent violation of RFC2181
section 5.2, but the RRSIG is a meta type and each RRSIG is related to
a RRset and it is important that the RRSIG be cached for the same time as
the RRset covered.


         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:43 2006
From: Rob Austein <sra+namedroppers@hactrn.net>
Subject: Re: Q18:  TTL values for RRSIG vs. RFC2181
Date: Fri, 31 Oct 2003 20:27:38 +0000
Lines: 39
Sender: owner-namedroppers@ops.ietf.org
References: <010e01c39fe0$ad7766c0$b9370681@barnacle>
	<6.0.0.22.2.20031031145555.0285c848@localhost>
Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Fri Oct 31 21:43:51 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <6.0.0.22.2.20031031145555.0285c848@localhost>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI)
Precedence: bulk

At Fri, 31 Oct 2003 15:03:58 -0500, Olafur Gudmundsson wrote:
> 
> </chair>
> IMHO it is more important that the RRSIG be cached for the same time
> as the RRset it is covering, than having purity among the TTL's
> of all the RRSIG's for one name.

<hat=just-another-bozo-on-this-bus>

I agree.  RRSIG RRs are bags hanging on the side of the covered RRset,
and for practical purposes RRSIG RRs just don't form normal RRsets.

</hat>

> How about:
> The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
> it covers.  Note this may lead to an apparent violation of RFC2181
> section 5.2, but the RRSIG is a meta type and each RRSIG is related to
> a RRset and it is important that the RRSIG be cached for the same time as
> the RRset covered.

<hat=editor>

I don't like "meta type" ('cause then we'd have to explain what it
means, which would almost certainly be harder than just saying
whatever it is that we do mean in the first place...), but I think
that the editors can handle the wordsmithing unless the WG feels a
strong need to constrain us to specific text.

The question before the WG is whether we've understood the content
issue correctly.

</hat>

--
to 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:43 2006
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: Re: Section 4 of dnssec-protocol-03
Date: Fri, 31 Oct 2003 17:07:39 -0500
Lines: 37
Sender: owner-namedroppers@ops.ietf.org
References: <bnu2rg$237g$1@sf1.isc.org>
 <g3ism5pcti.fsf@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Fri Oct 31 23:22:50 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: stjohns@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: Paul Vixie <vixie@vix.com>, namedroppers@ops.ietf.org
In-Reply-To: <g3ism5pcti.fsf@sa.vix.com>
References: <bnu2rg$237g$1@sf1.isc.org>
 <g3ism5pcti.fsf@sa.vix.com>
Precedence: bulk

At 11:54 AM 10/31/2003, Paul Vixie wrote:
> > ...  But this document is supposed to represent a complete compilation of
> > all the little twiddles in the virtual forest of documents making up the
> > DNSSEC stuff.  And a *replacement* for those documents - e.g. when
> > complete, this document will represent ground truth and the other 
> documents
> > will be deprecated.
>
>really?  the last thing i heard from -editors was that it was all about
>clarifying 2535.  apparently then, rolling up TCR et al will come later?

If this is what they said, I would venture that they have a much broader 
definition of "clarify" than I do.  Clarify implies "what we really meant 
was..." not "we need to change some things because they didn't work".  DS 
triggered TCR and both of those are covered within this document.

With respect to the current item, there is nothing in TCR that isn't 
dnssec-protocol-03 and having two active standards track RFCs addressing 
the exact same thing seems to me to be inviting more confusion.  At a 
minimum, when dnssec-protocol-03 is published, 2535, TCR, DS, and the 
original DO RFC should probably be considered superceeded and no longer 
authoritative for protocol purposes.

>--
>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/>


--
to 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:43 2006
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: DNSSEC editing process (Periodic posting)
Date: Fri, 31 Oct 2003 20:23:11 -0500
Lines: 77
Sender: owner-namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-From: owner-namedroppers@ops.ietf.org Sat Nov 01 02:39:19 2003
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: namedroppers@ops.ietf.org
Precedence: bulk


The DNSEXT working group has started a rewrite of the DNSSEC
specification into a documents that better reflect the protocol
and allow a test plan to be constructed from the specification.

To accomplish this, a team of volunteers has been formed to generate
the documents. The document editing team is tasked with documenting
the protocol as specified in RFC's generated by this group and id's
that have been passed on by the working group to the IESG.

The editors are NOT ALLOWED to make ANY changes in the protocol.
If clarifications are needed due to conflicting definitions,
imprecise specification, omission or other reason, the editors MUST
bring these issues to the attention of the working group on the
namedroppers mailing list.

To assist the editors, a small group of people with good understanding
of DNSSEC have been recruited to review document drafts and
answer questions that the editors have.
For simplified communication a mailing list has been created, anyone
can send messages to the editors via this mailing list
DNSSEC-editors@east.isi.edu.

Archive of this mailing list will be made available.

Please send minor corrections, comments, suggestions about the
DNSSECbis documents to dnssec-editors@east.isi.edu.

All major issues should be brought up on namedroppers, editors
MAY forward any correspondence to namedroppers, without asking
permission, if they deem the issues raised require wider attention.

DNSEXT chairs Olaf Kolkman  and =D3lafur Gu=F0mundsson approve new members=
 on
the dnssec-editors malling list.

DNSSEC-editors is NOT a design group, it is a document maintenance
group.

The current members of the mailing list are:
Editors:
	Roy Arends
	Rob Austein
	Matt Larson
	Dan Massey
	Scott Rose
=09
Advisors:
	Donald Eastlake
	Brian Wellington
	Edward Lewis
	Olafur Gudmundsson

The current set of documents produced by dnssec-editors is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt

Supporting documents include:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-04.txt

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-03.txt

All the documents will be undergoing rapid updates during the next few=
 months,
please review new version as they become available.
=09
	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:44 2006
From: Miek Gieben <miekg@atoom.net>
Subject: Re: Q18:  TTL values for RRSIG vs. RFC2181
Date: Fri, 31 Oct 2003 23:47:54 +0100
Lines: 24
Sender: owner-namedroppers@ops.ietf.org
References: <010e01c39fe0$ad7766c0$b9370681@barnacle> <6.0.0.22.2.20031031145555.0285c848@localhost> <20031031202739.783AA20B9@thangorodrim.hactrn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Nov 04 13:51:10 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Rob Austein <sra+namedroppers@hactrn.net>
Mail-Followup-To: Rob Austein <sra+namedroppers@hactrn.net>,
	namedroppers@ops.ietf.org
Content-Disposition: inline
In-Reply-To: <20031031202739.783AA20B9@thangorodrim.hactrn.net>
User-Agent: Vim/Mutt/Linux
X-Home: www.miek.nl
X-Virus-Scanned: by amavisd-new
Precedence: bulk

[On 31 Oct, @21:27, Rob wrote in "Re: Q18:  TTL values for RRSIG ..."]
> <hat=editor>
> 
> I don't like "meta type" ('cause then we'd have to explain what it
> means, which would almost certainly be harder than just saying
> whatever it is that we do mean in the first place...), but I think
> that the editors can handle the wordsmithing unless the WG feels a
> strong need to constrain us to specific text.
> 
> The question before the WG is whether we've understood the content
> issue correctly.
> 
> </hat>

I feel that making this exception for the SIG's TTL is the right thing
to do.

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:44 2006
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 20:04:32 -0500
Lines: 44
Sender: owner-namedroppers@ops.ietf.org
References: <Pine.GSO.4.55.0310282333050.4801@filbert>
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Nov 05 01:38:35 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-reply-to: Your message of "Tue, 28 Oct 2003 23:56:12 +0100."
             <Pine.GSO.4.55.0310282333050.4801@filbert> 
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Samuel" == Samuel Weiler <weiler@tislabs.com> writes:
    Samuel> Yup -- we need to do that.  How's this: If you see the zero bit
    Samuel> set AND THE NSEC VALIDATES, treat this name as unsecured unless
    Samuel> you have evidence to the contrary (ie. a validated RRset)?

  This sounds like the minimum that we can do.

    Samuel> I think we can get away with putting this off -- we have the
    Samuel> extension mechanism in place and can deal with it later.  With
    Samuel> the current typecode burn rate, the current format will outlast a
    Samuel> resolver replacement cycle.  Maybe two.

    Samuel> But if folks really insist, let's get it done quickly.  I'm sure
    Samuel> we can settle on a format.  Can we get multiple interoperable
    Samuel> implementations out the door before Minneapolis?  Seriously -- I
    Samuel> want to get this rev out.  I suggest that the chairs decline the
    Samuel> change unless we have two pieces of interoperable code within
    Samuel> some short amount of time, perferably pre-MSP.

  Why do we need two interop's in order to publish 2535bis?

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP58SHYqHRg3pndX9AQGQ+QQAwNEgpqWmitz+TcxEMfqd99Ircz7/h5e9
XjjuZqIWn1r9h8gSEDa1puchzoRqYhuaDwFdyjdpAUc5Ag5TrJH4NoI5aZozNp9w
LQQVbE0tQAqq4Y3OZydQX71JUXFoAoqD0J/v/hLLfy+F3tIUwCY7RYEdY3JeKSMx
ivdwnld6nio=
=h1Vs
-----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:44 2006
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 16:45:06 -0500
Lines: 33
Sender: owner-namedroppers@ops.ietf.org
References: <8F2EA9A2-0A50-11D8-A3BA-000393C783A2@isi.edu>
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Nov 05 22:04:02 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-reply-to: Your message of "Wed, 29 Oct 2003 15:43:32 EST."
             <8F2EA9A2-0A50-11D8-A3BA-000393C783A2@isi.edu> 
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----


  My opinion:

>>>>> "Daniel" == Daniel Massey <masseyd@ISI.EDU> writes:
    Daniel> e NSECbis has "ordered list" and replaces NSEC [2]

  With ordered list as specified by Graff's "compressed" format as the
only format. Or the basic one. I don't care.

    Daniel> A simple list is more likely be done correctly.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP6A04IqHRg3pndX9AQFLtQP/YbfcE7txOOUQOUrY8Hecgsdnv1NWY/qW
ZjZ6KNos+ib3zeEoPZMjOuIPs9avCoVfQrrzv/UczSCbj6InLiRA+J2XhqTGkV8J
8NsoTkjde6j3U0TL5VDrd+D1ZDZNJ5UdnWA/COIYT8jZy/E2ULZyWgw26O8plP5K
wb8BXemHJAA=
=XTND
-----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:44 2006
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: Re: Large typecodes and DNSSEC
Date: Wed, 29 Oct 2003 13:23:16 -0500
Lines: 41
Sender: owner-namedroppers@ops.ietf.org
References: <s9s4qxsrmc2.fsf@farside.isc.org>
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Nov 05 22:04:02 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: Michael Graff <Michael_Graff@isc.org>
In-reply-to: Your message of "Wed, 29 Oct 2003 17:21:49 GMT."
             <s9s4qxsrmc2.fsf@farside.isc.org> 
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Michael" == Michael Graff <Michael_Graff@isc.org> writes:
    Michael> And here it is.  :)

  Thank you.
  I suggest that the working group adopt this document.

    Michael> F The encoding format used.  0 indicates a simple list of 16-bit
    Michael> type codes.  1 indicates a slightly compressed type code list.

    Michael> 6 - Format 1: compressed type code list

  Minimally complicated, sure. Probably really easy to implement.

  I'm not even sure it is worth it. Likely not even worth my words to 
ask if it is worth it. Just do it.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP6AFkoqHRg3pndX9AQFZyQP8D3tR6Q8O6GrUauqK5Dwcr0V2RVYHFLAc
xKUjACdCulCVpxW99ot1si65UFXMlsQdnMrvsMhkASC6TjyXFZ+R8myIMIyGzggu
XDaRt35i9MOQQs5PK2gojmIy/FwzB0Gm5Fr+iweHj5qjV1PiO/bOkaZcU1ITm56h
f9KkX9dE0ys=
=/obH
-----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:44 2006
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: Re: Large typecodes and DNSSEC
Date: Tue, 28 Oct 2003 19:51:50 -0500
Lines: 45
Sender: owner-namedroppers@ops.ietf.org
References: <200310281647.45423.davidb@verisignlabs.com>
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Nov 05 22:05:25 2003
Return-path: <owner-namedroppers@ops.ietf.org>
To: David Blacka <davidb@verisignlabs.com>
In-reply-to: Your message of "Tue, 28 Oct 2003 16:47:45 EST."
             <200310281647.45423.davidb@verisignlabs.com> 
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "David" == David Blacka <davidb@verisignlabs.com> writes:
    David> At this point, having read through long threads discussion what we
    David> might have to do if RSA is broken, I am at a loss to understand
    David> why this issue hasn't been considered important.  Actually, I am
  
  Fatigue. It was my understanding that when this topic last came up,
that the WG was pretty exhausted about other things.

    David> Why not take a position?  I'll take a position: DNSSEC is not
    David> complete without the ability to handle types > 127.  Just because
    David> there aren't any now is no excuse. 
  
  I concur, and we should fix it.

    David> - use the remaining 7 bits in the first octet as a count of
    David> single-byte typecodes, called N.  The next N octets are an ordered
    David> list of 8-bit integers representing typecodes <= 255.  The
    David> remaining RDATA is an ordered list of 16-bit big-endian unsigned
    David> integers, each representing one type present.

  Works for me.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP58PJIqHRg3pndX9AQG/rQQAyJ1ZTg7CJGhh4avX1wohkFc4f5PykZSs
D0br1XqMzGQTlW2I19TiSJ1hRlbiwV7JvYrp55+W6dnioaBSQ56hpapgUHYpSHy0
EI6wYaAsVwpAfYAfUwkl3d/V/hIDconNo3lD9eTNp0kYYPLKThK/o4Aao74tfOyj
gJvAZn07LZg=
=SLKg
-----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/>