From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Olaf Kolkman <olaf@ripe.net>
Subject: DNSEXT list policy
Date: Sat, 1 Jan 2005 08:35:01 +0100
Lines: 193
X-From: owner-namedroppers@ops.ietf.org Sat Jan 01 08:52:05 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: U 0.497515 / -5.9
X-RIPE-Signature: ebb60a894eaadaacb0e1ad104d4946b2
Sender: owner-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". To
  counter a certain class of spam mails messages over 20000
  characters, originating from list subscribers, will be held for
  moderations.

  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.7 2004/05/17 12:46:38 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:46:12 2006
From: Simon Josefsson <jas@extundo.com>
Subject: Re: RFC 2538bis
Date: Mon, 03 Jan 2005 01:57:53 +0100
Lines: 149
References: <200410151949.PAA03947@ietf.org>
	<ilu8ya7tyqm.fsf@latte.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Mon Jan 03 02:12:12 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:23:050103:namedroppers@ops.ietf.org::q/ew+qJfhbL/CzKZ:000000000000000000000000000000000001VWG4
In-Reply-To: <ilu8ya7tyqm.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Sat, 16 Oct 2004 00:14:57 +0200")
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
X-Virus-Scanned: ClamAV 0.80/618/Mon Dec  6 00:09:24 2004
	clamav-milter version 0.80j
	on yxa.extundo.com
X-Virus-Status: Clean
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Dear All:

Since publishing rfc2538bis-00, I have received a number of comments,
mostly from the PKIX and OpenPGP working groups.  The suggestions have
been incorporated, or left as open issues (discussed below).

I have submitted the -01 draft to the IETF.  It can also be found at:

http://josefsson.org/rfc2538bis/draft-josefsson-rfc2538bis.txt

Thanks to rfcdiff, you may review the changes in that document
compared to RFC 2538:

http://josefsson.org/rfc2538bis/draft-josefsson-rfc2538bis-from-rfc2538xml.diff.html

A complete resource with XML, HTML, and TXT versions, and the two
input documents that motivated this work, can be found at:

http://josefsson.org/rfc2538bis/

The major addition in -01 compared to -00 are the new paragraphs in
section 3 that introduce the terms "content-based owner name" and
"purpose-based owner name".  The intention is to motivate the new
owner name guidelines.  As you might recall, for my needs, the RFC
2538 guidelines were not possible to use.  This was the motivation for
2538bis in the first place.

New since -00 is also the purpose-based owner name guideline for
X.509. However, this has been discussed earlier in:

http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt

Feedback on the new material are especially appreciated.

The document still mention three open issues.  I propose to resolve
the open issues as follows.  If there are no objections, I will
incorporate my proposals and publish -02.

If no further issues are brought up, I hope the document can be ready
for last call before the next meeting.

Issue #1: Handling of X.509 or OpenPGP data that is larger than 64kb.
This was discussed in section 4 of:

http://josefsson.org/gpgkeys_jkp/draft-josefsson-cert-openpgp.txt

However, it was pointed out that the specific proposal did not work
(because if the RDATA is 65535 there is no room for other data).  A
modified approach, that "chunk" the data appear to be feasible,
though.

To illustrate the problem, Philip Zimmermann's PGP key is over 100kb
large, and would not fit in a CERT RDATA field.

Because I am not aware of anyone except me who has discussed or
proposed a solution to this problem, it may be that it is not
considered a major issue.  Further, solving this appear to be
complicated to describe.  And the need doesn't appear to be great.

Finally, should this turn out to be a critical problem in the future,
the document could be updated again.

Proposal: Add the following text in a new section "Size limit":

   The RDATA field in DNS is restricted to 65535 octets (64kb).  This
   means that each CERT RR cannot contain more than 64kb worth of
   payload.

Issue #2:  Quoting the document:

   2.  Whether to enforce owner name guidelines with SHOULD/MUST.

       From David Shaw (on OpenPGP): "One of the things that struck me
       when reading this draft is that while there are several
       suggested ways to name keys in DNS, there is no one canonical
       name as a SHOULD or MUST.  I suggest that the key fingerprint
       be the canonical name, and all others be CNAMEs pointing to the
       fingerprint name.".

       From Sean P.  Turner (on PKIX): "Should "recommended" be
       "RECOMMENDED" in the 1st and 2nd sentences?"  referring to the
       text in section 3 that recommend appropriate owner names.

Since this issue was brought up in both PKIX and OpenPGP WGs, I
believe it should be addressed.  I'm inclined to agree with David's
proposal.

Unless someone knows of a good reason, preferably in the form of a
deployed use of the CERT RR, or an argument based on DNS traditions,
that would violate making the (using the new terminology)
purpose-based owner name rules a SHOULD, that is what I propose.

Proposal: Add "Implementations SHOULD use the purpose-based owner name
guidelines described in this document, and MAY use CNAMEs at the
content-based owner names, pointing to the purpose-based owner name.".

Issue #3: Quoting the document:

   3.  Should the document suggest use of both full fingerprints, 4/8
       byte OpenPGP key id owner names?  Perhaps only fingerprint
       version.

This is slightly related to the previous issue.  It may be argued that
the purposed-based owner name that SHOULD be used is the full OpenPGP
key fingerprint (this is what David propose), and that the others MAY
be CNAMEs.

However, I'm not sure this will work well.  Consider two full
fingerprints that have the same 4 byte key id:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567

Now, this won't work:

01234567 IN CNAME aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567
01234567 IN CNAME bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567

and although:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567 IN CNAME 01234567
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567 IN CNAME 01234567

would work, it means that querying for either of the two full
fingerprints will result in both keys under one name:

01234567 IN CERT <key for aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567>
01234567 IN CERT <key for bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567>

which is inefficient, because both the client and the server knew the
full fingerprint the client wanted.

Proposal: Mention this issue, and suggest that implementations MAY
chose to not use CNAMEs in this situation (thus violating the MAY in
issue #2), but rather serve the same key at several CERT RRs.

This happen to be what I implement.  My PGP DNS server answer queries
for full fingerprints, 4 and 8 byte key ids, and return the full CERT
RR immediately, without CNAMEs.  This has shown to be simple and
robust.

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:46:12 2006
From: wayne <wayne@schlitt.net>
Subject: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Mon, 03 Jan 2005 20:41:36 -0600
Lines: 66
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Tue Jan 04 09:50:04 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 47
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:zbYzJgWsRBkpzPagHueUzXcim9k=
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: BAYES_00
X-RIPE-Spam-Status: U 0.438364 / -2.6
X-RIPE-Signature: 35746cc710297540c87bf5db729571b4
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

[ Moderators note: This post needed manual approval.

   Either it was posted by a non-subscribed address, or the posting
   was too large ( > 20000bytes ) for this list.

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please use your subscribed address to post, or shorten your
   postings by using links instead of attachments. ]



fyi;

There is a new I-D for the SPF email anti-forgery system available for
review.  This draft tries to document the current practices of the
~~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
systems that are checking 20-100million emails per day.

See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt

Discussions about this, and previous, drafts have been taking place on
the spf-discuss@v2.listbox.com mailing list.  To subscribe or read
the archives, see http://spf.pobox.com/mailinglist.html

While I have been reading this mailing list for many months and will
note any comments posted here, sending email to the spf-discuss list
or to me personally is probably better than flooding this list.


I realize that the whole subject of SPF (and similar systems) has a
certain amount of controversy to it, but for the purposes of this
draft, I am very reluctant to try debate these issues.  The goal is to
document a de-facto standard.  Debates about better techniques, why
SPF is evil, etc. are probably best discussed on things like the IRTF
ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
separate thread/subject.


While SPF mostly deals with the [2]821 SMTP level, it also relies
heavily on DNS to communicate between the domain owner, and the email
receiver.  This I-D also makes provisions to create a new RR that is
just a clone of the TXT RR type.  While I did not make it to IETF-61,
it is my understanding that Stephane Bortzmeyer made a presentation on
this subject during the DNSEXT session.  I would like to thank
Stephane and the WG chairs for this review, and I would also like to
thank Ed Lewis for the presentation he made at the MARID Interim
Meeting last spring.



-wayne


[1] These numbers are estimates, but pretty solid ones.  I have data
to back them up and they are almost certainly underestimating the real
numbers.



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Mon, 10 Jan 2005 09:19:13 +0100
Organization: NIC France
Lines: 23
References: <x4ekh1vrtr.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Mon Jan 10 09:32:27 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
In-Reply-To: <x4ekh1vrtr.fsf@footbone.schlitt.net>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-1-686 i686
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Mon, Jan 03, 2005 at 08:41:36PM -0600,
 wayne <wayne@schlitt.net> wrote 
 a message of 47 lines which said:

> There is a new I-D for the SPF email anti-forgery system available
> for review.
...
> While SPF mostly deals with the [2]821 SMTP level, it also relies
> heavily on DNS to communicate between the domain owner, and the
> email receiver.  This I-D also makes provisions to create a new RR
> that is just a clone of the TXT RR type.  While I did not make it to
> IETF-61, it is my understanding that Stephane Bortzmeyer made a
> presentation on this subject during the DNSEXT session.

There have been apparently no reply. Does it mean that nobody see
solid problems and that there is a silent and rough consensus that
the I-D can move forward :-)

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Mon, 10 Jan 2005 01:02:56 -0800 (PST)
Lines: 50
References: <20050110081913.GA13715@nic.fr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Mon Jan 10 10:08:46 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: namedroppers@ops.ietf.org
In-Reply-To: <20050110081913.GA13715@nic.fr>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On Mon, 10 Jan 2005, Stephane Bortzmeyer wrote:

> > There is a new I-D for the SPF email anti-forgery system available
> > for review.
> ...
> > While SPF mostly deals with the [2]821 SMTP level, it also relies
> > heavily on DNS to communicate between the domain owner, and the
> > email receiver.  This I-D also makes provisions to create a new RR
> > that is just a clone of the TXT RR type.  While I did not make it to
> > IETF-61, it is my understanding that Stephane Bortzmeyer made a
> > presentation on this subject during the DNSEXT session.
> 
> There have been apparently no reply. Does it mean that nobody see
> solid problems and that there is a silent and rough consensus that
> the I-D can move forward :-)

I do see some problems, but I already raised them at spf-discuss. 
But since you asked about it on namedroppers, I'll focus just list
what I do not like as far as dns is concerned:

1. The draft says that if SPF record is not found for say "sub.example.com", 
that lookup should be made for zonecut record which would probably be
"example.com". This is done as a way to simulate *.example.com and provide
spf record for all subdomains (especially when they exist unlike "*"), but
I think the problem is that these default SPF record are not identified 
any difernent as with "*" and its just normal spf record for that domain 
that is always the default and one can not turn this off. I have proposed 
instead using special prefix - possibly "*spf*" or just "**" so that
such records are clearly identified, this would also allow in the future 
to add feature to dns server itself that it could substitute default on 
its own instead of forcing client to do 2nd lookup each time.

2. I'm still not perfectly happy that SPF is reusing TXT and especially 
that this draft has changed all examples to use TXT instead of SPF record 
type. In my opinion SPF draft should promote new SPF record type a lot 
more and have clearly defined "exit" strategy of moving away from TXT 
records once new DNS RR has been issued.

-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Mon, 10 Jan 2005 17:05:24 +0000
Lines: 49
References: <william@elan.net>
X-From: owner-namedroppers@ops.ietf.org Mon Jan 10 18:16:33 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "william(at)elan.net" <william@elan.net> 
	of "Mon, 10 Jan 2005 01:02:56 PST."
	<Pine.LNX.4.44.0501100043230.32345-100000@sokol.elan.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> 1. The draft says that if SPF record is not found for say
> "sub.example.com", that lookup should be made for zonecut record which
> would probably be "example.com". This is done as a way to simulate
> *.example.com and provide spf record for all subdomains (especially
> when they exist unlike "*"), but I think the problem is that these
> default SPF record are not identified any difernent as with "*" and
> its just normal spf record for that domain that is always the default
> and one can not turn this off. I have proposed instead using special
> prefix - possibly "*spf*" or just "**" so that such records are
> clearly identified, this would also allow in the future to add feature
> to dns server itself that it could substitute default on its own
> instead of forcing client to do 2nd lookup each time.

the SPF steamroller can't slow down or change direction, nope.  or else
we'd be using namehack-based subclassing a la the "mail-from" proposal.

however, some thought should be given to protecting the root servers.
given that a number of ill-considered SPF clientsides already do things
like look at some/all header addresses even if only envelope addresses
are indicated, thus breaking mailing list exploders who leave the headers
as they are and only rewrite the envelope, we know that SPF's clientside
will be broad, unaudited, and powerful.  it may be that given a domain
name of sub.example.com, queries will be made for TXT RRs having names

     sub.example.com
     example.com
     com
     .

which would be bad.  with specific reference to RFC 1535, i'd like this
danger to be called out in the dns-related part of the SPF document, in
case any clientside implentor ever actually reads the SPF specification.
perhaps a prohibition of the form "SPF queries must never be made for
domain names having fewer than two labels".

> 2. I'm still not perfectly happy that SPF is reusing TXT and especially 
> that this draft has changed all examples to use TXT instead of SPF record 
> type. In my opinion SPF draft should promote new SPF record type a lot 
> more and have clearly defined "exit" strategy of moving away from TXT 
> records once new DNS RR has been issued.

moreover, there should be two documents.  one an FYI describing SPF as it
is (TXT RR based), and one a proposed standard recommending a new RR type.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Jaap Akkerhuis <jaap@NLnetLabs.nl>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 15:46:17 +0100
Lines: 22
References: <20050110170524.7F54F13CDF@sa.vix.com>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 15:56:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-reply-to: Your message of Mon, 10 Jan 2005 17:05:24 +0000.
             <20050110170524.7F54F13CDF@sa.vix.com> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    
    with specific reference to RFC 1535, i'd like this
    danger to be called out in the dns-related part of the SPF document, in
    case any clientside implentor ever actually reads the SPF specification.
    perhaps a prohibition of the form "SPF queries must never be made for
    domain names having fewer than two labels".
    
Although I agree with Paul about the danger (unnecessarily querying
of root and tld domains) he tries to guard against with this language,
this won't help tlds with second level or deeper level structure
such as co.uk or eu.int.

This whole idea of walking up the tree looking for an SPF record
seems to be broken to me.

	jaap

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Dean Anderson <dean@av8.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 10:47:35 -0500 (EST)
Lines: 54
References: <20050110081913.GA13715@nic.fr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 16:56:43 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: dean@localhost.localdomain
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
In-Reply-To: <20050110081913.GA13715@nic.fr>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

SPF has been shown not to work, and I've collected about 14 major problems
with it, posted on ietf-mxcomp.  SPF fails to achieve the goals set out,
and makes some problems worse.  The ietf-mxcomp working group (created for
SPF) has shut down.  But some people continue to push SPF ahead anyway.  
I think the reasons are financial. Some have patents and products, and
want an IETF stamp of approval for their marketing literature.

Indeed, I thought you were one of the people who wanted to push it ahead
despite the failures.  Is your post a rhetorical question?

I think the silence (and workgroup dissolution) means that people have
realized that it won't work and that no one has any solutions.

		--Dean

On Mon, 10 Jan 2005, Stephane Bortzmeyer wrote:

> On Mon, Jan 03, 2005 at 08:41:36PM -0600,
>  wayne <wayne@schlitt.net> wrote 
>  a message of 47 lines which said:
> 
> > There is a new I-D for the SPF email anti-forgery system available
> > for review.
> ...
> > While SPF mostly deals with the [2]821 SMTP level, it also relies
> > heavily on DNS to communicate between the domain owner, and the
> > email receiver.  This I-D also makes provisions to create a new RR
> > that is just a clone of the TXT RR type.  While I did not make it to
> > IETF-61, it is my understanding that Stephane Bortzmeyer made a
> > presentation on this subject during the DNSEXT session.
> 
> There have been apparently no reply. Does it mean that nobody see
> solid problems and that there is a silent and rough consensus that
> the I-D can move forward :-)
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 16:52:39 +0100
Organization: NIC France
Lines: 15
References: <20050110081913.GA13715@nic.fr> <Pine.LNX.4.44.0501111039320.25262-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 16:58:39 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Dean Anderson <dean@av8.com>
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0501111039320.25262-100000@localhost.localdomain>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-1-686 i686
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, Jan 11, 2005 at 10:47:35AM -0500,
 Dean Anderson <dean@av8.com> wrote 
 a message of 47 lines which said:

> SPF has been shown not to work,

This is clearly off-topic for this group. As said by the chairs at
IETF 61, "DNS extensions" should focus on DNS issues, like Paul Vixie
did by addressing the new RR type question.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 17:15:23 +0100
Organization: NIC France
Lines: 29
References: <20050110170524.7F54F13CDF@sa.vix.com> <200501111446.j0BEkHRd014084@open.nlnetlabs.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 17:20:18 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Jaap Akkerhuis <jaap@NLnetLabs.nl>
Content-Disposition: inline
In-Reply-To: <200501111446.j0BEkHRd014084@open.nlnetlabs.nl>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-1-686 i686
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, Jan 11, 2005 at 03:46:17PM +0100,
 Jaap Akkerhuis <jaap@NLnetLabs.nl> wrote 
 a message of 21 lines which said:

> this won't help tlds with second level or deeper level structure
> such as co.uk or eu.int.

At least, it will mitigate the problem.
 
> This whole idea of walking up the tree looking for an SPF record
> seems to be broken to me.

The rationale is to handle domains with subdomains (like
www.example.com or sales.example.com) which typically forget to set up
a SPF record for the subdomains. So, the phisher can just say MAIL
FROM:<president@www.example.com> and defeat SPF even if example.com is
protected.

Of course, the proper solution is to have SPF records automatically
generated by the same process that creates the zone file with the
proper PTR, the MX records and so on. But some people seems to edit
large zone files by hand (they typically do not know M4 or Perl or
Ruby) and want a mechanism to help them.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 17:17:34 +0000
Lines: 31
References: <20050110170524.7F54F13CDF@sa.vix.com>
 <200501111446.j0BEkHRd014084@open.nlnetlabs.nl>
 <20050111161523.GB10493@nic.fr>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 18:24:29 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>,
	Jaap Akkerhuis <jaap@NLnetLabs.nl>
In-Reply-To: <20050111161523.GB10493@nic.fr>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 11 January 2005 17:15 +0100 Stephane Bortzmeyer <bortzmeyer@nic.fr> 
wrote:

> Of course, the proper solution is to have SPF records automatically
> generated by the same process that creates the zone file with the
> proper PTR, the MX records and so on. But some people seems to edit
> large zone files by hand (they typically do not know M4 or Perl or
> Ruby) and want a mechanism to help them.

People's inability to edit zonefiles by hand properly or implement proper
macro languages does not seem to me a sufficient reason to load up the DNS
servers of those above them in the hierarchy. Seems to me you are trying to
solve a layer 8 problem at the protocol layer, when it should, if anywhere,
be solved at the application layer.

I had heard wind (possibly malicious, so I don't assign it much
credibility) that the real purpose behind the tree walk was so those who
don't like the default SPF action could lobby TLDs etc. so that the default
SPF for (say) any domains within (e.g.) co.uk could be changed by (e.g.)
Nominet (and .com by Verisign etc.). I think this is a responsibility zone
operators should not seek...

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Robert Martin-Legene <robert@dk-hostmaster.dk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 20:10:43 +0100
Lines: 28
References: <20050110170524.7F54F13CDF@sa.vix.com> <200501111446.j0BEkHRd014084@open.nlnetlabs.nl> <20050111161523.GB10493@nic.fr> <027E2CD01066B81A584BCE5F@[192.168.0.4]>
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 Tue Jan 11 20:21:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org
Content-Disposition: inline
In-Reply-To: <027E2CD01066B81A584BCE5F@[192.168.0.4]>
User-Agent: Mutt/1.4.1i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, Jan 11, 2005 at 05:17:34PM +0000, Alex Bligh wrote:
>I had heard wind (possibly malicious, so I don't assign it much
>credibility) that the real purpose behind the tree walk was so those who
>don't like the default SPF action could lobby TLDs etc. so that the default
>SPF for (say) any domains within (e.g.) co.uk could be changed by (e.g.)
>Nominet (and .com by Verisign etc.). I think this is a responsibility zone
>operators should not seek...

I wonder how many registries would really want to do this. It sounds
very dangerous.=20

However, the load on the TLD servers could be greatly diminished
by adding a TLD TXT record with a very high TTL.

I am not saying it's a solution to the problem. Just yet another hack.
The application should never query the TLD servers (nor lvl 2 for e.g.
=2Euk) for SPF-records of any kind.

--=20
Robert Martin-Leg=E8ne
IT security manager
DK Hostmaster A/S

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 19:24:38 +0000
Lines: 19
References: <20050110170524.7F54F13CDF@sa.vix.com>
 <200501111446.j0BEkHRd014084@open.nlnetlabs.nl>
 <20050111161523.GB10493@nic.fr> <027E2CD01066B81A584BCE5F@[192.168.0.4]>
 <20050111191043.GA28114@thunder.dkhm>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 20:29:29 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Martin-Legene <robert@dk-hostmaster.dk>,
	namedroppers@ops.ietf.org
In-Reply-To: <20050111191043.GA28114@thunder.dkhm>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 11 January 2005 20:10 +0100 Robert Martin-Legene 
<robert@dk-hostmaster.dk> wrote:

> I am not saying it's a solution to the problem. Just yet another hack.
> The application should never query the TLD servers (nor lvl 2 for e.g.
> .uk) for SPF-records of any kind.

May be I misunderstood. How does the application know to query
for 2 levels in sales.ibm.com, but only one level for sales.co.uk?

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Robert Martin-Legene <robert@dk-hostmaster.dk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 20:28:05 +0100
Lines: 18
References: <20050110170524.7F54F13CDF@sa.vix.com> <200501111446.j0BEkHRd014084@open.nlnetlabs.nl> <20050111161523.GB10493@nic.fr> <027E2CD01066B81A584BCE5F@[192.168.0.4]> <20050111191043.GA28114@thunder.dkhm> <C11A25C5CD68A4ABFEB45BC2@[192.168.100.25]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 20:33:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Alex Bligh <alex@alex.org.uk>
Content-Disposition: inline
In-Reply-To: <C11A25C5CD68A4ABFEB45BC2@[192.168.100.25]>
User-Agent: Mutt/1.4.1i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, Jan 11, 2005 at 07:24:38PM +0000, Alex Bligh wrote:
>May be I misunderstood. How does the application know to query
>for 2 levels in sales.ibm.com, but only one level for sales.co.uk?

I was stressing that *I* dont think it should.

It probably doesn't know, and that's a problem.

--=20
Robert Martin-Leg=E8ne
IT-sikkerhedschef / IT security manager
DK Hostmaster A/S

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Jaap Akkerhuis <jaap@NLnetLabs.nl>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 20:37:20 +0100
Lines: 20
References: <C11A25C5CD68A4ABFEB45BC2@[192.168.100.25]>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 20:42:39 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-reply-to: Your message of Tue, 11 Jan 2005 19:24:38 +0000.
             <C11A25C5CD68A4ABFEB45BC2@[192.168.100.25]> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    
    > I am not saying it's a solution to the problem. Just yet another hack.
    > The application should never query the TLD servers (nor lvl 2 for e.g.
    > .uk) for SPF-records of any kind.
    
    May be I misunderstood. How does the application know to query
    for 2 levels in sales.ibm.com, but only one level for sales.co.uk?

Also note that there are TLDs out there which have a mixed system:
they allow myname.example. and myname.com.example.  If you want to
have any hack like this to work, you have to configure the whole
current and future name space structure in the hack to make it work.

	jaap

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 21:23:35 +0000
Lines: 30
References: <robert@dk-hostmaster.dk>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 22:37:31 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Robert Martin-Legene <robert@dk-hostmaster.dk> 
	of "Tue, 11 Jan 2005 20:10:43 +0100."
	<20050111191043.GA28114@thunder.dkhm> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> It sounds very dangerous.

yes.  see RFC 1535 (and perhaps RFC 1536) to understand the dangers
inherent in client-side dns surfing.

> However, the load on the TLD servers could be greatly diminished by
> adding a TLD TXT record with a very high TTL.

no.  enough broken dns clients out there fail to cache anything at all,
positive or negative, that the presence of a TLD TXT RR would not slow
down the rate at which these queries were generated, or needlessly and
endlessly repeated.

> I am not saying it's a solution to the problem. Just yet another hack.
> The application should never query the TLD servers (nor lvl 2 for e.g.
> .uk) for SPF-records of any kind.

i had not even considered .CO.UK (et al) when i wrote my "less than two
labels" recommendation.  there's basically no way to appropriately limit
the search based on the TLD or SLD.  since there's also absolutely no
reason to do this kind of searching from the client side -- whatever they
use to look up MX will work to look up TXT -- which means, wildcards or
masqueradenames.  this "search the parent" logic has to be removed, or
replaced with a "MUST NOT" of some kind.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 22:43:26 +0100
Lines: 22
References: <20050110170524.7F54F13CDF@sa.vix.com> <200501111446.j0BEkHRd014084@open.nlnetlabs.nl> <20050111161523.GB10493@nic.fr> <027E2CD01066B81A584BCE5F@[192.168.0.4]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 22:51:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Alex Bligh <alex@alex.org.uk>
Content-Disposition: inline
In-Reply-To: <027E2CD01066B81A584BCE5F@[192.168.0.4]>
User-Agent: Mutt/1.3.28i
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 3.0
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, Jan 11, 2005 at 05:17:34PM +0000,
 Alex Bligh <alex@alex.org.uk> wrote 
 a message of 25 lines which said:

> I had heard wind (possibly malicious, so I don't assign it much
> credibility) that the real purpose behind the tree walk was so those
> who don't like the default SPF action could lobby TLDs etc. so that
> the default SPF for (say) any domains within (e.g.) co.uk could be
> changed by (e.g.)  Nominet (and .com by Verisign etc.).

They are not rumours, some people already requested that (not the I-D
authors, nor me). A TLD even announced its SPF record for the TLD as
an "anti-spam" service...

(Today, four TLD, all managed by the same registry, have a SPF 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:46:12 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 14:02:10 -0800 (PST)
Lines: 115
References: <20050110170524.7F54F13CDF@sa.vix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 23:08:45 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: Paul Vixie <paul@vix.com>
In-Reply-To: <20050110170524.7F54F13CDF@sa.vix.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On Mon, 10 Jan 2005, Paul Vixie wrote:

> > 1. The draft says that if SPF record is not found for say
> > "sub.example.com", that lookup should be made for zonecut record which
> > would probably be "example.com". This is done as a way to simulate
> > *.example.com and provide spf record for all subdomains (especially
> > when they exist unlike "*"), but I think the problem is that these
> > default SPF record are not identified any difernent as with "*" and
> > its just normal spf record for that domain that is always the default
> > and one can not turn this off. I have proposed instead using special
> > prefix - possibly "*spf*" or just "**" so that such records are
> > clearly identified, this would also allow in the future to add feature
> > to dns server itself that it could substitute default on its own
> > instead of forcing client to do 2nd lookup each time.
> 
> however, some thought should be given to protecting the root servers.
> given that a number of ill-considered SPF clientsides already do things
> like look at some/all header addresses even if only envelope addresses
> are indicated, thus breaking mailing list exploders who leave the headers
> as they are and only rewrite the envelope, we know that SPF's clientside
> will be broad, unaudited, and powerful.  it may be that given a domain
> name of sub.example.com, queries will be made for TXT RRs having names
> 
>      sub.example.com
>      example.com
>      com

That is not exactly true. They are not planning to "walk down the tree" 
but they will look authoritive zone domain (the one that holds SOA for
that domain) and then lookup record at that start (i.e. if 
sub1.sub2.example.com is a host in the zone of example.com, the lookup 
will immediately come to example.com and not first to sub2.example.com). 
That pretty much means the root servers will never see the such lookups. 
But situation is different for TLDs and SLDs, there are in fact number of 
domains used as nameservers which "A" records are registered directly in 
TLD zones and I'm afraid some implementations may incorrectly assume that 
TLD zone is start of authority for that domain (they are not supposed to 
make this assumption just because "A" record is returned in the ADDITIONAL 
section but we all know majority will not do extra dns lookup once they 
get the answer - be it from ADDITIONAL section or otherwise).

I'm also generally concerned that SPF lookups just for single host will
very often result in at least 4 dns lookups with zonecut defaults (one TXT 
lookup for sub.domain.com, one SPF lookup for sub.domain.com, one TXT 
lookup for domain.com, one SPF lookup for domain.com) and that is just
too much extra load on ISP dns servers and ISPs already have more then
enough problems with their DNS servers getting overloaded because of
other anti-spam filter and as ISP operator and dns host for 1000+ domains
I'm quite concerned.

That is why when I originally mentioned the concept of putting spf default 
at zonecut at interim MARID meeting in May, I had in mind that it would 
not be SPF client doing lookups but that instead its dns server at the ISP 
that would recognize "default wildcarded" SPF records and serve them and 
I'm of the opinion that this should be considered tool for the dns server 
operator rather then client hack. 

If you remember I in fact emailed you if BIND could implement it (i.e. 
synthetic new type of wildcard for when record does exist) and if this 
would require upgrade to DNS protocol. If I understood the answer, it
would because since zones are transfered and secondary can be running
different version of dns server - it should then also be able to
understand new symantics (i.e. just like with regular wildcards where
answer is synthesized but its done same way by every dns server).

Now what I propose is that we do focus on making these zonecut default
records something for dns server to understand (which will require update
to dns specs) and synthesize the answer automatically but in the mean time 
allow clients to simulate it and do 2nd lookup. This way even if one dns 
servers understands new semantics and secondary does not, it could still 
work but we are assuming that in the future once all dns servers are upgraded
the 2nd dns lookup will never be done. If we do want to do it this way, 
then I think it should be new type of wildcard record (and "**" seems quite
good for that purpose) so it could be applicable to more then just SPF.

> which would be bad.  with specific reference to RFC 1535, i'd like this
> danger to be called out in the dns-related part of the SPF document, in
> case any clientside implentor ever actually reads the SPF specification.
> perhaps a prohibition of the form "SPF queries must never be made for
> domain names having fewer than two labels".

What about example.com.uk? You can't make an assumption that TLD is correct
start of domain delegation.
 
> > 2. I'm still not perfectly happy that SPF is reusing TXT and especially 
> > that this draft has changed all examples to use TXT instead of SPF record 
> > type. In my opinion SPF draft should promote new SPF record type a lot 
> > more and have clearly defined "exit" strategy of moving away from TXT 
> > records once new DNS RR has been issued.
> 
> moreover, there should be two documents.  one an FYI describing SPF as it
> is (TXT RR based), and one a proposed standard recommending a new RR type.

The current draft is going for experimental status RFC and is the one 
describing what could loosely be called current practice of how SPF is
used (I note that some features are in fact implemented a lot more widely 
then others, for example lookups at EHLO are done at less then 1/10th of 
the rate the MAIL-FROM lookups are done and the mentioned wildcard default 
are almost not implemented at all, which is  why I think its not too late 
to change this). I would definitely be opposed to having used TXT RR in 
standard track document but even with experiment it should be made clear
that we want to move all lookups to SPF before it could become standard.

-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 22:52:56 +0100
Lines: 29
References: <C11A25C5CD68A4ABFEB45BC2@[192.168.100.25]> <200501111937.j0BJbKAa018369@open.nlnetlabs.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 23:15:26 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Jaap Akkerhuis <jaap@NLnetLabs.nl>
Content-Disposition: inline
In-Reply-To: <200501111937.j0BJbKAa018369@open.nlnetlabs.nl>
User-Agent: Mutt/1.3.28i
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 3.0
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, Jan 11, 2005 at 08:37:20PM +0100,
 Jaap Akkerhuis <jaap@NLnetLabs.nl> wrote 
 a message of 19 lines which said:

> Also note that there are TLDs out there which have a mixed system:
> they allow myname.example. and myname.com.example.  If you want to
> have any hack like this to work, you have to configure the whole
> current and future name space structure in the hack to make it work.

Hence the proposal to use the "zone cut" algorithm (RFC 2181) for the
lookup, which avoids any assumption about the structure or the depth
of the name space...

With the "security belt" added by Paul Vixie (never request for names
of zero or one label), it seems safe, even if there are better
solutions (like mentioned by Alex Bligh).

For the fun, do note that the zone cut algorithm can be defeated by
unusual configurations (so it is a good idea to introduce Paul Vixie's
limit). For instance, try to find the zone cut above doesnotexist.ac
(hint: some of the name servers of the TLD are recursive).



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Don Stokes <don@plugh.daedalus.co.nz>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 11:21:58 +1300
Lines: 22
References: <20050111161523.GB10493@nic.fr>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 23:28:32 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Your message of "Tue, 11 Jan 2005 17:15:23 BST."
             <20050111161523.GB10493@nic.fr> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
>> This whole idea of walking up the tree looking for an SPF record
>> seems to be broken to me.
>
>The rationale is to handle domains with subdomains (like
>www.example.com or sales.example.com) which typically forget to set up
>a SPF record for the subdomains. So, the phisher can just say MAIL
>FROM:<president@www.example.com> and defeat SPF even if example.com is
>protected.

What's wrong with a wildcard TXT (or better still SPF) RR for such
subdomains?  Put that in the SPF spec, rather than speculatively heading
up the three.

-- don

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 14:45:01 -0800 (PST)
Lines: 25
References: <91525.1105482118@toybsd.zl2tnm.gen.nz>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 11 23:48:19 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: Don Stokes <don@plugh.daedalus.co.nz>
In-Reply-To: <91525.1105482118@toybsd.zl2tnm.gen.nz>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On Wed, 12 Jan 2005, Don Stokes wrote:

> What's wrong with a wildcard TXT (or better still SPF) RR for such
> subdomains?  Put that in the SPF spec, rather than speculatively heading
> up the three.

"*" wildcards are only useful for hosts that don't exist at all (no dns 
RR of any kind for that hostname), but they will not work for hosts that 
have some RR record which is what SPF people are after.

P.S. Is there some reason you have not read the Ed Lewis's wildcard draft 
that was discussed on this list just couple months ago? 
 
-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 23:22:36 +0000
Lines: 25
References: <william@elan.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 00:33:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "william(at)elan.net" <william@elan.net> 
	of "Tue, 11 Jan 2005 14:45:01 PST."
	<Pine.LNX.4.44.0501111441370.12250-100000@sokol.elan.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > What's wrong with a wildcard TXT (or better still SPF) RR for such
> > subdomains?  Put that in the SPF spec, rather than speculatively heading
> > up the three.
> 
> "*" wildcards are only useful for hosts that don't exist at all (no dns 
> RR of any kind for that hostname), but they will not work for hosts that 
> have some RR record which is what SPF people are after.

that still doesn't make any sense.  SPF RRs will only be used when there
is an extant LHS@RHS, and the RHS has to have either an A or MX RR which
is at either a real or synthesized (wildcard) name.  put the SPF RR (or
the TXT RR) adjacent to the existing MX or A RR, either at a real name if
that's how the A or MX is found, or at a wildcard "name" if that's how the
A or MX is found.

> P.S. Is there some reason you have not read the Ed Lewis's wildcard draft 
> that was discussed on this list just couple months ago? 

i'm pretty sure that we've all read that, or helped write it, or whatever.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 23:32:40 +0000
Lines: 27
References: <20050110170524.7F54F13CDF@sa.vix.com>
 <200501111446.j0BEkHRd014084@open.nlnetlabs.nl>
 <20050111161523.GB10493@nic.fr> <027E2CD01066B81A584BCE5F@[192.168.0.4]>
 <20050111214326.GB23107@sources.org>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 00:38:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
In-Reply-To: <20050111214326.GB23107@sources.org>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 11 January 2005 22:43 +0100 Stephane Bortzmeyer <bortzmeyer@nic.fr> 
wrote:

> They are not rumours, some people already requested that (not the I-D
> authors, nor me). A TLD even announced its SPF record for the TLD as
> an "anti-spam" service...
>
> (Today, four TLD, all managed by the same registry, have a SPF record.)

Well I'm no fan of spam, but I believe the argument over an SPF default
should be an IETF one - I can't (and I'm involved with a registry) see a
justification for registries effectively retrospectively being able to
impose an alternative. IE I am presuming there are good reasons the SPF
default is the way it is, and it should not be within the administrative
purview of some other entity to go change it (shades of sitefinder...).
That said, the argument that tree iteration is going to cause load problems
is more serious.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 23:42:38 +0000
Lines: 40
References: <Pine.LNX.4.44.0501111441370.12250-100000@sokol.elan.net>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 00:47:45 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "william(at)elan.net" <william@elan.net>,
	Don Stokes <don@plugh.daedalus.co.nz>
In-Reply-To: <Pine.LNX.4.44.0501111441370.12250-100000@sokol.elan.net>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 11 January 2005 14:45 -0800 "william(at)elan.net" <william@elan.net> 
wrote:

>> What's wrong with a wildcard TXT (or better still SPF) RR for such
>> subdomains?  Put that in the SPF spec, rather than speculatively heading
>> up the three.
>
> "*" wildcards are only useful for hosts that don't exist at all (no dns
> RR of any kind for that hostname), but they will not work for hosts that
> have some RR record which is what SPF people are after.
>
> P.S. Is there some reason you have not read the Ed Lewis's wildcard draft
> that was discussed on this list just couple months ago?

Whilst wildcards may not be a perfect solution, they are just one example
of synthesized/pseudosynthesized records at the authoritative server level.
By synthesized/psuedosynthesized I mean here only that the end user did not
input all the data of the result that's looked up (so I include, for
instance, macros in this) - they might or might not be there in an AXFR.
There is nothing wrong with application level "wildcards" handling this.

EG $authoritative_server_vendor could implement the "**" record/macro to
match any existing record and append a TXT record.

Why does this need solving at protocol layer at all? (people being unable
or unwilling to configure macros, and/or authoritative nameservers
not having an automagic function to turn SPF on in all zones etc.
does not seem like a good reason to me). We don't autogenerate/strip glue
records at a protocol layer because people are too lazy/incompetent to
work out how they work.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 18:22:35 -0600
Lines: 42
References: <william@elan.net> <20050111232236.E75DC13971@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 04:59:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 26
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:e/1BtZTk9zX9LGzzyobCV0CTiuk=
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


 [ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

In <20050111232236.E75DC13971@sa.vix.com> Paul Vixie <paul@vix.com> writes:

>> > What's wrong with a wildcard TXT (or better still SPF) RR for such
>> > subdomains?  Put that in the SPF spec, rather than speculatively heading
>> > up the three.
>> 
>> "*" wildcards are only useful for hosts that don't exist at all (no dns 
>> RR of any kind for that hostname), but they will not work for hosts that 
>> have some RR record which is what SPF people are after.
>
> that still doesn't make any sense.  SPF RRs will only be used when there
> is an extant LHS@RHS, and the RHS has to have either an A or MX RR which
> is at either a real or synthesized (wildcard) name.

The problem is that spammers and phishers can easily use
nonexistant.subdomain.example.com to get around example.com's sender
policy.  This has to work for both the RFC2821 MAIL FROM identity and
the RFC2821 HELO identity.  Sure the email receiver can have a policy
of rejecting email from non-existant domains or domains without an A
record, but in the world of email, there is far too much garbage sent
by legitimate mailers to make such a receiver policy universal.  There
needs to be a way for example.com to publish something for the entire
zone that it controls, even the non-existant parts.


-wayne




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 12:44:59 -0600
Lines: 91
References: <william@elan.net> <20050110170524.7F54F13CDF@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 04:59:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 75
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:zHpoBtP+WIvpXyF7sQcH2xYTH04=
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


 [ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

In <20050110170524.7F54F13CDF@sa.vix.com> Paul Vixie <paul@vix.com> writes:

>> 1. The draft says that if SPF record is not found for say
>> "sub.example.com", that lookup should be made for zonecut record which
>> would probably be "example.com". This is done as a way to simulate
>> *.example.com and provide spf record for all subdomains (especially
>> when they exist unlike "*"), [...]
>
> the SPF steamroller can't slow down or change direction, nope.  or else
> we'd be using namehack-based subclassing a la the "mail-from" proposal.

Hi Paul.

Although I've been reading posts from you since the late 80s, I'm
afraid I haven't read enough to know for sure whether you are speaking
sarcastically or not, so please excuse me if I respond seriously to a
joke.

Yes, it is now very hard to slow down or change the direction of SPF.
The spec has been pretty slushy for over a year, and incompatible
changes are going to cause a lot of problems.

As far as the namehack-based subclassing thing goes, two points.

First, William was talking about where to find the SPF record that
should be used as a *default*, not where all SPF records are located.
What he was talking about had nothing to do with subtyping the TXT RR
instead using a new RR type (e.g. SPF).

As for why the (current) SPF spec doesn't use the namehack-based
subclassing, at one time the SPF spec did use _spf.domain.tld.
Unfortunately, we found too many DNS hosting services that didn't
allow the underscore to be entered into the web pages.  This is kind
of a delema for those hosting services.  Yes, an underscore is
perfectly valid for a domain name, but it isn't valid for a host
name.  Trying to explain this difference to the general public
requires more effort than I suspect most DNS hosters are willing to
do.  Making a special exception for SPF records was not something we
expected that DNS hosters would make.  At least not when this was
changed over a year ago.


> however, some thought should be given to protecting the root servers.

I agree, and I'll try to find a good spot to add some language about
this.

Things are not quite as bad as they may seem.  It is subtle, but if an
SPF implementation conforms to the draft-schlitt-spf-classic-00 spec,
it takes work to generate a DNS query with only one label.  The ABNF
requires all domain specs to end with a dot followed by a "toplabel",
or a macro variable.  So, "include:com" is already invalid.  Normally,
the macro variables will have at least two labels in them, so
"include:%{o}" isn't going to be a problem either.  Even
"include:1.2.3.4" isn't valid, so the root servers won't be hit with
lookups for IP addresses.


> [...]                                    it may be that given a domain
> name of sub.example.com, queries will be made for TXT RRs having names
>
>      sub.example.com
>      example.com
>      com
>      .
>
> which would be bad.

I agree that this would be bad, but the current SPF spec would not
allow the checking for SPF records at "com" or ".".  If an SPF record
is not found at the exact domain name, the only other location that is
checked is at the top of the zone (i.e., right under the zone cut).


-wayne




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 12:49:25 -0600
Lines: 36
References: <20050110170524.7F54F13CDF@sa.vix.com> <200501111446.j0BEkHRd014084@open.nlnetlabs.nl>
 <20050111161523.GB10493@nic.fr> <027E2CD01066B81A584BCE5F@[192.168.0.4]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 04:59:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 20
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:HgSsQvuiGI0ilko4Ng3Gc+reiMs=
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


 [ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

In <027E2CD01066B81A584BCE5F@[192.168.0.4]> Alex Bligh <alex@alex.org.uk> writes:

> I had heard wind (possibly malicious, so I don't assign it much
> credibility) that the real purpose behind the tree walk was so those who
> don't like the default SPF action could lobby TLDs etc. so that the default
> SPF for (say) any domains within (e.g.) co.uk could be changed by (e.g.)
> Nominet (and .com by Verisign etc.). I think this is a responsibility zone
> operators should not seek...

Any such rumors that you have heard are either due to ignorance or
maliciousness.  None of the various SPF specs that have existed have
ever called for an arbitrary tree-walk, let alone one all the way to
the root.  The current SPF spec calls for checking SPF records in two
places, and two places only: at the given domain, and at the top of
the zone (just below the zone cut).  As such, any conforming SPF
implementation would never know about any SPF records at co.uk, or
.com.


-wayne




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 12:21:45 -0600
Lines: 113
References: <20050110081913.GA13715@nic.fr> <Pine.LNX.4.44.0501100043230.32345-100000@sokol.elan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Cc: spf-discuss@sea.gmane.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 04:59:17 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 97
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:B/YEveby8svmAhJFupdK+b3bqcc=
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


 [ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]


[note:  I've cc:'ed this to SPF-discuss because I think they will find
it useful.]


In <Pine.LNX.4.44.0501100043230.32345-100000@sokol.elan.net> "william(at)elan.net" <william@elan.net> writes:

> On Mon, 10 Jan 2005, Stephane Bortzmeyer wrote:
>
>> > There is a new I-D for the SPF email anti-forgery system available
>> > for review.
>> ...
>> > While SPF mostly deals with the [2]821 SMTP level, it also relies
>> > heavily on DNS to communicate between the domain owner, and the
>> > email receiver.  This I-D also makes provisions to create a new RR
>> > that is just a clone of the TXT RR type.  While I did not make it to
>> > IETF-61, it is my understanding that Stephane Bortzmeyer made a
>> > presentation on this subject during the DNSEXT session.
>> 
>> There have been apparently no reply. Does it mean that nobody see
>> solid problems and that there is a silent and rough consensus that
>> the I-D can move forward :-)

I wish.  ;-)


> I do see some problems, but I already raised them at spf-discuss. 
> But since you asked about it on namedroppers, I'll focus just list
> what I do not like as far as dns is concerned:

Yes, William has made a very large number of very helpful comments
about the various SPF drafts.  I've addressed many, but not all of
them. 


> 1. The draft says that if SPF record is not found for say "sub.example.com", 
> that lookup should be made for zonecut record which would probably be
> "example.com". This is done as a way to simulate *.example.com and provide
> spf record for all subdomains (especially when they exist unlike "*"), but
> I think the problem is that these default SPF record are not identified 
> any difernent as with "*" and its just normal spf record for that domain 
> that is always the default and one can not turn this off. I have proposed 
> instead using special prefix - possibly "*spf*" or just "**" so that
> such records are clearly identified, this would also allow in the future 
> to add feature to dns server itself that it could substitute default on 
> its own instead of forcing client to do 2nd lookup each time.

The idea of using a special subdomain for the default SPF record has
been kicked around before.  I know that Mark Lentczner (another I-D
author), and I talked about it a little bit.  Going back over the
comments I made to you on the SPF-discuss list, I see that I didn't
talk about it.

The reason why I didn't say anything about it was because I don't have
very strong feelings about the subject either way.  Right now, the SPF
I-D makes no mention of any special domain names or sub domains, so
I would kind of like to avoid creating one.  Also, if mandating a
special subdomain will generate complaints about "breaking wildcards",
which is another subject I don't have strong feelings on, but others
do.

Another possiblity would be to create a different record at the top of
the zone, with a different version string of, say, "v=spf1-default".
Then you could do something like "v=spf1-default redirect=%{d}" if you
want to get the current semantics, or "v=spf1-default -all" to deny
all email coming from subdomains without SPF records.  If the default
SPF record is really long and DNS packet space is limited, you could
use "v=spf1-default redirect=*spf*.%{d}" and get the semantics you
suggest.

Note:  These default SPF records are should only be used in cases
where mail claims to come from a subdomain that email normally
shouldn't come from.  The SPF spec says that domain owners should use
explicit SPF records for all other cases.  So, extra DNS lookups
shouldn't be a huge problem.  Legitimate email should never have the
overhead, and spammers would gain no advantage to using them.


> 2. I'm still not perfectly happy that SPF is reusing TXT and especially 
> that this draft has changed all examples to use TXT instead of SPF record 
> type. In my opinion SPF draft should promote new SPF record type a lot 
> more and have clearly defined "exit" strategy of moving away from TXT 
> records once new DNS RR has been issued.

As I've mentioned many times, I just don't see any practical migration
strategy for DNS RR usage.  The implicit MX rule of using the A record
is still very much needed after all these years.

The language that is in the draft about using TXT RRs and SPF RRs was
something that Mark Lentczner worked out with "the DNS folks" during
the MARID WG process.  (No, I don't know exactly who "the DNS folks"
were.)   Yes, I did many (but not all) of the examples, but that is
because I don't see why deployment of name servers that support the
SPF RR type for many years.


-wayne




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:12 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 04:19:37 +0000
Lines: 45
References: <wayne@schlitt.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 05:25:54 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from wayne <wayne@schlitt.net> 
	of "Tue, 11 Jan 2005 18:22:35 CST."
	<x43bx7lcms.fsf@footbone.schlitt.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > ...  SPF RRs will only be used when there is an extant LHS@RHS, and
> > the RHS has to have either an A or MX RR which is at either a real
> > or synthesized (wildcard) name.
> 
> The problem is that spammers and phishers can easily use
> nonexistant.subdomain.example.com to get around example.com's sender
> policy.

an spf subscriber can trivially detect this.  and probably already is.
postfix calls this functionality by many names, such as:

        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_invalid_hostname,
        reject_unauth_pipelining,
        reject_unauth_destination,
        reject_unknown_hostname,
        reject_non_fqdn_hostname,

and anyone who is interested enough in preventing forgery to install an
spf-capable mailer has the option of turning on features related to
nonexistent subdomains of spf-publishing domains.

since this can easily be handled on the client using the existing
protocol and well-tested features of common implementations, it should
not be made into an spf protocol requirement.

> This has to work for both the RFC2821 MAIL FROM identity and the
> RFC2821 HELO identity.  Sure the email receiver can have a policy of
> rejecting email from non-existant domains or domains without an A
> record, but in the world of email, there is far too much garbage sent
> by legitimate mailers to make such a receiver policy universal.  There
> needs to be a way for example.com to publish something for the entire
> zone that it controls, even the non-existant parts.

if a legitimate mailer is going to send garbage, they shouldn't publish
spf records.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 04:26:39 +0000
Lines: 22
References: <wayne@schlitt.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 05:32:22 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from wayne <wayne@schlitt.net> 
	of "Tue, 11 Jan 2005 12:49:25 CST."
	<x4is63ls22.fsf@footbone.schlitt.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> ... The current SPF spec calls for checking SPF records in two places,
> and two places only: at the given domain, and at the top of the zone
> (just below the zone cut).  As such, any conforming SPF implementation
> would never know about any SPF records at co.uk, or .com.

in what way are you discovering the zone cut?  it sounds as if you're
committing the "novice dns" mistake of assuming that every label cut
is also a zone cut.  if GW.HOME.VIX.COM is the mail sender (A and AAAA
exist), but its name is really GW.HOME in the zone VIX.COM (and there
is therefore no HOME.VIX.COM zone cut, NS RRset, or SOA RR), how would
you propose to discover the "zone cut" you're speaking of?

i know how i had to do it in bind8's res_findzonecut() (for RFC 2136
dynamic update clients to use when finding out where to send their
updates) and it's _hard_.  surely you aren't expecting every SMTP
listener to do this on every SMTP session they process.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 20:56:28 -0800 (PST)
Lines: 77
References: <20050112042639.8881D13DE2@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 Wed Jan 12 06:00:57 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: Paul Vixie <paul@vix.com>
In-Reply-To: <20050112042639.8881D13DE2@sa.vix.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On Wed, 12 Jan 2005, Paul Vixie wrote:

> > ... The current SPF spec calls for checking SPF records in two places,
> > and two places only: at the given domain, and at the top of the zone
> > (just below the zone cut).  As such, any conforming SPF implementation
> > would never know about any SPF records at co.uk, or .com.
> 
> in what way are you discovering the zone cut?  it sounds as if you're
> committing the "novice dns" mistake of assuming that every label cut
> is also a zone cut.  if GW.HOME.VIX.COM is the mail sender (A and AAAA
> exist), but its name is really GW.HOME in the zone VIX.COM (and there
> is therefore no HOME.VIX.COM zone cut, NS RRset, or SOA RR), how would
> you propose to discover the "zone cut" you're speaking of?

By checking the authority section:
-------------------------------------------------------------------------
$ dig soa gw.home.vix.com
; <<>> DiG 9.2.4 <<>> soa gw.home.vix.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49803
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;gw.home.vix.com.               IN      SOA

;; AUTHORITY SECTION:
vix.com.                0       IN      SOA     ns.lah1.vix.com. 
hostmaster.vix.com. 2005010200 3600 1800 604800 3600
-------------------------------------------------------------------------

So zonecut is "vix.com." since that is the start of authority. Current
SPF draft would call for doing SPF and/or TXT lookup at that zonecut.
Personally I'd prefer lookup to be madeto "**".<zonecut> instead.

The are some assumptions that are not in the draft but that we talked
about, in particular its assumed that if DNS RR is not available that DNS
server would return authority info in ADDITIONAL section of dns response
packet (which all BIND servers apparently do, if some other server does
not then additional dns lookup would be needed), i.e.:

-------------------------------------------------------------------------
$ dig gw.home.vix.com
; <<>> DiG 9.2.4 <<>> gw.home.vix.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13468
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;gw.home.vix.com.               IN      A

;; AUTHORITY SECTION:
vix.com.                3600    IN      SOA     ns.lah1.vix.com. 
hostmaster.vix.com. 2005010200 3600 1800 604800 3600
-------------------------------------------------------------------------

> i know how i had to do it in bind8's res_findzonecut() (for RFC 2136
> dynamic update clients to use when finding out where to send their
> updates) and it's _hard_.  surely you aren't expecting every SMTP
> listener to do this on every SMTP session they process.

Personally I'd not mind with having that function becoming part of resolver,
that will sure help us out ...

-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 05:24:36 +0000
Lines: 24
References: <william@elan.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 06:30:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "william(at)elan.net" <william@elan.net> 
	of "Tue, 11 Jan 2005 20:56:28 PST."
	<Pine.LNX.4.44.0501112042310.12250-100000@sokol.elan.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > ... how would you propose to discover the "zone cut" you're speaking of?
> 
> By checking the authority section:

did you know that the authority section is optional in positive responses?
(have you read RFC 2308?)

> > i know how i had to do it in bind8's res_findzonecut() ...
> 
> Personally I'd not mind with having that function becoming part of resolver,
> that will sure help us out ...

it has been part of the BIND resolver library since BIND 8.2 or so.  but
you are asking that every SMTP listener possess it and call it on every
SMTP session, which is a lot of potential extra traffic for all concerned.

and none of it is necessary to your application.  just don't query for
anything except the RHS.  (see my other reply elsewhere on this thread.)

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 22:11:30 -0800 (PST)
Lines: 39
References: <20050112052436.94F1F139A3@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 Wed Jan 12 07:15:07 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: Paul Vixie <paul@vix.com>
In-Reply-To: <20050112052436.94F1F139A3@sa.vix.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On Wed, 12 Jan 2005, Paul Vixie wrote:

> > > ... how would you propose to discover the "zone cut" you're speaking of?
> > 
> > By checking the authority section:
> 
> did you know that the authority section is optional in positive responses?
> (have you read RFC 2308?)

Positive responses are not a problem - if somebody queries for SPF RR and 
gets it, there is no need to do anything else. If there is no authority 
section for negative response, then client can directly query for SOA.

> > > i know how i had to do it in bind8's res_findzonecut() ...
> > 
> > Personally I'd not mind with having that function becoming part of resolver,
> > that will sure help us out ...
> 
> it has been part of the BIND resolver library since BIND 8.2 or so. but
> you are asking that every SMTP listener possess it and call it on every
> SMTP session, which is a lot of potential extra traffic for all concerned.

Which is exactly why I said that we should make it special prefix that
dns server can recognize it and synthesize the answer. The client can
simulate this with zonecut method but as more dns servers begin to
support it, its no longer a problem in the long run.

---
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 06:24:47 +0000
Lines: 24
References: <wayne@schlitt.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 07:29:54 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from wayne <wayne@schlitt.net> 
	of "Tue, 11 Jan 2005 12:44:59 CST."
	<x4mzvfls9g.fsf@footbone.schlitt.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> Although I've been reading posts from you since the late 80s, I'm
> afraid I haven't read enough to know for sure whether you are speaking
> sarcastically or not, so please excuse me if I respond seriously to a
> joke.

no worries.  i'm not joking.  spf has been a marketing-driven juggernaut
since its first day, and nothing anybody has been able to say has changed
its course by even a degree.

> Yes, it is now very hard to slow down or change the direction of SPF.
> The spec has been pretty slushy for over a year, and incompatible
> changes are going to cause a lot of problems.

s/for over a year/since it was first proposed/, please.  i'm assuming that
you've read <http://www.circleid.com/article/634_0_1_0_C/>, and my response.

however, we've all been advised to limit our discussions about this draft
to dns-specific issues, so we should take this part offline.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 06:30:08 +0000
Lines: 26
References: <william@elan.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 07:36:04 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "william(at)elan.net" <william@elan.net> 
	of "Tue, 11 Jan 2005 22:11:30 PST."
	<Pine.LNX.4.44.0501112201260.12250-100000@sokol.elan.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > (have you read RFC 2308?)
> 
> Positive responses are not a problem - if somebody queries for SPF RR and 
> gets it, there is no need to do anything else. If there is no authority 
> section for negative response, then client can directly query for SOA.

it is very nearly unthinkable to me that a mail server, as a client of dns,
should ever have to make an SOA query, under any circumstances, especially
not fairly common circumstances.  ("positive" includes NOERROR/NODATA.)

> > ... are asking that every SMTP listener possess it and call it on every
> > SMTP session, which is a lot of potential extra traffic for all concerned.
> 
> Which is exactly why I said that we should make it special prefix that
> dns server can recognize it and synthesize the answer. The client can
> simulate this with zonecut method but as more dns servers begin to
> support it, its no longer a problem in the long run.

i really am pretty sure that the dns servers will be changed to support SPF
other than to support a new RRtype when y'all get around to proposing that.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Tue, 11 Jan 2005 23:10:24 -0800 (PST)
Lines: 57
References: <20050112063008.CBCF113DE2@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 Wed Jan 12 08:13:19 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: Paul Vixie <paul@vix.com>
In-Reply-To: <20050112063008.CBCF113DE2@sa.vix.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On Wed, 12 Jan 2005, Paul Vixie wrote:

> > > (have you read RFC 2308?)
> > 
> > Positive responses are not a problem - if somebody queries for SPF RR and 
> > gets it, there is no need to do anything else. If there is no authority 
> > section for negative response, then client can directly query for SOA.
> 
> it is very nearly unthinkable to me that a mail server, as a client of dns,
> should ever have to make an SOA query, under any circumstances, especially
> not fairly common circumstances.  ("positive" includes NOERROR/NODATA.)

As I said, on the tests it appears that dns servers (bind 8 and bind 9 
at least) do provide this information nearly all the time including for 
NOERROR/NODATA, so I don't think querying for SOA is going to be needed 
very often. And yes it does sound weird for non-dns service to query for 
soa,  but its not breaking anything either as far as I can see and querying
for soa can be usefull for more then just dns internal communication, for 
example to find tech/hostmaster address if whois is not available (ok, you 
can go ahead and blame me for this trick and inappropriate use :)

> > > ... are asking that every SMTP listener possess it and call it on every
> > > SMTP session, which is a lot of potential extra traffic for all concerned.
> > 
> > Which is exactly why I said that we should make it special prefix that
> > dns server can recognize it and synthesize the answer. The client can
> > simulate this with zonecut method but as more dns servers begin to
> > support it, its no longer a problem in the long run.
> 
> i really am pretty sure that the dns servers will be changed to support 
> SPF other than to support a new RRtype when y'all get around to 
> proposing that.

Should I take as that you're willing to support such a feature (synthetic
wildcard for existing hostname but without needed RR) in future versions
of bind? In that case it makes sense for this to become a new dns protocol
feature so that other dns servers would know how to support it too, so I 
think it would be good idea to write it out as ietf document (separate and
not just part of spf draft).

And to make it possible to identify dns records where such new wildcard 
does need to be supported, I think we do need special prefix (and its not 
too late as I don't even know any spf implementation that is doing zonecut  
default checks yet). 

-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 09:23:47 +0100
Lines: 26
References: <20050111215256.GA24161@sources.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 09:37:00 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol
To: namedroppers@ops.ietf.org
In-reply-to: Your message of "Tue, 11 Jan 2005 22:52:56 +0100."
             <20050111215256.GA24161@sources.org> 
X-Organization: Uni Bielefeld, Technische Fakultaet
X-Phone: +49 521 106 2902
Content-ID: <27148.1105518222.1@zeder.TechFak.Uni-Bielefeld.DE>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Stephane Bortzmeyer wrote:

> With the "security belt" added by Paul Vixie (never request for names
> of zero or one label), it seems safe, even if there are better
> solutions (like mentioned by Alex Bligh).

that 'belt', which I guess Paul didn't really suggest, tends to be at least as
bad as the desease. The 'tree climbing' approach is the result of a
misconception about the DNS: it tries to kind of inherit records or even policy
from higher levels in the DNS, which is not only wrong for TLD or "registry
level" zones like DE or co.uk, respectively, but also further down the tree.
The foo department of bar.example cannot be assumed to by default apply
the same policies as bar.example. In the same way we do not inherit or
deduce MX RRs or A RRs, the temptation should be resisted in this case.

Unfortunately there are some precedents (see 'wpad'), but those should not
count as justification. This is DNS, other services might be more appropriate
for the inheritance approach.

-Peter

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 10:39:38 +0100
Lines: 21
References: <20050110170524.7F54F13CDF@sa.vix.com> <Pine.LNX.4.44.0501102042010.12250-100000@sokol.elan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 10:47:29 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "william(at)elan.net" <william@elan.net>
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0501102042010.12250-100000@sokol.elan.net>
User-Agent: Mutt/1.3.28i
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 3.0
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, Jan 11, 2005 at 02:02:10PM -0800,
 william(at)elan.net <william@elan.net> wrote 
 a message of 114 lines which said:

> They are not planning to "walk down the tree" but they will look
> authoritive zone domain (the one that holds SOA for that domain)

The SPF draft says "the SPF client MUST find the Zone Cut as defined
in [RFC2181] section 6" and RFC 2181 uses NS records, not SOA.

For a "normal" zone loaded by BIND, it does not matter. But you can
always find funny cases where it's different depending on wether you
use NS or SOA (study doesnotexist.ac).



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 10:41:09 +0100
Lines: 17
References: <x4mzvfls9g.fsf@footbone.schlitt.net> <20050112062447.E432713CDF@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 Wed Jan 12 10:49:20 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>
Content-Disposition: inline
In-Reply-To: <20050112062447.E432713CDF@sa.vix.com>
User-Agent: Mutt/1.3.28i
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 3.0
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, Jan 12, 2005 at 06:24:47AM +0000,
 Paul Vixie <paul@vix.com> wrote 
 a message of 23 lines which said:

> spf has been a marketing-driven juggernaut since its first day, and
> nothing anybody has been able to say has changed its course by even
> a degree.

Not really, for instance the "DNS walking up to the zone cut" is a
very recent addition, no SPF implementation currently does 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 listbox+trampoline+735+779500+6b7ca774@v2.listbox.com  Fri Dec 29 10:46:13 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 03:11:38 -0800 (PST)
Lines: 941
References: <20050112093938.GA13528@sources.org>
Reply-To: spf-discuss@v2.listbox.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org, <spf-discuss@v2.listbox.com>
X-From: listbox+trampoline+735+779500+6b7ca774@v2.listbox.com Wed Jan 12 12:09:35 2005
Return-path: <listbox+trampoline+735+779500+6b7ca774@v2.listbox.com>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: spf-discuss@v2.listbox.com
In-Reply-To: <20050112093938.GA13528@sources.org>
Sender: owner-spf-discuss@v2.listbox.com
Precedence: list
List-ID: <spf-discuss@v2.listbox.com>
List-Software: listbox.com v2.0
List-Help: <http://v2.listbox.com/doc/help_sub?list_name=spf-discuss@v2.listbox.com>
List-Subscribe: <mailto:subscribe-spf-discuss@v2.listbox.com>, <http://v2.listbox.com/subscribe/?listname=spf-discuss@v2.listbox.com>
List-Unsubscribe: <mailto:unsubscribe-spf-discuss@v2.listbox.com>, <http://v2.listbox.com/member/unsubscribe/?listname=spf-discuss@v2.listbox.com>
Errors-To: listbox+trampoline+735+779500+6b7ca774@v2.listbox.com

On Wed, 12 Jan 2005, Stephane Bortzmeyer wrote:

> On Tue, Jan 11, 2005 at 02:02:10PM -0800,
>  william(at)elan.net <william@elan.net> wrote 
>  a message of 114 lines which said:
> 
> > They are not planning to "walk down the tree" but they will look
> > authoritive zone domain (the one that holds SOA for that domain)
> 
> The SPF draft says "the SPF client MUST find the Zone Cut as defined
> in [RFC2181] section 6" and RFC 2181 uses NS records, not SOA.
> 
> For a "normal" zone loaded by BIND, it does not matter. But you can
> always find funny cases where it's different depending on wether you
> use NS or SOA (study doesnotexist.ac).

The problems occur because one of their nameservers sometimes does not
work (ns2c.nic.ac which is referred to from some authority answers for ns)
but actual start of authority domain is the same no matter if you lookup
for SOA or NS. I preferred SOA because that is real authority data and 
this is what is (optional but almost always) included in authority section
when you lookup RR and it does not exist (NODATA) and frankly its an 
oversight on my part that I did not notice that reference is made to 
finding zonecut by means of NS.

This all points out that using existing DNS RFC2181 as reference for what 
we want is probably not the best idea and that we need new separate draft 
document explaining how these new zonecut default answer wildcards are 
supposed to work and how dns server can simulate and synthesize the answer
and how dns client (or dns resolver) can find it if the answer was not 
available by finding correct zonecut from either dns packet authority
section or making a separate lookup for that authority data.

Below are the results of me checking .ac as Stephane suggested - as you can
see they always provide same zonecut domain name answers. The difference 
does exist for sub.domain.com where some of the servers do provide the 
answer but majority do not. This should also be studied separately because
we need to decide how zonecut default wildcard should work for NXDOMAIN 
answers, but my own preference is that it SHOULD NOT apply there - if domain
is not available, then there would be no email coming from it (and if there
is it can be discarded by other means as Paul already indicated) and if 
somebody does care then they can just add regular "*" wildcard record.

--------------------------------------------------------------------------
Lookups for NS and SOA for NODOMAINHERE.AC (to compare AUTHORITY section) 
--------------------------------------------------------------------------
; <<>> DiG 9.2.1 <<>> ns nodomainhere.ac @a.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44170
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nodomainhere.ac.		IN	NS

;; AUTHORITY SECTION:
nodomainhere.ac.	593	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; Query time: 167 msec
;; SERVER: 64.251.31.177#53(a.nic.ac)
;; WHEN: Wed Jan 12 02:06:57 2005
;; MSG SIZE  rcvd: 84


; <<>> DiG 9.2.1 <<>> soa nodomainhere.ac @a.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42572
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	SOA

;; ANSWER SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 182 msec
;; SERVER: 64.251.31.177#53(a.nic.ac)
;; WHEN: Wed Jan 12 02:07:05 2005
;; MSG SIZE  rcvd: 149


; <<>> DiG 9.2.1 <<>> ns nodomainhere.ac @b.nic.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42829
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nodomainhere.ac.		IN	NS

;; AUTHORITY SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; Query time: 167 msec
;; SERVER: 66.235.201.216#53(b.nic.io)
;; WHEN: Wed Jan 12 02:07:15 2005
;; MSG SIZE  rcvd: 84


; <<>> DiG 9.2.1 <<>> soa nodomainhere.ac @b.nic.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56857
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	SOA

;; ANSWER SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 134 msec
;; SERVER: 66.235.201.216#53(b.nic.io)
;; WHEN: Wed Jan 12 02:07:22 2005
;; MSG SIZE  rcvd: 149


; <<>> DiG 9.2.1 <<>> ns nodomainhere.ac @b.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57591
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nodomainhere.ac.		IN	NS

;; AUTHORITY SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; Query time: 364 msec
;; SERVER: 217.160.203.158#53(b.nic.ac)
;; WHEN: Wed Jan 12 02:07:32 2005
;; MSG SIZE  rcvd: 84


; <<>> DiG 9.2.1 <<>> soa nodomainhere.ac @b.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56061
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	SOA

;; ANSWER SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 304 msec
;; SERVER: 217.160.203.158#53(b.nic.ac)
;; WHEN: Wed Jan 12 02:07:45 2005
;; MSG SIZE  rcvd: 149


; <<>> DiG 9.2.1 <<>> ns nodomainhere.ac @b.nic.sh
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37382
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nodomainhere.ac.		IN	NS

;; AUTHORITY SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; Query time: 166 msec
;; SERVER: 216.117.156.206#53(b.nic.sh)
;; WHEN: Wed Jan 12 02:07:59 2005
;; MSG SIZE  rcvd: 84


; <<>> DiG 9.2.1 <<>> soa nodomainhere.ac @b.nic.sh
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63044
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	SOA

;; ANSWER SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 128 msec
;; SERVER: 216.117.156.206#53(b.nic.sh)
;; WHEN: Wed Jan 12 02:08:08 2005
;; MSG SIZE  rcvd: 149


; <<>> DiG 9.2.1 <<>> ns nodomainhere.ac @ns2.jp.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55417
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	NS

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 147 msec
;; SERVER: 202.181.97.168#53(ns2.jp.io)
;; WHEN: Wed Jan 12 02:08:30 2005
;; MSG SIZE  rcvd: 107


; <<>> DiG 9.2.1 <<>> soa nodomainhere.ac @ns2.jp.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27911
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	SOA

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 130 msec
;; SERVER: 202.181.97.168#53(ns2.jp.io)
;; WHEN: Wed Jan 12 02:08:36 2005
;; MSG SIZE  rcvd: 107


; <<>> DiG 9.2.1 <<>> ns nodomainhere.ac @ns3.icb.co.uk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3763
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nodomainhere.ac.		IN	NS

;; AUTHORITY SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; Query time: 292 msec
;; SERVER: 217.199.188.61#53(ns3.icb.co.uk)
;; WHEN: Wed Jan 12 02:08:52 2005
;; MSG SIZE  rcvd: 84


; <<>> DiG 9.2.1 <<>> soa nodomainhere.ac @ns3.icb.co.uk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48018
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	SOA

;; ANSWER SECTION:
nodomainhere.ac.	600	IN	SOA	ns1c.nic.ac. admin.nic.ac. 2003120101 10800 3600 604800 3600

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 280 msec
;; SERVER: 217.199.188.61#53(ns3.icb.co.uk)
;; WHEN: Wed Jan 12 02:08:58 2005
;; MSG SIZE  rcvd: 149


; <<>> DiG 9.2.1 <<>> ns nodomainhere.ac @ns2.uucp.ne.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12657
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	NS

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 140 msec
;; SERVER: 202.181.96.60#53(ns2.uucp.ne.jp)
;; WHEN: Wed Jan 12 02:09:10 2005
;; MSG SIZE  rcvd: 107


; <<>> DiG 9.2.1 <<>> soa nodomainhere.ac @ns2.uucp.ne.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49812
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nodomainhere.ac.		IN	SOA

;; AUTHORITY SECTION:
nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.
nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 125 msec
;; SERVER: 202.181.96.60#53(ns2.uucp.ne.jp)
;; WHEN: Wed Jan 12 02:09:14 2005
;; MSG SIZE  rcvd: 107


; <<>> DiG 9.2.1 <<>> ns nodomainhere.ac @ns1c.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8297
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nodomainhere.ac.               IN      NS

;; AUTHORITY SECTION:
nodomainhere.ac.        600     IN      SOA     ns1c.nic.ac. admin.nic.ac. 
2003120101 10800 3600 604800 3600

;; Query time: 91 msec
;; SERVER: 216.117.170.115#53(ns1c.nic.ac)
;; WHEN: Wed Jan 12 02:59:55 2005
;; MSG SIZE  rcvd: 90


; <<>> DiG 9.2.1 <<>> soa nodomainhere.ac @ns1c.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31333
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nodomainhere.ac.               IN      SOA

;; ANSWER SECTION:
nodomainhere.ac.        600     IN      SOA     ns1c.nic.ac. admin.nic.ac. 
2003120101 10800 3600 604800 3600

;; Query time: 166 msec
;; SERVER: 216.117.170.115#53(ns1c.nic.ac)
;; WHEN: Wed Jan 12 02:59:12 2005
;; MSG SIZE  rcvd: 90

--------------------------------------------------------------------------
Lookups for A for SUB.NODOMAINHERE.AC (to compare AUTHORITY sections) 
--------------------------------------------------------------------------

; <<>> DiG 9.2.1 <<>> sub.nodomainhere.ac @ns2.uucp.ne.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62958
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	A

;; AUTHORITY SECTION:
sub.nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.
sub.nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 140 msec
;; SERVER: 202.181.96.60#53(ns2.uucp.ne.jp)
;; WHEN: Wed Jan 12 02:09:22 2005
;; MSG SIZE  rcvd: 111


; <<>> DiG 9.2.1 <<>> sub.nodomainhere.ac @ns3.icb.co.uk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3351
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	A

;; Query time: 289 msec
;; SERVER: 217.199.188.61#53(ns3.icb.co.uk)
;; WHEN: Wed Jan 12 02:09:29 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> sub.nodomainhere.ac @ns2.jp.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57455
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	A

;; AUTHORITY SECTION:
sub.nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.
sub.nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 203 msec
;; SERVER: 202.181.97.168#53(ns2.jp.io)
;; WHEN: Wed Jan 12 02:09:35 2005
;; MSG SIZE  rcvd: 111


; <<>> DiG 9.2.1 <<>> sub.nodomainhere.ac @b.nic.sh
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64983
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	A

;; Query time: 90 msec
;; SERVER: 216.117.156.206#53(b.nic.sh)
;; WHEN: Wed Jan 12 02:09:41 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> sub.nodomainhere.ac @b.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52524
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	A

;; Query time: 296 msec
;; SERVER: 217.160.203.158#53(b.nic.ac)
;; WHEN: Wed Jan 12 02:09:45 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> sub.nodomainhere.ac @b.nic.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2781
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	A

;; Query time: 108 msec
;; SERVER: 66.235.201.216#53(b.nic.io)
;; WHEN: Wed Jan 12 02:09:49 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> sub.nodomainhere.ac @a.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 483
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	A

;; Query time: 171 msec
;; SERVER: 64.251.31.177#53(a.nic.ac)
;; WHEN: Wed Jan 12 02:09:54 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> sub.nodomainhere.ac @ns1c.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58157
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.           IN      A

;; AUTHORITY SECTION:
nodomainhere.ac.        600     IN      SOA     ns1c.nic.ac. admin.nic.ac. 
2003120101 10800 3600 604800 3600

;; Query time: 207 msec
;; SERVER: 216.117.170.115#53(ns1c.nic.ac)
;; WHEN: Wed Jan 12 02:58:23 2005
;; MSG SIZE  rcvd: 94

--------------------------------------------------------------------------
Lookups for SOA for SUB.NODOMAINHERE.AC (to compare AUTHORITY sections) 
--------------------------------------------------------------------------

; <<>> DiG 9.2.1 <<>> soa sub.nodomainhere.ac @ns2.uucp.ne.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18735
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	SOA

;; AUTHORITY SECTION:
sub.nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.
sub.nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 129 msec
;; SERVER: 202.181.96.60#53(ns2.uucp.ne.jp)
;; WHEN: Wed Jan 12 02:52:14 2005
;; MSG SIZE  rcvd: 111


; <<>> DiG 9.2.1 <<>> soa sub.nodomainhere.ac @ns2.jp.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9000
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	SOA

;; AUTHORITY SECTION:
sub.nodomainhere.ac.	86400	IN	NS	ns1c.nic.ac.
sub.nodomainhere.ac.	86400	IN	NS	ns2c.nic.ac.

;; ADDITIONAL SECTION:
ns1c.nic.ac.		3600	IN	A	216.117.170.115
ns2c.nic.ac.		3600	IN	A	64.251.31.233

;; Query time: 125 msec
;; SERVER: 202.181.97.168#53(ns2.jp.io)
;; WHEN: Wed Jan 12 02:52:17 2005
;; MSG SIZE  rcvd: 111


; <<>> DiG 9.2.1 <<>> soa sub.nodomainhere.ac @ns3.icb.co.uk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42199
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	SOA

;; Query time: 258 msec
;; SERVER: 217.199.188.61#53(ns3.icb.co.uk)
;; WHEN: Wed Jan 12 02:52:52 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> soa sub.nodomainhere.ac @b.nic.sh
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5653
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	SOA

;; Query time: 110 msec
;; SERVER: 216.117.156.206#53(b.nic.sh)
;; WHEN: Wed Jan 12 02:53:17 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> soa sub.nodomainhere.ac @b.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9748
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	SOA

;; Query time: 280 msec
;; SERVER: 217.160.203.158#53(b.nic.ac)
;; WHEN: Wed Jan 12 02:53:27 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> soa sub.nodomainhere.ac @b.nic.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32734
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	SOA

;; Query time: 94 msec
;; SERVER: 66.235.201.216#53(b.nic.io)
;; WHEN: Wed Jan 12 02:53:34 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> soa sub.nodomainhere.ac @a.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4826
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.		IN	SOA

;; Query time: 135 msec
;; SERVER: 64.251.31.177#53(a.nic.ac)
;; WHEN: Wed Jan 12 02:53:40 2005
;; MSG SIZE  rcvd: 37


; <<>> DiG 9.2.1 <<>> soa sub.nodomainhere.ac @ns1c.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17808
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.nodomainhere.ac.           IN      SOA

;; AUTHORITY SECTION:
nodomainhere.ac.        600     IN      SOA     ns1c.nic.ac. admin.nic.ac. 
2003120101 10800 3600 604800 3600

;; Query time: 135 msec
;; SERVER: 216.117.170.115#53(ns1c.nic.ac)
;; WHEN: Wed Jan 12 02:57:10 2005
;; MSG SIZE  rcvd: 94

--------------------------------------------------------------------------
Lookups for HINFO for NIC.AC (they have TXT record for NIC.AC but not HINFO)
--------------------------------------------------------------------------

; <<>> DiG 9.2.1 <<>> hinfo nic.ac @ns2.uucp.ne.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20391
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nic.ac.				IN	HINFO

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 116 msec
;; SERVER: 202.181.96.60#53(ns2.uucp.ne.jp)
;; WHEN: Wed Jan 12 02:45:59 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> hinfo nic.ac @ns3.icb.co.uk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24775
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nic.ac.				IN	HINFO

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 162 msec
;; SERVER: 217.199.188.61#53(ns3.icb.co.uk)
;; WHEN: Wed Jan 12 02:46:07 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> hinfo nic.ac @ns2.jp.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41250
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nic.ac.				IN	HINFO

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 137 msec
;; SERVER: 202.181.97.168#53(ns2.jp.io)
;; WHEN: Wed Jan 12 02:46:14 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> hinfo nic.ac @b.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48099
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nic.ac.				IN	HINFO

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 171 msec
;; SERVER: 217.160.203.158#53(b.nic.ac)
;; WHEN: Wed Jan 12 02:46:26 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> hinfo nic.ac @b.nic.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56580
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nic.ac.				IN	HINFO

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 21 msec
;; SERVER: 66.235.201.216#53(b.nic.io)
;; WHEN: Wed Jan 12 02:46:42 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> hinfo nic.ac @b.nic.sh
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11333
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nic.ac.				IN	HINFO

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 162 msec
;; SERVER: 216.117.156.206#53(b.nic.sh)
;; WHEN: Wed Jan 12 02:46:53 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> hinfo nic.ac @a.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34481
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nic.ac.				IN	HINFO

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 107 msec
;; SERVER: 64.251.31.177#53(a.nic.ac)
;; WHEN: Wed Jan 12 02:46:59 2005
;; MSG SIZE  rcvd: 72

--------------------------------------------------------------------------
Lookups for TXT for NS.NIC.AC (NS.NIC.AC host exist but does not have TXT)
--------------------------------------------------------------------------

; <<>> DiG 9.2.1 <<>> txt ns.nic.ac @ns2.uucp.ne.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31761
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.nic.ac.			IN	TXT

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 125 msec
;; SERVER: 202.181.96.60#53(ns2.uucp.ne.jp)
;; WHEN: Wed Jan 12 03:10:23 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> txt ns.nic.ac @ns3.icb.co.uk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26560
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.nic.ac.			IN	TXT

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 162 msec
;; SERVER: 217.199.188.61#53(ns3.icb.co.uk)
;; WHEN: Wed Jan 12 03:10:48 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> txt ns.nic.ac @ns2.jp.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47938
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.nic.ac.			IN	TXT

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 125 msec
;; SERVER: 202.181.97.168#53(ns2.jp.io)
;; WHEN: Wed Jan 12 03:11:00 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> txt ns.nic.ac @b.nic.sh
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61937
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.nic.ac.			IN	TXT

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 89 msec
;; SERVER: 216.117.156.206#53(b.nic.sh)
;; WHEN: Wed Jan 12 03:11:04 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> txt ns.nic.ac @b.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38409
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.nic.ac.			IN	TXT

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 171 msec
;; SERVER: 217.160.203.158#53(b.nic.ac)
;; WHEN: Wed Jan 12 03:11:11 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> txt ns.nic.ac @b.nic.io
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29993
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.nic.ac.			IN	TXT

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 21 msec
;; SERVER: 66.235.201.216#53(b.nic.io)
;; WHEN: Wed Jan 12 03:11:16 2005
;; MSG SIZE  rcvd: 72


; <<>> DiG 9.2.1 <<>> txt ns.nic.ac @a.nic.ac
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36464
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.nic.ac.			IN	TXT

;; AUTHORITY SECTION:
nic.ac.			3600	IN	SOA	ns.nic.ac. nicadmin.nic.ac. 94 3600 1800 3600000 3600

;; Query time: 97 msec
;; SERVER: 64.251.31.177#53(a.nic.ac)
;; WHEN: Wed Jan 12 03:11:21 2005
;; MSG SIZE  rcvd: 72





From listbox+trampoline+735+779500+6b7ca774@v2.listbox.com  Fri Dec 29 10:46:13 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 14:15:27 +0100
Lines: 35
References: <20050112093938.GA13528@sources.org> <Pine.LNX.4.44.0501120159480.12250-100000@sokol.elan.net>
Reply-To: spf-discuss@v2.listbox.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org, spf-discuss@v2.listbox.com
X-From: listbox+trampoline+735+779500+6b7ca774@v2.listbox.com Wed Jan 12 14:23:48 2005
Return-path: <listbox+trampoline+735+779500+6b7ca774@v2.listbox.com>
To: spf-discuss@v2.listbox.com
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0501120159480.12250-100000@sokol.elan.net>
User-Agent: Mutt/1.3.28i
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 3.0
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com
Sender: owner-spf-discuss@v2.listbox.com
Precedence: list
List-ID: <spf-discuss@v2.listbox.com>
List-Software: listbox.com v2.0
List-Help: <http://v2.listbox.com/doc/help_sub?list_name=spf-discuss@v2.listbox.com>
List-Subscribe: <mailto:subscribe-spf-discuss@v2.listbox.com>, <http://v2.listbox.com/subscribe/?listname=spf-discuss@v2.listbox.com>
List-Unsubscribe: <mailto:unsubscribe-spf-discuss@v2.listbox.com>, <http://v2.listbox.com/member/unsubscribe/?listname=spf-discuss@v2.listbox.com>
Errors-To: listbox+trampoline+735+779500+6b7ca774@v2.listbox.com

On Wed, Jan 12, 2005 at 03:11:38AM -0800,
 william(at)elan.net <william@elan.net> wrote 
 a message of 939 lines which said:

> but actual start of authority domain is the same no matter if you
> lookup for SOA or NS.

Not really, see later.

> I preferred SOA because that is real authority data 
...
> This all points out that using existing DNS RFC2181 as reference for
> what we want is probably not the best idea

I assume that RFC 2181 uses NS for a reason. I do not know it but we
could ask the authors or Google or the namedroppers' archive.

> and that we need new separate draft document explaining how these
> new zonecut default answer wildcards are supposed to work and how
> dns server can simulate and synthesize the answer and how dns client
> (or dns resolver) can find it if the answer was not available by
> finding correct zonecut

Good luck for the discussion on namedroppers :-)

> Below are the results of me checking .ac as Stephane suggested - as
> you can see they always provide same zonecut domain name
> answers. The difference does exist for sub.domain.com where some of
> the servers do provide the answer but majority do not.

This is because some name servers of the TLD are recursive but not all
(there is a "rd" in your flags but not always a "ra" in the
answer). Check with "dig +norecurse" and you'll see a different
picture, specially for zone cuts.



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Zone cut
Date: Wed, 12 Jan 2005 13:50:17 +0000
Lines: 24
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 14:57:38 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

I had always assumed (fatal error) that although the location of the
zone cut is clearly relevant to implementation of DNS protocol, it
should be transparent to applications using it, i.e. that an
application should be able to rely on the fact that a the domain name
foo.bar.example.com works the same, whether or not there's a zone cut
between labels "foo" and "bar". As such I further assumed that protocols
SHOULD NOT rely on the location of the zone cut.

Thinking about it again, I don't have much basis for the assumption apart
from the fact it seems a good principle of abstraction in a layered
architecture (to encapsulate underlying protocol implementation so
it's invisible to upper layers), and that it might allow future protocol
changes where (for instance) zone cut markedly changed or ceased to
exist as a concept (perhaps some day we might want zone cut==label cut).

Was my assumption right or wrong? Should it be documented?

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Robert Martin-Legene <robert@dk-hostmaster.dk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 15:15:51 +0100
Lines: 31
References: <20050111191043.GA28114@thunder.dkhm> <20050111212335.578BC13E3B@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 15:23:20 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>
Content-Disposition: inline
In-Reply-To: <20050111212335.578BC13E3B@sa.vix.com>
User-Agent: Mutt/1.4.1i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, Jan 11, 2005 at 09:23:35PM +0000, Paul Vixie wrote:
>> However, the load on the TLD servers could be greatly diminished by
>> adding a TLD TXT record with a very high TTL.
>
>no.  enough broken dns clients out there fail to cache anything at all,
>positive or negative, that the presence of a TLD TXT RR would not slow
>down the rate at which these queries were generated, or needlessly and
>endlessly repeated.

Yes it would.

That there are some broken clients does not mean that all others will
misbehave. And if you are lucky they even have a cache in front of them
- but you assume that is broken too, I suppose - we have all seen
repetetive queries on our servers. Fine. But it still has an effect for
all correctly functioning implementations. So I think you are
exaggerating a little bit when you say plainly that it will have no
effect.

(and I still don't think it's a solution to a problem)

--=20
Robert Martin-Leg=E8ne
IT security manager
DK Hostmaster A/S

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 14:36:55 +0000
Lines: 13
References: <paul@vix.com>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 15:46:08 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Paul Vixie <paul@vix.com> 
	of "Wed, 12 Jan 2005 06:30:08 GMT."
	<20050112063008.CBCF113DE2@sa.vix.com> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

i wrote:

> i really am pretty sure that the dns servers will be changed to support SPF

s/will/won't/.  sorry.  (though it was clear in context, i suppose.)

> other than to support a new RRtype when y'all get around to proposing that.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 14:44:38 +0000
Lines: 63
References: <william@elan.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 15:51:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "william(at)elan.net" <william@elan.net> 
	of "Tue, 11 Jan 2005 23:10:24 PST."
	<Pine.LNX.4.44.0501112250020.12250-100000@sokol.elan.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > it is very nearly unthinkable to me that a mail server, as a client of dns,
> > should ever have to make an SOA query, under any circumstances, especially
> > not fairly common circumstances.  ("positive" includes NOERROR/NODATA.)
> 
> As I said, on the tests it appears that dns servers (bind 8 and bind 9 
> at least) do provide this information nearly all the time including for 
> NOERROR/NODATA, so I don't think querying for SOA is going to be needed 
> very often.

this is namedroppers@, not bind-workers@.  how a particular implementation
behaves is of no interest to the ietf, other than if a widely implemented
protocol violation (which this is not) makes it necessary to design-around
(which this does not).

> And yes it does sound weird for non-dns service to query for soa, but
> its not breaking anything either as far as I can see and querying for
> soa can be usefull for more then just dns internal communication, for
> example to find tech/hostmaster address if whois is not available (ok,
> you can go ahead and blame me for this trick and inappropriate use :)

that's what RP RR's are for.  or did you not know that SOA was never cached?

> > i really am pretty sure that the dns servers will be changed to support 
> > SPF other than to support a new RRtype when y'all get around to 
> > proposing that.

s/will/won't/, sorry.  though i suppose it was clear in context.

> Should I take as that you're willing to support such a feature (synthetic
> wildcard for existing hostname but without needed RR) in future versions
> of bind?

no.  i misspoke.  BIND will implement the dns protocol as defined by the
ietf, with occasional experimental features if those do not violate the
protocol defined by the ietf.

> In that case it makes sense for this to become a new dns protocol
> feature so that other dns servers would know how to support it too, so
> I think it would be good idea to write it out as ietf document
> (separate and not just part of spf draft).

even though i misspoke, there's a path forward illuminated by the mistake.
if you want rrtype-specific wildcards, like for example an "**" label in a
zone file should be a wildcard but only for the rrtypes at the "**" node,
then go ahead and propose it.  if ietf approved such a standard, then BIND
will implement it.  i suspect that the process would be too long for SPF's
requirements.

> And to make it possible to identify dns records where such new wildcard 
> does need to be supported, I think we do need special prefix (and its not 
> too late as I don't even know any spf implementation that is doing zonecut  
> default checks yet). 

that's not a reason for a special prefix.  but as SOA is not cached, it is
not something that should be queried for other than as part of DNS operations
such as serial number queries governing IXFR/AXFR or UPDATE.  since SPF does
not yet do any zonecut checks, please remove that part of the draft.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 14:53:12 +0000
Lines: 49
References: <bortzmeyer@nic.fr>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 16:02:54 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org, spf-discuss@v2.listbox.com
In-Reply-To: Message from Stephane Bortzmeyer <bortzmeyer@nic.fr> 
	of "Wed, 12 Jan 2005 14:15:27 +0100."
	<20050112131527.GA23620@sources.org> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

note 1: in my prior mail on this thread i referred to the meng weng interview
at <http://www.circleid.com/article/634_0_1_0_C/>, and my response there.  it
turns out the circleid folks braino'd the URL for MAIL-FROM.  i've since added
an httpd "Alias" here that makes their broken URL work.  if you tried to
follow that link and couldn't, please try again now.

note 2: i'm replying to a message that was sent to both namedroppers@ and
spf-discuss@.  this terrifies me.  i'm setting reply-to; plz honour it even
though i'm not a member of the spf-discuss@ list and won't see the rest of
this thread.  if you're replying to the DNS issues, do so on namedroppers@,
but in any case, do not bridge this thread to both mailing lists.

> > I preferred SOA because that is real authority data 
> ...
> > This all points out that using existing DNS RFC2181 as reference for
> > what we want is probably not the best idea
> 
> I assume that RFC 2181 uses NS for a reason. I do not know it but we
> could ask the authors or Google or the namedroppers' archive.

SOA is never cached.  it is only meant to be queried for as part of DNS
protocol operations like figuring out if the serial number has changed
(for IXFR/AXFR) or figuring out where to send a DNS UPDATE message.  no
normal client of DNS data should propose to query for this.  those of you
who are coders can look at my comments in bind8's res_findzonecut() for
more information about finding zone cuts, and you should be asking yourself,
why would a mail server ever do this, let alone do it on every SMTP session?

> > Below are the results of me checking .ac as Stephane suggested - as
> > you can see they always provide same zonecut domain name
> > answers. The difference does exist for sub.domain.com where some of
> > the servers do provide the answer but majority do not.
> 
> This is because some name servers of the TLD are recursive but not all
> (there is a "rd" in your flags but not always a "ra" in the
> answer). Check with "dig +norecurse" and you'll see a different
> picture, specially for zone cuts.

indeed, it is vitally unwise to depend on the behaviour of a specific zone
or a specific dns implementation when planning a protocol feature.  you have
to look at what's permitted under the existing specification, and then delete
(not add) some things based on current global practices.  sending back an
SOA is optional in many cases.  see RFC 2308.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 06:21:48 -0600
Lines: 52
References: <wayne@schlitt.net> <20050112041937.9D7E513CDF@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 16:08:33 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 36
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:HIHLFc9a+Ur9/hhfJvv/jND2uHg=
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


 [ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

In <20050112041937.9D7E513CDF@sa.vix.com> Paul Vixie <paul@vix.com> writes:

>> > ...  SPF RRs will only be used when there is an extant LHS@RHS, and
>> > the RHS has to have either an A or MX RR which is at either a real
>> > or synthesized (wildcard) name.
>> 
>> The problem is that spammers and phishers can easily use
>> nonexistant.subdomain.example.com to get around example.com's sender
>> policy.
>
> an spf subscriber can trivially detect this.  [...]

I'm not sure what you mean by an "spf subscriber", I'm guessing you
are talking about the system that checks for SPF records.  (This is
called the "spf client" in the I-D.)


> postfix calls this functionality by many names, such as: [list snipped]

Yes, and other mailers have similar options, but those are receiver
policies, not sender policies.  


> and anyone who is interested enough in preventing forgery to install an
> spf-capable mailer has the option of turning on features related to
> nonexistent subdomains of spf-publishing domains.

I don't see how you can detect if a domain owner has published SPF
records without checking for them in the DNS.  Nonexistant subdomains
won't return SPF records.  Hence, the default at the zone cut.

I really don't see how the email receiver (SMTP server) options that
you mentioned above will work for the "spf subscriber".


-wayne




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 05:57:57 -0600
Lines: 52
References: <wayne@schlitt.net> <20050112042639.8881D13DE2@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 16:08:33 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 36
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:zXKFDrgYlrtchRuKghiQV4P0nFY=
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


 [ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

In <20050112042639.8881D13DE2@sa.vix.com> Paul Vixie <paul@vix.com> writes:

>> ... The current SPF spec calls for checking SPF records in two places,
>> and two places only: at the given domain, and at the top of the zone
>> (just below the zone cut).
>
> in what way are you discovering the zone cut?

See: http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-00.html#version


>                                                it sounds as if you're
> committing the "novice dns" mistake of assuming that every label cut
> is also a zone cut.

It sounds as if you're assuming instead of reviewing the I-D.


> i know how i had to do it in bind8's res_findzonecut() (for RFC 2136
> dynamic update clients to use when finding out where to send their
> updates) and it's _hard_.  surely you aren't expecting every SMTP
> listener to do this on every SMTP session they process.

Actually, res_findzonecut() is what I've based my code on.  See this
post I made to spf-discuss almost a year ago:

http://archives.listbox.com/spf-discuss@v2.listbox.com/200403/0026.html


I don't claim to be an expert on DNS.  As others have pointed out, the
zone cut is one of the newest features of SPF (introducted about May
'03).  I certainly could be convinced to drop it and/or modify it to
make it work better.


-wayne




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 14:57:28 +0000
Lines: 40
References: <robert@dk-hostmaster.dk>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 16:11:26 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Robert Martin-Legene <robert@dk-hostmaster.dk> 
	of "Wed, 12 Jan 2005 15:15:51 +0100."
	<20050112141551.GB5932@thunder.dkhm> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> >> However, the load on the TLD servers could be greatly diminished by
> >> adding a TLD TXT record with a very high TTL.
>
> >no.  enough broken dns clients out there fail to cache anything at all,
> >positive or negative, that the presence of a TLD TXT RR would not slow
> >down the rate at which these queries were generated, or needlessly and
> >endlessly repeated.
> 
> Yes it would.

no, actually, it would not.

> That there are some broken clients does not mean that all others will
> misbehave.

i didn't say all others would misbehave.  i said that the rate at which
these queries were generated, or needless and endlessly repeated, would
not be affected by the presence of a TLD TXT RR.

> And if you are lucky they even have a cache in front of them - but you
> assume that is broken too, I suppose - we have all seen repetetive
> queries on our servers.  Fine.  But it still has an effect for all
> correctly functioning implementations.  So I think you are
> exaggerating a little bit when you say plainly that it will have no
> effect.

the dominant effects will come from the people who don't cache.  for more
information on this, see all three papers at

	    http://dns.measurement-factory.com/writings/

> (and I still don't think it's a solution to a problem)

hopefully we're on the same page now.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: Zone cut
Date: Wed, 12 Jan 2005 10:20:49 -0500
Lines: 98
References: <B99DEED72EF9CF2867283DBF@[192.168.1.112]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 16:27:48 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: edlewis@127.0.0.1
In-Reply-To: <B99DEED72EF9CF2867283DBF@[192.168.1.112]>
To: Alex Bligh <alex@alex.org.uk>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 13:50 +0000 1/12/05, Alex Bligh wrote:
>I had always assumed (fatal error) that although the location of the
>zone cut is clearly relevant to implementation of DNS protocol, it
>should be transparent to applications using it, i.e. that an
>application should be able to rely on the fact that a the domain name
>foo.bar.example.com works the same, whether or not there's a zone cut
>between labels "foo" and "bar". As such I further assumed that protocols
>SHOULD NOT rely on the location of the zone cut.

Hmmmm.  (This kind of rambled on and on as I wrote...)

I can think of two applications efforts in which knowledge of zone 
cuts have come up.  I'll lay them out as data, not pointing out 
whether this is good or bad.

CRISP/IRIS, (a few will hate me for this analogy: = "WHOIS on 
steriods") has discussed using awareness of zone cuts to know where 
to locate IRIS-speaking servers.  There are alternatives to that 
using SRV and NAPTR, off the top of my head I forget whether 
awareness of zone cuts is still significant.  Perhaps not, but it was 
in there at one time.  Also, zone cuts in the reverse map didn't 
yield the desired results.

MARID, that ill-fated mail-related group, kicked around the idea of 
using records at the apex of a zone to cover the domains in the zone 
- an end run around them nasty wildcards.

I raise these not to say that apps should be aware of zone cuts, even 
if they seem to want to be.  I think IRIS uses other navigation 
techniques now, the MARID WG has been buried.  So "should be aware" 
might be "no".

>Thinking about it again, I don't have much basis for the assumption apart
>from the fact it seems a good principle of abstraction in a layered
>architecture (to encapsulate underlying protocol implementation so
>it's invisible to upper layers), and that it might allow future protocol
>changes where (for instance) zone cut markedly changed or ceased to
>exist as a concept (perhaps some day we might want zone cut==label cut).

Well, zone cuts are manifestations of administrative boundaries 
within the data model of DNS.  In as much as a the management/control 
plane of the protocol determines how the data plane "works", the 
mgt/control plane doesn't determine what is in the data plane.

One of the back-of-the-mind concepts that underlies DNS is the 
difference between names, addresses and routes.  A name is a tag that 
identifies an object.  An address is a tag that identifies where an 
object is, and changes as an object moves.  A route is a tag that 
identifies how to get from one object to another - and changes if 
either or both ends move.

A domain name (sequence of labels and all that) isn't really a name 
by that definition - you can argue (fruitlessly) whether it is an 
address (in the tree) or a route (from the root [no pun intended]). 
I tend to think of it as a route - because the labels prescribe the 
path.  OTOH - we never write www.example.cctld.gtld.example.www to 
talk about how to route between two domains.

Come to think of it, there's a different abstraction I use for the 
DNS data model though.  Whether domain names are routes or addresses 
is really a management/control "how you find it" issue.  For the data 
model, I think of DNS as an old time n-tuple/blackboard system(s) I 
learned about in AI days.

The idea is that you through up a 4-tuple (QNAME, QTYPE, QCLASS, 
____) and get another one back (QNAME, QTYPE, QCLASS, RDATA).  In 
lectures on these mythical systems, it didn't matter how the system 
found the response, that's what you got.  (Note: this is why I stomp 
my feet so much about query flags not being part of the query.)

In short, with that concept behind the data model of DNS, the 
management structure is not supposed to be exposed to the service 
user.  But protocol engineers being protocol engineers - we just 
can't stand to let laying principles get in the way.

>Was my assumption right or wrong? Should it be documented?

This should already be in 1034 (Concepts) unless there are 
clarifications needed.  Maybe there and in a bunch of texts on AI, 
data structures, command and control systems (for the plane 
things)... ;)

In summary - I thought this was going to be a 30-second response, a 
break from a deadline I have on other stuff.  But Alex's question is 
hitting the tip of an iceberg on a discussion about the computer 
*science* essence of DNS.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: IETF-62 Agenda items
Date: Wed, 12 Jan 2005 12:15:05 -0500
Lines: 37
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 Wed Jan 12 18:22:18 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
To: namedroppers@ops.ietf.org
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


IETF-62 March 6-11 2005.

The meeting is in less than 2 months, the chairs have requested one
long slot for this meeting.

Feels free to send in agenda items soon in order to help us chairs to
gauge if we need to add second slot.

Also this is a friendly reminder to document editors to take a look at
their documents and update them OR declare the documents are ready for
last call.

If there are many agenda requests there is still time to ask
for second slot so get those requests in.

Important deadlines:
February 7, Monday - Working Group Chair approval for initial document=20
(Version -00) submissions due by 09:00 ET (14:00 GMT)

February 14, Monday - Internet Draft Cut-off for initial document (-00)=20
submission by 09:00 ET (14:00 GMT)

February 21, Monday - Internet Draft final submission cut-off by 09:00 ET=20
(14:00 GMT)

So anyone intents to ask for a document to become a WG document the
co-chairs MUST see a draft of that document before Feb 7'th.

  	=D3lafur (and Olaf)


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 17:24:45 +0000
Lines: 66
References: <wayne@schlitt.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 18:46:59 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from wayne <wayne@schlitt.net> 
	of "Wed, 12 Jan 2005 06:21:48 CST."
	<x46522kfc3.fsf@footbone.schlitt.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > an spf subscriber can trivially detect this.  [...]
> 
> I'm not sure what you mean by an "spf subscriber", I'm guessing you
> are talking about the system that checks for SPF records.  (This is
> called the "spf client" in the I-D.)

ok, s/subscriber/client/, i'll try to remember.

> > postfix calls this functionality by many names, such as: [list snipped]
> 
> Yes, and other mailers have similar options, but those are receiver
> policies, not sender policies.  

so far so good.

> > and anyone who is interested enough in preventing forgery to install
> > an spf-capable mailer has the option of turning on features related
> > to nonexistent subdomains of spf-publishing domains.
> 
> I don't see how you can detect if a domain owner has published SPF
> records without checking for them in the DNS.  Nonexistant subdomains
> won't return SPF records.  Hence, the default at the zone cut.

this is still asking the recipient to pay for the sender's sins.  if an
SPF publisher wants their SPF data to be relevant then you have to deal
with the fact that SPF clients will, in addition to checking for SPF,
reject mail that has nonexistent RHS's or HELO names.

the way this would look in your draft is something like:

"SPF Clients should take precautions to reject e-mail containing
nonexistent domain names; SPF Publishers should be aware that this
will occur, and avoid emitting legitimate e-mail containing such
domain names."

> I really don't see how the email receiver (SMTP server) options that
> you mentioned above will work for the "spf subscriber".

see above.  with this simple rule, SPF Clients and SPF Publishers can
cooperate reliably in matters of e-mail authenticity, yet shift none of
the costs of this cooperation onto those who do not publish or consume
SPF data.  a forger who tried to use a nonexistent domain name as a way
to defeat the SPF checking would find their mail rejected due to the
nonexistence of the domain name rather than due to the presence of SPF.

i'm aware of dns installations who conform to rfc1034/rfc1035 in every
way, even though they only answer SOA queries from locally trusted hosts
such as dynamic update clients or IXFR/AXFR slave servers.  not even the
logic and commentary in BIND8's res_findzonecut() will save you from that.
it is well and truly too late to mandate that SOA's be sent, and even if
we could mandate it, we wouldn't want every mail server querying for them
since they aren't cached.  the performance and information-leak problems
from that would scream "bad engineering" even if the protocol could be
changed to require that zone cuts be visible to outsiders.

on a personal note, i'm struck by the similarity of this discussion to
others i've had about SPF in the past.  there's a "proof by vigorous
assertion" feeling about all this.  so let me play rough for a minute:

	   "DNS doesn't work the way you want it to.  Get over 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:46:13 2006
From: Florian Weimer <fw@deneb.enyo.de>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 21:23:18 +0100
Lines: 24
References: <Pine.LNX.4.44.0501112201260.12250-100000@sokol.elan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Paul Vixie <paul@vix.com>,  namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 21:31:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "william(at)elan.net" <william@elan.net>
In-Reply-To: <Pine.LNX.4.44.0501112201260.12250-100000@sokol.elan.net>
	(william elan net's message of "Tue, 11 Jan 2005 22:11:30 -0800
	(PST)")
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

* william elan net:

> On Wed, 12 Jan 2005, Paul Vixie wrote:
>
>> > > ... how would you propose to discover the "zone cut" you're speaking of?
>> > 
>> > By checking the authority section:
>> 
>> did you know that the authority section is optional in positive responses?
>> (have you read RFC 2308?)
>
> Positive responses are not a problem - if somebody queries for SPF
> RR and gets it, there is no need to do anything else.

SPF lookup for domains used in Internet mail *always* result in
positive responses because there exists an MX or A record for that
domain.  Conforming resolvers do not return an error code in this
case, but an empty data section.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Matt Larson <mlarson@verisign.com>
Subject: Caching SOA records (was Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt)
Date: Wed, 12 Jan 2005 15:24:17 -0500
Lines: 36
References: <Pine.LNX.4.44.0501112250020.12250-100000@sokol.elan.net> <20050112144438.B965313971@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 Wed Jan 12 21:32:05 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>
Content-Disposition: inline
In-Reply-To: <20050112144438.B965313971@sa.vix.com>
User-Agent: Mutt/1.5.6i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 12 Jan 2005, Paul Vixie wrote:
> but as SOA is not cached,

This statement is contradicted by RFC 1034, section 4.3.4:

  Name servers and resolvers should never attempt to add SOAs to the
  additional section of a non-authoritative response, or attempt to infer
  results which are not directly stated in an authoritative response.
  There are several reasons for this, including: cached information isn't
  usually enough to match up RRs and their zone names, SOA RRs may be
  cached due to direct SOA queries, and name servers are not required to
  output the SOAs in the authority section.

and RFC 2182:

  7.2. TTLs on SOA RRs

     It may be observed that in section 3.2.1 of RFC1035, which defines
     the format of a Resource Record, that the definition of the TTL field
     contains a throw away line which states that the TTL of an SOA record
     should always be sent as zero to prevent caching.  This is mentioned
     nowhere else, and has not generally been implemented.
     Implementations should not assume that SOA records will have a TTL of
     zero, nor are they required to send SOA records with a TTL of zero.

FWIW, my BIND 9.2.4 recursive name server clearly caches SOA records,
as do a few other BIND recursive servers of random or unknown version
numbers that I queried.

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:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Caching SOA records (was Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt)
Date: Wed, 12 Jan 2005 21:03:46 +0000
Lines: 13
References: <mlarson@verisign.com>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 22:10:09 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Matt Larson <mlarson@verisign.com> 
	of "Wed, 12 Jan 2005 15:24:17 EST."
	<20050112202417.GK8791@chinook.corpit.vrsn.com> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> FWIW, my BIND 9.2.4 recursive name server clearly caches SOA records,
> as do a few other BIND recursive servers of random or unknown version
> numbers that I queried.

i stand corrected.  i usually don't think of RFC 2182 when i think of dns,
and the "throw away line" in RFC 1035 has governed both my thinking, and
various early coding efforts.  (matt has corrected me on this point before.)

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 15:14:15 -0600
Lines: 128
References: <wayne@schlitt.net> <20050112172445.7EC84139A3@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 22:24:11 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 121
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:+oCmkT+teno+/Sa0vBcsQ+W+kKk=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



In <20050112172445.7EC84139A3@sa.vix.com> Paul Vixie <paul@vix.com> writes:

> on a personal note, i'm struck by the similarity of this discussion to
> others i've had about SPF in the past.  there's a "proof by vigorous
> assertion" feeling about all this.  so let me play rough for a minute:
>
> 	   "DNS doesn't work the way you want it to.  Get over it."
>

I'm quoting last things first to get this out of the way.

No problems playing rough, I've around the net since the late 80s and
have a very thick skin.  I will, however, assume the same for you and
say that there are a lot of similarities with what you are saying now
with previous comments I've seen from you about SPF.  A lot of what
you have been saying smacks of condescension, sour grapes and, yes,
ignorance.

In your reply to Meng's interview on CircleID[1], you said you very
much wish you would have jumped on this idea back in 1998.  I agree,
you should have.  You didn't.  Get over it.

Your claim last fall[2] that "he" (Meng?  me?  someone else?) didn't
know any better than to use TXT RRs is blatantly false and shows your
ignorance.  Meng started out by merging RMX and DMP, and RMX tried to
use a new RR.  We investigated and discussed using a new RR and
decided that trying to get a new RR would take years, would hurt
deployment, and in our humble opinions, we could design SPF records so
that problems with using TXT (as outline in, e.g. dns-choices) could
be largely avoided.

Your question[3] about how we intend to find the zone cut again shows
your ignorance and that you have not even bothered to read the draft.
I thought there was a rule in the IETF that those that haven't read
the drafts shouldn't comment on them.  Even if there isn't, I think we
would be a lot more productive if you did.


The people involved in developing SPF are not world experts in all
things email, DNS and/or spam.  Many of us, however, are very
knowledgeable about several of these areas.  In general, our overriding
goal has been to create a good (but not necessarily perfect) system
to slow email forgery and get as rapid a deployment as possible.
Rapid deployment has, for better or worse, influenced many of our
decisions, including using DNS instead of a new protocol, using TXT
RRs, not using a subdomain for subtyping, not requiring upgrades to
DNS servers, etc.  We have concentrated on the practical, rather than
*just* the theoretical.

We are trying to give domain owners a voice that email receivers can
listen to and determine if a given email is forged/authorized.  Many
of us feel that it is important to be able to easily give the domain
owner a voice about their entire domain.  The zone cut idea is one
possibility, creating a new kind of DNS wildcard system is another.
The zone cut stuff is working, in practice, for me in my beta-code.
If it can't be made to work, or we can find another idea that would
work better, I'm all for dropping it.


Ok, sorry for the long rant, but I think it is important for the
namedropper folks who have not been involved with email/spam to the
degree that Paul or the SPF folks to understand where SPF is coming
from. 


> the way this would look in your draft is something like:
>
> "SPF Clients should take precautions to reject e-mail containing
> nonexistent domain names; SPF Publishers should be aware that this
> will occur, and avoid emitting legitimate e-mail containing such
> domain names."

Again, always rejecting email from non-existent domains doesn't solve
all of the problem that the zone cut tries to solve.  You are
requiring that all email senders fix their systems to not issue bad
MAIL FROM/HELO domains, rather than just those domain owners that want
to use SPF.  (Or, another way to look at it is that you are requiring
SPF clients to reject legitimate email just because they check SPF
records.)

That won't fly, deployment wise.

Also, the zone cut language doesn't just deal with cases of
non-existent domains.  It also means that you don't have to publish
SPF records for all the hosts in your domain.  You just need to
publish the ones that are involved with non-forged email.

This is getting somewhat out of the area of DNS and into email.  What
would be extremely useful for SPF, and other anti-forgery systems such
as Yahoo's DomainKeys or Cisco's IIM, is the ability for a domain
owner to be able to speak for their entire domain.  Can we find a DNS
way of doing that?


> i'm aware of dns installations who conform to rfc1034/rfc1035 in every
> way, even though they only answer SOA queries from locally trusted hosts
> such as dynamic update clients or IXFR/AXFR slave servers.  not even the
> logic and commentary in BIND8's res_findzonecut() will save you from that.
> it is well and truly too late to mandate that SOA's be sent, and even if
> we could mandate it, we wouldn't want every mail server querying for them
> since they aren't cached.  the performance and information-leak problems
> from that would scream "bad engineering" even if the protocol could be
> changed to require that zone cuts be visible to outsiders.

I have not hit those cases that you speak of in my, admittedly,
limited testing.  I think it would be reasonable to require domain
owners that wish to use the zone default SPF record to have a working
zone.  As long as broken zones don't cause problems for SPF checkers,
that shouldn't be too bad.


-wayne



[1] http://www.circleid.com/article/634_0_1_0_C/
[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01923.html
[3] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00028.html



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: Caching SOA records
Date: Wed, 12 Jan 2005 15:29:02 -0600
Lines: 22
References: <mlarson@verisign.com> <20050112210346.D79BF139A3@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 22:38:38 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 15
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:9EhtJS7KeSWILWaZEluTfBGdlTE=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <20050112210346.D79BF139A3@sa.vix.com> Paul Vixie <paul@vix.com> writes:

> i stand corrected.  i usually don't think of RFC 2182 when i think of dns,
> and the "throw away line" in RFC 1035 has governed both my thinking, and
> various early coding efforts.  (matt has corrected me on this point before.)

minor nit:  That's RFC2181, not 2182.

It happens to be the same RFC that I reference in the spf-classic
draft for the definition of a zone cut.  I found it quite educational,
and if there is misinformation in it, I would be quite interested in
learning about the errors.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 16:35:32 -0500
Lines: 25
References: <Pine.LNX.4.44.0501111441370.12250-100000@sokol.elan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ed.lewis@neustar.biz
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 22:43:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: edlewis@127.0.0.1
In-Reply-To: <Pine.LNX.4.44.0501111441370.12250-100000@sokol.elan.net>
To: namedroppers@ops.ietf.org
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Thanks for the prompt.

At 14:45 -0800 1/11/05, william(at)elan.net wrote:

>P.S. Is there some reason you have not read the Ed Lewis's wildcard draft
>that was discussed on this list just couple months ago?

Note to self: work on this document soon.

I can see why the doc hasn't been read - apparently the version from 
last October didn't enter the ID repository correctly.  I wouldn't 
blame anyone for not seeing it.  I should do something about it.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: Caching SOA records (was Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt)
Date: Thu, 13 Jan 2005 08:52:54 +1100
Lines: 30
References: <20050112210346.D79BF139A3@sa.vix.com>
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 23:02:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-reply-to: Your message of "Wed, 12 Jan 2005 21:03:46 -0000."
             <20050112210346.D79BF139A3@sa.vix.com> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


> > FWIW, my BIND 9.2.4 recursive name server clearly caches SOA records,
> > as do a few other BIND recursive servers of random or unknown version
> > numbers that I queried.
> 
> i stand corrected.  i usually don't think of RFC 2182 when i think of dns,
> and the "throw away line" in RFC 1035 has governed both my thinking, and
> various early coding efforts.  (matt has corrected me on this point before.)

	named negative responses to SOA queries as if they had a
	zero TTL.  This is done to allow a client to query for the
	SOA record to find the zone cut and if the query domain
	didn't exist to not leave a negative cache entry that would
	slow the visibility of changes made by subsequent UPDATE
	requests.

	This is not in any RFC though perhaps it should be.
	This only applies to releases of named that support UPDATE.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 22:08:36 +0000
Lines: 95
References: <wayne@schlitt.net>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 23:21:17 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from wayne <wayne@schlitt.net> 
	of "Wed, 12 Jan 2005 15:14:15 CST."
	<x4llayic48.fsf@footbone.schlitt.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

i'm trying hard to limit my comments on this thread to the dns-relevant bits.

> Rapid deployment has, for better or worse, influenced many of our decisions

if you're basically just pandering to your installed base, why not admit this,
tell the IETF what you've done in the form of an FYI, and give yourself a rest?

> The zone cut stuff is working, in practice, for me in my beta-code.
> If it can't be made to work, or we can find another idea that would
> work better, I'm all for dropping it.

anything can be made to work in beta-code.  when you seek universal deployment,
the size of that universe dictates that you work within the letter and spirit
of the spec rather than within the loopholes and enforceability limits.

> > the way this would look in your draft is something like:
> >
> > "SPF Clients should take precautions to reject e-mail containing
> > nonexistent domain names; SPF Publishers should be aware that this
> > will occur, and avoid emitting legitimate e-mail containing such
> > domain names."
> 
> Again, always rejecting email from non-existent domains doesn't solve
> all of the problem that the zone cut tries to solve.  You are
> requiring that all email senders fix their systems to not issue bad
> MAIL FROM/HELO domains, rather than just those domain owners that want
> to use SPF.

i have been running this way for a couple of years.  rarely i'll get a phone
call from somebody who tried to HELO me from a NAT'd host whose hostname was
not visible in external dns.  i always apologize and then give them my "fax"
number.  this hasn't happened since spring 2004, and i get a LOT of mail from
a LOT of places.  are you sure your information on this is as current as mine?

> (Or, another way to look at it is that you are requiring SPF clients
> to reject legitimate email just because they check SPF records.)

here, we're quibbling over what it means for e-mail to be "legitimate".  the
spirit of HELO is "this is my hostname".  while "HELO localhost" is legitimate
under the letter of RFC 2821, i'd argue that it's a violation of the spirit of
RFC 2821.  given that you're asking RFC 2821 server-side implementations to
consider rejecting e-mail for reasons not contemplated by RFC 2821, it's hard
for me to understand you when you say...

> That won't fly, deployment wise.

but whatever.  let's move on.

> Also, the zone cut language doesn't just deal with cases of
> non-existent domains.  It also means that you don't have to publish
> SPF records for all the hosts in your domain.  You just need to
> publish the ones that are involved with non-forged email.

i was thinking that you'd publish SPF records for things that had MX
records, or at worst, from things that had (MX or A or AAAA) records.
if you're having trouble doing this, take a look at the "m4" or "cpp"
preprocessors, or ask your DNS vendor for a built in macro processing
facility.

> This is getting somewhat out of the area of DNS and into email.  What
> would be extremely useful for SPF, and other anti-forgery systems such
> as Yahoo's DomainKeys or Cisco's IIM, is the ability for a domain
> owner to be able to speak for their entire domain.  Can we find a DNS
> way of doing that?

ultimately your concern is about nonexistent subdomains.  if a forger can
get more value out of spoofing nonexistent subdomains than from spoofing
nonexistent unrelated domains, then i've been out of the anti-spam world
longer than i thought.  here's what it sounds like you ought to do.

1. codify current behaviour (not the beta-code behaviour; the global one)
2. explain the good and bad aspects of the current dns wildcard features
3. launch a separate effort to add a rrtype-specific wildcard dns feature

> ...  I think it would be reasonable to require domain owners that wish
> to use the zone default SPF record to have a working zone.  As long as
> broken zones don't cause problems for SPF checkers, that shouldn't be
> too bad.

i'm thinking of all dns queries that will be received by nonparticipants,
and sent by SPF Clients to those nonparticipants upon every inbound SMTP
session.

(one non-dns-related side note: somebody around here told me recently that
they had had to delete their SPF records because one or more SPF Clients
had implemented SPF improperly, and were rejecting mailing list e-mail
based on the mismatch between the header From: and the list exploder.  all
this proves is that no matter how careful a specification is authored, it
still has to run the gauntlet of wide scale implementation.)

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Chris Thompson <cet1@cus.cam.ac.uk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 22:25:29 +0000 (GMT)
Lines: 38
References: <878y6ye6rt.fsf@deneb.enyo.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 23:30:36 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <878y6ye6rt.fsf@deneb.enyo.de> from "Florian Weimer" at Jan 12, 5 09:23:18 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Length: 1414
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Florian Weimer <fw@deneb.enyo.de> writes:
> 
> * william elan net:
> 
> > On Wed, 12 Jan 2005, Paul Vixie wrote:
> >
> >> > > ... how would you propose to discover the "zone cut" you're speaking of?
> >> > 
> >> > By checking the authority section:
> >> 
> >> did you know that the authority section is optional in positive responses?
> >> (have you read RFC 2308?)
> >
> > Positive responses are not a problem - if somebody queries for SPF
> > RR and gets it, there is no need to do anything else.
> 
> SPF lookup for domains used in Internet mail *always* result in
> positive responses because there exists an MX or A record for that
> domain.  Conforming resolvers do not return an error code in this
> case, but an empty data section.

Despite the RCODE=NOERROR setting, such responses are most naturally 
classified as "negative": see RFC 2308. In particular, an SOA record 
would be in the authority section if the _recommendations_ of that RFC 
are followed, allowing the stab-in-the-dark at the zone boundary being
proposed for SPF.

Disclaimer: this isn't meant to indicate approval for the I-D being
discussed, or indeed for anything whatsoever associated with SPF. :-(

Chris Thompson
Email: cet1@cam.ac.uk

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Caching SOA records (was Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt)
Date: Wed, 12 Jan 2005 22:45:24 +0000
Lines: 11
References: <mlarson@verisign.com>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 12 23:51:50 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Matt Larson <mlarson@verisign.com> 
	of "Wed, 12 Jan 2005 15:24:17 EST."
	<20050112202417.GK8791@chinook.corpit.vrsn.com> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

one more thing, because i'm feeling a sheepish need to explain my confusion.

> FWIW, my BIND 9.2.4 recursive name server clearly caches SOA records, ...

BIND 8.4.5, which is the last nameserver i personally worked on, does not.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Wed, 12 Jan 2005 17:30:42 -0800 (PST)
Lines: 139
References: <20050112144438.B965313971@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 Thu Jan 13 02:41:05 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: Paul Vixie <paul@vix.com>
In-Reply-To: <20050112144438.B965313971@sa.vix.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On Wed, 12 Jan 2005, Paul Vixie wrote:

> > As I said, on the tests it appears that dns servers (bind 8 and bind 9 
> > at least) do provide this information nearly all the time including for 
> > NOERROR/NODATA, so I don't think querying for SOA is going to be needed 
> > very often.
> 
> this is namedroppers@, not bind-workers@.  how a particular implementation
> behaves is of no interest to the ietf, other than if a widely implemented
> protocol violation (which this is not) makes it necessary to design-around
> (which this does not).

BIND is not the only dns server that returns SOA in authority section for 
NODATA. Verisign's server does the same too and ULTRADNS is doing same.

The point is that if in 99% of cases dns servers already return an answer 
that we're looking for, then trying to use that is certainly not stupid or
bad idea (as long as we know how to get the answer in the remaining cases).

> > And yes it does sound weird for non-dns service to query for soa, but
> > its not breaking anything either as far as I can see and querying for
> > soa can be usefull for more then just dns internal communication, for
> > example to find tech/hostmaster address if whois is not available (ok,
> > you can go ahead and blame me for this trick and inappropriate use :)
> 
> that's what RP RR's are for. 

How many RPs have you seen in the wild lately? Its practicly a dead RR...

> or did you not know that SOA was never cached?

I believe SOA responses are not cached only if its for non-existing domains.
Its possible that RFCs say that SOA lookups may or may not be cached, but
the same is true for all other DNS RR lookups too and I do believe that
direct queries for SOA are in fact cached.

But it is certainly true that you might expect special treatment for 
piece of data that is carrying caching information.

> > > i really am pretty sure that the dns servers will be changed to support 
> > > SPF other than to support a new RRtype when y'all get around to 
> > > proposing that.
> 
> s/will/won't/, sorry.  though i suppose it was clear in context.

No wonder I got surprised that it was so easy to get a yes answer ...

> > Should I take as that you're willing to support such a feature (synthetic
> > wildcard for existing hostname but without needed RR) in future versions
> > of bind?
> 
> no.  i misspoke.  BIND will implement the dns protocol as defined by the
> ietf, with occasional experimental features if those do not violate the
> protocol defined by the ietf.

The slow process of adding new features to dns (both protocol and to 
implementation) is why most in SPF community want to simulate wildcard 
with user-level queries on zonecut for default record. Same is why they 
chose to use TXT RR instead of new RR.

I believe the solution lies in the middle - we should proceed with both 
user-level queries and with process of adding new zonecut-default wildcard 
to DNS system. This way the currently proposed system of user-level queries
for zonecut records will become absolute and not used in the future any more.

The above is similtar to what was proposed by Ted Hardie at MARID meeting -
allow to use TXT temporarily (maybe 5 years) and get new RR and  provide 
ways to use both with in the future moving towards new RR and changing 
from SHOULD check both records to MUST check SPF RR first and then 
absoluting TXT 10 years down the road.

> > In that case it makes sense for this to become a new dns protocol
> > feature so that other dns servers would know how to support it too, so
> > I think it would be good idea to write it out as ietf document
> > (separate and not just part of spf draft).
> 
> even though i misspoke, there's a path forward illuminated by the mistake.
> if you want rrtype-specific wildcards, like for example an "**" label in a
> zone file should be a wildcard but only for the rrtypes at the "**" node,
> then go ahead and propose it.  if ietf approved such a standard, then BIND
> will implement it.  i suspect that the process would be too long for SPF's
> requirements.

I maybe willing to wait and go through the process, but I certainly dont 
expect that majority of spf community would (i.e. considering that they 
did not even agree to use prefix for placement of data with primary argument
againt being that it was not always correct character in the dns user
interface that they get to use with the web hosting company). Good 
technical reasons and arguments and trying to follow proper standards 
process don't appear to always work the right way when dealing with spf ...

In any case for more practical question. Do youthink getting draft like 
this to experimental status be possible within say a year (not necessarily
just for spf reasons)?

> > And to make it possible to identify dns records where such new wildcard 
> > does need to be supported, I think we do need special prefix (and its not 
> > too late as I don't even know any spf implementation that is doing zonecut  
> > default checks yet). 
> 
> that's not a reason for a special prefix. 

There are several reasons for it that I discussed at SPF (current situation
requires special handling with complex redirects when somebody does need it
to be different; with introduction of EHLO checks and without scoping it 
has larger chance for confusion and incorrectly blocked email, etc). And
with prefix it has a chance to accomondate protocols other then just SPF.

> but as SOA is not cached, it is not something that should be queried for 
> other than as part of DNS operations such as serial number queries 
> governing IXFR/AXFR or UPDATE. 

I do not believe that there is any documents that specifically limits SOA
use in this way. But I'll investigate further if doing NS checks instead 
of SOA has any difference in the result, however if it turns out that 
doing SOA provides correct information all the time or faster then I'll 
advocate for that (and if I remember right your own code for finding 
zonecuts is in fact using SOA!) 

> since SPF does not yet do any zonecut checks, please remove that part of 
> the draft.

Not up to me, I've already asked for it to be removed or modified twice
at spf-discuss as I'm not willing to support it the way it is now because
it will lead to way too many queries to ISP mail servers and to much 
cofusion for dns administrators.

-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: John Levine <johnl@iecc.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: 13 Jan 2005 02:48:53 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 52
References: <20050112220836.0872E139A3@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 03:56:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20050112220836.0872E139A3@sa.vix.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>> The zone cut stuff is working, in practice, for me in my beta-code.
>> If it can't be made to work, or we can find another idea that would
>> work better, I'm all for dropping it.

I would surmise that none of your clients use djbdns as their DNS
software.  Its cache does correct negative caching, but it doesn't
return SOA records as additional or authority data.  You don't have to
like djbdns, but enough people use it that you can't wave it off.

The only halfway reliable ways to find zone cuts are either to build
your own resolver into your application and follow the chain of NS
records from the root, which seems a lot to ask an application to do,
or as an approximation walk up the DNS tree looking for SOA records.
If you're going to walk up the tree anyway, you might as well look for
the data you really want rather than SOAs and permit domain-wide data
at any DNS node.

Beyond the faux wildcard issue, there are some other DNS issues with
SPF that I'm wondering about.  The most serious is the blizzard of
requests that interpreting SPF records can require.  I realize that
CNAME has many of the same issues, but SPF introduces not just long
chains but bushy trees.  For a contrived example, check the SPF for
very.slow.sp.am, which takes about half an hour to resolve.  When I
pointed out this DOS opportunity to Meng, he "fixed" it by setting
arbitrary limits on the number of indirect references allowed when
interpreting an SPF record, thereby introducing a variety of ways to
make make working SPF mysteriously fail as domains down the tree add
an extra reference or two.  Based on other experience with DNS, is
there anything helpful one could say other than suggesting that they
take the bushiness out?

Another question is the big record problem.  Some SPF descriptions are
complicated enough that they won't fit in 512 bytes.  What's the best
thing to do?  Hotmail.com broke theirs up into four chunks named
spf-a.hotmail.com through spf-d.hotmail.com, with the main hotmail.com
SPF including the four.  The total amount of data is only about 1K so
a UDP transaction with the truncation bit followed by a TCP
transaction would probably be fewer packets than the five queries the
split version needs.  Other than reminding people that EDNS0 is
available for their large packet needs, any suggestions on artificial
subdivision vs. TCP?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 02:02:34 -0600
Lines: 119
References: <20050112220836.0872E139A3@sa.vix.com> <20050113024853.20331.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 09:20:07 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 112
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:Kz2M/9FcxTI5RYSFBKaNJz0u3/Y=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <20050113024853.20331.qmail@xuxa.iecc.com> John Levine <johnl@iecc.com> writes:

>>> The zone cut stuff is working, in practice, for me in my beta-code.
>>> If it can't be made to work, or we can find another idea that would
>>> work better, I'm all for dropping it.
>
> I would surmise that none of your clients use djbdns as their DNS
> software.  Its cache does correct negative caching, but it doesn't
> return SOA records as additional or authority data.  You don't have to
> like djbdns, but enough people use it that you can't wave it off.

It is likely that my code has not been tested on djbdns, but doing
digs by hand, I could not find any problems.  Pobox.com uses tinydns
and checking ns1.rightbox.com seems to return SOA records just fine.

Could you please give me some more details?


> Beyond the faux wildcard issue, there are some other DNS issues with
> SPF that I'm wondering about.  The most serious is the blizzard of
> requests that interpreting SPF records can require.

This is also a large concern of mine.  Have you read the current I-D?
In particular, the processing limits for the number of DNS requests?


>                          For a contrived example, check the SPF for
> very.slow.sp.am, which takes about half an hour to resolve.

Is this the same example as you gave here?

http://www.imc.org/ietf-mxcomp/mail-archive/msg02436.html

If so, my response is pretty much the same as last time:

http://www.imc.org/ietf-mxcomp/mail-archive/msg02438.html


Since then, I *have* been allowed to add a time to SPF checks and I
have also added process limits similar to the ones found in the
libspf2 SPF implementation that I mentioned in my reply.

I also brought up the subject of SPF and DDoS attacks in this message.
http://www.imc.org/ietf-mxcomp/mail-archive/msg02440.html
There is a URL to a another message in there which is munged.  It
should be:
http://archives.listbox.com/spf-discuss@v2.listbox.com/200312/0393.html

>                                                              When I
> pointed out this DOS opportunity to Meng, he "fixed" it by setting
> arbitrary limits on the number of indirect references allowed when
> interpreting an SPF record,

I'm not sure when you pointed this out to Meng but the SPF specs have
had limits on the number of include: and redirect= references for a
year.


> [...]                       thereby introducing a variety of ways to
> make make working SPF mysteriously fail as domains down the tree add
> an extra reference or two.

I'm not sure if anything can be done about that.  Either you have
limits, in which case you can run into those limits, or you don't have
limits, in which case you have DNS DoS and DDoS problems.

In practice, very few domains come even close to the process limits.
(I have done surveys of all SPF records in the .com, .net and .org
domains.  Results from the surveys were posted on the MARID list.)


>                             Based on other experience with DNS, is
> there anything helpful one could say other than suggesting that they
> take the bushiness out?

You mean by removing the include: and redirect= mechanisms?  That
would be a huge incompatiblity, and wouldn't by itself solve the DoS
problems.


> Another question is the big record problem.  Some SPF descriptions are
> complicated enough that they won't fit in 512 bytes.  What's the best
> thing to do?  Hotmail.com broke theirs up into four chunks named
> spf-a.hotmail.com through spf-d.hotmail.com, with the main hotmail.com
> SPF including the four.  The total amount of data is only about 1K so
> a UDP transaction with the truncation bit followed by a TCP
> transaction would probably be fewer packets than the five queries the
> split version needs.  Other than reminding people that EDNS0 is
> available for their large packet needs, any suggestions on artificial
> subdivision vs. TCP?

Hotmail has some of the largest SPF records that I know of, most SPF
records are fall smaller.  (Again, survey results were posted to
MARID.)  It is my understanding that MS has listed every IP address
that they own in their SPF records, instead of listing the ranges that
send email.  My initial reaction to hotmail's records is that they
should put a little effort into making their records smaller.

As far as DNS over TCP goes, there are a lot of (broken) firewalls out
there that have been configured to reject TCP port 53.  Any SPF
publisher that wishes to have their records available to everyone
needs to avoid falling back to TCP.

As far as the total amount of traffic caused by hotmail's 5 SPF
records vs one TCP DNS lookup, I'm not sure that TCP would be
cheaper.  You would generate one UDP lookup anyway, and then you have
the three-way TCP startup handshake and the four-way TCP teardown.


-wayne




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 15:43:30 +0100
Organization: NIC France
Lines: 34
References: <x4llayic48.fsf@footbone.schlitt.net> <20050112220836.0872E139A3@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 Thu Jan 13 15:57:48 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>
Content-Disposition: inline
In-Reply-To: <20050112220836.0872E139A3@sa.vix.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-1-686 i686
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, Jan 12, 2005 at 10:08:36PM +0000,
 Paul Vixie <paul@vix.com> wrote 
 a message of 94 lines which said:

> somebody around here told me recently that they had had to delete
> their SPF records because one or more SPF Clients had implemented
> SPF improperly, and were rejecting mailing list e-mail based on the
> mismatch between the header From: and the list exploder.

I know at least one program which is broken enough to do so, a Mozilla
Thunderbird extension:

http://www.extensionsmirror.nl/index.php?showtopic=1338

(Checking the RFC 2822 From: has nothing to do with SPF.)

But the adventure of your somebody proves nothing: after all, I had to
change my email configuration several times because people were
implementing stupid checks, too (see the thread "fixing insecure email
infrastructure" today on NANOG).

> all this proves is that no matter how careful a specification is
> authored, it still has to run the gauntlet of wide scale
> implementation.)

We all agree there are broken software and hasty implementors. But the
bug in the mentioned program is so huge, there is nothing the draft
authors could have done against 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:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 15:14:07 +0000
Lines: 36
References: <bortzmeyer@nic.fr>
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 16:21:59 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Stephane Bortzmeyer <bortzmeyer@nic.fr> 
	of "Thu, 13 Jan 2005 15:43:30 +0100."
	<20050113144330.GA7921@nic.fr> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > all this proves is that no matter how careful a specification is
> > authored, it still has to run the gauntlet of wide scale
> > implementation.)
> 
> We all agree there are broken software and hasty implementors. But the
> bug in the mentioned program is so huge, there is nothing the draft
> authors could have done against it.

the lesson, though, is that if something should or should not be done, a
"good spec" will say exactly what that is, rather than just saying lots
of other things such that if you read it carefully you'll know everything
you need to know.  as an occasional spec author myself i have been rather
guilty of this offense.  rfc2136, for example, contains this little gem:

   1.2 - Glue RRs

   For the purpose of determining whether a domain name used in the
   UPDATE protocol is contained within a specified zone, a domain name
   is "in" a zone if it is owned by that zone's domain name.  See
   section 7.18 for details.

this predates the discussion of "in-ballywick" by almost a decade.  and to
me, "owned by" had a very specific and obvious meaning.  some others scratched
their heads, knew it was true and right, but didn't understand it at all.
(it means "at or below, even if it's in a subzone," in case you're curious.)

the caution this suggestions for SPF is that if this SOA-surfing idea goes
forward, something has GOT TO BE SAID about protecting TLD and root servers
from queries about these names.  (note that the SOA-surfing idea should not
go forward, in my view, i'm just saying, if it does in spite of my view.)

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 10:43:24 -0500
Lines: 44
References: <x4llayic48.fsf@footbone.schlitt.net>
 <20050112220836.0872E139A3@sa.vix.com> <20050113144330.GA7921@nic.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ed.lewis@neustar.biz
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 16:49:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: edlewis@127.0.0.1
In-Reply-To: <20050113144330.GA7921@nic.fr>
To: namedroppers@ops.ietf.org
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Time for a periodic rant.

>We all agree there are broken software and hasty implementors. But the
>bug in the mentioned program is so huge, there is nothing the draft
>authors could have done against it.

Why isn't such a situation brought to the attention of the IETF?

The IETF is supposed to design "good" protocols and to develop 
"clear" documents.  ("Good" manifested in achieving Proposed 
Standard, "clear" manifested in achieving Draft Standard.)

The way I look at it - there is a balance between documents 
(representing design) and code (representing implementation).

The documents represent strategy or design for solving a problem, 
considering all the angles (and "corner cases").  E.g., data model, 
management model, congestion management of the transport, IDN 
compatibility, etc.  The value of the IETF is that so many different 
kinds of expertise can be called on to review a solution.

Code represents the muscle of the Internet, the pragmatic view of the 
world.  It is how the network works.  Code deals with physical 
limits, I/O speed, data transmission speed; it deals with user 
nuances and legal issues too.

Code without design is a mess.  We know that.  Design without code is 
useless.  Evidently we need to do a better job preventing that.

If implementers (or interoperability testers) find a document to be 
inaccurate they should be encouraged to say so.  The IETF would be 
strengthened by such feedback.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 09:47:38 -0600
Lines: 19
References: <bortzmeyer@nic.fr> <20050113151407.F141513DE2@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 16:54:35 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 12
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:43dFONBKDEepHPq53f6GDc9DEyk=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <20050113151407.F141513DE2@sa.vix.com> Paul Vixie <paul@vix.com> writes:

> the caution this suggestions for SPF is that if this SOA-surfing idea goes
> forward, something has GOT TO BE SAID about protecting TLD and root servers
> from queries about these names.

I have already said that I thought that putting an something in about
never querying domains with less than two labels is a good idea.  I
think it is a good idea whether the zone cut stuff remains or not.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 16:34:48 +0000
Lines: 41
References: <bortzmeyer@nic.fr> <20050113151407.F141513DE2@sa.vix.com>
 <x4y8exgwkl.fsf@footbone.schlitt.net>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 17:42:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: wayne <wayne@schlitt.net>, namedroppers@ops.ietf.org
In-Reply-To: <x4y8exgwkl.fsf@footbone.schlitt.net>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 13 January 2005 09:47 -0600 wayne <wayne@schlitt.net> wrote:

> I have already said that I thought that putting an something in about
> never querying domains with less than two labels is a good idea.  I
> think it is a good idea whether the zone cut stuff remains or not.

(not that that protects ccTLDs)

I still don't understand *why* this has to be solved at the SPF client
end through recursion at all, rather than at the SPF publisher's end,
either by
i)   writing the records right in the first place, or
ii)  software/macros/text/documentation to help them do so, or
iii) modification of the server software (does not require an IETF
     protocol change) to run a different default (e.g. a config
     option for (say) $vendorware that says "incorporate an SPF record
     from the parent zone into a child, if I am running both and
     the parent zone has one but the child doesn't").

This puts the burden of the problem on the nameservers and systems
of those implementing SPF, not on "innocent bystanders" further up
the tree. It also ditches a whole pile of unnecessary network traffic.

You appear to be trying to engineer a protocol layer solution to user level
problems, and risk causing collateral damage (as well as some ugliness).
Applications (not protocols) are there to help users out with difficult
configuration problems. Sometimes the proposed cure for "difficult user
config" is worse than the disease. I am reminded of Microsoft Office
Assistant. [No jokes please long the lines of: "You appear to be
trying to write an Internet Draft - can I help you remove unnecessary
tree recursion?"]

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 17:20:24 +0100
Lines: 22
References: <x4y8exgwkl.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 17:43:55 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol
To: namedroppers@ops.ietf.org
In-reply-to: Your message of "Thu, 13 Jan 2005 09:47:38 CST."
             <x4y8exgwkl.fsf@footbone.schlitt.net> 
X-Organization: Uni Bielefeld, Technische Fakultaet
X-Phone: +49 521 106 2902
Content-ID: <27006.1105633222.1@zeder.TechFak.Uni-Bielefeld.DE>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

wayne <wayne@schlitt.net> wrote:

> I have already said that I thought that putting an something in about
> never querying domains with less than two labels is a good idea.  I
> think it is a good idea whether the zone cut stuff remains or not.

as has been pointed out, there is no magic about the *two* labels. There
are registries operating at SLD level, like the various co.XX ones
and, more importantly, the basic concept of inheriting the data from
one level up is not the DNS school of thought.

-Peter

PS: Someone might now remember the _whois._tcp.foo.bar.example thing, which
    also relies on tree walking. Since it works with and in DNS data, it's
    a different issue.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: John Levine <johnl@iecc.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: 13 Jan 2005 16:49:05 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 95
References: <cs5bug$279q$1@sf1.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: wayne@schlitt.net
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 17:56:46 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <cs5bug$279q$1@sf1.isc.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>> I would surmise that none of your clients use djbdns as their DNS
>> software.  Its cache does correct negative caching, but it doesn't
>> return SOA records as additional or authority data.  You don't have to
>> like djbdns, but enough people use it that you can't wave it off.
>
>It is likely that my code has not been tested on djbdns, but doing
>digs by hand, I could not find any problems.  Pobox.com uses tinydns
>and checking ns1.rightbox.com seems to return SOA records just fine.
>
>Could you please give me some more details?

Tinydns is the server, which returns SOA.  Dnscache is the cache,
which does not, e.g., using my local cache:

$ dig mail.iecc.com a  

; <<>> DiG 8.3 <<>> mail.iecc.com a 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      mail.iecc.com, type = A, class = IN

;; ANSWER SECTION:
mail.iecc.com.          23h54m28s IN A  208.31.42.99

;; Total query time: 127 msec
;; FROM: xuxa.iecc.com to SERVER: default -- 208.31.42.32
;; WHEN: Thu Jan 13 11:39:33 2005
;; MSG SIZE  sent: 31  rcvd: 47

$ dig mail.iecc.com txt

; <<>> DiG 8.3 <<>> mail.iecc.com txt 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      mail.iecc.com, type = TXT, class = IN

;; Total query time: 69 msec
;; FROM: xuxa.iecc.com to SERVER: default -- 208.31.42.32
;; WHEN: Thu Jan 13 11:39:29 2005
;; MSG SIZE  sent: 31  rcvd: 31

Normal clients ignore the authority section, so dnscache doesn't
include it.

I don't know anyone who runs a promiscuous dnscache, but if you want
to send me a set of IPs you use, I'd be happy to give you access to
mine for testing.

>> Beyond the faux wildcard issue, there are some other DNS issues with
>> SPF that I'm wondering about.  The most serious is the blizzard of
>> requests that interpreting SPF records can require.
>
>This is also a large concern of mine.  Have you read the current I-D?
>In particular, the processing limits for the number of DNS requests?

Yes.  That's why I mentioned the mysterious failures.  You set up your
SPF to include:bigisp.net, you test it, it works great.  Then
bigisp.net rearranges its mail servers, adds another couple of lookups
to its SPF, and now your SPF has stopped working.  That doesn't strike
me as robust design.

>In practice, very few domains come even close to the process limits.
>(I have done surveys of all SPF records in the .com, .net and .org
>domains.  Results from the surveys were posted on the MARID list.)

Indeed, but "this fixed limit is plenty big" has led to grief more
times than I can count.  It's a KICK ME sign.

>> there anything helpful one could say other than suggesting that they
>> take the bushiness out?
>
>You mean by removing the include: and redirect= mechanisms?  That
>would be a huge incompatiblity, and wouldn't by itself solve the DoS
>problems.

My suggestion has always been that you run the big complicated set
calculations when you construct your SPF record, and then publish the
set of IPs that it finds.  If the result of the calculation changes,
you rerun it and update your DNS data.  That's what my FSP strawman did.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 16:45:47 +0000
Lines: 20
References: <wayne@schlitt.net>
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 17:58:45 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: wayne <wayne@schlitt.net>
In-Reply-To: Message from wayne <wayne@schlitt.net> 
	of "Thu, 13 Jan 2005 09:47:38 CST."
	<x4y8exgwkl.fsf@footbone.schlitt.net> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > the caution this suggestions for SPF is that if this SOA-surfing idea goes
> > forward, something has GOT TO BE SAID about protecting TLD and root servers
> > from queries about these names.
> 
> I have already said that I thought that putting an something in about
> never querying domains with less than two labels is a good idea.  I
> think it is a good idea whether the zone cut stuff remains or not.

in the time since i first proposed the two-label rule, someone pointed out
CO.UK to me, where it's actually a three-label rule.  i don't think this
kind of rule can work.  i don't think that anything like this can work.  if
someone can force you to query for F(name) simply by mentioning a nonexistent
"name", where F() is a function returning the parent, grandparent, child,
brother, or indeed any name other than "name", then it's a new DDoS vector.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Jaap Akkerhuis <jaap@NLnetLabs.nl>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 18:18:10 +0100
Lines: 18
References: <20050113164547.25EB813971@sa.vix.com>
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 18:37:50 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-reply-to: Your message of Thu, 13 Jan 2005 16:45:47 +0000.
             <20050113164547.25EB813971@sa.vix.com> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    
    in the time since i first proposed the two-label rule, someone pointed out
    CO.UK to me, where it's actually a three-label rule.

And not only that. If example.org is not only a domainname but also
the name of the mx host for this tiny example organisation it should
be a one-label rule :-).  And then I thought about 1.3.e164.arpa...

But the basic lesson is that the number of labels don't tell you
anything about the structure og the name space.

	jaap

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: John Levine <johnl@iecc.com>
Subject: Re: Zone cut
Date: 13 Jan 2005 17:47:23 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 33
References: <cs56gm$1h4g$1@sf1.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: Ed.Lewis@neustar.biz
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 18:57:18 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <cs56gm$1h4g$1@sf1.isc.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>Well, zone cuts are manifestations of administrative boundaries
>within the data model of DNS.

Sometimes.  Sometimes they are merely an implementation detail.  For
example, there is a zone cut at korea.services.net even though all
of services.net belongs to me and is hosted on my servers.  The
services.net zone is served through tinydns, while korea.services.net
is served through rbldbsd because it's a DNSBL.

Similarly, there's a zone cut at contacts.abuse.net because that zone
has a specialized server that synthesizes responses based on info from
the abuse.net database.  

You really can't assume anything about a zone cut except that it's a
zone cut.  You can't even assume it's all under a common
administration since there are servers that serve out of databases, so
the rules about who manages what are in the database schema which we
can't see.

I agree that for some purposes it would be nice to draw a line around
chunks of the DNS and say "this is all the same FOO" for some FOO, but
zone cuts aren't the right lines to use.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 12:13:27 -0600
Lines: 32
References: <x4y8exgwkl.fsf@footbone.schlitt.net> <200501131620.j0DGKOo27012@zeder.TechFak.Uni-Bielefeld.DE>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 19:54:13 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 25
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:MNXXRy4TC0/7VrWlSaxGJCHxtwM=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <200501131620.j0DGKOo27012@zeder.TechFak.Uni-Bielefeld.DE> Peter Koch <pk@TechFak.Uni-Bielefeld.DE> writes:

> wayne <wayne@schlitt.net> wrote:
>
>> I have already said that I thought that putting an something in about
>> never querying domains with less than two labels is a good idea.  I
>> think it is a good idea whether the zone cut stuff remains or not.
>
> as has been pointed out, there is no magic about the *two* labels.

I'm very much aware of that.

This is a safety-net, designed to catch situations that shouldn't
happen, rather than something that is intended to be used regularly.
To the best of my knowledge, it is the root and TLD name servers that
have to deal with most of the crap thrown at the DNS.  While some
applications may have good reasons to check for "com." or "uk.", I
can't see that for SPF and therefore the spec should not allow it.

Paul's suggestion is good and useful.  Paul's suggestion is not
perfect and doesn't guarentee that every DNS query that every SPF
client makes is valid.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: Zone cut
Date: Thu, 13 Jan 2005 15:20:58 -0500
Lines: 18
References: <20050113174723.21817.qmail@xuxa.iecc.com>
 <1105644491.15714.282.camel@egyptian-gods.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: John Levine <johnl@iecc.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 21:28:38 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: edlewis@127.0.0.1
In-Reply-To: <1105644491.15714.282.camel@egyptian-gods.mit.edu>
To: Greg Hudson <ghudson@MIT.EDU>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 14:28 -0500 1/13/05, Greg Hudson wrote:
>I'm also concerned that if applications start paying attention to zone
>cuts, DNS administrators will become more constrained in what they do.

That's a good point - operations ought to push the protocol, but 
never impinge it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: Zone cut
Date: Thu, 13 Jan 2005 15:19:44 -0500
Lines: 41
References: <20050113174723.21817.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: namedroppers@ops.ietf.org, Ed.Lewis@neustar.biz
X-From: owner-namedroppers@ops.ietf.org Thu Jan 13 21:28:47 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: edlewis@127.0.0.1
In-Reply-To: <20050113174723.21817.qmail@xuxa.iecc.com>
To: John Levine <johnl@iecc.com>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 17:47 +0000 1/13/05, John Levine wrote:
>>Well, zone cuts are manifestations of administrative boundaries
>>within the data model of DNS.
>
>Sometimes.  Sometimes they are merely an implementation detail.  For
>example, there is a zone cut at korea.services.net even though all
>of services.net belongs to me and is hosted on my servers.  The
>services.net zone is served through tinydns, while korea.services.net
>is served through rbldbsd because it's a DNSBL.

That's an example of an administrative boundary. ;)  At least to the 
DNS.  The DNS (if it were a sentient being) wouldn't know that you 
are the holder of the privileged user account password that allows 
you to manage the two zones.

(If you did DNSSEC, you'd have to have a key for each administration. 
However, you could be the exclusive user of both keys, and the key 
material could even be the same.  But to DNS, they are different 
keys.)

Even if you used BIND (let's just say) and had two zones, example.net 
and example.example.net and ran them both on the same machines 
everywhere, there is an administrative boundary present to the DNS. 
This is manifested in having separate zone clauses in the named.conf 
file.

The point you make highlights why zones cuts aren't intended to be 
seen outside the DNS.  They mean little in other planes of thought, 
even if all zone cuts are equal to the protocol.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Greg Hudson <ghudson@MIT.EDU>
Subject: Re: Zone cut
Date: Thu, 13 Jan 2005 14:28:11 -0500
Lines: 19
References: <20050113174723.21817.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 00:11:48 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050113174723.21817.qmail@xuxa.iecc.com>
X-Mailer: Ximian Evolution 1.4.5 
X-Scanned-By: MIMEDefang 2.42
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Thu, 2005-01-13 at 12:47, John Levine wrote:
> You really can't assume anything about a zone cut except that it's a
> zone cut.  You can't even assume it's all under a common
> administration since there are servers that serve out of databases, so
> the rules about who manages what are in the database schema which we
> can't see.

I'm also concerned that if applications start paying attention to zone
cuts, DNS administrators will become more constrained in what they do. 
I'd hate to start hearing about conversations like: "Why don't we just
start delegating the foo subdomain?"  "We're not sure what impact that
would have on SPF clients."


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Thu, 13 Jan 2005 16:07:43 -0800 (PST)
Lines: 71
References: <20050113164905.15748.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org, <wayne@schlitt.net>
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 01:31:33 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050113164905.15748.qmail@xuxa.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


I've gone through list of all popular dns servers listed at 
http://mydns.bboy.net/survey/ and tested if they return SOA with
NODATA or not. For the servers that have at least 0.1% market
penetration (BIND8, BIND9, djb TinyDNS, Microsoft DNS, MyDNS,
PowerDNS, SimpleDNS+, PlantDNS, UltraDNS, NSD) - they all do!.

John points an interesting picture of how it works different with dns 
caching servers so I'd like to know if there is a webpage that lists 
different caching servers implementations so I could do more tests
(as well as if there is way to find location for at least one of
 those caching servers - i.e. like fpdns helped me to locate dns
 servers to test on)

On 13 Jan 2005, John Levine wrote:

> >It is likely that my code has not been tested on djbdns, but doing
> >digs by hand, I could not find any problems.  Pobox.com uses tinydns
> >and checking ns1.rightbox.com seems to return SOA records just fine.
> >
> >Could you please give me some more details?
> 
> Tinydns is the server, which returns SOA.  Dnscache is the cache,
> which does not, e.g., using my local cache:
> 
> $ dig mail.iecc.com a  
> 
> ; <<>> DiG 8.3 <<>> mail.iecc.com a 
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUERY SECTION:
> ;;      mail.iecc.com, type = A, class = IN
> 
> ;; ANSWER SECTION:
> mail.iecc.com.          23h54m28s IN A  208.31.42.99
> 
> ;; Total query time: 127 msec
> ;; FROM: xuxa.iecc.com to SERVER: default -- 208.31.42.32
> ;; WHEN: Thu Jan 13 11:39:33 2005
> ;; MSG SIZE  sent: 31  rcvd: 47
> 
> $ dig mail.iecc.com txt
> 
> ; <<>> DiG 8.3 <<>> mail.iecc.com txt 
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUERY SECTION:
> ;;      mail.iecc.com, type = TXT, class = IN
> 
> ;; Total query time: 69 msec
> ;; FROM: xuxa.iecc.com to SERVER: default -- 208.31.42.32
> ;; WHEN: Thu Jan 13 11:39:29 2005
> ;; MSG SIZE  sent: 31  rcvd: 31
> 
> Normal clients ignore the authority section, so dnscache doesn't
> include it.
> 
> I don't know anyone who runs a promiscuous dnscache, but if you want
> to send me a set of IPs you use, I'd be happy to give you access to
> mine for testing.


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Dean Anderson <dean@av8.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Fri, 14 Jan 2005 04:04:32 -0500 (EST)
Lines: 88
References: <a06110401be0c42a3b6c5@[10.31.32.124]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 10:17:03 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: dean@cirrus.av8.net
To: Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <a06110401be0c42a3b6c5@[10.31.32.124]>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Thu, 13 Jan 2005, Edward Lewis wrote:

> Time for a periodic rant.
> 
> >We all agree there are broken software and hasty implementors. But the
> >bug in the mentioned program is so huge, there is nothing the draft
> >authors could have done against it.
> 
> Why isn't such a situation brought to the attention of the IETF?
> 
> The IETF is supposed to design "good" protocols and to develop 
> "clear" documents.  ("Good" manifested in achieving Proposed 
> Standard, "clear" manifested in achieving Draft Standard.)

How about "good" as in SOLVING PROBLEMS, not just making patent holders
money selling defective products?

I was told that the fact that discussing that SPF standarization is dead
(dead for good technical reasons) is off-topic.  In some sense, the debate
of that point is off-topic. That conclusion was made by another working
group and it is certainly off-topic to try to rehash that conclusion.

And supposing SPF _email_operation_ is offtopic, then about 50 of the last
75 messages are also off-topic. This group isn't here to solve SPF bugs,
but rather to determine if SPF has negative impact on DNS operation.

Certainly, this discussion is worthy of a dilbert cartoon...

Pretty obviously, there are several "on-topic" issues:

1) DNS cache impact
2) DNS server load issues
3) Is SPF a gratuitous change to DNS if SPF won't be standardized

There has been almost no discussion of the above.

What is off-topic to DNS is:

1) mail client bugs which reject email
2) implementation of mail clients
3) implemenation of mail servers.
4) mail protocol issues
5) whether the SPF Working group made a mistake

Here are some relevant facts that shouldn't be ignored:

	1) THE SPF WORKING GROUP CONCLUDED THAT SPF HAS INSURMOUNTABLE
TECHNICAL PROBLEMS
	2) THAT THE SPF WORKING GROUP HAS DISSOLVED AS A RESULT OF THESE 
TECHNICAL INSURMOUNTABLE PROBLEMS

These facts, particularly the last one, are of relevance to the DNSEXT
working group. It is not topical to debate the merits of the IETF-MXCOMP
(SPF) working group findings. However, they cannot be ignored.  It is not
the purpose of this group to consider the merits of SPF.  However, this
working group should respect the findings of other working groups.  The
conclusions of other working groups are relevant to this groups' work.

That being the case, there is little point in considering its impact on
DNS, as its not part of the IETF protocol suite.

We know by the continued zeal of SPF proponents in spite of the
dissolution of the SPF working group, that these SPF zealots will have no
interest in any negative DNS effects, anyway.  Any inconvenient findings
will be ignored.

With that in mind, I'm interested to know what the "hoped-for" outcome of 
this discussion is going to be?  What's the best that could happen?

Is it just that proponents of SPF hope to reverse their failure in the SPF
working group and get this working group to standardize their proposals
(without analyzing them in detail)?

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Fri, 14 Jan 2005 11:29:35 +0100
Organization: RIPE NCC
Lines: 26
References: <20050112220836.0872E139A3@sa.vix.com>
	<20050113024853.20331.qmail@xuxa.iecc.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 Fri Jan 14 11:37:03 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050113024853.20331.qmail@xuxa.iecc.com>
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.040186 / -5.9
X-RIPE-Signature: 327a387b1a7c534da9dbb54b8bf8a8aa
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On 13 Jan 2005 02:48:53 -0000
John Levine <johnl@iecc.com> wrote:

> Another question is the big record problem.  Some SPF descriptions are
>  complicated enough that they won't fit in 512 bytes.  What's the best
>  thing to do?  Hotmail.com broke theirs up into four chunks named
>  spf-a.hotmail.com through spf-d.hotmail.com, with the main hotmail.com
>  SPF including the four.  The total amount of data is only about 1K so
>  a UDP transaction with the truncation bit followed by a TCP
>  transaction would probably be fewer packets than the five queries the
>  split version needs.  Other than reminding people that EDNS0 is
>  available for their large packet needs, any suggestions on artificial
>  subdivision vs. TCP?


The main argument against TCP is not a traffic argument (although if
one is volume charged it could be a consideration) but the amount of
state the OS the nameserver runs on needs to maintain.

-- 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:46:13 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Fri, 14 Jan 2005 18:01:41 +0700
Lines: 26
References: <20050111215256.GA24161@sources.org>  <C11A25C5CD68A4ABFEB45BC2@[192.168.100.25]> <200501111937.j0BJbKAa018369@open.nlnetlabs.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Jaap Akkerhuis <jaap@NLnetLabs.nl>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 12:12:08 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
In-Reply-To: <20050111215256.GA24161@sources.org> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        Tue, 11 Jan 2005 22:52:56 +0100
    From:        Stephane Bortzmeyer <bortzmeyer@nic.fr>
    Message-ID:  <20050111215256.GA24161@sources.org>

  | Hence the proposal to use the "zone cut" algorithm (RFC 2181) for the
  | lookup,

Huh?

I wrote 2181 - there is no "zone cut algorithm" in it.

It does describe what a zone cut is, and gives some properties,
but most certainly doesn't pretend there is some piece of magic
by which clients can discover where a cut exists.

Dynamic updates do something like that, but only from inside the
zone.

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:46:13 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Fri, 14 Jan 2005 18:39:04 +0700
Lines: 21
References: <Pine.LNX.4.44.0501112201260.12250-100000@sokol.elan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 13:01:44 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "william(at)elan.net" <william@elan.net>
In-Reply-To: <Pine.LNX.4.44.0501112201260.12250-100000@sokol.elan.net> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        Tue, 11 Jan 2005 22:11:30 -0800 (PST)
    From:        "william(at)elan.net" <william@elan.net>
    Message-ID:  <Pine.LNX.4.44.0501112201260.12250-100000@sokol.elan.net>

  | If there is no authority 
  | section for negative response, then client can directly query for SOA.

That's impossible.   You cannot find a zone but by making an
SOA query, that would beg the question - that is, you have to
know what name to query, that's the name at the zone cut, which
is what you were seeking in the first place.

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:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Fri, 14 Jan 2005 16:21:19 +0000
Lines: 751
References: <kre@munnari.OZ.AU>
Cc: "william(at)elan.net" <william@elan.net>,
	namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 18:04:28 2005
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 "Fri, 14 Jan 2005 18:39:04 +0700."
	<23705.1105702744@munnari.OZ.AU> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>   | If there is no authority 
>   | section for negative response, then client can directly query for SOA.
> 
> That's impossible.   You cannot find a zone but by making an
> SOA query, that would beg the question - that is, you have to
> know what name to query, that's the name at the zone cut, which
> is what you were seeking in the first place.

robert, i've directed the authors of this draft at the bind8 sources for
"res_findzonecut()" several times; if they wanted to know why finding a
zone cut is hard, they could.  the fact that they continue to assert that
it's easy, should tell you that they already know what to believe, and
will not be listening to contrary input.

here, for the ".tar.gz" challenged, is the code in question, which i wrote.
in my considered opinion, any application who wants to know where a zone
cut is has to do AT LEAST AS MUCH WORK as what's described as follows:

---

#if !defined(lint) && !defined(SABER)
static const char rcsid[] = "$Id: res_findzonecut.c,v 8.23 2004/09/16 07:09:33 marka Exp $";
#endif /* not lint */

/*
 * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
 * Copyright (c) 1999 by Internet Software Consortium.
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
 * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

/* Import. */

#include "port_before.h"

#include <sys/param.h>
#include <sys/socket.h>
#include <sys/time.h>

#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>

#include <errno.h>
#include <limits.h>
#include <netdb.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <isc/list.h>

#include "port_after.h"

#include <resolv.h>

/* Data structures. */

typedef struct rr_a {
	LINK(struct rr_a)	link;
	union res_sockaddr_union addr;
} rr_a;
typedef LIST(rr_a) rrset_a;

typedef struct rr_ns {
	LINK(struct rr_ns)	link;
	const char *		name;
	unsigned int		flags;
	rrset_a			addrs;
} rr_ns;
typedef LIST(rr_ns) rrset_ns;

#define	RR_NS_HAVE_V4		0x01
#define	RR_NS_HAVE_V6		0x02

/* Forward. */

static int	satisfy(res_state, const char *, rrset_ns *,
			union res_sockaddr_union *, int);
static int	add_addrs(res_state, rr_ns *,
			  union res_sockaddr_union *, int);
static int	get_soa(res_state, const char *, ns_class, int,
			char *, size_t, char *, size_t,
			rrset_ns *);
static int	get_ns(res_state, const char *, ns_class, int, rrset_ns *);
static int	get_glue(res_state, ns_class, int, rrset_ns *);
static int	save_ns(res_state, ns_msg *, ns_sect,
			const char *, ns_class, int, rrset_ns *);
static int	save_a(res_state, ns_msg *, ns_sect,
		       const char *, ns_class, int, rr_ns *);
static void	free_nsrrset(rrset_ns *);
static void	free_nsrr(rrset_ns *, rr_ns *);
static rr_ns *	find_ns(rrset_ns *, const char *);
static int	do_query(res_state, const char *, ns_class, ns_type,
			 u_char *, ns_msg *);
static void	res_dprintf(const char *, ...) ISC_FORMAT_PRINTF(1, 2);

/* Macros. */

#define DPRINTF(x) do {\
		int save_errno = errno; \
		if ((statp->options & RES_DEBUG) != 0U) res_dprintf x; \
		errno = save_errno; \
	} while (0)

/* Public. */

/*
 * int
 * res_findzonecut(res, dname, class, zname, zsize, addrs, naddrs)
 *	find enclosing zone for a <dname,class>, and some server addresses
 * parameters:
 *	res - resolver context to work within (is modified)
 *	dname - domain name whose enclosing zone is desired
 *	class - class of dname (and its enclosing zone)
 *	zname - found zone name
 *	zsize - allocated size of zname
 *	addrs - found server addresses
 *	naddrs - max number of addrs
 * return values:
 *	< 0 - an error occurred (check errno)
 *	= 0 - zname is now valid, but addrs[] wasn't changed
 *	> 0 - zname is now valid, and return value is number of addrs[] found
 * notes:
 *	this function calls res_nsend() which means it depends on correctly
 *	functioning recursive nameservers (usually defined in /etc/resolv.conf
 *	or its local equivilent).
 *
 *	we start by asking for an SOA<dname,class>.  if we get one as an
 *	answer, that just means <dname,class> is a zone top, which is fine.
 *	more than likely we'll be told to go pound sand, in the form of a
 *	negative answer.
 *
 *	note that we are not prepared to deal with referrals since that would
 *	only come from authority servers and our correctly functioning local
 *	recursive server would have followed the referral and got us something
 *	more definite.
 *
 *	if the authority section contains an SOA, this SOA should also be the
 *	closest enclosing zone, since any intermediary zone cuts would've been
 *	returned as referrals and dealt with by our correctly functioning local
 *	recursive name server.  but an SOA in the authority section should NOT
 *	match our dname (since that would have been returned in the answer
 *	section).  an authority section SOA has to be "above" our dname.
 *
 *	however, since authority section SOA's were once optional, it's
 *	possible that we'll have to go hunting for the enclosing SOA by
 *	ripping labels off the front of our dname -- this is known as "doing
 *	it the hard way."
 *
 *	ultimately we want some server addresses, which are ideally the ones
 *	pertaining to the SOA.MNAME, but only if there is a matching NS RR.
 *	so the second phase (after we find an SOA) is to go looking for the
 *	NS RRset for that SOA's zone.
 *
 *	no answer section processed by this code is allowed to contain CNAME
 *	or DNAME RR's.  for the SOA query this means we strip a label and
 *	keep going.  for the NS and A queries this means we just give up.
 */

int
res_findzonecut(res_state statp, const char *dname, ns_class class, int opts,
		char *zname, size_t zsize, struct in_addr *addrs, int naddrs)
{
	int result, i;
	union res_sockaddr_union *u;

	
	opts |= RES_IPV4ONLY;
	opts &= ~RES_IPV6ONLY;

	u = calloc(naddrs, sizeof(*u));
	if (u == NULL)
		return(-1);

	result = res_findzonecut2(statp, dname, class, opts, zname, zsize,
				  u, naddrs);

	for (i = 0; i < result; i++) {
		addrs[i] = u[i].sin.sin_addr;
	}
	free(u);
	return (result);
}

int
res_findzonecut2(res_state statp, const char *dname, ns_class class, int opts,
		 char *zname, size_t zsize, union res_sockaddr_union *addrs,
		 int naddrs)
{
	char mname[NS_MAXDNAME];
	u_long save_pfcode;
	rrset_ns nsrrs;
	int n;

	DPRINTF(("START dname='%s' class=%s, zsize=%ld, naddrs=%d",
		 dname, p_class(class), (long)zsize, naddrs));
	save_pfcode = statp->pfcode;
	statp->pfcode |= RES_PRF_HEAD2 | RES_PRF_HEAD1 | RES_PRF_HEADX |
			 RES_PRF_QUES | RES_PRF_ANS |
			 RES_PRF_AUTH | RES_PRF_ADD;
	INIT_LIST(nsrrs);

	DPRINTF(("get the soa, and see if it has enough glue"));
	if ((n = get_soa(statp, dname, class, opts, zname, zsize,
			 mname, sizeof mname, &nsrrs)) < 0 ||
	    ((opts & RES_EXHAUSTIVE) == 0 &&
	     (n = satisfy(statp, mname, &nsrrs, addrs, naddrs)) > 0))
		goto done;

	DPRINTF(("get the ns rrset and see if it has enough glue"));
	if ((n = get_ns(statp, zname, class, opts, &nsrrs)) < 0 ||
	    ((opts & RES_EXHAUSTIVE) == 0 &&
	     (n = satisfy(statp, mname, &nsrrs, addrs, naddrs)) > 0))
		goto done;

	DPRINTF(("get the missing glue and see if it's finally enough"));
	if ((n = get_glue(statp, class, opts, &nsrrs)) >= 0)
		n = satisfy(statp, mname, &nsrrs, addrs, naddrs);

 done:
	DPRINTF(("FINISH n=%d (%s)", n, (n < 0) ? strerror(errno) : "OK"));
	free_nsrrset(&nsrrs);
	statp->pfcode = save_pfcode;
	return (n);
}

/* Private. */

static int
satisfy(res_state statp, const char *mname, rrset_ns *nsrrsp,
	union res_sockaddr_union *addrs, int naddrs)
{
	rr_ns *nsrr;
	int n, x;

	n = 0;
	nsrr = find_ns(nsrrsp, mname);
	if (nsrr != NULL) {
		x = add_addrs(statp, nsrr, addrs, naddrs);
		addrs += x;
		naddrs -= x;
		n += x;
	}
	for (nsrr = HEAD(*nsrrsp);
	     nsrr != NULL && naddrs > 0;
	     nsrr = NEXT(nsrr, link))
		if (ns_samename(nsrr->name, mname) != 1) {
			x = add_addrs(statp, nsrr, addrs, naddrs);
			addrs += x;
			naddrs -= x;
			n += x;
		}
	DPRINTF(("satisfy(%s): %d", mname, n));
	return (n);
}

static int
add_addrs(res_state statp, rr_ns *nsrr,
	  union res_sockaddr_union *addrs, int naddrs)
{
	rr_a *arr;
	int n = 0;

	for (arr = HEAD(nsrr->addrs); arr != NULL; arr = NEXT(arr, link)) {
		if (naddrs <= 0)
			return (0);
		*addrs++ = arr->addr;
		naddrs--;
		n++;
	}
	DPRINTF(("add_addrs: %d", n));
	return (n);
}

static int
get_soa(res_state statp, const char *dname, ns_class class, int opts,
	char *zname, size_t zsize, char *mname, size_t msize,
	rrset_ns *nsrrsp)
{
	char tname[NS_MAXDNAME];
	u_char *resp = NULL;
	int n, i, ancount, nscount;
	ns_sect sect;
	ns_msg msg;
	u_int rcode;

	/*
	 * Find closest enclosing SOA, even if it's for the root zone.
	 */

	/* First canonicalize dname (exactly one unescaped trailing "."). */
	if (ns_makecanon(dname, tname, sizeof tname) < 0)
		goto cleanup;
	dname = tname;

	resp = malloc(NS_MAXMSG);
	if (resp == NULL)
		goto cleanup;

	/* Now grovel the subdomains, hunting for an SOA answer or auth. */
	for (;;) {
		/* Leading or inter-label '.' are skipped here. */
		while (*dname == '.')
			dname++;

		/* Is there an SOA? */
		n = do_query(statp, dname, class, ns_t_soa, resp, &msg);
		if (n < 0) {
			DPRINTF(("get_soa: do_query('%s', %s) failed (%d)",
				 dname, p_class(class), n));
			goto cleanup;
		}
		if (n > 0) {
			DPRINTF(("get_soa: CNAME or DNAME found"));
			sect = ns_s_max, n = 0;
		} else {
			rcode = ns_msg_getflag(msg, ns_f_rcode);
			ancount = ns_msg_count(msg, ns_s_an);
			nscount = ns_msg_count(msg, ns_s_ns);
			if (ancount > 0 && rcode == ns_r_noerror)
				sect = ns_s_an, n = ancount;
			else if (nscount > 0)
				sect = ns_s_ns, n = nscount;
			else
				sect = ns_s_max, n = 0;
		}
		for (i = 0; i < n; i++) {
			const char *t;
			const u_char *rdata;
			int rdlen;
			ns_rr rr;

			if (ns_parserr(&msg, sect, i, &rr) < 0) {
				DPRINTF(("get_soa: ns_parserr(%s, %d) failed",
					 p_section(sect, ns_o_query), i));
				goto cleanup;
			}
			if (ns_rr_type(rr) == ns_t_cname ||
			    ns_rr_type(rr) == ns_t_dname)
				break;
			if (ns_rr_type(rr) != ns_t_soa ||
			    ns_rr_class(rr) != class)
				continue;
			t = ns_rr_name(rr);
			switch (sect) {
			case ns_s_an:
				if (ns_samedomain(dname, t) == 0) {
					DPRINTF(
				    ("get_soa: ns_samedomain('%s', '%s') == 0",
						dname, t)
						);
					errno = EPROTOTYPE;
					goto cleanup;
				}
				break;
			case ns_s_ns:
				if (ns_samename(dname, t) == 1 ||
				    ns_samedomain(dname, t) == 0) {
					DPRINTF(
		       ("get_soa: ns_samename() || !ns_samedomain('%s', '%s')",
						dname, t)
						);
					errno = EPROTOTYPE;
					goto cleanup;
				}
				break;
			default:
				abort();
			}
			if (strlen(t) + 1 > zsize) {
				DPRINTF(("get_soa: zname(%lu) too small (%lu)",
					 (unsigned long)zsize,
					 (unsigned long)strlen(t) + 1));
				errno = EMSGSIZE;
				goto cleanup;
			}
			strcpy(zname, t);
			rdata = ns_rr_rdata(rr);
			rdlen = ns_rr_rdlen(rr);
			if (ns_name_uncompress(resp, ns_msg_end(msg), rdata,
					       mname, msize) < 0) {
				DPRINTF(("get_soa: ns_name_uncompress failed")
					);
				goto cleanup;
			}
			if (save_ns(statp, &msg, ns_s_ns,
				    zname, class, opts, nsrrsp) < 0) {
				DPRINTF(("get_soa: save_ns failed"));
				goto cleanup;
			}
			free(resp);
			return (0);
		}

		/* If we're out of labels, then not even "." has an SOA! */
		if (*dname == '\0')
			break;

		/* Find label-terminating "."; top of loop will skip it. */
		while (*dname != '.') {
			if (*dname == '\\')
				if (*++dname == '\0') {
					errno = EMSGSIZE;
					goto cleanup;
				}
			dname++;
		}
	}
	DPRINTF(("get_soa: out of labels"));
	errno = EDESTADDRREQ;
 cleanup:
	if (resp != NULL)
		free(resp);
	return (-1);
}

static int
get_ns(res_state statp, const char *zname, ns_class class, int opts,
      rrset_ns *nsrrsp)
{
	u_char *resp;
	ns_msg msg;
	int n;

	resp = malloc(NS_MAXMSG);
	if (resp == NULL)
		return (-1);

	/* Go and get the NS RRs for this zone. */
	n = do_query(statp, zname, class, ns_t_ns, resp, &msg);
	if (n != 0) {
		DPRINTF(("get_ns: do_query('%s', %s) failed (%d)",
			 zname, p_class(class), n));
		free(resp);
		return (-1);
	}

	/* Remember the NS RRs and associated A RRs that came back. */
	if (save_ns(statp, &msg, ns_s_an, zname, class, opts, nsrrsp) < 0) {
		DPRINTF(("get_ns save_ns('%s', %s) failed",
			 zname, p_class(class)));
		free(resp);
		return (-1);
	}

	free(resp);
	return (0);
}

static int
get_glue(res_state statp, ns_class class, int opts, rrset_ns *nsrrsp) {
	rr_ns *nsrr, *nsrr_n;
	u_char *resp;

	resp = malloc(NS_MAXMSG);
	if (resp == NULL)
		return(-1);

	/* Go and get the A RRs for each empty NS RR on our list. */
	for (nsrr = HEAD(*nsrrsp); nsrr != NULL; nsrr = nsrr_n) {
		ns_msg msg;
		int n;

		nsrr_n = NEXT(nsrr, link);

		if ((nsrr->flags & RR_NS_HAVE_V4) == 0) {
			n = do_query(statp, nsrr->name, class, ns_t_a,
				     resp, &msg);
			if (n < 0) {
				DPRINTF(
				       ("get_glue: do_query('%s', %s') failed",
					nsrr->name, p_class(class)));
				goto cleanup;
			}
			if (n > 0) {
				DPRINTF((
			"get_glue: do_query('%s', %s') CNAME or DNAME found",
					 nsrr->name, p_class(class)));
			}
			if (save_a(statp, &msg, ns_s_an, nsrr->name, class,
				   opts, nsrr) < 0) {
				DPRINTF(("get_glue: save_r('%s', %s) failed",
					 nsrr->name, p_class(class)));
				goto cleanup;
			}
		}

		if ((nsrr->flags & RR_NS_HAVE_V6) == 0) {
			n = do_query(statp, nsrr->name, class, ns_t_aaaa,
				     resp, &msg);
			if (n < 0) {
				DPRINTF(
				       ("get_glue: do_query('%s', %s') failed",
					nsrr->name, p_class(class)));
				goto cleanup;
			}
			if (n > 0) {
				DPRINTF((
			"get_glue: do_query('%s', %s') CNAME or DNAME found",
					 nsrr->name, p_class(class)));
			}
			if (save_a(statp, &msg, ns_s_an, nsrr->name, class,
				   opts, nsrr) < 0) {
				DPRINTF(("get_glue: save_r('%s', %s) failed",
					 nsrr->name, p_class(class)));
				goto cleanup;
			}
		}

		/* If it's still empty, it's just chaff. */
		if (EMPTY(nsrr->addrs)) {
			DPRINTF(("get_glue: removing empty '%s' NS",
				 nsrr->name));
			free_nsrr(nsrrsp, nsrr);
		}
	}
	free(resp);
	return (0);

 cleanup:
	free(resp);
	return (-1);
}

static int
save_ns(res_state statp, ns_msg *msg, ns_sect sect,
	const char *owner, ns_class class, int opts,
	rrset_ns *nsrrsp)
{
	int i;

	for (i = 0; i < ns_msg_count(*msg, sect); i++) {
		char tname[MAXDNAME];
		const u_char *rdata;
		rr_ns *nsrr;
		ns_rr rr;
		int rdlen;

		if (ns_parserr(msg, sect, i, &rr) < 0) {
			DPRINTF(("save_ns: ns_parserr(%s, %d) failed",
				 p_section(sect, ns_o_query), i));
			return (-1);
		}
		if (ns_rr_type(rr) != ns_t_ns ||
		    ns_rr_class(rr) != class ||
		    ns_samename(ns_rr_name(rr), owner) != 1)
			continue;
		nsrr = find_ns(nsrrsp, ns_rr_name(rr));
		if (nsrr == NULL) {
			nsrr = malloc(sizeof *nsrr);
			if (nsrr == NULL) {
				DPRINTF(("save_ns: malloc failed"));
				return (-1);
			}
			rdata = ns_rr_rdata(rr);
			rdlen = ns_rr_rdlen(rr);
			if (ns_name_uncompress(ns_msg_base(*msg),
					       ns_msg_end(*msg), rdata,
					       tname, sizeof tname) < 0) {
				DPRINTF(("save_ns: ns_name_uncompress failed")
					);
				free(nsrr);
				return (-1);
			}
			nsrr->name = strdup(tname);
			if (nsrr->name == NULL) {
				DPRINTF(("save_ns: strdup failed"));
				free(nsrr);
				return (-1);
			}
			INIT_LINK(nsrr, link);
			INIT_LIST(nsrr->addrs);
			nsrr->flags = 0;
			APPEND(*nsrrsp, nsrr, link);
		}
		if (save_a(statp, msg, ns_s_ar,
			   nsrr->name, class, opts, nsrr) < 0) {
			DPRINTF(("save_ns: save_r('%s', %s) failed",
				 nsrr->name, p_class(class)));
			return (-1);
		}
	}
	return (0);
}

static int
save_a(res_state statp, ns_msg *msg, ns_sect sect,
       const char *owner, ns_class class, int opts,
       rr_ns *nsrr)
{
	int i;

	for (i = 0; i < ns_msg_count(*msg, sect); i++) {
		ns_rr rr;
		rr_a *arr;

		if (ns_parserr(msg, sect, i, &rr) < 0) {
			DPRINTF(("save_a: ns_parserr(%s, %d) failed",
				 p_section(sect, ns_o_query), i));
			return (-1);
		}
		if ((ns_rr_type(rr) != ns_t_a &&
		     ns_rr_type(rr) != ns_t_aaaa) ||
		    ns_rr_class(rr) != class ||
		    ns_samename(ns_rr_name(rr), owner) != 1 ||
		    ns_rr_rdlen(rr) != NS_INADDRSZ)
			continue;
		if ((opts & RES_IPV6ONLY) != 0 && ns_rr_type(rr) != ns_t_aaaa)
			continue;
		if ((opts & RES_IPV4ONLY) != 0 && ns_rr_type(rr) != ns_t_a)
			continue;
		arr = malloc(sizeof *arr);
		if (arr == NULL) {
			DPRINTF(("save_a: malloc failed"));
			return (-1);
		}
		INIT_LINK(arr, link);
		memset(&arr->addr, 0, sizeof(arr->addr));
		switch (ns_rr_type(rr)) {
		case ns_t_a:
			arr->addr.sin.sin_family = AF_INET;
#ifdef HAVE_SA_LEN
			arr->addr.sin.sin_len = sizeof(arr->addr.sin);
#endif
			memcpy(&arr->addr.sin.sin_addr, ns_rr_rdata(rr),
			       NS_INADDRSZ);
			arr->addr.sin.sin_port = htons(NAMESERVER_PORT);
			nsrr->flags |= RR_NS_HAVE_V4;
			break;
		case ns_t_aaaa:
			arr->addr.sin6.sin6_family = AF_INET6;
#ifdef HAVE_SA_LEN
			arr->addr.sin6.sin6_len = sizeof(arr->addr.sin6);
#endif
			memcpy(&arr->addr.sin6.sin6_addr, ns_rr_rdata(rr), 16);
			arr->addr.sin.sin_port = htons(NAMESERVER_PORT);
			nsrr->flags |= RR_NS_HAVE_V6;
			break;
		default:
			abort();
		}
		APPEND(nsrr->addrs, arr, link);
	}
	return (0);
}

static void
free_nsrrset(rrset_ns *nsrrsp) {
	rr_ns *nsrr;

	while ((nsrr = HEAD(*nsrrsp)) != NULL)
		free_nsrr(nsrrsp, nsrr);
}

static void
free_nsrr(rrset_ns *nsrrsp, rr_ns *nsrr) {
	rr_a *arr;
	char *tmp;

	while ((arr = HEAD(nsrr->addrs)) != NULL) {
		UNLINK(nsrr->addrs, arr, link);
		free(arr);
	}
	DE_CONST(nsrr->name, tmp);
	free(tmp);
	UNLINK(*nsrrsp, nsrr, link);
	free(nsrr);
}

static rr_ns *
find_ns(rrset_ns *nsrrsp, const char *dname) {
	rr_ns *nsrr;

	for (nsrr = HEAD(*nsrrsp); nsrr != NULL; nsrr = NEXT(nsrr, link))
		if (ns_samename(nsrr->name, dname) == 1)
			return (nsrr);
	return (NULL);
}

static int
do_query(res_state statp, const char *dname, ns_class class, ns_type qtype,
	 u_char *resp, ns_msg *msg)
{
	u_char req[NS_PACKETSZ];
	int i, n;

	n = res_nmkquery(statp, ns_o_query, dname, class, qtype,
			 NULL, 0, NULL, req, NS_PACKETSZ);
	if (n < 0) {
		DPRINTF(("do_query: res_nmkquery failed"));
		return (-1);
	}
	n = res_nsend(statp, req, n, resp, NS_MAXMSG);
	if (n < 0) {
		DPRINTF(("do_query: res_nsend failed"));
		return (-1);
	}
	if (n == 0) {
		DPRINTF(("do_query: res_nsend returned 0"));
		errno = EMSGSIZE;
		return (-1);
	}
	if (ns_initparse(resp, n, msg) < 0) {
		DPRINTF(("do_query: ns_initparse failed"));
		return (-1);
	}
	n = 0;
	for (i = 0; i < ns_msg_count(*msg, ns_s_an); i++) {
		ns_rr rr;

		if (ns_parserr(msg, ns_s_an, i, &rr) < 0) {
			DPRINTF(("do_query: ns_parserr failed"));
			return (-1);
		}
		n += (ns_rr_class(rr) == class &&
		      (ns_rr_type(rr) == ns_t_cname ||
		       ns_rr_type(rr) == ns_t_dname));
	}
	return (n);
}

static void
res_dprintf(const char *fmt, ...) {
	va_list ap;

	va_start(ap, fmt);
	fputs(";; res_findzonecut: ", stderr);
	vfprintf(stderr, fmt, ap);
	fputc('\n', stderr);
	va_end(ap);
}

---

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Engineering SPF
Date: 14 Jan 2005 18:18:06 -0000
Lines: 44
References: <x4ekh1vrtr.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: wayne@schlitt.net
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 19:29:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Let's assume, for the sake of argument, that

   (1) we want the information communicated by the deployed SPF
       protocol---does the administrator of X want IP address Y to be
       able to send mail with return addresses @X?---but

   (2) we've decided that we'll have to change how this information is
       retrieved through DNS---leaving the current software alone would
       be nice but the protocol design is simply too painful.

How, then, should the administrator of X use DNS to publish information
about various IP addresses Y? How can we handle the problems of large
packets, subdomains, etc.? I'd like to see this how-to-use-DNS question
discussed separately from questioning assumption #1 (and #2).

Most of the problems of the current protocol design appear to be caused
by crunching information about all the Y's into a single DNS record for
X. The client is actually interested in a particular Y, and can simply
ask about, say, Ztruncto63.reverse(Y).spfidentifier.X for return address
Z@X. The hotmail administrator, for example, would have records such as

   *.spf63784604719468285133.hotmail.com. TXT "n"
   *.137.2.199.spf63784604719468285133.hotmail.com. TXT "y"
   ...

rather than the current multiple-level spf-*.hotmail.com structure. The
63784604719468285133 tag serves the same function as an underscore and a
new record type, without the interoperability problems of an underscore
and without the interoperability problems of a new record type.

This initial spreading of queries appears to remove the need for other
forms of indirection, so clients become much simpler and the efficiency
problems of the current SPF protocol go away.

Comments?

---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:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
Date: Fri, 14 Jan 2005 13:33:11 -0600
Lines: 80
References: <kre@munnari.OZ.AU> <20050114162119.A4D8813E4E@sa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 20:40:50 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 73
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:M0jxVhgRNsPqWi21ym7fzxeX87g=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <20050114162119.A4D8813E4E@sa.vix.com> Paul Vixie <paul@vix.com> writes:

>>   | If there is no authority 
>>   | section for negative response, then client can directly query for SOA.
>> 
>> That's impossible.   You cannot find a zone but by making an
>> SOA query, that would beg the question - that is, you have to
>> know what name to query, that's the name at the zone cut, which
>> is what you were seeking in the first place.
>
> robert, i've directed the authors of this draft at the bind8 sources for
> "res_findzonecut()" several times; if they wanted to know why finding a
> zone cut is hard, they could.  the fact that they continue to assert that
> it's easy, should tell you that they already know what to believe, and
> will not be listening to contrary input.

Paul, I only know of *once* that you have directed me to the
res_findzonecut() function, and that was in:
http://article.gmane.org/gmane.ietf.dnsext/6438

> here, for the ".tar.gz" challenged, is the code in question, which i wrote.
> in my considered opinion, any application who wants to know where a zone
> cut is has to do AT LEAST AS MUCH WORK as what's described as follows:

I am not ".tar.gz" challenged.  As I said in the post referenced
above:

| Actually, res_findzonecut() is what I've based my code on.  See this
| post I made to spf-discuss almost a year ago:
| 
| http://archives.listbox.com/spf-discuss@v2.listbox.com/200403/0026.html

So, I was quite capable of finding that function, I did it a long time
ago, I've studied it and while it may have been hard for you to
create, life is much easier for those of us who have followed.
Especially since you have kindly used a very liberal copyright.


Yes, that code can cause a lot of DNS lookups in the worst case, but
it seems ok to me in the typical case.


Please, we are trying to solve problems here.  Your exaggerations and
not even reading my replies to you isn't helping.  Going around saying "I
told them so!", when, really, you didn't is kind of tacky.


The real-world problem that we are trying to solve is:

    Domain owners want to have a voice in how the domain name that
    they have bought gets used.  Others would like to hear what the
    domain owners have to say. The particular case we are dealing with
    is email in conjunction with SPF, but there are other cases too.

    
DNS seems to be a good way of communicating, considering that the
communication is about their domain.  Unfortunately, DNS wildcards
(currently) don't allow the domain owner to cover all of their domain.

Using zone cuts to simulate a different kind of DNS wildcarding is not
pretty and is not as cheap as it could be, but is the best solution I
know of that exists today.


Even last fall, when I started working on this particular SPF-classic
draft, I said that I would be flexible on how this stuff worked.  I am
looking for a solution to a problem.  Help would be appreciated.


thanks


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: Engineering SPF
Date: Fri, 14 Jan 2005 13:54:24 -0600
Lines: 61
References: <x4ekh1vrtr.fsf@footbone.schlitt.net> <20050114181806.82936.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 20:59:34 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 54
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:OmxJcOtDzcSNuuT1Zv4vWbigagk=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <20050114181806.82936.qmail@cr.yp.to> "D. J. Bernstein" <djb@cr.yp.to> writes:

> Let's assume, for the sake of argument, that [snip]
>
> How, then, should the administrator of X use DNS to publish information
> about various IP addresses Y? How can we handle the problems of large
> packets, subdomains, etc.? I'd like to see this how-to-use-DNS question
> discussed separately from questioning assumption #1 (and #2).

Hi Dan.

Yes, the "how to use DNS?" question has been asked in relation to this
subject many times.  I found the discussion quite interesting, but I'm
not sure that it would be a good idea to rehash it here.  The answer
is one in which I believe that reasonable people can disagree on.
There are a lot of trade-offs involved and depending on how you
consider the various costs, you can end up with very different
answers.

A good overview of this subject was written up by the IRTF's ASRG WG.
See:
http://asrg.kavi.com/apps/group_public/download.php/31/draft-irtf-asrg-lmap-discussion-00.txt

In particular, look at section 4.


> Most of the problems of the current protocol design appear to be caused
> by crunching information about all the Y's into a single DNS record for
> X. The client is actually interested in a particular Y, and can simply
> ask about, say, Ztruncto63.reverse(Y).spfidentifier.X for return address
> Z@X. The hotmail administrator, for example, would have records such as
>
>    *.spf63784604719468285133.hotmail.com. TXT "n"

Minor nit, but unless I'm very much mistaken, you also need:

     *.199.spf63784604719468285133.hotmail.com. TXT "n"
     *.2.199.spf63784604719468285133.hotmail.com. TXT "n"

>    *.137.2.199.spf63784604719468285133.hotmail.com. TXT "y"

This arrangement has a lower cost when you only want to find the
answer once, but has a higher cost if you get a lot of email claiming
to be from hotmail.com.  Spoofed email claiming to be from hotmail.com
gets sent by hundreds of thousands of zombied boxes.


If you like this form, however, you can do it right now with SPF via:

hotmail.com.  TXT  "v=spf1 exists:%{ir}.spf63784604719468285133.%{d} -all"
*.137.2.199.spf63784604719468285133.hotmail.com. A 127.0.0.2


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Florian Weimer <fw@deneb.enyo.de>
Subject: Re: Engineering SPF
Date: Fri, 14 Jan 2005 22:46:53 +0100
Lines: 27
References: <x4ekh1vrtr.fsf@footbone.schlitt.net>
	<20050114181806.82936.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Fri Jan 14 22:55:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org,  wayne@schlitt.net
In-Reply-To: <20050114181806.82936.qmail@cr.yp.to> (D. J. Bernstein's message
	of "14 Jan 2005 18:18:06 -0000")
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

* D. J. Bernstein:

> This initial spreading of queries appears to remove the need for other
> forms of indirection, so clients become much simpler and the efficiency
> problems of the current SPF protocol go away.

I think the indirection/macro expansion capability is actually needed
in practice.  For example, T-Online might want to use DARTmail's bulk
mailing capabilities, and want them to use a @t-online.de addresses
(in order to avoid customer confusion).  With SPF, DARTmail publishes
an SPF record, which T-Online includes (by reference) in its SPF
record for t-online.de.  The effect is that DARTmail can send mail
under the t-online.de domain, and T-Online doesn't have to maintain a
list of DARTmail's mail relays.

I don't think this property is preserved in your proposal.  T-Online
would have to generate responses dynamically, or keep a list of IP
addresses DARTmail's server.

(This message should not be read an endorsement of SPF or similar
technologies.)

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: John Levine <johnl@iecc.com>
Subject: Re: Engineering SPF
Date: 15 Jan 2005 04:34:26 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 93
References: <cs932k$2kmv$1@sf1.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: djb@cr.yp.to
X-From: owner-namedroppers@ops.ietf.org Sat Jan 15 05:45:27 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <cs932k$2kmv$1@sf1.isc.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>Most of the problems of the current protocol design appear to be caused
>by crunching information about all the Y's into a single DNS record for
>X. The client is actually interested in a particular Y, and can simply
>ask about, say, Ztruncto63.reverse(Y).spfidentifier.X for return address
>Z@X.

Back when the ASRG LMAP group was active, this question was argued at
length.  I characterized the two approaches as block data, where all
of the valid IPs for a domain are retrieved as a group, and factored
data where the info for each (domain,IP) pair is stored under a
separate name.  SPF and Hadmut Danisch's RMX are the best known block
schemes, and Gordon Fecyk's DMP the best known factored.  I offered
a strawman called FSV that "panders to both factions" and provided both.

RMX basically published lists of CIDR ranges per domain using proposed
RMX and APL (CIDR range set) records.  DMP used names like
1.2.0.192.in-addr._smtp-client.example.com to identify valid and
invalid hosts, putting the reversed IP at the front so you could use
wildcards to help publish info for large IP ranges with the same data,

I think I can summarize the arguments for of each side, even
though I don't necessarily believe them.

For factored records: 

Good: They're easy to check, possibly using a variation of the code
used now to check DNSBLs.  Since you make exactly one query per
message, performance is predictable and fast.

Bad: A large domain may need a whole lot of records, e.g., AOL's SPF
record factors out to more than 2300 IP addresses and Hotmail's, if
you believe it, factors out to over 500,000.  If you send mail through
your ISP, you're at the mercy of the ISP to find out what their
sending hosts are. For DMP you could probably use a CNAME to alias
_smtp-client.littledomain.org to _smtp-client.bigisp.net (or would
that need a DNAME?)

For the common case where a small set of IPs are marked "yes" and the
rest of them should be marked "no", it can be challenging to publish all
the wildcards needed to cover all of the "no" values.  In FSV I just
published records for "yes" and had a distinguished name you could check
to tell whether the domain published FSV and hence whether to interpret
the lack of of a "yes" as a "no" or unknown.  


For block records: 

Good: Microsoft argued quite vehemently that the DNS cost of checking
block records was vastly lower than factored records.  Some mail
servers use a process per SMTP session (qmail), and others have one
big long-running process with threads (Exchange).  If your MTA is of
the latter variety, the MTA can slurp up block records and cache their
data internally which they said is a lot faster.  I think this says
more about lousy DNS caches than about DNS performance, but what do I
know?

SPF is intended to be easy to publish even if hard to decode, on the
theory that every domain owner that sends mail needs to be able to
publish SPF records, but only the 12 people in the world who maintain
MTAs need to know how to decode them.  That's why it has the zillion
features to provide indirect references of various sorts.

Bad: 

Records for large domains can potentially be big, causing various big DNS
record problems.

For SPF in particular, interpreting the records can take arbitrarily
long and arbitrarily many DNS references (give or take the indirection
limits which give you predictable worst case performance at the cost
of unpredictable results.)  RMX has one level of indirection, from RMX
records to APL CIDR range records, with the expectation that the
little domain can refer to its ISP's APL record.


I need hardly remind people that SPF's victory over competing path
authorization proposals had nothing to do with their relative
technical merits, but if you care about those merits, that what we
thought they are.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: John Levine <johnl@iecc.com>
Subject: Re: Engineering SPF
Date: 15 Jan 2005 04:40:05 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 26
References: <87k6qfheeq.fsf@deneb.enyo.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: fw@deneb.enyo.de
X-From: owner-namedroppers@ops.ietf.org Sat Jan 15 05:47:03 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <87k6qfheeq.fsf@deneb.enyo.de>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>I think the indirection/macro expansion capability is actually needed
>in practice.  For example, T-Online might want to use DARTmail's bulk
>mailing capabilities, and want them to use a @t-online.de addresses
>(in order to avoid customer confusion).

My ex-client Orbitz uses Dartmail to send its newsletter, although
they send their other mail themselves. The newsletter comes from
@email.orbitz.com rather than @orbitz.com.  They delegate
email.orbitz.com to Dartmail which publishes SPF data for it.  Check
it out.

The problem that indirection is intended to solve is the little domain
that sends through its ISP's mail servers and wants to say "my SPF is
the same as bigisp.net."  One could argue that's not the recipient's
problem to figure out.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Faux wildcards
Date: 15 Jan 2005 17:13:11 -0500
Lines: 80
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Sat Jan 15 23:24:58 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "DNS whizzes" <namedroppers@ops.ietf.org>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

I've been working on CSV, a simple scheme for HELO/EHLO authentication
with Dave Crocker and some other people.  By far the knottiest question
we've been wresting with is if and how to do wildcard-like things.

For CSV we're using repurposed SRV records.  They have the fields we need,
they're widely supported by DNS software, including software written in
the Seattle suburbs, and the name prefixes that all SRV records have avoid
collisions.

If you're a mail server, and an incoming connection says EHLO
GOOD.EXAMPLE.COM, the server looks up

	_client._smtp.GOOD.EXAMPLE.COM

and if it finds it, the record tells you whether that's the name of a
valid SMTP client host, and the name part of the SRV record tells it the
name to look up if it wants to check that the name has a valid A record.

But if the SRV record doesn't exist, then what?

I see two situations where a wildcard-like facility for CSV would be
useful.  One is forgery.  I have domains that contain no MTAs, and it
would be nice to be able to say in one place that, e.g. any MTA that
HELO's as <anything>.services.net is lying.  The other is what I
generically call Big ISPs, with a large farm of hosts, such as dialup or
DHCP users, all of which exist and have names, but by policy none of which
should be sending mail directly.  Although in theory it would be possible
to add a SRV record to correspond to each A record, it would aid CSV's
adoption if they could say in one place that all of their authorized mai
client hosts have explicit records and the rest are no good.

We went throught the usual supects.  Wildcards are out because they don't
work with prefixes, and if we got rid of the prefixes, we'd have other
problems.  There was one advocate for zone cuts but we shouted him down
with the same arguments we've recently heard here.  So we ended up with a
tree walk, not unlike the one that was proposed for WHOIS last year.

We took one of the bits in the SRV record we hadn't used yet and made it
the "explicit" bit, that says that all authorized clients in subdomains of
this one have explicit CSV records.  If the lookup above didn't work, the
MTA can walk the tree, and visit some or all of these looking for the
explicit bit:

	_client._smtp.EXAMPLE.COM
	_client._smtp.COM
	_client._smtp.

After a lot of wrangling, we decided not to specify the direction of the
walk, and decreed that if a domain's record and one of its subdomain's
records have inconsistent explicit bits, the result is undefined.
Walking down has the advantage that in the (we hope) common case that a
domain puts a record high up in the tree, it'll be found quickly, and if a
bad guy does a fake HELO x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.example, the walk
can if it wants decide that since nobody's ever seen a real HELO with more
than five components, it'll stop after five rounds and if in the future
someone wants to use an MTA with a deeper name than that, they better
publish a CSV for it.

We should add a stop rule saying that you don't walk above the first or
second level of the DNS tree to limit the number of visits to the roots,
but that's basically it.  We don't require that a host have an A or AAAA
record, because we're still seeing way too many legitimate MTAs whose
HELOs are within the proper domain but don't match an A record, with
Hotmail's HELO hotmail.com being the best known. (The name in the SRV
record is the one whose address you verify, so you can make up fake names
with A records to match the addresses of your mail hosts if you need to.)

If you accept our premise that some sort way to announce the CSV policy
for a subtree of DNS is useful, is this the best we can do?

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
Subject: Re: Faux wildcards
Date: Sun, 16 Jan 2005 01:16:55 +0100
Lines: 84
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 01:23:32 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol
To: "DNSEXT WG" <namedroppers@ops.ietf.org>
In-reply-to: Your message of "15 Jan 2005 17:13:11 EST."
             <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com> 
X-Organization: Uni Bielefeld, Technische Fakultaet
X-Phone: +49 521 106 2902
Content-ID: <5688.1105834612.1@zeder.TechFak.Uni-Bielefeld.DE>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

"John R Levine" <johnl@iecc.com> wrote:

> For CSV we're using repurposed SRV records.  They have the fields we need,

you're not really *using* SRVs in what was draft-ietf-marid-csv-csa-01.txt,
they are just used as containers for your data with e.g. the weight field
redifined or 'overloaded'.

> useful.  One is forgery.  I have domains that contain no MTAs, and it

Same problem hare as with the recent SPF thread: RRsets are associated with
domain names, not with what is perceived as 'a domain', i.e. everything
down the tree starting usually at the second level. For the latter you'd need
wildcards (still with a conceptual difference).

> HELO's as <anything>.services.net is lying.  The other is what I

How about the absence of the RR as an indicator?

> generically call Big ISPs, with a large farm of hosts, such as dialup or
> DHCP users, all of which exist and have names, but by policy none of which
> should be sending mail directly.  Although in theory it would be possible
> to add a SRV record to correspond to each A record, it would aid CSV's

You mean an SRV RR at each domain name that owns an address (maybe A) RR?
Why don't you just specify that? The number of names is just a provisioning
problem.

> adoption if they could say in one place that all of their authorized mai
> client hosts have explicit records and the rest are no good.

But that's not how the DNS works. Why would one willing to adopt CSV or
anything similar not be able or willing to add the necessary RRs below
the zone apex?

> We went throught the usual supects.  Wildcards are out because they don't
> work with prefixes, and if we got rid of the prefixes, we'd have other

They work perfectly well, but they just either cover more than you need or
in case the owners exist (i.e. hosts have A RRs) the wildcards do no longer
apply.

> with the same arguments we've recently heard here.  So we ended up with a
> tree walk, not unlike the one that was proposed for WHOIS last year.

As I said in an earlier message, the _whois._tcp thing also walks the tree,
but that's something completely different because it follows the DNS hierarchy
and does not imply or deduce any (policy) information further up or down the
tree.

> 	_client._smtp.EXAMPLE.COM
> 	_client._smtp.COM
> 	_client._smtp.

Again, RFC 1535 says "don't".

> domain puts a record high up in the tree, it'll be found quickly, and if a
> bad guy does a fake HELO x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.example, the walk
> can if it wants decide that since nobody's ever seen a real HELO with more

And why would you know that a CSV RR published in the e.g. Uni-Bielefeld.DE
zone would apply to anything in TechFak.Uni-Bielefeld.DE or Biologie.
Uni-Bielefeld.DE or anywhere else, regardless of any zone cuts in between?

> We should add a stop rule saying that you don't walk above the first or
> second level of the DNS tree to limit the number of visits to the roots,

Or to "co.TLD", for example? (Anyone propose TLD based exception or rules
lists (UK:2, DE:1, MUSEUM:0)?)

> If you accept our premise that some sort way to announce the CSV policy
> for a subtree of DNS is useful, is this the best we can do?

Ex falso quodlibet. Following draft-iab-dns-choices-00 and what you've
described a dedicated RR type (your overloading of the SRV seems almost
no better or worse than using a TXT to me) is the preferred choice.

-Peter

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: John Levine <johnl@iecc.com>
Subject: Re: Faux wildcards
Date: 16 Jan 2005 01:47:06 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 114
References: <cscdss$r9f$1@sf1.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: pk@TechFak.Uni-Bielefeld.DE
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 02:55:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <cscdss$r9f$1@sf1.isc.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>> For CSV we're using repurposed SRV records.  They have the fields we need,
>
>you're not really *using* SRVs in what was draft-ietf-marid-csv-csa-01.txt,
>they are just used as containers for your data with e.g. the weight field
>redifined or 'overloaded'.

Indeed, that's why I said repurposed.

>> useful.  One is forgery.  I have domains that contain no MTAs, and it
>
>Same problem hare as with the recent SPF thread: RRsets are associated with
>domain names, not with what is perceived as 'a domain', i.e. everything
>down the tree starting usually at the second level. For the latter you'd need
>wildcards (still with a conceptual difference).

In this case, by a domain I mean a node in the DNS tree and all of its
children, not necessarily at any particular level.  I specifically do
not mean a zone.

>> HELO's as <anything>.services.net is lying.  The other is what I
>How about the absence of the RR as an indicator?

No, that's a classic FUSSP flaw, in that it'll only work when the
entire world deploys the scheme.  Until then, you can't tell a missing
RR due to deliberate omission from one due to not having gotten around
to doing CSV yet.

>> generically call Big ISPs, with a large farm of hosts, such as dialup or
>> DHCP users, all of which exist and have names, but by policy none of which
>> should be sending mail directly.  Although in theory it would be possible
>> to add a SRV record to correspond to each A record, it would aid CSV's
>
>You mean an SRV RR at each domain name that owns an address (maybe A) RR?
>Why don't you just specify that? The number of names is just a provisioning
>problem.

Because the number of names can be enormous.  For many large ISPs it's
in the hundreds of thousands.  For AOL it's in the millions.  Like I
said, in theory it's possible, in practice it's a huge burden.

>> adoption if they could say in one place that all of their authorized mail
>> client hosts have explicit records and the rest are no good.
>
>But that's not how the DNS works. Why would one willing to adopt CSV or
>anything similar not be able or willing to add the necessary RRs below
>the zone apex?

Partly because you can't predict the fake names that people might use,
partly because the number of required RRs would be very large.  Also,
as noted before, zone boundaries are irrelevant and a record with the
explicit bit can occur at any level.

>> We went throught the usual supects.  Wildcards are out because they don't
>> work with prefixes, and if we got rid of the prefixes, we'd have other
>
>They work perfectly well, but they just either cover more than you need or
>in case the owners exist (i.e. hosts have A RRs) the wildcards do no longer
>apply.

No, for SRV applications they don't work at all.  Names like
_client._smtp.*.example.com don't match anything useful.

>> domain puts a record high up in the tree, it'll be found quickly, and if a
>> bad guy does a fake HELO x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.example, the walk
>> can if it wants decide that since nobody's ever seen a real HELO with more
>
>And why would you know that a CSV RR published in the e.g. Uni-Bielefeld.DE
>zone would apply to anything in TechFak.Uni-Bielefeld.DE or Biologie.
>Uni-Bielefeld.DE or anywhere else, regardless of any zone cuts in between?

Gee, we had this argument, too.  It's because subzones of
Uni-Bielefeld.DE are delegated from Uni-Bielefeld.DE, of course, and
are completely at the mercy of the operator of the higher level zone
already.  There seem to be a lot of subzone operators who wish this
weren't true, but if you want to constrain the behavior of the zones
that delegate to you, you have to do it administratively, not within
the DNS.  And for the third time, zone cuts aren't relevant to this
design.

>> We should add a stop rule saying that you don't walk above the first or
>> second level of the DNS tree to limit the number of visits to the roots,
>
>Or to "co.TLD", for example? (Anyone propose TLD based exception or rules
>lists (UK:2, DE:1, MUSEUM:0)?)

Yes, we're aware that the delegation rules are at many different
levels.  In CA it can be 1, 2, or 3, in US it can be 1, 3, or 4.  As I
said, this is to limit the load on the roots, not to attempt to intuit
zone structure.

>Ex falso quodlibet. Following draft-iab-dns-choices-00 and what
>you've described a dedicated RR type (your overloading of the SRV
>seems almost no better or worse than using a TXT to me) is the
>preferred choice.

The major advantage of SRV, as I said in my previous message, is that
all SRV records have name prefixes so you don't get the name and
semantics overloading problems you do with TXT, even if you use the
fields in the SRV to mean something new.  A smaller but I think still
meaningful advantage is that we don't require clients to do parsing
and type conversion like SPF does.  The most complicated operation you
need to interpret CSV data is bit masking on a numeric field.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:13 2006
From: Pekka Savola <pekkas@netcore.fi>
Subject: Re: Faux wildcards
Date: Sun, 16 Jan 2005 08:03:03 +0200 (EET)
Lines: 51
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: DNS whizzes <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 07:16:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: John R Levine <johnl@iecc.com>
In-Reply-To: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Sun, 15 Jan 2005, John R Levine wrote:
> I've been working on CSV, a simple scheme for HELO/EHLO authentication
> with Dave Crocker and some other people.  By far the knottiest question
> we've been wresting with is if and how to do wildcard-like things.
>
> For CSV we're using repurposed SRV records.  They have the fields we need,
> they're widely supported by DNS software, including software written in
> the Seattle suburbs, and the name prefixes that all SRV records have avoid
> collisions.
[...]

If you want to do wildcard-like thing, maybe wildcards is the answer, 
but not necessarily in the place you were thinking of using them..

I don't think this answers your actual question, but people have 
deployed a mechanism where information is stored in the reverse DNS; 
you'd create explicit records for the valid IP addresses of mail 
servers, and use wildcards to cover the rest with "don't accept mail 
from here" records.

And if the record for mail servers was actually specified to be a 
pointer to the forward DNS, that could also provide a means to give 
information what the EHLO string should be, e.g.,

*.3.4.in-addr.arpa. MAIL-EHLO [some encoding to say "nope."] 
1.2.3.4.in-addr.arpa. MAIL-EHLO good.example.com.

then if you wanted to "verify" (though I'm not sure what this would 
actually verify..), you could do a second lookup for:

_client._smtp.good.example.com. which would have to point at 4.3.2.1

This avoids having to walk down or up the tree. Take a look at: 
draft-durand-naptr-service-discovery-00.txt

I don't quite understand why you'd want to look up EHLO string, 
instead of getting the information from the IP address; an attacker 
can make EHLO arbitrary and make all kinds of attacks, but IP address 
has a fixed format is hopefully (in this kind of TCP session) 
difficult to spoof.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: Faux wildcards
Date: 16 Jan 2005 01:28:04 -0500
Lines: 38
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
 <Pine.LNX.4.61.0501160749360.28480@netcore.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: "DNS whizzes" <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 07:35:11 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Pekka Savola" <pekkas@netcore.fi>
In-Reply-To: <Pine.LNX.4.61.0501160749360.28480@netcore.fi>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> I don't think this answers your actual question, but people have
> deployed a mechanism where information is stored in the reverse DNS;
> you'd create explicit records for the valid IP addresses of mail
> servers, and use wildcards to cover the rest with "don't accept mail
> from here" records.

That's MTA MARK.  I've seen the spec, but I don't know of anyone who uses
it.  It's an OK design, except of course that it suffers from the usual
problem that wildcards don't do what you want them to.  In this case
wildcards are useless since any name with a PTR RR, which should be all of
them, won't be covered by a wildcard.  I've seen variant versions that
stick in extra levels of name to move the mark records into a separate
sub-namespace, but I think the deployment issues (see below) make that
doubly impractical.

> I don't quite understand why you'd want to look up EHLO string,
> instead of getting the information from the IP address;

Because rDNS is a mess.  There are enough situations where the people in
charge of the rDNS for a chunk of IP space don't talk to the people using
that space that I don't know anyone who thinks it's practical to put
anything other than PTR records in rDNS space.  We deliberately decided to
key CSV from the HELO name rather than IP because it's much more
reasonable assume that someone sending mail for example.com controls the
DNS for example.com than that they control the rDNS for their servers.

You don't have to tell me that's not how it should be, but that's how it
is.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:13 2006
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: RE: Faux wildcards
Date: Sun, 16 Jan 2005 09:47:17 -0800
Lines: 114
Mime-Version: 1.0
Content-Type: text/plain
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 18:59:55 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "'Peter Koch'" <pk@TechFak.Uni-Bielefeld.DE>,
        DNSEXT WG
	 <namedroppers@ops.ietf.org>
X-Mailer: Internet Mail Service (5.5.2657.72)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

 
> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Peter Koch

> "John R Levine" <johnl@iecc.com> wrote:
> 
> > For CSV we're using repurposed SRV records.  They have the 
> fields we 
> > need,
> 
> you're not really *using* SRVs in what was 
> draft-ietf-marid-csv-csa-01.txt, they are just used as 
> containers for your data with e.g. the weight field redifined 
> or 'overloaded'.

John is using the SRV syntax and overlaying his own semantics by means of a
prefix.

It's a perfectly reasonable architectural approach. 


> > useful.  One is forgery.  I have domains that contain no 
> MTAs, and it
> 
> Same problem hare as with the recent SPF thread: RRsets are 
> associated with domain names, not with what is perceived as 
> 'a domain', i.e. everything down the tree starting usually at 
> the second level. For the latter you'd need wildcards (still 
> with a conceptual difference).

Actually the wildcards do absolutely nothing to solve any of the maintenance
issues that John is concerned with, not one.

The problem is that a wildcard only matches a node that DOES NOT EXIST AT
ALL. The only use for a DNS wildcard in the context of spam is to say THIS
NODE DOES NOT EXIST AT ALL from which the only reasonable assumption would
be DO NOT ACCEPT EMAIL FROM THIS NODE.

What John really needs to address his admin issues is a DNS server macro.
People who need that feature can unilaterally upgrade their DNS server to
one that supports the feature needed. Nobody else need be affected.

In fact I don't even need to do that, I just put a preprocessor in front of
BIND.


> > HELO's as <anything>.services.net is lying.  The other is what I
> 
> How about the absence of the RR as an indicator?

What we need is an RR that can stand for THIS NODE DOES NOT EXIST, then all
the policy extensions that are going to be added to the DNS in the next
couple of years can make use of the same record.

Perhaps we could call it the NXT record :-)

Actually the semantics we actually need are slightly different since some
people want to be able to pretend that *.example.com really does exist when
it does not. 

__*.example.com 				Node to hang the policies
off
_client._smtp.__*.example.com		A policy within the node


> > adoption if they could say in one place that all of their 
> authorized 
> > mai client hosts have explicit records and the rest are no good.
> 
> But that's not how the DNS works. Why would one willing to 
> adopt CSV or anything similar not be able or willing to add 
> the necessary RRs below the zone apex?

What John is trying to do is to make it easier to administer a zone. It is a
reasonable feature to put in a DNS server, it is a feature that should be in
a DNS server. It is not a feature that belongs in a protocol.

The DNS configuration file need not be the same as the zone transfer file. 

> As I said in an earlier message, the _whois._tcp thing also 
> walks the tree, but that's something completely different 
> because it follows the DNS hierarchy and does not imply or 
> deduce any (policy) information further up or down the tree.
> 
> > 	_client._smtp.EXAMPLE.COM
> > 	_client._smtp.COM
> > 	_client._smtp.
> 
> Again, RFC 1535 says "don't".

This seems a reasonable recommendation to me. 


> Ex falso quodlibet. Following draft-iab-dns-choices-00 and 
> what you've described a dedicated RR type (your overloading 
> of the SRV seems almost no better or worse than using a TXT 
> to me) is the preferred choice.

The IAB draft is a ridiculous polemic which does not consider the prefix
architecture fairly. It should not progress as a standard, it is yet another
example of a group of IETF insiders using their incumbency to promote their
own pet projects to the exclusion of other equally sound architectural
views.

The prefix architecture works exactly as well as a new RR deployment and
does not depend on any DNS infrastructure changes being deployed.

That is what I will be using.


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: RE: Faux wildcards
Date: Sun, 16 Jan 2005 09:54:35 -0800
Lines: 33
Mime-Version: 1.0
Content-Type: text/plain
Cc: pk@TechFak.Uni-Bielefeld.DE
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 19:02:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "'John Levine'" <johnl@iecc.com>, namedroppers@ops.ietf.org
X-Mailer: Internet Mail Service (5.5.2657.72)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of John Levine
> Gee, we had this argument, too.  It's because subzones of 
> Uni-Bielefeld.DE are delegated from Uni-Bielefeld.DE, of 
> course, and are completely at the mercy of the operator of 
> the higher level zone already.  There seem to be a lot of 
> subzone operators who wish this weren't true, but if you want 
> to constrain the behavior of the zones that delegate to you, 
> you have to do it administratively, not within the DNS.  And 
> for the third time, zone cuts aren't relevant to this design.

Here I think there is a problem. This type of argument can come unstuck
really baddly, it is close to 'as secure as' which is how http passwords got
spec'd to be sent en-clair and how WEP became a disaster etc.

I think that the problem you will find here is not so much a deliberate
attack but accidental treading on su-admin zones. 

For example MIT has a network group that manages *.mit.edu, but the LCS and
AI labs have traditionally managed *.ai.mit.edu and *.lcs.mit.edu (now
*.csail.mit.edu) independently. 

What your proposal does is to change the balance of power between the apex
operator and the subzone operator. There is no process in place to make sure
that changes at the apex do not inadvertently tread on configuration at the
leaves.

The same thing will turn up all over the place. It's a really bad plan.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: Faux wildcards
Date: Sun, 16 Jan 2005 12:00:01 -0600
Lines: 74
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 19:07:57 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 67
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:a7CJmq44i6wO0gySkYQCJaGOV2g=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com> "John R Levine" <johnl@iecc.com> writes:

> I've been working on CSV, a simple scheme for HELO/EHLO authentication
> with Dave Crocker and some other people.  By far the knottiest question
> we've been wresting with is if and how to do wildcard-like things.

Disclamer:

SPF and CSV are (arguably) competing proposals.  Both are designed to
help reduce abuses in email.  Both cover, in part, the HELO domain.
SPF abuses the TXT RR, CSV abuses the SRV RR.  CSV requires fewer DNS
lookups, SPF has *far* more deployment.  Both run into similar
problems.

For the purposes of namedroppers, I think it would be best to avoid
any discussions about which is "better" and to discount comments from
backers of one proposal that disparage the other.  (I'm an SPFer.)


> GOOD.EXAMPLE.COM, the server looks up
>
> 	_client._smtp.GOOD.EXAMPLE.COM
>
> and if it finds it, [...]
>
> But if the SRV record doesn't exist, then what?


This gets back to what I posted yesterday:

| The real-world problem that we are trying to solve is:
| 
|     Domain owners want to have a voice in how the domain name that
|     they have bought gets used.  Others would like to hear what the
|     domain owners have to say. The particular case we are dealing with
|     is email in conjunction with SPF, but there are other cases too.

Ok, John is talking about email in conjunction with CSV, but there are
also many other similar cases in conjunction with email.  For example
Yahoo's DomainKey's proposal and the Identified Internet Mail (IIM)
proposal both could really use similar functionality.  It would be
nice if there was a way of saying "all email from my domain is S/MIME
(or PGP) signed, and here is the cert".

For non-email items, things like the RP RR would be *far* more useful
if it could be wildcarded to the entire domain/zone.


> [snip]

Most of the rest of John's post follows *very* similar discussions in
the SPF community, only we weighed the costs slightly differently, and
came to the conclusion that finding the zone cut was slightly less
ugly than a tree walk.  I can't speak for the
CSV/DK/IIM/etc. communities, but I think the SPF community would jump
at a better solution than either zone cuts or tree walks to solve this
problem.

The pressure for a solution to the this real-world problem is huge,
especially in the anti-phishing community where.  For example,
citibank, ebay and earthlink all want to be able to assert claims over
all of *.citibank.com, *.ebay.com and *.earthlink.com, not just the
points that exist.


-wayne



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: Faux wildcards
Date: Sun, 16 Jan 2005 12:11:38 -0600
Lines: 36
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com> <Pine.LNX.4.61.0501160749360.28480@netcore.fi>
 <Pine.BSI.4.56.0501160113450.26048@tom.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 19:16:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 29
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:5BMyvU8CaU9fJMnJjljOYhfx6W8=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <Pine.BSI.4.56.0501160113450.26048@tom.iecc.com> "John R Levine" <johnl@iecc.com> writes:

>> I don't quite understand why you'd want to look up EHLO string,
>> instead of getting the information from the IP address;
>
> Because rDNS is a mess.  There are enough situations where the people in
> charge of the rDNS for a chunk of IP space don't talk to the people using
> that space that I don't know anyone who thinks it's practical to put
> anything other than PTR records in rDNS space.  We deliberately decided to
> key CSV from the HELO name rather than IP because it's much more
> reasonable assume that someone sending mail for example.com controls the
> DNS for example.com than that they control the rDNS for their servers.

I'll add two more reasons for not using the IP address and using a
domain name instead.

First, the folks running the in-addr tree have said "DON'T!  We can't
deal with the extra traffic."

Secondly, the domain names show up in email headers, such as the
Received: header.  Experience has shown that there is a very large
number of people who know enough to get their mail agents to show the
headers, and yet can not actually read and detect forgeries in them.
As a result, just having your domain name show up near the top of the
Received: headers can result in a lot of people incorrectly assuming
your domain is somehow responsible.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: Faux wildcards
Date: Sun, 16 Jan 2005 12:41:38 -0600
Lines: 39
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 19:46:24 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Injected-Via-Gmane: http://gmane.org/
To: namedroppers@ops.ietf.org
Lines: 32
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Cancel-Lock: sha1:DPl7EADqp7wHGD0xiGPD6g1f+5Q=
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com> "Hallam-Baker, Phillip" <pbaker@verisign.com> writes:

> Actually the wildcards do absolutely nothing to solve any of the maintenance
> issues that John is concerned with, not one.
>
> The problem is that a wildcard only matches a node that DOES NOT EXIST AT
> ALL. The only use for a DNS wildcard in the context of spam is to say THIS
> NODE DOES NOT EXIST AT ALL from which the only reasonable assumption would
> be DO NOT ACCEPT EMAIL FROM THIS NODE.

If you do not accept email from nodes that don't exist, then you will
be throwing out a lot of legitimate email.  Far too much email gets
sent using HELO domains with either domain names that are only
viewable inernally, are typos, or are due to misconfigurations for
most people to take this stand.  Spammers and phishers have taken
advantage of this situation.


> What John is trying to do is to make it easier to administer a zone. It is a
> reasonable feature to put in a DNS server, it is a feature that should be in
> a DNS server. It is not a feature that belongs in a protocol.
>
> The DNS configuration file need not be the same as the zone transfer file. 

In theory, this is very true.  In practice, it has problems.  Such
features do not exist in name server software, requiring everyone to
create local modifications.  Also, if every host in your zone file
needs to have an SPF, CSV, DK, RP, etc. record added to it, you are
going to greatly increase the size of the zones.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: RE: Faux wildcards
Date: Sun, 16 Jan 2005 11:30:23 -0800
Lines: 38
Mime-Version: 1.0
Content-Type: text/plain
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 20:36:46 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "'wayne'" <wayne@schlitt.net>, namedroppers@ops.ietf.org
X-Mailer: Internet Mail Service (5.5.2657.72)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of wayne

> First, the folks running the in-addr tree have said "DON'T!  
> We can't deal with the extra traffic."

That is not a reason. If there is purpose to use of an infrastructure then
we should fix the infrastructure. SPF will increase the load on core DNS
significantly, that means real cost to DNS infrastructure operators but I
have not hear any complaints from there.

I mind a lot when I am being asked to spend real money and use real
electricity to no purpose at all, if it is going to be used and there is a
reason there is no problem.

> Secondly, the domain names show up in email headers, such as the
> Received: header.  Experience has shown that there is a very 
> large number of people who know enough to get their mail 
> agents to show the headers, and yet can not actually read and 
> detect forgeries in them. As a result, just having your 
> domain name show up near the top of the
> Received: headers can result in a lot of people incorrectly 
> assuming your domain is somehow responsible.

This is a much better reason. The admin of the reverse DNS is not great,
that can be improved but the admin zones are never going to match very well.

Reverse DNS is used to mean 'I am responsible for this IP address'. It is a
really good infrastructure for handing off services like INCH/RID. It is not
suitable for application level.

	Phill

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: RE: Faux wildcards
Date: Sun, 16 Jan 2005 11:40:59 -0800
Lines: 67
Mime-Version: 1.0
Content-Type: text/plain
X-From: owner-namedroppers@ops.ietf.org Sun Jan 16 20:45:35 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "'wayne'" <wayne@schlitt.net>, namedroppers@ops.ietf.org
X-Mailer: Internet Mail Service (5.5.2657.72)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


> From: owner-namedroppers@ops.ietf.org 
> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of wayne

> In 
> <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad
> .vrsn.com> "Hallam-Baker, Phillip" <pbaker@verisign.com> writes:
> 
> > Actually the wildcards do absolutely nothing to solve any of the 
> > maintenance issues that John is concerned with, not one.
> >
> > The problem is that a wildcard only matches a node that 
> DOES NOT EXIST 
> > AT ALL. The only use for a DNS wildcard in the context of 
> spam is to 
> > say THIS NODE DOES NOT EXIST AT ALL from which the only reasonable 
> > assumption would be DO NOT ACCEPT EMAIL FROM THIS NODE.
> 
> If you do not accept email from nodes that don't exist, then 
> you will be throwing out a lot of legitimate email.  Far too 
> much email gets sent using HELO domains with either domain 
> names that are only viewable inernally, are typos, or are due 
> to misconfigurations for most people to take this stand.  
> Spammers and phishers have taken advantage of this situation.

In which case what you really want is something like the following, a
wildcard that defaults the lookup of the entire subtree to some existing
node then a set of policy records tied off that node. Ie.

*.example.com ---> default.example.com
exists.example.com  A blahhh
_prefix.default.example.com  TXT "Default policy record"

OK so we when we do the lookup for the node that exists we hit a record that
exists, find that there is no stated policy for that node.

If we look up anything else we hit the mapping record and get directed to
default. 

Just think of it as a wildcard SOA :-)


> 
> In theory, this is very true.  In practice, it has problems.  
> Such features do not exist in name server software, requiring 
> everyone to create local modifications.  Also, if every host 
> in your zone file needs to have an SPF, CSV, DK, RP, etc. 
> record added to it, you are going to greatly increase the 
> size of the zones.

These people said that there was no problem at all causing the .com zone
file to expand by about 10Gb. That was not a deployment problem that needed
to be considered so I don't think that 10,000 nodes times a few Kb is a show
stopper.

Companies such as AOL who have millions of records will simply use a DNS
server that can synthesize records on the fly if they have that much
difficulty. They probably already do something of this sort anyway.

The macro preprocessor thingie is only for folk who have smallish zone
files.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Danny Mayer <mayer@gis.net>
Subject: Re: Faux wildcards
Date: Sun, 16 Jan 2005 22:30:26 -0500
Lines: 33
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
 <Pine.LNX.4.61.0501160749360.28480@netcore.fi>
 <Pine.BSI.4.56.0501160113450.26048@tom.iecc.com> <x4651xdz1h.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 04:41:52 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
To: wayne <wayne@schlitt.net>,namedroppers@ops.ietf.org
In-Reply-To: <x4651xdz1h.fsf@footbone.schlitt.net>
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
 <Pine.LNX.4.61.0501160749360.28480@netcore.fi>
 <Pine.BSI.4.56.0501160113450.26048@tom.iecc.com>
X-Rcpt-To: <namedroppers@ops.ietf.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 01:11 PM 1/16/2005, wayne wrote:
>I'll add two more reasons for not using the IP address and using a
>domain name instead.
>
>First, the folks running the in-addr tree have said "DON'T!  We can't
>deal with the extra traffic."

If the in-addr tree folks can't handle the traffic now they need additional
resources. If this is so important to citibank, ebay, etc. they can easily
afford to shell out some money to help out the in-addr tree folks with
additional infrastructure.  The root operators are doing it, it's just
another branch of the tree.

>Secondly, the domain names show up in email headers, such as the
>Received: header.  Experience has shown that there is a very large
>number of people who know enough to get their mail agents to show the
>headers, and yet can not actually read and detect forgeries in them.
>As a result, just having your domain name show up near the top of the
>Received: headers can result in a lot of people incorrectly assuming
>your domain is somehow responsible.

I have no idea what that means and why you think that not using the IP
address solves this. If the mail gets sent, whatever is there is still there
unless you are thinking of rewriting the headers along with way.

Danny


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Danny Mayer <mayer@gis.net>
Subject: Re: Faux wildcards
Date: Sun, 16 Jan 2005 22:33:36 -0500
Lines: 19
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com> <x41xcldxnh.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 04:41:53 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
To: wayne <wayne@schlitt.net>,namedroppers@ops.ietf.org
In-Reply-To: <x41xcldxnh.fsf@footbone.schlitt.net>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com>
X-Rcpt-To: <namedroppers@ops.ietf.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 01:41 PM 1/16/2005, wayne wrote:
>If you do not accept email from nodes that don't exist, then you will
>be throwing out a lot of legitimate email.  Far too much email gets
>sent using HELO domains with either domain names that are only
>viewable inernally, are typos, or are due to misconfigurations for
>most people to take this stand.  Spammers and phishers have taken
>advantage of this situation.

All the more reason for enforcing the rules by refusing invalid names.
People will quickly fix the problem if it's preventing mail getting through.

Danny


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: John Levine <johnl@iecc.com>
Subject: Re: Faux wildcards
Date: 17 Jan 2005 04:37:31 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 19
References: <4.3.1.2.20050116223150.026a7e68@pop.gis.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: mayer@gis.net
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 05:42:10 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <4.3.1.2.20050116223150.026a7e68@pop.gis.net>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>>be throwing out a lot of legitimate email.  Far too much email gets
>>sent using HELO domains with either domain names that are only
>>viewable inernally, are typos, or are due to misconfigurations for
>>most people to take this stand.

>All the more reason for enforcing the rules by refusing invalid names.
>People will quickly fix the problem if it's preventing mail getting through.

See if you can get Hotmail to fix their HELO's.  Once they do it,
then we can get everyone else to fall into line.

R's,
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:46:13 2006
From: John Levine <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 17 Jan 2005 04:36:13 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 54
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: pbaker@verisign.com
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 05:42:11 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>What John really needs to address his admin issues is a DNS server macro.
>People who need that feature can unilaterally upgrade their DNS server to
>one that supports the feature needed. Nobody else need be affected.

Yes indeed.  If I could tell my server to serve this record for any
request that matches _client.smtp.*.example.com I'd be a happy camper,
and CSV clients could just make the one obvious query and be done.
And if it were just me, I'd do it.  I've written funky servers before;
caches and resolvers are hard, but servers turn out to be surprisingly
easy.  (There's a reason that tinydns is called tinydns.)

>In fact I don't even need to do that, I just put a preprocessor in
>front of BIND.

Are you sure?  Offhand I can't think of any way to fake a.*.b in a BIND
zone other than a terabyte of all possble bit patterns.

>The prefix architecture works exactly as well as a new RR deployment
>and does not depend on any DNS infrastructure changes being deployed.

Well, it works a lot better if your servers can match a.*.b.  But you're
right that the clients will work just fine.

The wildcard theory is that if you deploy new RR types, you don't need
prefixes, so wildcards work.  As Phill and I agree (wow, alert the
media) actually, they don't, since any RR at a node keeps wildcards
from matching, even queries for other RR types.  So, for example, in
my case where I want to mark a big farm of hosts all as not valid,
even if I had a shiny new RR type, I still couldn't use a wildcard
because the A records for those hosts would keep the wildcard from
matching any of them.

Given how many people misunderstand this point, including a couple of
IETF greybeards I talked to at IETF 61, I think we can make a rather
strong argument that this aspect of wildcards is just wrong.  But if
we're going to change the way that wildcards work, I'd rather make big
changes to make them really useful.

Since wildcards are invisible to DNS clients, the only place the current
definition matters is in AXFR data between servers, and in the code in
the server that matches them.  Should we be saying that if you want to
deploy SPF or CSV or DK or IIM or any other anti-spam scheme that needs
to be able to say "anything else is bogus" you'll need a better server
than BIND?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:13 2006
From: wayne <wayne@schlitt.net>
Subject: Re: Faux wildcards
Date: Sun, 16 Jan 2005 23:09:26 -0600
Lines: 81
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com>
	<4.3.1.2.20050116223150.026a7e68@pop.gis.net>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 06:14:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <4.3.1.2.20050116223150.026a7e68@pop.gis.net> (Danny Mayer's
 message of "Sun, 16 Jan 2005 22:33:36 -0500")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <4.3.1.2.20050116223150.026a7e68@pop.gis.net> Danny Mayer <mayer@gis.net> writes:

> At 01:41 PM 1/16/2005, wayne wrote:
>>If you do not accept email from nodes that don't exist, then you will
>>be throwing out a lot of legitimate email.  Far too much email gets
>>sent using HELO domains with either domain names that are only
>>viewable inernally, are typos, or are due to misconfigurations for
>>most people to take this stand.  Spammers and phishers have taken
>>advantage of this situation.
>
> All the more reason for enforcing the rules by refusing invalid names.
> People will quickly fix the problem if it's preventing mail getting through.

Three comments:

1) This mailing list is about DNS, not about email or spam.  My
   comment was in relation to the need for a different form of DNS
   wildcards, but this is quickly drifting off topic.

2) It is wildly recognized in the email/anti-spam community that
   people have a very wide range of tolerances for false positives
   (legitimate email being falsely rejected), and false negatives
   (spam that gets through).

   What I stated was a recognition of this and, since there are no
   protocol police, trying to change how the world works is hard.  If
   you think it is worth your while to try change this, you might try
   starting with changing the IETF.

3) Let's look at the Received: headers from Danny's email:

      [Received: headers coming from the list deleted]
   
      Received: from [208.218.130.12] (helo=gis.net)
      	by psg.com with esmtp (Exim 4.43 (FreeBSD))
      	id 1CqNeH-0005VP-MC
      	for namedroppers@ops.ietf.org; Mon, 17 Jan 2005 03:33:49 +0000

   Note that Danny's MTA gave a HELO of gis.net, which doesn't have the
   IP address of 208.218.130.12.

      Received: from tecotoo.localhost ([207.7.195.195]) by
                mx04.gis.net; Sun, 16 Jan 2005 22:33:48 -0500

   Note that tecotoo.localhost is not a valid domain.

   Note that 207.7.195.195 does not have a valid rDNS PTR.

      Received: from tecotoo (tecotoo [127.0.0.1]) by
                tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP
                id va000983 for <namedroppers@ops.ietf.org>;
                Sun, 16 Jan 2005 22:33:41 +0000
   
   Note that tecotoo is not a valid domain.


   It is a good thing that Danny's MTAs don't practice what Danny
   preaches, otherwise we would never had heard from Danny.  But hey,
   don't feel too bad.  I once went and checked the quality of HELO
   domains given by people on the IETF MARID WG, a group chartered to
   find solutions to email-forgery/spam/phishing problems, and the
   results were pretty bad.[1]



-wayne

[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg03102.html
    Note that that the comments involve very heavy sarcasm, much of
    which will not be recognized if you aren't very involved in email
    and the MARID WG.  Also note that since that post, I changed from
    my midwestcs.com domain to my schlitt.net domain.  Also, by
    "invalid HELO domain", I did not limit myself to just domains that
    returned NXDOMAIN.


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Sun, 16 Jan 2005 21:29:51 -0800 (PST)
Lines: 85
References: <20050117043613.9948.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org, <pbaker@verisign.com>
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 06:30:44 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050117043613.9948.qmail@xuxa.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On 17 Jan 2005, John Levine wrote:

> >What John really needs to address his admin issues is a DNS server macro.
> >People who need that feature can unilaterally upgrade their DNS server to
> >one that supports the feature needed. Nobody else need be affected.
> 
> Yes indeed.  If I could tell my server to serve this record for any
> request that matches _client.smtp.*.example.com I'd be a happy camper,

That is pretty much what I'm trying to propose, new wildcard that supports
prefixes and answers when host exist and not only when it does not, for
what you want you would add "_client.smtp.**" in the zone file. 

However as Paul Vixie said couple times already, we can go ahead and propose
it, have the draft discussed at namedroppers, etc. But it will take several
years for it to become a standard and to have been implemented in majority
of dns servers and people to have installed new versions of the software. 
So for immediate needs of SPF or CSV domain administrators, this would not 
exactly work.

What I had been trying to push for is to supplement it with simple algorithm
that would allow client to look for exactly same wildcard. This does mean 
additional dns lookup, but clients will not be doing lookups any more 
when dns servers are updated and can sythesize the response (and end-user 
does not even need to know about it - he just enters this new wildcard 
record and it works, either with server that understands it or if not 
with client that looks for it).

This has primarily been discussed at SPF-discuss last week and I think people
there agree that its reasonable compromise (doing both as DNS extension 
for new wildcard and directly looking for it at zonecut). And regarding 
zonecut as mentioned I checked top 10 dns servers and they all provide 
"hint" of where zonecut is in the form of SOA in the AUTHORITY section.

There is also no big deal if this hint and wildcard is not availble to 
every user, we just want it available for greater majority so that there
is not much cause for bad guys to try to abuse it and and seeing as the 
numbers would be something like 95% of users would see it (the only case I
could find is the one you wrote about with djb caching dns servers that do 
not show the AUTHORITY when serving record from cache), I think we're fine.

And as this is very simple algorithm that avoids having to "search" for
zonecut - if hint is avalable, then use it, if not not don't bother. The 
good thing about it is that at most 1 extra dns lookup is done and no 
"tree walking" (which is bad as it could result in arbitrary large number 
of dns requests) as what had proposed by CLEAR group (ietf-clear is where 
CSV is discussed).

As far as draft of all the above with introduction of new wildcard - people
at namedroppers can expect one probably by Paris meeting.

> The wildcard theory is that if you deploy new RR types, you don't need
> prefixes, so wildcards work.  As Phill and I agree (wow, alert the
> media) actually, they don't, since any RR at a node keeps wildcards
> from matching, even queries for other RR types.  So, for example, in
> my case where I want to mark a big farm of hosts all as not valid,
> even if I had a shiny new RR type, I still couldn't use a wildcard
> because the A records for those hosts would keep the wildcard from
> matching any of them.

I think its not just you and Phil but me and all others in former MARID 
also agree that current wildcards are of no use to us exactly because
of above.

> Given how many people misunderstand this point, including a couple of
> IETF greybeards I talked to at IETF 61, I think we can make a rather
> strong argument that this aspect of wildcards is just wrong.  But if
> we're going to change the way that wildcards work, I'd rather make big
> changes to make them really useful.

We should not make changes to existing wildcards - people are expecting
results they do now. They only way is to actually introduce new wildcard.
 
-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:13 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Faux wildcards
Date: Mon, 17 Jan 2005 06:28:35 +0000
Lines: 59
References: <johnl@iecc.com>
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 07:34:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from John Levine <johnl@iecc.com> 
	of "17 Jan 2005 04:37:31 GMT."
	<20050117043731.10504.qmail@xuxa.iecc.com> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > > be throwing out a lot of legitimate email.  Far too much email
> > > gets sent using HELO domains with either domain names that are
> > > only viewable inernally, are typos, or are due to
> > > misconfigurations for most people to take this stand.

speaking as someone whose postfix config rejects such mail, i can tell
you that a lot of folks have pointed out that RFC 2821 allows bad HELO
behaviour and that my servers are technically noncompliant.  i agree,
and i usually just provide my fax number along with my apologies for
any inconvenience.

> > All the more reason for enforcing the rules by refusing invalid
> > names.  People will quickly fix the problem if it's preventing mail
> > getting through.
> 
> See if you can get Hotmail to fix their HELO's.  Once they do it,
> then we can get everyone else to fall into line.

it's 2005.  anyone who does something a spammer typically does will
look somewhat like a spammer, and be treated often as a spammer, no
matter what RFC 2821 allows.  in 1995 we could bask in the warmth of
"the spec".  in 2005, every sender has to revise their view of "what
kind of traffic is actually going to get through."

people on hotmail, yahoo, or any dsl or dynamic ip range can't send
me e-mail.  that's not going to change.  i am really quite glad that
i don't have a business requirement to accept such e-mail, and i am
really quite surprised that others who also lack such requirements
still accept such e-mail.  "walks like a duck, quacks like a duck,
BLAM, it's duck soup."

but i digress.  we were talking about dns?  i already pointed out in
private e-mail to dcrocker and jlevine (a while ago) that CSV was a
fine looking proposal and might be a reasonable direction forward,
BUT that the field wasn't level and the selection wouldn't be made on
the basis of technical merit.  ("or else we'd have MAIL-FROM by now.")
SPF has no technical merit that makes it compelling in any way -- it
was born in ignorance and has been muddied by subsequent bandaids.
BUT the marketing was powerful and so there is an installed base and
so SPF actually matters, but not because it's better, or even good,
or even "good enough".  microsoft and yahoo finally realized this,
and are going to use powerful marketing rather than technical arguments
to advance "senderid" and "domainkeys" respectively.  let a thousand
flowers bloom, etc.  SPF will compete on its own terms, which aren't
and never were "technical merit".  why on earth is anybody discussing
SPF's merits as if SPF weren't just a marketing driven juggernaut?
if SPF didn't have an installed base we wouldn't be talking about it
at all, and yet a number of folks here are falling into the trap of
talking about how SPF should best be expanded.  i've recommended that
the authors document SPF as it is, and let expansion come later.  this
is because the installed base deserves an RFC to look at.  whether
expansion comes in the form of rr-specific wildcards, or switching
to domainkeys, is something for others to look at, probably elsewhere.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Mon, 17 Jan 2005 14:18:11 +0700
Lines: 55
References: <20050117043613.9948.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org, pbaker@verisign.com
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 08:23:34 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050117043613.9948.qmail@xuxa.iecc.com> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        17 Jan 2005 04:36:13 -0000
    From:        John Levine <johnl@iecc.com>
    Message-ID:  <20050117043613.9948.qmail@xuxa.iecc.com>

  | Are you sure?  Offhand I can't think of any way to fake a.*.b in a BIND
  | zone other than a terabyte of all possble bit patterns.

Why would you ever need to do that?

  | The wildcard theory is that if you deploy new RR types, you don't need
  | prefixes, so wildcards work.  As Phill and I agree (wow, alert the
  | media) actually, they don't, since any RR at a node keeps wildcards
  | from matching, even queries for other RR types.  So, for example, in
  | my case where I want to mark a big farm of hosts all as not valid,
  | even if I had a shiny new RR type, I still couldn't use a wildcard
  | because the A records for those hosts would keep the wildcard from
  | matching any of them.

Yes.   But if you know the names, you don't need wildcards, there the
macro pre-processor can generate the new records for you (it knows exactly
which names it needs to handle, after all).   It is only where you want to
(or need to) match names that you don't know in advance that you need
wildcards, and there wildcards work.

I have no idea why you believe you need _client._smtp.*.example.com to
hang a record off, just hang it from *.example.com - if someone queries
for _client._smtp.bogus.example.com (for the appropriate RR type) the
wildcard will cause the RR that you hung from *.example.com to be
returned.

If someone asks for _server._telnet.bogus.example.com they'll get the
same data, but why would you care?

That is, unless of course, the whole proposal is crazy, and is abusing an
existing RR type for a whole bunch of different purposes, and relying upon
the different prefix to get you just the precise one that you want.  Then
you'd have trouble, but no-one would stoop to that kind of thing, would they?

  | Given how many people misunderstand this point, including a couple of
  | IETF greybeards I talked to at IETF 61, I think we can make a rather
  | strong argument that this aspect of wildcards is just wrong.

I disagree.  wildcards as defined are exactly what is required in the
DNS protocol (servers can do whatever they like wrt how extra records are
populated into zone files for names that are known - including dynamic 
creation, pro-processing of the zone file, ...).

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:46:14 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: Faux wildcards
Date: Mon, 17 Jan 2005 14:31:16 +0700
Lines: 62
References: <x4acr9dzku.fsf@footbone.schlitt.net>  <Pine.BSI.4.56.0501150110120.6851@tom.iecc.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 Jan 17 08:41:46 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: wayne <wayne@schlitt.net>
In-Reply-To: <x4acr9dzku.fsf@footbone.schlitt.net> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        Sun, 16 Jan 2005 12:00:01 -0600
    From:        wayne <wayne@schlitt.net>
    Message-ID:  <x4acr9dzku.fsf@footbone.schlitt.net>

  | The pressure for a solution to the this real-world problem is huge,

Of course.  And this is really the problem.

  | especially in the anti-phishing community where.  For example,
  | citibank, ebay and earthlink all want to be able to assert claims over
  | all of *.citibank.com, *.ebay.com and *.earthlink.com, not just the
  | points that exist.

And of course, they want the same kind of protection in other environments.

ebay is almost completely electronic (I believe) so it is hard to use as
an example, and I must confess my ignorance, I don't know what earthlink is.

But citibank is a great example.   Not only would they like to stop people
using *.citibank.com for unapproved purposes, they also want to stop people
setting up buildings on random street corners, with a sign saying "citibank"
and proceeding to accept deposits...   But do they do that by demanding that
the makers of paint generate paint that won't form into the word "citibank"
unless it has been passed through an approved citibank wharehouse?
Hardly - they don't use anything related to the technology of sign making
at all to get the protection they need.

Just the same way, they desire (I presume) to stop unauthorised persons from
sending letters saying "Your citibank credit card account is overdue, please
remit $37.18 to in the enclosed reply paid envelope within 7 days".  Do they
do that by having printers refuse to write the word "citibank" (or the logo)?
Or by having the post office only accept mail with a citibank (style) of
logo on the envelope if it is posted at a particular post office (and then
validate each message as it is posted).   Again, don't be absurd.

The problem here is that there is this immense pressure to have the
problem "fixed", and rather than being honest, and simply replying "we can't
reasonably fix that from where we are, look elsewhere", most of the
community is out there saying "sure, we're technologists, we can do anything"
and promising that a fix will be found.    And then, of course, because
we are technologists, and for that matter, network protocol workers, that's
the one tool that we have to manipulate - so that's what people (with all
of the best intentions in most cases) are out there doing - trying to use
the only tool at their disposal to fix a problem they've been told that
they have to fix.

The more responsible attitude however would simply be to say "no, sorry,
we cannot fix this problem, look elsewhere for a solution", because that's
really the truth.

kre

ps: now having typed all this, I realise that it is totallu inappropriate
for namedroppers, so I better make sure I find the "erase" button before
I accidentally push "send" and awa


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: Faux wildcards
Date: Mon, 17 Jan 2005 10:26:39 +0100
Organization: RIPE NCC
Lines: 26
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
	<Pine.LNX.4.61.0501160749360.28480@netcore.fi>
	<Pine.BSI.4.56.0501160113450.26048@tom.iecc.com>
	<x4651xdz1h.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 10:36:51 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: wayne <wayne@schlitt.net>
In-Reply-To: <x4651xdz1h.fsf@footbone.schlitt.net>
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.000171 / -5.9
X-RIPE-Signature: f8989414946d1a5a20009517b12442d1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


<chair-hat off>

On Sun, 16 Jan 2005 12:11:38 -0600
wayne <wayne@schlitt.net> wrote:

> 
>  First, the folks running the in-addr tree have said "DON'T!  We can't
>  deal with the extra traffic."


Interesting, I wonder who claimed that they run the in-addr tree?  I
wonder for which zones these folk run authoritative servers.


-- 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:46:14 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Fw: Approval to Post Version -00 Internet-Drafts for the 62nd IETF
 Meeting in Minneapolis, MN
Date: Mon, 17 Jan 2005 10:54:27 +0100
Organization: RIPE NCC
Lines: 63
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 11:05:17 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.030493 / -5.9
X-RIPE-Signature: bdb51a9500784bc728e207c8f42239a7
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk




Dear Colleagues,

In order to be able to make the deadline mentioned below the chairs
would like to receive the filename of planned WG drafts by Friday,
February 4.

We would also like to receive a copy of your source file. XML is
prefered at the time you update a WG-draft.

For details on the cutt-off date see:
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg00828.html


--Olaf



---------------------- Begin forwarded message ----------------------


Date: Fri, 14 Jan 2005 09:56:39 -0500
From: Internet-Drafts Administrator <internet-drafts@ietf.org>
To: Working Group Chairs <wgchairs@ietf.org>
Cc: 
Subject: Approval to Post Version -00 Internet-Drafts for the 62nd IETF Meeting in Minneapolis, MN 


Dear IETF Working Group Chairs:

In order to expedite the processing of the many version -00 I-Ds that 
the Secretariat  receives before an IETF meeting, we ask that you please 
notify the Secretariat prior to the initial submission cutoff date of all 
version -00 I-Ds that you expect to approve for posting as WG documents.  
Please send the filenames of your approved -00 I-Ds to internet-drafts@ietf.org 
by no later than five (5) business days prior to the cutoff date for -00 submissions, 
or by Monday, February 7th at 9:00 AM ET for the 62nd IETF Meeting. Please include 
the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure 
that version -00 I-Ds are posted in a timely manner, allowing more time for review 
by the public.

Thank you for your cooperation in this matter.

The Internet-Drafts Administrator




---------------------- End forwarded message ------------------------

-- 

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.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:46:14 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: rfc2538bis to working group document
Date: Mon, 17 Jan 2005 11:57:18 +0100
Organization: RIPE NCC
Lines: 27
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 12:12:51 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.000217 / -5.9
X-RIPE-Signature: 497b53a661612e354dd4c6b15a485098
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


Dear Colleagues,

Unless there are no objections by the end of this week Simon will post
draft-josefsson-rfc2538bis-01.txt asdraft-ietf-dnsext-rfc2538bis-00.txt, 
thereby making the document a working group document (as it is 
on our charter).

Shortly after the posting, and before the next meeting we will issue
a last call on this document.

Please review the document and send feedback to Simon and this list.

See http://josefsson.org/rfc2538bis/ for document history.

-- 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:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: Faux wildcards
Date: Mon, 17 Jan 2005 09:37:14 -0600
Lines: 49
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
	<Pine.LNX.4.61.0501160749360.28480@netcore.fi>
	<Pine.BSI.4.56.0501160113450.26048@tom.iecc.com>
	<x4651xdz1h.fsf@footbone.schlitt.net>
	<20050117102639.01d1170a.olaf@ripe.net>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 16:48:22 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <20050117102639.01d1170a.olaf@ripe.net> (Olaf M. Kolkman's
 message of "Mon, 17 Jan 2005 10:26:39 +0100")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <20050117102639.01d1170a.olaf@ripe.net> "Olaf M. Kolkman" <olaf@ripe.net> writes:

> <chair-hat off>
>
> On Sun, 16 Jan 2005 12:11:38 -0600
> wayne <wayne@schlitt.net> wrote:
>
>> 
>>  First, the folks running the in-addr tree have said "DON'T!  We can't
>>  deal with the extra traffic."
>
>
> Interesting, I wonder who claimed that they run the in-addr tree?  I
> wonder for which zones these folk run authoritative servers.


Short answer:  I was wrong.  Sorry for the confusion.  The rest of the
problems with dealing with only IP addresses remain.


Long answer:

I have never really been involved in any of the proposals that put
stuff in the in-addr tree and did not follow the discussions closely.
Either my memory is bad (probable) or I can't quickly find any quotes
to back up my memory.

I seem to recall several people at the IETF-59 MARID BoF expressing
concern about the DNS loads, in particular in the in-addr part of the
tree.  The video of the BoF is still around and I can dig through it
if people *really* care.

Easier quotes to find come from the MARID archive, such as:

http://www.imc.org/ietf-mxcomp/mail-archive/msg00135.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg02530.html

These posts express "concern", "wanting to be kept informed", "will
need time to upgrade", etc.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: RIR comment, was Re: Faux wildcards
Date: Mon, 17 Jan 2005 11:00:22 -0500
Lines: 26
References: <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com>
 <Pine.LNX.4.61.0501160749360.28480@netcore.fi>
 <Pine.BSI.4.56.0501160113450.26048@tom.iecc.com>
 <x4651xdz1h.fsf@footbone.schlitt.net>
 <20050117102639.01d1170a.olaf@ripe.net>
 <x43bx0cbit.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 17:04:45 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: edlewis@127.0.0.1
In-Reply-To: <x43bx0cbit.fsf@footbone.schlitt.net>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 9:37 -0600 1/17/05, wayne wrote:

>>>   First, the folks running the in-addr tree have said "DON'T!  We can't
>>>   deal with the extra traffic."

>http://www.imc.org/ietf-mxcomp/mail-archive/msg02530.html

Ack - I'd change the tone to "BEWARE!  We may have to scale."  The 
bigger issue is *voluntary* participation in the reverse map and 
lackadaisical maintenance of the delegated servers.  Policies would 
need to change, a non-technical problem, to solve that.

What ever happened to that 'reverse map is required' draftin DNSOP? 
;)  I ask quasi-rhetorically.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
Subject: Re: Faux wildcards
Date: Mon, 17 Jan 2005 22:09:30 +0100
Lines: 48
References: <20050116014706.15302.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Mon Jan 17 22:23:51 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol
To: namedroppers@ops.ietf.org
In-reply-to: Your message of "16 Jan 2005 01:47:06 GMT."
             <20050116014706.15302.qmail@xuxa.iecc.com> 
X-Organization: Uni Bielefeld, Technische Fakultaet
X-Phone: +49 521 106 2902
Content-ID: <17461.1105996169.1@zeder.TechFak.Uni-Bielefeld.DE>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

John Levine <johnl@iecc.com> wrote:

> Because the number of names can be enormous.  For many large ISPs it's
> in the hundreds of thousands.  For AOL it's in the millions.  Like I
> said, in theory it's possible, in practice it's a huge burden.

depending on the motivation, the perceived level of urgency and the
tools/clue available, it should still be doable. Large zones already exist
and anyone at the size of AOL (just quoting your example above) would be
able to cope with it, admittedly not for free.

> No, for SRV applications they don't work at all.  Names like
> _client._smtp.*.example.com don't match anything useful.

No, but *.example.com would. Combined with a dedicated, new, RR type, that
should serve your needs.

> Gee, we had this argument, too.  It's because subzones of
> Uni-Bielefeld.DE are delegated from Uni-Bielefeld.DE, of course, and
> are completely at the mercy of the operator of the higher level zone

No, they are not, that's why they are delegated their own zone. It may be
the case that in this case the principal of the University (or the
CEO/CTO of a company or ...) may demand a certain policy, but this is
out of the scope of the DNS and in particular you cannot assume this in
the general case.

> the DNS.  And for the third time, zone cuts aren't relevant to this
> design.

The zone cuts are definitely nothing the application and/or the querier
should worry about, but they are definitely relevant to the extent one
can control the namespace. That's why delegation exists.

> levels.  In CA it can be 1, 2, or 3, in US it can be 1, 3, or 4.  As I
> said, this is to limit the load on the roots, not to attempt to intuit
> zone structure.

Obviously not only the root, otherwise you'd allow for _client._smtp.<TLD>,
which would obviously bad for TLDs other than GOV, MIL, or VA.

-Peter

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: RIR comment, was Re: Faux wildcards
Date: Tue, 18 Jan 2005 06:35:02 +0700
Lines: 21
References: <a06110402be118f54d6b0@[10.31.32.134]>  <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com> <Pine.LNX.4.61.0501160749360.28480@netcore.fi> <Pine.BSI.4.56.0501160113450.26048@tom.iecc.com> <x4651xdz1h.fsf@footbone.schlitt.net> <20050117102639.01d1170a.olaf@ripe.net> <x43bx0cbit.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 00:49:07 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <a06110402be118f54d6b0@[10.31.32.134]> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        Mon, 17 Jan 2005 11:00:22 -0500
    From:        Edward Lewis <Ed.Lewis@neustar.biz>
    Message-ID:  <a06110402be118f54d6b0@[10.31.32.134]>

  | What ever happened to that 'reverse map is required' draftin DNSOP? 
  | ;)  I ask quasi-rhetorically.

One might hope it is dead.   There's no rational reason to require that
(as opposed to permit it) - aside for making more work for DNS operators.

We have evidence that the net works without in-addr.arpa mappings, that's
what half the world is doing today.   Clearly they're not essential.

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:46:14 2006
From: Pekka Savola <pekkas@netcore.fi>
Subject: Re: RIR comment, was Re: Faux wildcards
Date: Tue, 18 Jan 2005 07:58:25 +0200 (EET)
Lines: 24
References: <a06110402be118f54d6b0@[10.31.32.134]> 
 <Pine.BSI.4.56.0501150110120.6851@tom.iecc.com> <Pine.LNX.4.61.0501160749360.28480@netcore.fi>
 <Pine.BSI.4.56.0501160113450.26048@tom.iecc.com> <x4651xdz1h.fsf@footbone.schlitt.net>
 <20050117102639.01d1170a.olaf@ripe.net> <x43bx0cbit.fsf@footbone.schlitt.net>
  <18880.1106004902@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Edward Lewis <Ed.Lewis@neustar.biz>,
   IETF DNSEXT WG <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 07:10:53 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: <18880.1106004902@munnari.OZ.AU>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, 18 Jan 2005, Robert Elz wrote:
>  | What ever happened to that 'reverse map is required' draftin DNSOP?
>  | ;)  I ask quasi-rhetorically.
>
> One might hope it is dead.   There's no rational reason to require that
> (as opposed to permit it) - aside for making more work for DNS operators.
>
> We have evidence that the net works without in-addr.arpa mappings, that's
> what half the world is doing today.   Clearly they're not essential.

This should be brought up in dnsop -- but there have been efforts to 
revive it.  Not as a document describing "do reverse mapping, period", 
but as a document describing why it's a good (or bad) idea.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: John Levine <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 18 Jan 2005 17:10:58 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 51
References: <7595.1105946291@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: kre@munnari.OZ.AU
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 18:25:46 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <7595.1105946291@munnari.OZ.AU>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>That is, unless of course, the whole proposal is crazy, and is
>abusing an existing RR type for a whole bunch of different purposes,
>and relying upon the different prefix to get you just the precise one
>that you want.  Then you'd have trouble, but no-one would stoop to
>that kind of thing, would they?

Seems to me that particular horse left the barn five years ago when
RFC 2782 was published.  The meanings of a SRV record at
_http._tcp.foo.example and one at _whois._tcp.foo.example have always
been different.  I wouldn't think it'd take a lot of imagination to
see why a wildcard scheme that gave you the effect of
_http._tcp.*.example would be useful.

If you're going to add different kinds of data, I only see three ways
to do so.  You can add a new RR type, you can use a prefix, or you can
use something like TXT records and try to disambiguate using a unique
prefix in the contents.

If we'd been adding new RR types all along, they'd be the obvious
choice, but we didn't, we blew it, and there's far too much crud DNS
software in daily use that can't deal with new RRs.  I wish it weren't
so, but one of the few unambiguous results from the MARID mess was to
establish that a large vendor in the northwestern US ships both DNS
clients and servers that absolutely cannot handle new RRs without a
significant software upgrade.

I suspect I don't have to argue here why TXT records with a content
prefix are a bad idea, so I won't.  That leaves us with name prefixes.
It seems to me that name prefixes work great.  You can add all the new
prefixes you want without having to worry about whether clients can
handle them.  They create sub-name spaces where, if you want, you can
use any wacky record semantics you want and it won't bother anyone
else.  The only problem is that they don't play well with traditional
DNS wildcards.

A rather important difference between new RRs and new wildcards is
that I can do it unilaterally at the server, since wildcards aren't
visible to clients.

Am I missing anything here?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:14 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 17:46:04 +0000
Lines: 23
References: <20050118171058.5588.qmail@xuxa.iecc.com>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kre@munnari.OZ.AU, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 18:51:56 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: John Levine <johnl@iecc.com>, namedroppers@ops.ietf.org
In-Reply-To: <20050118171058.5588.qmail@xuxa.iecc.com>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 18 January 2005 17:10 +0000 John Levine <johnl@iecc.com> wrote:

> A rather important difference between new RRs and new wildcards is
> that I can do it unilaterally at the server, since wildcards aren't
> visible to clients.
>
> Am I missing anything here?

One thing I think you might be missing is the interaction between
"new wildcards" and DNSSEC. I cannot immediately see how you can
introduce a "new wildcard" with existing NSEC based authenticated
denial, without EITHER online signing in every case, OR client side
changes as well as server side changes. I may be wrong though.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 13:31:23 -0600
Lines: 120
References: <20050118171058.5588.qmail@xuxa.iecc.com>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 20:40:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <20050118171058.5588.qmail@xuxa.iecc.com> (John Levine's
 message of "18 Jan 2005 17:10:58 -0000")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <20050118171058.5588.qmail@xuxa.iecc.com> John Levine <johnl@iecc.com> writes:

> If you're going to add different kinds of data, I only see three ways
> to do so.  You can add a new RR type, you can use a prefix, or you can
> use something like TXT records and try to disambiguate using a unique
> prefix in the contents.
>
> If we'd been adding new RR types all along, they'd be the obvious
> choice, but we didn't, we blew it, and there's far too much crud DNS
> software in daily use that can't deal with new RRs.  I wish it weren't
> so, but one of the few unambiguous results from the MARID mess was to
> establish that a large vendor in the northwestern US ships both DNS
> clients and servers that absolutely cannot handle new RRs without a
> significant software upgrade.
>
> I suspect I don't have to argue here why TXT records with a content
> prefix are a bad idea, so I won't.  [...]


I've stayed away from commenting on draft-iab-dns-choices, in part
because others have express my objections to it, and in part because
trying to gore the sacred cow of "new RRs are the only way" didn't
look very productive.  dns-choices can go ahead and become yet another
widely ignored RFC.

dns-choices is full of strawman arguments and omissions of problems.

For new RRs, deployment problems are downplayed.  The time it takes to
even get a new RR allocated is completely ignored.  Yeah, there are a
few experimental RR types allocated that you don't need to go through
IANA, but then you have the problem with transitioning from the
experimental RR type to an official one.  The experimental RR types
still have the problems with collisions.  You also have problems with
old/broken DNS software that doesn't support these experimental RR
types.

Also omitted is the problem of whether the usage of the new use of the
RR type is going to take off or fizzle.  One one hand, DNS is already
filled with RR types that are almost never used and now can't be used
for anything else.  This argues for only giving new RR types to those
usages that have a high probability of success.  On the other hand,
ideas whose time has come have a way of taking off without control.
If SPF was going to use a new RR type, it would have needed to have
been allocated in the summer of 2003 and deployment of new name server
software would have needed to have started by the fall of 2003.


On the strawman side, as has been pointed out by many, using a
subdomain as a selector works reasonably well.  It would work *far*
better if DNS wildcards could be upgraded to make things like
_foo.*.example.com do what most people expect it to do.  IMHO, making
wildcards more useful is a far more productive use of people's time
than forcing everyone to use new RRs.  The deployment of better
wildcards is no worse than the deployment of a new RR, and it only has
to be done once.


The re-use of existing RRs with magic numbers in the RDATA is argued
against in dns-choices because of the problems with when too many
different applications all try and use the same RR.  In the case of
SPF and TXT RRs, we did a survey of usage of TXT RRs in the
appropriate parts of the DNS trees (domains used in the RFC2821 MAIL
FROM and RFC2821 HELO).  We found the usage wasn't very high, and at
the rate of growth in usage over the last decade, the TXT usage would
last for another decade or two.

There are several reasons why using TXT with magic numbers is the
"obvious" right thing to do which are completely ignored by
dns-choices.  Experience with Unix over the last 2+ decades has shown
that magic numbers work very well in practice on Unix files.  Using
text also has the advantage that you do not need special tools to
create, look at, or debug the data.  With a new RR type, you need to
not only modify your name server software (if you don't want to have
to use hex encoding), but you also need to update things like dig (if
you don't want to have to use hex decoding).  The amount of code need
to parse and print SPF records from a binary format[1] is far larger
than I think most name server software would want to include.  Yeah,
SPF has a complicated format, but the same problem exists if you want
to add 5,000 new RR types.

Ok, so what is the solution to TXT RR sets getting too full?  Simple.
Increase the amount of TXT RRs available to be used.  There are tens
of thousands of unallocated RR types.  Instead of allocating just one
new RR type, as was considered for the SINK RR, allocate a dozen, or a
hundred, or even a thousand of them.

Create TXT00-TXT99, all with the TXT RR format.  Yeah, it will take
years to get them widely deployed, just like all new RR types, but
once that is done, people can easily pick which ever TXT## that is not
widely used and do their experiment.  If the experiment fizzles, no
problem at all.  If it takes off, then maybe someday that particular
TXT## RR should be renamed and reserved for that usage.  If it looks
like the first allocated block of records is going to get full in the
next 5 years, then go allocate a bunch more.

Yes, people would have to use a magic number in the RDATA, but as Unix
has show, that will probably not be a problem.  Yes, text encoding is
not as compact as binary but, again, in practice, that isn't as much
of a problem as deploying new tools to deal with the binary format.

Like the effort needed to deploy better wildcards so that subdomain
selectors would work better, deploying a bunch of new TXT RR types
would also be a far better use of people's time.


Forcing people to create new RR types hasn't worked in the past, and
creating a new RFC for DNS Choices isn't going to change that.


-wayne





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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 21:10:54 +0100
Lines: 55
References: <x4acr6bkl0.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 21:18:04 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-reply-to: Your message of "Tue, 18 Jan 2005 13:31:23 CST."
             <x4acr6bkl0.fsf@footbone.schlitt.net> 
X-Organization: Uni Bielefeld, Technische Fakultaet
X-Phone: +49 521 106 2902
Content-ID: <22510.1106079049.1@zeder.TechFak.Uni-Bielefeld.DE>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

wayne <wayne@schlitt.net> wrote:

> better if DNS wildcards could be upgraded to make things like
> _foo.*.example.com do what most people expect it to do.  IMHO, making
> wildcards more useful is a far more productive use of people's time
> than forcing everyone to use new RRs.  The deployment of better

even more productive could be some education about what wildcards are
and how they work, me thinks. There's a draft underway doing that.

> "obvious" right thing to do which are completely ignored by
> dns-choices.  Experience with Unix over the last 2+ decades has shown
> that magic numbers work very well in practice on Unix files.  Using

Although I remember some HP-UX cluster files I haven't recently come
across a unix file where I opened the file giving a unique name and was
then presented with a set of answers to choose from. Subtyping is a problem
since you cannot make the subtype part of the query. (Well, given the level
of change some in this thread are willing to apply to the DNS infrastructure
it won't last long until this (e.g. "associative DNS queries") will be
proposed ...)

> Forcing people to create new RR types hasn't worked in the past, and
> creating a new RFC for DNS Choices isn't going to change that.

Just in case you (or anyone else) missed RFC 3597, there's also excellent work
done by Jakob Schlyter on interoperability of this spec (see San Diego's
dnsext minutes) and there have been various deployment surveys for
name server software. Can we now please declare the "new RR types won't
work" an urban legend?  The MARID problem was different and that pointless
debate should better not be rehashed here again.

What I really have a hard time to understand is that every suggestion (use
reverse, use wildcards combined with new type, ...) is rejected with some
not necessarily substantiated argument of "won't work due to some deployment
obstacle".  However, changing the basic DNS infrastructure is an option?

All it comes down to is a provisioning problem (generating "millions"
of RRs - in how many cases are there really "millions" and how do those
zone admins handle all the MX RRs? Huh, no MX at all?) that doesn't
need a protocol change, not even any change in the name server software.
And if anyone is concerned about the size of the resulting zone
they better look at how DNSSEC will increase that size - and that it's
a non issue for the vast majority. And they better be prepared to use
DNSSEC once anti spam rules make DNS even more attractive for forgery.

There's no need for "new" wildcards.

-Peter

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 20:37:46 +0000
Lines: 20
References: <200501182010.j0IKAsM22516@zeder.TechFak.Uni-Bielefeld.DE>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 21:44:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>,
	IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <200501182010.j0IKAsM22516@zeder.TechFak.Uni-Bielefeld.DE>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 18 January 2005 21:10 +0100 Peter Koch <pk@TechFak.Uni-Bielefeld.DE> 
wrote:

> There's no need for "new" wildcards.

I'm not (yet) sure whether "new" wildcards is a protocol change, or
an "ease of use config option" on servers (i.e. an application change)
meaning "reflect this label type to all possible QNAME queries of
this type in the zone and subdomains thereof that I am authoritative
for". If it is the latter, I'm not sure we need pronounce on it.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 12:53:36 -0800 (PST)
Lines: 70
References: <x4acr6bkl0.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 21:56:38 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <x4acr6bkl0.fsf@footbone.schlitt.net>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On Tue, 18 Jan 2005, wayne wrote:

> I've stayed away from commenting on draft-iab-dns-choices, in part
> because others have express my objections to it, and in part because
> trying to gore the sacred cow of "new RRs are the only way" didn't
> look very productive.  dns-choices can go ahead and become yet another
> widely ignored RFC.

I'm not going to comment much on draft-iab-dns-choices either because others
already done it, but I'd like to just note that I'm in lot less opposition 
to it then Wayne (although Wayne's opinion does seem to represent majority
view of people involved in SPF) and I do not believe SPF was right in using
TXT in anything other then localized experiment and that going further then
that with existing RR type leads to collisions and loss of meaning for RR.

> On the strawman side, as has been pointed out by many, using a subdomain 
> as a selector works reasonably well.  It would work *far* better if DNS 
> wildcards could be upgraded to make things like _foo.*.example.com do 
> what most people expect it to do.  IMHO, making wildcards more useful is 
> a far more productive use of people's time than forcing everyone to use 
> new RRs.  The deployment of better wildcards is no worse than the 
> deployment of a new RR, and it only has to be done once.

I agree, we better start soon so that we don't have the same problem as 
SPF for some other project.

> Create TXT00-TXT99, all with the TXT RR format. Yeah, it will take
> years to get them widely deployed, just like all new RR types, but
> once that is done, people can easily pick which ever TXT## that is not
> widely used and do their experiment.  If the experiment fizzles, no
> problem at all.  If it takes off, then maybe someday that particular
> TXT## RR should be renamed and reserved for that usage.  If it looks
> like the first allocated block of records is going to get full in the
> next 5 years, then go allocate a bunch more.

I think something like above maybe done with redefining use of DNS CLASS.
Currently its practically official that the only class used is IN (the use 
of Hesiod and Chaos is pretty close to 0). What we could do is redefine the
field and say that it is to be used to specify "subclass" for any type (with
say first 1024 being general types and anything above is type-specific
subclass all for use on the internet) i.e. its classification of how the 
RR type is used and multiple different ones are allowed for any domain. 
We define that instead of requirying to specify Class by name, systems 
and dns administrators can use class numbers and that all DNS servers 
and clients should support any arbitrary class number for any type. Now 
somebody who wants to reuse some dns type for something new can run his 
experiment on some random high class number and if it is usefull that 
CLASS number is registered with IANA as specific CLASS for the type.

As example, if this were used for SPF (which is not going to happen, it is
now way too late), it would mean that instead of having this in the zone:
 host	IN	TXT	"v=spf1 ..."
The administrators would instead put:
 host	2222	TXT	"v=spf1 ..."
Where 2222 could be SPF-specific subclass of TXT type. BTW - I just tested
the above and it actually works (!!), at least with bind - try:
'dig -c 2222 -t TXT sub2.etest.elan.net'

---
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 15:51:22 -0500
Organization: VeriSign, Inc.
Lines: 91
References: <20050118171058.5588.qmail@xuxa.iecc.com> <7758A8E6B6E3773F9590D32E@Satori.nominet.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 22:01:32 2005
Return-path: <owner-namedroppers@ops.ietf.org>
Received-SPF: unknown (Address does not pass the Sender Policy Framework)
  SPF=HELO;
  sender=[10.131.244.227];
  remoteip=::ffff:172.25.170.10;
  remotehost=;
  helo=[10.131.244.227];
  receiver=mail.verisignlabs.com;
Received-SPF: unknown (IP address lookup failed.?)
  SPF=MAILFROM;
  sender=davidb@verisignlabs.com;
  remoteip=::ffff:172.25.170.10;
  remotehost=;
  helo=[10.131.244.227];
  receiver=mail.verisignlabs.com;
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <7758A8E6B6E3773F9590D32E@Satori.nominet.org.uk>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Alex Bligh wrote:
> 
> 
> --On 18 January 2005 17:10 +0000 John Levine <johnl@iecc.com> wrote:
> 
>> A rather important difference between new RRs and new wildcards is
>> that I can do it unilaterally at the server, since wildcards aren't
>> visible to clients.
>>
>> Am I missing anything here?
> 
> 
> One thing I think you might be missing is the interaction between
> "new wildcards" and DNSSEC. I cannot immediately see how you can
> introduce a "new wildcard" with existing NSEC based authenticated
> denial, without EITHER online signing in every case, OR client side
> changes as well as server side changes. I may be wrong though.

I think you are right.  DNSSEC makes wildcards very visible at the 
client, at least to the client's DNSSEC validation code.

However, it occurs to me that in some narrow cases it might be possible 
to introduce new wildcard behavior without client side changes, along 
with a few caveats.

The narrow case I am thinking of is a definition of a new wildcard 
algorithm that is a subset of the current one.  And by subset I mean 
that the new wildcard does not match where the existing wildcard does 
not match, and may not match where the current wildcard does match.

For example, let's posit a new wildcard, %, that can be deployed in the 
way close to what John Levine wishes:

    _client._smtp.%.foo.example.com IN SRV ...

will match when qname looks like 
_client._smtp.does-not-exist.foo.example.com, and when qname looks like 
_client._smtp.does.not.exist.foo.example.com, but not match 
does-not-exist.foo.example.com and does not match 
_client._smtp.exists.foo.example.com.

It is not necessarily difficult to implement this as a server-side 
feature (hack, if you will), sans DNSSEC.

With DNSSEC, you have the problem that the client's validator must be 
able to cryptographically prove the synthesized response, yet it knows 
nothing about this '%' wildcard.  So, this hacked server needs to do 
something weird in the DNSSEC case: it needs to lie.

So, when signing this zone, a 'normal' wildcard (where _blah._blah.% is 
replaced by *) is created and signed, and an NSEC proving that the 
wildcard does not exist is also created and signed.

Positive matches are handled as if the normal wildcard exists, negative 
matches are handled as if the normal wildcard did not exist:

Q:
   _client._smtp.baz.foo.example.com. IN SRV
AN:
   _client._smtp.baz.foo.example.com. IN SRV ...
   _client._smtp.baz.foo.example.com. IN RRSIG ... labels=3
AU:
    example.com. NS ..
    b.foo.example.com. IN NSEC c.foo.example.com. ... (proves that 
_client._smtp.baz.foo.example.com does not exist in the zone)
...

and,

Q:
   _http._tcp.baz.foo.example.com. IN SRV
AN: (RCODE = 3)
AU:
   b.foo.example.com. IN NSEC c.foo.example.com. ...
   foo.example.com. IN NSEC a.foo.example.com ... (proves that 
*.foo.example.com. is not in the zone)
...

It is true that this technique (if it even works at all) makes it 
possible to spoof the existence of the wildcard match away, 
undetectably, however.

-- 
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:46:14 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 16:01:18 -0500
Lines: 34
References: <20050118171058.5588.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: namedroppers@ops.ietf.org, kre@munnari.OZ.AU
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 22:09:02 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <20050118171058.5588.qmail@xuxa.iecc.com>
To: John Levine <johnl@iecc.com>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 5:10 PM +0000 1/18/05, John Levine wrote:
>Seems to me that particular horse left the barn five years ago when
>RFC 2782 was published.  The meanings of a SRV record at
>_http._tcp.foo.example and one at _whois._tcp.foo.example have always
>been different.  I wouldn't think it'd take a lot of imagination to
>see why a wildcard scheme that gave you the effect of
>_http._tcp.*.example would be useful.

The SRV record didn't need an alteration of section 4.3.2 of RFC 
1034.  The scheme you suggest would.  Section 4.3.2 of RFC 1034 is 
simply titled "Algorithm" and is the basic algorithm for any name 
server.  For that reason, I don't see that the SRV record has set a 
precedent that leads to this change in wildcard processing.

>It seems to me that name prefixes work great.  You can add all the new
...
>else.  The only problem is that they don't play well with traditional
>DNS wildcards.

I can't imagine adding a solution that works 90% of the time to a 
critical system.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: John Levine <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 18 Jan 2005 21:11:41 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 47
References: <200501182010.j0IKAsM22516@zeder.TechFak.Uni-Bielefeld.DE>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: pk@TechFak.Uni-Bielefeld.DE
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 22:18:11 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <200501182010.j0IKAsM22516@zeder.TechFak.Uni-Bielefeld.DE>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> Can we now please declare the "new RR types won't work" an urban
> legend?

Nope.

> The MARID problem was different and that pointless debate should
> better not be rehashed here again.

The specfic issue is that widely used Microsoft firewalls proxy DNS
requests using a separate RPC for each RR type.  The firewalls do not
pass native DNS packets in either direction.  To handle a new RR, it
both needs a new RPC service on the firewall, and an new RPC request
routine in the client.  That needs software upgrades all around, and
it's a major bar to deployment to tell people that they need to spend
money and change their firewalls.

Nobody, inside or outside of Microsoft, was defending this as a good
design, but there are a lot of them in the field.  Denying that they
exist or ignoring them isn't going to win any arguments.

> All it comes down to is a provisioning problem (generating
> "millions" of RRs - in how many cases are there really "millions"
> and how do those zone admins handle all the MX RRs? Huh, no MX at
> all?)  that doesn't need a protocol change, not even any change in
> the name server software.

Part of the issue here seems to be that people have difficulty
understanding what the goal is.  It's to provide a nothing-here answer
for unused names, in a way that lets clients distinguish a domain that
returns deliberate nothing-here responses from one that has no data
either way.

I realize that one response is to say "DNS doesn't do that, go away",
but if we can't offer people a plausible way to publish data in DNS,
we're going to be seeing ugly proprietary publishing schemes that are
far worse than anything that people have disparaged here.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:14 2006
From: John Levine <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 18 Jan 2005 21:13:30 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 18
References: <FF637C2EF0B869FD27744C26@Satori.nominet.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: alex@alex.org.uk
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 22:23:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <FF637C2EF0B869FD27744C26@Satori.nominet.org.uk>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>> There's no need for "new" wildcards.
>
>I'm not (yet) sure whether "new" wildcards is a protocol change, or
>an "ease of use config option" on servers (i.e. an application change)

It's only a protocol change if you use AXFR or IXFR to synchronize
servers.  It doesn't affect normal DNS client-server interactions at
all.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:14 2006
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 18 Jan 2005 21:25:33 -0000
Lines: 23
References: <x4acr6bkl0.fsf@footbone.schlitt.net> <200501182010.j0IKAsM22516@zeder.TechFak.Uni-Bielefeld.DE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 22:32:06 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Peter Koch writes:
> Can we now please declare the "new RR types won't work" an urban legend?

What have you been smoking? New types are screwed up by an incredible
amount of DNS software---including BIND before version 9.1, and pretty
much everything from Microsoft.

> excellent work done by Jakob Schlyter on interoperability of this spec

Are you talking about the report several months ago where Schlyter said
that DNSJava 1.6.4, BIND 8.4.5rc4, BIND 9.3.0rc2, NSD 2.1.1, NET::DNS
0.47 patchlevel1, and ANS 2.2.1.0.d could handle arbitrary types? That's
wonderful. Now how about the fifty bazillion ancient BIND installations
that _can't_ handle new types?

---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:46:14 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 21:37:08 +0000
Lines: 57
References: <20050118171058.5588.qmail@xuxa.iecc.com>
 <7758A8E6B6E3773F9590D32E@Satori.nominet.org.uk>
 <41ED76CA.9050808@verisignlabs.com>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 22:54:37 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <41ED76CA.9050808@verisignlabs.com>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 18 January 2005 15:51 -0500 David Blacka <davidb@verisignlabs.com> 
wrote:

> I think you are right.  DNSSEC makes wildcards very visible at the
> client, at least to the client's DNSSEC validation code.
>
> However, it occurs to me that in some narrow cases it might be possible
> to introduce new wildcard behavior without client side changes, along
> with a few caveats.

I *think* there's an even narrower case which might (with adaptions) even
fit John's requirement better.

Suppose you invent a "pseudo-wildcard" '&' (as we are into typographical
symbols). This matches "any existing QLABEL for which I am authoritative".

So a zone with "RR"s (and you'll see why the quotes in a second) of the form
  &.example.com	IN	TXT "bar"
  foo.example.com	IN	A	1.2.3.4
  foo2.example.com	IN 	A 	2.3.4.5

has a response for QNAME="foo", QTYPE=TXT of "bar", but NXDOMAIN for
QNAME="baz", QTYPE=TXT.

The reason why this is so much easier is that even to prior to signing,
the server can expand the "RRs" in the zonefile into
  foo.example.com	IN	A	1.2.3.4
  foo.example.com	IN	TXT	"bar"
  foo2.example.com	IN	A	2.3.4.5
  foo2.example.com	IN	TXT	"bar"

and these real RR's can be signed in the normal way.

Clearly the server side complication is making it appear in subdomains
that are also served...

Introduce a (traditional) wildcard as well (to handle queries for
non-existent labels) with the same RHS, and you've (almost) got what
John wants, without any wire protocol mods.

> (stuff I need to think more about snipped)
>
> It is true that this technique (if it even works at all) makes it
> possible to spoof the existence of the wildcard match away, undetectably,
> however.

Hmmm... another challenge for authenticated denial review.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 13:42:11 -0800
Lines: 23
References: <20050118211141.2884.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: pk@TechFak.Uni-Bielefeld.DE
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 22:57:33 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <20050118211141.2884.qmail@xuxa.iecc.com>
To: John Levine <johnl@iecc.com>, namedroppers@ops.ietf.org
X-PMX-Version: 4.7.0.111621
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 9:11 PM +0000 1/18/05, John Levine wrote:
>  Part of the issue here seems to be that people have difficulty
>understanding what the goal is. It's to provide a nothing-here answer
>for unused names, in a way that lets clients distinguish a domain that
>returns deliberate nothing-here responses from one that has no data
>either way.
>

That isn't the only goal I've heard.  One goal I've heard is to have
some way of saying "This is the default for members of this set;
specific members in the set may have separate declarations
that define something different".  That is different from "nothing-here
answer for unused names", since it applies to names which do exist
but have no separate declaration.

			regards,
				Ted Hardie

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 22:45:01 +0100
Lines: 36
References: <20050118211141.2884.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 22:58:09 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol
To: namedroppers@ops.ietf.org
In-reply-to: Your message of "18 Jan 2005 21:11:41 GMT."
             <20050118211141.2884.qmail@xuxa.iecc.com> 
X-Organization: Uni Bielefeld, Technische Fakultaet
X-Phone: +49 521 106 2902
Content-ID: <5175.1106084676.1@anathema.TechFak.Uni-Bielefeld.DE>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

John Levine <johnl@iecc.com> wrote:

> > The MARID problem was different and that pointless debate should
> > better not be rehashed here again.

> routine in the client.  That needs software upgrades all around, and
> it's a major bar to deployment to tell people that they need to spend
> money and change their firewalls.

I'll follow my own advice.

> Part of the issue here seems to be that people have difficulty
> understanding what the goal is.  It's to provide a nothing-here answer
> for unused names, in a way that lets clients distinguish a domain that
> returns deliberate nothing-here responses from one that has no data
> either way.

Take new RR type FOO. Attach information to existing names by adding
a FOO RR (or a FOO RRset, for that matter) to those names' RRs, either
"manually" by server based macro expansion (a la $GENERATE) or via a
preprocessor external to the name server.
Attach (maybe different) information to non-existing names by using wildcards,
if necessary. Now, if a FOO query doesn't return a FOO RRset, you'll
assume that the FOO scheme is not (yet) supported.

NB: I do not say publishing the information *and* maybe its complement is a
    good idea or a clever long term strategy. It just helps to
    distinguish between 'supported' and 'unsupported'.

-Peter

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 21:42:25 +0000
Lines: 46
References: <johnl@iecc.com>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 23:08:10 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from John Levine <johnl@iecc.com> 
	of "18 Jan 2005 21:13:30 GMT."
	<20050118211330.4589.qmail@xuxa.iecc.com> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> >> There's no need for "new" wildcards.

i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.

> >I'm not (yet) sure whether "new" wildcards is a protocol change, or
> >an "ease of use config option" on servers (i.e. an application change)
> 
> It's only a protocol change if you use AXFR or IXFR to synchronize
> servers.  It doesn't affect normal DNS client-server interactions at
> all.

it's a zone behaviour representation issue, so it's a protocol change.  if
it's to be called a protocol, then it will describe the behaviour of servers
in the presence of various kinds of authority data and in response to various
queries.  even if axfr/ixfr isn't used, then the representation needed to
cause this behaviour will still have to be signallable by dynamic updates,
and visible with maintainance queries (such as a query for a literal "*" does
in the current wildcard mechanism), and as others have noted, it will have
an impact on dnssec proofs, of both the positive and negative variety.

even if the protocol change is to say "zones using this new kind of wildcard
cannot be represented in axfr/ixfr or dynamically updated", it'd still be a
protocol change.

right now, a nonterminal "*" is meaningless to the wildcard algorythm.  it
will have to remain meaningless in case someone is using this encoding and
depending on it to be meaningless or "just an asterisk label, not special".

to add nonterminal wildcards or rrtype-specific wildcards, we will have to
define a new encoding that is currently not just meaningless but invalid.
and then we'll have to define negotiation mechanisms as necessary to ensure
that both sides of an axfr/ixfr or multiple MS-A-D masters or both sides of
a dynamic update all agree that the new encoding has a specific new meaning
and is not invalid as it would be to pre-epoch servers.  this means it's a
protocol change.  don't fear protocol changes.  we added EDNS.  we added
dynamic update.  we're adding DNSSEC.  we added TSIG.

and don't fear new rrtypes.  we added SRV and a whole lot of others.  it
takes time and that's too bad but it can be done and should be done and in
the case of SPF-like functionality, apparently it must be done.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 18 Jan 2005 17:16:12 -0500
Lines: 32
References: <20050118211141.2884.qmail@xuxa.iecc.com> <p06200706be13303e8218@[129.46.227.161]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 18 23:21:58 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Ted Hardie" <hardie@qualcomm.com>
In-Reply-To: <p06200706be13303e8218@[129.46.227.161]>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> That isn't the only goal I've heard.  One goal I've heard is to have
> some way of saying "This is the default for members of this set;
> specific members in the set may have separate declarations
> that define something different".  That is different from "nothing-here
> answer for unused names", since it applies to names which do exist
> but have no separate declaration.

Yes, that's the other goal.  I will agree that by adding enough extra
records to the DNS you can get the effect of a default by adding an
explicit RR to every name that already exists, so that's a more debatable
argument about how much glop domain owners are likely to be willing to
add.  Personally, since my DNS data file is generated by perl scripts, I'd
find it no big deal.

But the nothing-here issue is much tougher, since I don't see any way to
fake it other than by defining RRs and waiting a decade for every
Microsoft user to upgrade his firewall.

The same tree walk that handles the nothing-here case also handles the
default case, so if you can stand the first, the second is there if you
want it.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Eric A. Hall" <ehall@ehsco.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 20:23:03 -0500
Lines: 21
References: <20050118211141.2884.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, pk@TechFak.Uni-Bielefeld.DE
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 02:33:07 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050118211141.2884.qmail@xuxa.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On 1/18/2005 4:11 PM, John Levine wrote:

> The specfic issue is that widely used Microsoft firewalls proxy DNS
> requests using a separate RPC for each RR type.

And they could have easily fixed this bug during the period we've been
debating the subject, but they haven't.

Designing protocols around buggy software that the vendor has empirically
abandoned is wrong.

-- 
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:46:14 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 18 Jan 2005 20:57:37 -0500
Lines: 31
References: <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 03:04:44 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Eric A. Hall" <ehall@ehsco.com>
In-Reply-To: <41EDB677.2090209@ehsco.com>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > The specfic issue is that widely used Microsoft firewalls proxy DNS
> > requests using a separate RPC for each RR type.
>
> And they could have easily fixed this bug during the period we've been
> debating the subject, but they haven't.

Honestly, I don't know how to respond to silly arguments like this.  The
MARID fiasco started about a year ago.  A year is a fairly short release
cycle for a commercial software product of any size.  (Been there.)
There are still substantial numbers of Microsoft customers using software
that they shipped three, four, even six years ago.  This shouldn't
surprise anyone, since there are still plenty of people using versions of
every other kind of software that were shipped years ago.

There's no question that Microsoft made some poor design decisions in
their DNS software, but even if they were dying to get everyone to upgrade
(which they certainly are for some upgrades like XP SP2), it'll be years
until you can assume that most of the users have installed it.  They're
still issuing patches for Win98, because the large number of people still
using it grouse and they can't abondon it.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: John Levine <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 19 Jan 2005 02:37:54 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 45
References: <csk8qp$2ctj$1@sf1.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: Ed.Lewis@neustar.biz
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 03:44:34 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <csk8qp$2ctj$1@sf1.isc.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>>Seems to me that particular horse left the barn five years ago when
>>RFC 2782 was published. ...

>The SRV record didn't need an alteration of section 4.3.2 of RFC 
>1034.

I may have been unclear since my message was about two fairly separate
topics.

One is using SRV records with different interpretations of the fields.
That doesn't need any changes to anything.  Nothing else uses a prefix
of _client._smtp, so CSV SRV records won't collide with anything else.

Our SRV records don't work with wildcards, but no SRV records have
ever worked with wildcards.  So nothing's changed, if you did a
wildcard SRV before you'd be sorry, and you still will be.

>> It seems to me that name prefixes work great.  You can add ...
>> The only problem is that they don't play well with traditional DNS
>> wildcards.

>I can't imagine adding a solution that works 90% of the time to a 
>critical system.

Well, yeah, that's the problem, isn't it?

My inclination at this point it to tell CSV clients to do the tree
walk, since that works with any old DNS server, and to encourage the
servers to consider more sophisticated record synthesis so they can
respond directly to an initial CSV query even if it's for something
without an explicit record in the server.  If the client gets a
response to the initial exact match query, it won't do the tree walk,
so this works with current software, and allows servers to do an
upgrade transparently if they want.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:14 2006
From: Danny Mayer <mayer@gis.net>
Subject: Re: Faux wildcards
Date: Tue, 18 Jan 2005 19:49:42 -0500
Lines: 38
References: <4.3.1.2.20050116223150.026a7e68@pop.gis.net>
 <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com>
 <4.3.1.2.20050116223150.026a7e68@pop.gis.net> <x4is5wd4l5.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 04:50:35 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>,
 "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <x4is5wd4l5.fsf@footbone.schlitt.net>
References: <4.3.1.2.20050116223150.026a7e68@pop.gis.net>
 <C6DDA43B91BFDA49AA2F1E473732113E010BEF34@mou1wnexm05.vcorp.ad.vrsn.com>
 <4.3.1.2.20050116223150.026a7e68@pop.gis.net>
X-Rcpt-To: <namedroppers@ops.ietf.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 12:09 AM 1/17/2005, wayne wrote:
>In <4.3.1.2.20050116223150.026a7e68@pop.gis.net> Danny Mayer 
><mayer@gis.net> writes:
>2) It is wildly recognized in the email/anti-spam community that
>    people have a very wide range of tolerances for false positives
>    (legitimate email being falsely rejected), and false negatives
>    (spam that gets through).
>
>    What I stated was a recognition of this and, since there are no
>    protocol police, trying to change how the world works is hard.  If
>    you think it is worth your while to try change this, you might try
>    starting with changing the IETF.
>
>3) Let's look at the Received: headers from Danny's email:

Your points 2 and 3 (I deleted the actual analysis) shows that looking
at the names being sent is useless and confirms that you should stick
to the IP address only. I have my local system set up as a local smtp
server whose job it is to forward my mail to my ISP (as well as handle
my personal mailinglists). That's not an unusual situation. My ISP's
SMTP server is set up to only accept mail from those IP addresses
that it owns as well as to deliver to domains that it is responsible for
receiving email (like gis.net). These are the situations that antispam
protocols need to handle.

You should be able to make use of any record type that DNS supports
including PTR, SRV, TXT and any new record type that you wish to
propose to support your efforts (modulo what the DNS community thinks
should be supported and obtained through the usual IETF process.

Danny


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Eric A. Hall" <ehall@ehsco.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Tue, 18 Jan 2005 23:14:37 -0500
Lines: 32
References: <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com> <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 05:21:10 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
To: John R Levine <johnl@iecc.com>
In-Reply-To: <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On 1/18/2005 8:57 PM, John R Levine wrote:

>>>The specfic issue is that widely used Microsoft firewalls proxy DNS
>>>requests using a separate RPC for each RR type.
>>
>>And they could have easily fixed this bug during the period we've been
>>debating the subject, but they haven't.

> There's no question that Microsoft made some poor design decisions in
> their DNS software, but even if they were dying to get everyone to upgrade
> (which they certainly are for some upgrades like XP SP2), it'll be years
> until you can assume that most of the users have installed it.

This is quite the strawman circle-jerk. First of all, the complaint as
stated is that they haven't even patched the code yet, and that if they'd
patch it (as opposed to distribute it to every system that ever downloaded
a test package) this problem would go away. Second, requiring the use of
service packs and patches is common practice, and telling people that they
need to get some hotfix for their borked ~firewall is neither new nor
prohibitive. Third, designing protocols to accomodate broken software is
bad design 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:46:14 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 18 Jan 2005 23:43:07 -0500
Lines: 28
References: <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com> <41EDDEAD.6050505@ehsco.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 05:49:25 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Eric A. Hall" <ehall@ehsco.com>
In-Reply-To: <41EDDEAD.6050505@ehsco.com>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> This is quite the strawman circle-jerk. First of all, the complaint as
> stated is that they haven't even patched the code yet,

No, actually, the complaint is that they screwed up the design.  It's not
at all obvious to me how you'd patch around that design other than perhaps
adding a generic pass-through-the-bits call, and even if they did that I
don't know how it might affect calls that do ANY requests.

But it hardly matters whether they've shipped an upgrade or not.  As Dan
Bernstein pointed out, even though the MS firewall is the most egregiously
broken package with respect to new RRs, there are still plenty of *IX
systems running old versions of BIND that will fall over if confronted
with new RR's, too.  I entirely agree that as a long term goal we should
try and figure out how to get people to upgrade their DNS software, but
it's nuts to do designs that you can't use until they do.

Or to put it another way, if you believe that most people update their
software, why aren't we all using IPv6?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:14 2006
From: "Eric A. Hall" <ehall@ehsco.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 00:01:23 -0500
Lines: 26
References: <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com> <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com> <41EDDEAD.6050505@ehsco.com> <Pine.BSI.4.56.0501182331170.9202@tom.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 06:08:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
To: John R Levine <johnl@iecc.com>
In-Reply-To: <Pine.BSI.4.56.0501182331170.9202@tom.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On 1/18/2005 11:43 PM, John R Levine wrote:

> Or to put it another way, if you believe that most people update their
> software

Can we stick to the points I'm actually making?

It's not unprecedented or uncommon to tell people that they have to
upgrade to use some other piece of software. This happens all the time in
MS-land in particular (cf Active Directory, DirectX, Windows XP, etc etc
ect), and this has also happened with DNS extensions as well (eg, "upgrade
BIND if you need to use SRV"). Besides which, if they aren't even patching
the software, then it's effectively abandonware and is irrelevant to the
design anyway. In either case, the shortcomings of a particular product
should be and effectively is irrelevant.

-- 
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:46:14 2006
From: Pekka Savola <pekkas@netcore.fi>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 07:40:40 +0200 (EET)
Lines: 36
References: <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "Eric A. Hall" <ehall@ehsco.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 06:48:12 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: John R Levine <johnl@iecc.com>
In-Reply-To: <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 18 Jan 2005, John R Levine wrote:
> There are still substantial numbers of Microsoft customers using software
> that they shipped three, four, even six years ago.  This shouldn't
> surprise anyone, since there are still plenty of people using versions of
> every other kind of software that were shipped years ago.

Probably.  But how many of those SMTP servers which need to make these 
lookups, or how many DNS servers (providing information about that 
site's zone) are behind such firewalls?

There's no doubt there's breakage out there, but the point is whether 
we need to care about it.

I can't imagine a major mail system or DNS server would be behind such 
a firewall.  And our primary target is major mail systems and zones, I 
suspect.  In the big picture, small sites using broken and abandoned 
firewalls seem irrelevant.

The simple answer could be, "if you have a broken firewall, you can't 
use this mechanism.  Here [link] are instructions on known-bad and 
known-good implementations".

We've been there with ECN.  We're there with different DNS equipment 
breaking AAAA (or anything except A) records.  We'll continue to get 
there.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Pekka Savola <pekkas@netcore.fi>
Subject: DNS spec compliancy and how to get there
Date: Wed, 19 Jan 2005 07:45:12 +0200 (EET)
Lines: 32
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 06:50:11 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

DJB quoted Peter Koch and wrote:
=====
> excellent work done by Jakob Schlyter on interoperability of this spec

Are you talking about the report several months ago where Schlyter said
that DNSJava 1.6.4, BIND 8.4.5rc4, BIND 9.3.0rc2, NSD 2.1.1, NET::DNS
0.47 patchlevel1, and ANS 2.2.1.0.d could handle arbitrary types? That's
wonderful. Now how about the fifty bazillion ancient BIND installations
that _can't_ handle new types?
=====

This strikes to me that we need pretty urgently to have some kind of 
"[minimum] requirements for DNS implementations [that wish to be 
compliant to DNS specs]" (like hosts requirements, router 
requirements, or IPv6 host requirements documents).

That seems to be the only way to write clearly which features are 
optional and which must be supported.

Would some folks be interested in working on this?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: bmanning@vacation.karoshi.com
Subject: Re: DNS spec compliancy and how to get there
Date: Wed, 19 Jan 2005 05:56:39 +0000
Lines: 44
References: <Pine.LNX.4.61.0501190740480.32749@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 07:03:29 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Pekka Savola <pekkas@netcore.fi>
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0501190740480.32749@netcore.fi>
User-Agent: Mutt/1.4.1i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, Jan 19, 2005 at 07:45:12AM +0200, Pekka Savola wrote:
> DJB quoted Peter Koch and wrote:
> =====
> >excellent work done by Jakob Schlyter on interoperability of this spec
> 
> Are you talking about the report several months ago where Schlyter said
> that DNSJava 1.6.4, BIND 8.4.5rc4, BIND 9.3.0rc2, NSD 2.1.1, NET::DNS
> 0.47 patchlevel1, and ANS 2.2.1.0.d could handle arbitrary types? That's
> wonderful. Now how about the fifty bazillion ancient BIND installations
> that _can't_ handle new types?
> =====
> 
> This strikes to me that we need pretty urgently to have some kind of 
> "[minimum] requirements for DNS implementations [that wish to be 
> compliant to DNS specs]" (like hosts requirements, router 
> requirements, or IPv6 host requirements documents).
> 
> That seems to be the only way to write clearly which features are 
> optional and which must be supported.
> 
> Would some folks be interested in working on this?

	there are at least three efforts underway...
	my own efforts have been bounced by the ID gatekeepers
	twice... so no ID yet.

--bill
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> --
> to unsubscribe send a message to namedroppers-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:46:14 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 19 Jan 2005 01:49:20 -0500
Lines: 29
References: <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com> <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 07:57:44 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Pekka Savola" <pekkas@netcore.fi>
In-Reply-To: <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> Probably.  But how many of those SMTP servers which need to make these
> lookups, or how many DNS servers (providing information about that
> site's zone) are behind such firewalls?

DNS servers, probably not many.  SMTP servers, lots of them.  They're
running Exchange, if they weren't behind a firewall they wouldn't last
five minutes.

> There's no doubt there's breakage out there, but the point is whether
> we need to care about it.

As Dan B. noted, the MS firewall is the biggest single collection of RR
brokenware, but there's plenty more in the form of obsolete versions of
BIND and other DNS software that people are still running.

I'm not saying that we should give up and never ever add a new RR type,
but I am saying that requiring a new RR is in 2005 a major bar to
widespread deployment.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 07:11:11 +0000
Lines: 12
References: <johnl@iecc.com>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 08:16:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "John R Levine" <johnl@iecc.com> 
	of "18 Jan 2005 23:43:07 EST."
	<Pine.BSI.4.56.0501182331170.9202@tom.iecc.com> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> Or to put it another way, if you believe that most people update their
> software, why aren't we all using IPv6?

and yet, we'll keep adding new rr types, and they'll mostly work, and
where they don't, they'll put pressure on middlebox vendors.  this is
called "progress."

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 07:17:13 +0000
Lines: 13
References: <johnl@iecc.com>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 08:21:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "John R Levine" <johnl@iecc.com> 
	of "19 Jan 2005 01:49:20 EST."
	<Pine.BSI.4.56.0501190145590.19226@tom.iecc.com> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> I'm not saying that we should give up and never ever add a new RR type,
> but I am saying that requiring a new RR is in 2005 a major bar to
> widespread deployment.

we all knew that.  which is why we all recommended a new type be added in
2003.  now it appears that failure to heed will be rewarded by approval of
a bad design, and the lazy can become the victims.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Pekka Savola <pekkas@netcore.fi>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 09:20:29 +0200 (EET)
Lines: 48
References: <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com> <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <Pine.BSI.4.56.0501190145590.19226@tom.iecc.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 Wed Jan 19 08:25:19 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: John R Levine <johnl@iecc.com>
In-Reply-To: <Pine.BSI.4.56.0501190145590.19226@tom.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 19 Jan 2005, John R Levine wrote:
>> Probably.  But how many of those SMTP servers which need to make these
>> lookups, or how many DNS servers (providing information about that
>> site's zone) are behind such firewalls?
>
> DNS servers, probably not many.  SMTP servers, lots of them.  They're
> running Exchange, if they weren't behind a firewall they wouldn't last
> five minutes.

Are big/significant exchange servers, receiving incoming mail, behind 
*such* firewalls?  I'd suspect most (and almost all bigger ones) 
Exchange servers would definately be behind a *real* firewall, not a 
proxy server by MS (or whatever causing the problems quoted here).

> As Dan B. noted, the MS firewall is the biggest single collection of RR
> brokenware, but there's plenty more in the form of obsolete versions of
> BIND and other DNS software that people are still running.
>
> I'm not saying that we should give up and never ever add a new RR type,
> but I am saying that requiring a new RR is in 2005 a major bar to
> widespread deployment.

True, though if we're never going to use it, we're never going to get 
there...

I think the most important thing here is to recognize the scenarios 
where we absolutely want to get this deployed, versus those sites 
which would possibly want to use this thing (but can't, due to 
miscellanous brokenware).

We may need to make the deployment sufficiently easy for those we 
absolutely want to use this thing (e.g., very big mail providers, very 
big zone owners, ...?), but we *necessarily* don't need to do that for 
those who are not critical for the success of this solution.  They'll 
upgrade their brokenware if they see an incentive to do so. Otherwise, 
it's their mail that gets spoofed, or they cannot check the originator 
of the mail.  Why do we care?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 15:45:21 +0700
Lines: 53
References: <Pine.BSI.4.56.0501190145590.19226@tom.iecc.com>  <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com> <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com> <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Pekka Savola" <pekkas@netcore.fi>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 10:06:08 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "John R Levine" <johnl@iecc.com>
In-Reply-To: <Pine.BSI.4.56.0501190145590.19226@tom.iecc.com> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        19 Jan 2005 01:49:20 -0500
    From:        "John R Levine" <johnl@iecc.com>
    Message-ID:  <Pine.BSI.4.56.0501190145590.19226@tom.iecc.com>

  | As Dan B. noted, the MS firewall is the biggest single collection of RR
  | brokenware, but there's plenty more in the form of obsolete versions of
  | BIND and other DNS software that people are still running.

His point was just that's there's lots of ancient stuff around, which can't
handle new types.   And that's both correct, and not very relevant.

The point you keep ignoring is that the only people who need to handle the
new type are those who want to use it (as client or server).   That is,
it is irrelevant that someone's system can't handle the BOZO RR type, if
they don't add it to their servers, and don't have clients that query for it.

This may be a good test of just how real the demand for SPF (or similar)
really is, and how must of it is just hype.   If you tell people that to
use SPF they're going to have to spend $'s to upgrade (or even
totally replace with something from a different vendor) their systems,
we'll find out just how important SPF really is to them, won't we?

If they're prepared to do that, then all this noise about new types being
hard to deploy will be just irrelevant, as people would be actively
deploying it.   If they're not prepared to upgrade, then clearly the
functionality being claimed as important, isn't really all that important
after all.

  | I'm not saying that we should give up and never ever add a new RR type,
  | but I am saying that requiring a new RR is in 2005 a major bar to
  | widespread deployment.

Only if you're trying to force widespread deployment of something for
which people see no benefit to themselves.   If the end users who have
to upgrade can see a genuine benefit in the upgrade, they do it.

Note here that the whole net doesn't have to upgrade to support a new RR
type - that's what Paul V's message was trying to illustrate.   SRV records
have been added, and are used.    Yet as djb's message indicated, there
are still zillions of servers around that have no idea what an SRV record
is, and have no chance of ever processing one correctly.   Yet everything
still works - those who need SRV have servers that handle it.   Those who
don't simply don't care - if their servers are OK for other reasons, fine,
if they're not, as long as they work for their actual needs, that's also fine.

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:46:14 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 15:50:54 +0700
Lines: 39
References: <20050118171058.5588.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 10:06:19 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050118171058.5588.qmail@xuxa.iecc.com> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        18 Jan 2005 17:10:58 -0000
    From:        John Levine <johnl@iecc.com>
    Message-ID:  <20050118171058.5588.qmail@xuxa.iecc.com>

  | Seems to me that particular horse left the barn five years ago when
  | RFC 2782 was published.  The meanings of a SRV record at
  | _http._tcp.foo.example and one at _whois._tcp.foo.example have always
  | been different.

Of course.   But I don't use such a thing with an undefined "foo".

  | I wouldn't think it'd take a lot of imagination to
  | see why a wildcard scheme that gave you the effect of
  | _http._tcp.*.example would be useful.

It would aid laziness to have a record generator for the DNS yes, and
if that were dynamic, it could save on memory in servers for large zones.
But nothing is needed that needs to affect the protocol (AXFR/IXFR included).

For names that don't exist (unknown "foo") there's no benefit I've yet
been able to determine.

  | It seems to me that name prefixes work great.

You mean you think it is OK for you (and the rest of the community) to
"steal" my namespace - to take names from my domain and define how they're
supposed to be used?   SRV already did that (but since it is only for use
on its specialised record type, it is comparatively harmless).   Doing it
for ant of the standard RR types is totally unacceptable.   I define what
names get allocated in my domains, you don't.

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:46:14 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: What is a type? I-D ACTION:draft-iab-dns-choices-00.txt
Date: Wed, 19 Jan 2005 11:48:05 +0100
Lines: 59
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 11:55:10 2005
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

The following may be of some interest to existing and future creators of
DNS-based "kitchen sinks" [I-D: draft-iab-dns-choices-00.txt]

What is a type?
===============
Consider the following sample definition from the Internet-Draft
draft-delany-domainkeys-base-01.txt (describing Yahoo's "DomainKeys"
proposal for improving e-mail security):

    brisbane._domainkey  IN TXT  "g=; k=rsa; p=MHww ... IDAQAB"

A popular view is that this is an example of "subtyping" the TXT type.
But this view is incorrect from a real-world perspective.  The data type
is actually "_domainkey" and nothing else.

So what's TXT then?  Well, all non-local data types need some kind of external
representation and the by far most common way to represent "config" data to be
administered by humans (and machines), is to use a textual representation.
TXT does that for you.  Yahoo would due to this, not had gained anything
(but troubles) by defining and registering a DomainKeys-specific text container.

Performance
===========
Since DNS lookups can be done with full granularity (*._domainkey.example.com
or brisbane._domainkey.example.com), it seems that there are no apparent
performance issues to solve.

A single remaining issue
========================
Although hardly a problem for DomainKeys, this definition actually makes
"_domainkey" a reserved word in an unmanaged global namespace.  If you scale-up
this type definition concept by some two or three magnitudes, you may see why
URIs and OIDs have rather become the norm for most other Internet standards.

In case anybody really is interested in solving this "potential problem in
the making", this is in fact absolutely trivial.  Assuming that DomainKeys
is defined by RFC 6789, you could use the RFC as the foundation for the
DomainKeys private data type by assigning it the IETF URN "urn:ietf:rfc:6789".
Running this URN trough a suitable  URI-to-DNS-label converter, you could
end-up with something like this:

  brisbane.urn_2ietf_2rfc_26789  IN TXT  "g=; k=rsa; p=MHww ... IDAQAB"

By using this somewhat ugly scheme, new DNS resource types can be safely
defined by various private and public communities, with no more central
control than required by any other Internet development.

Note: DomainKeys only served as an example, but the basic scheme applies to
a large class of other applications that could use DNS-based data objects.

Anders Rundgren
Principal Engineer, RSA Security


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 10:16:46 -0500
Lines: 71
References: <20050118171058.5588.qmail@xuxa.iecc.com>
 <7758A8E6B6E3773F9590D32E@Satori.nominet.org.uk>
 <41ED76CA.9050808@verisignlabs.com>
 <3148F5967C784997FD53BBB6@Satori.nominet.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ed.lewis@neustar.biz
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 16:27:18 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <3148F5967C784997FD53BBB6@Satori.nominet.org.uk>
To: namedroppers@ops.ietf.org
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 9:37 PM +0000 1/18/05, Alex Bligh wrote:

>The reason why this is so much easier is that even to prior to signing,
>the server can expand the "RRs" in the zonefile into
...
>
>Introduce a (traditional) wildcard as well (to handle queries for
>non-existent labels) with the same RHS, and you've (almost) got what
>John wants, without any wire protocol mods.

Mr. Bligh is on to something here.

Thinking (independent from his message) about this I hit:

1) The DNS is meant to be used by asking a specific question and 
getting a specific answer.

2) The DNS lacks a feature in which any query whose name is within a 
zone answers with a zone-wide record set.

3) Every time we add new features to the code of DNS, we introduce a 
new generation of obsoleted code.

The purpose of DNS has been hashed over and over (the holy Q-tuple, 
etc.) so I'll skip that.  The problem is that the mail protocols 
don't know what they want to ask, not specifically enough for DNS's 
purposes.  Mail doesn't know which entity's information is needed 
hence mail cannot translate this into a domain name and form a 
specific question.  Lacking a directory service, what mail needs is a 
more directory-like lookup service.

There seems to be commonly held belief that if DNS were to feature 
the ability to answer with data for all names in a zone (present or 
not), the mail protocol designers would be more happy than they are 
now.  (The wildcard example in RFC 1034 shows the use of wildcards 
for MX records leading me to think that perhaps wildcards were 
introduced first for mail.)

If we were to undertake an effort to add such a feature in DNS, we 
would have to make changes to the basic algorithm in RFC 1034 
(4.3.2).  In step 2, we are told to select the zone.  In conjunction 
with that we would also then have to possibly select the zone-wide 
data sets.  In step 3 we locate the name we want (substeps a,b,c are 
there), we would have to amend these steps to deal with either a lack 
of a name, a CNAME out of the zone, or even a conflict between a 
zone-wide set and a same-typed set at a found name (scope rules).  My 
point is that this is a change to the code algorithm, meaning that a 
change of this magnitude would mean that we wind up with all of 
today's DNS servers being members of the obsolete corps.  (If you 
think dealing with only yesterday's code as obsolete...)

In thinking this over, I was about to suggest what Alex already has - 
just preprocess all the data you need.  The same idea came up in 2001 
as we dumped A6 in favor AAAA (and bitstrings in favor of nibbles). 
For IPv6, the preprocessor would have to calculate AAAA's for events 
like renumbering.  For mail, the preprocessor would have to calculate 
the wildcards and specific records needed to answer.  You would need 
a tool to do this, but it's computationally feasible.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: What is a type? I-D ACTION:draft-iab-dns-choices-00.txt
Date: Wed, 19 Jan 2005 10:59:32 -0500
Lines: 54
References: <008501c4fe14$5edd77f0$80c5a8c0@rsaedoscymkikx>
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 Wed Jan 19 17:14:05 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <008501c4fe14$5edd77f0$80c5a8c0@rsaedoscymkikx>
To: "Anders Rundgren" <anders.rundgren@telia.com>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 11:48 AM +0100 1/19/05, Anders Rundgren wrote:
>The following may be of some interest to existing and future creators of
>DNS-based "kitchen sinks" [I-D: draft-iab-dns-choices-00.txt]
>
>What is a type?
>===============

(History soapbox comment)

This is defined in RFC 1034, section 3.6 (Resource Records) starting 
on page 11.  In particular, this is taken from page 12:

# When we talk about a specific RR, we assume it has the following:
#
# owner           which is the domain name where the RR is found.
#
# type            which is an encoded 16 bit value that specifies the type
#                 of the resource in this resource record.  Types refer to
#                 abstract resources.
# ...

*Redefining* terms has proven to cause more confusion than progress.

 From someone who's travelled down the wrong road to extensions 
(DNSSEC leading to RFC 2065), you have to work within the system to 
make progress.  The security experts involved then were more 
concerned about cryptography and chains of trust than figuring out 
how the DNS worked and shoring up the protocols real vulnerabilities. 
E.g., instead of deriving a DS RR as a manifestation of the 
delegation, they held fast to the notion that keys ought to be kept 
off-line.  (Then along came dynamic update and registries that update 
DNS many times an hour.)

Redefining terms and questioning the basic philosophy will only lead 
to a torpedoing of the entire effort, maybe even the base.

>A single remaining issue
>========================

Optimism. ;)
Couldn't resist.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: What is a type? I-D ACTION:draft-iab-dns-choices-00.txt
Date: Wed, 19 Jan 2005 18:03:41 +0100
Lines: 23
References: <008501c4fe14$5edd77f0$80c5a8c0@rsaedoscymkikx> <a06200706be1430715df8@[192.168.1.103]>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Cc: <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 18:13:54 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Edward Lewis" <Ed.Lewis@neustar.biz>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>"Edward Lewis" <Ed.Lewis@neustar.biz> wrote:

>Redefining terms and questioning the basic philosophy will only lead 
>to a torpedoing of the entire effort, maybe even the base.

"Redefining terms".  Rather documenting how things actually work.

"Questioning the basic philosophy".
Well, I cannot recall any other Internet-scale system which requires that
app-specific data types are defined by centrally maintained 16-bit integers.

I don't seriously believe that any consensus on this will ever occurr.  I'm
fully satisfied if the various communities creating applications, can agree on
some kind of "interpretation" of what they are doing, because then progress
can hopefully be made.

Anders Rundgren

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: What is a type? I-D ACTION:draft-iab-dns-choices-00.txt
Date: Wed, 19 Jan 2005 18:14:33 +0000
Lines: 20
References: <008501c4fe14$5edd77f0$80c5a8c0@rsaedoscymkikx>
 <a06200706be1430715df8@[192.168.1.103]>
 <003e01c4fe48$d80d57b0$80c5a8c0@rsaedoscymkikx>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 19:23:05 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Anders Rundgren <anders.rundgren@telia.com>,
	Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <003e01c4fe48$d80d57b0$80c5a8c0@rsaedoscymkikx>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 19 January 2005 18:03 +0100 Anders Rundgren 
<anders.rundgren@telia.com> wrote:

> Well, I cannot recall any other Internet-scale system which requires that
> app-specific data types are defined by centrally maintained 16-bit
> integers.

Go look at the list of IANA registries. You will find rather
a lot of 16-bit (and indeed 8-bit) registries. Protocol numbers,
and well known ports off the top of my head.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 13:04:20 -0600
Lines: 37
References: <20050118214225.549E213E12@sa.vix.com>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 20:10:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <20050118214225.549E213E12@sa.vix.com> (Paul Vixie's message of
 "Tue, 18 Jan 2005 21:42:25 +0000")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <20050118214225.549E213E12@sa.vix.com> Paul Vixie <paul@vix.com> writes:

>> >> There's no need for "new" wildcards.
>
> i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.

I agree with Paul here.


> right now, a nonterminal "*" is meaningless to the wildcard algorythm.  it
> will have to remain meaningless in case someone is using this encoding and
> depending on it to be meaningless or "just an asterisk label, not special".
>
> to add nonterminal wildcards or rrtype-specific wildcards, we will have to
> define a new encoding that is currently not just meaningless but invalid.

Ok, I confess I don't understand how wildcards and DNSSEC works, but
current wildcards are server side only.  So, we could just have an
option enable expanded wildcards that defaults to "off".  So, if
someone has "foo.*.bar.example.com. IN A 1.2.3.4", that would remain
as it is.  The meaning, however, could change for those that want to
change it.  The option would need to be per-zone and there would need
to be some way of communicating this option to secondar NSs.  One
really ugly solution to this would be to create a "EWLD" RR type to
denote that this zone wishes to use extended wildcards.  Like the SOA
record, the "EWLD" RR would need to be at the zone origin.



-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 19:25:26 +0000
Lines: 40
References: <20050118214225.549E213E12@sa.vix.com>
 <x4u0pd9r63.fsf@footbone.schlitt.net>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 20:34:31 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <x4u0pd9r63.fsf@footbone.schlitt.net>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 19 January 2005 13:04 -0600 wayne <wayne@schlitt.net> wrote:

> Ok, I confess I don't understand how wildcards and DNSSEC works, but
> current wildcards are server side only.  So, we could just have an
> option enable expanded wildcards that defaults to "off".  So, if
> someone has "foo.*.bar.example.com. IN A 1.2.3.4", that would remain
> as it is.  The meaning, however, could change for those that want to
> change it.

Genuine question: what is the perceived advantage of "new type of wildcard"
over preprocessing?

I know one answer: if the "new wildcard" matches non-existent LABELS,
and the preprocessing cannot decompose the directive into a selection
of traditional RR's and wildcards, then preprocessing isn't going to
work and you are stuck with synthesis (and, with DNSSEC, online signing).

But is there a current known case where this is problematic?

foo.&.bar.example.com  (for "&" = new wildcard)

such as I believe is wanted by the SPF folks could be decomposed
by preprocessing into foo.<label>.bar.example.com records for all
instances of <label> within bar.example.com. (note config subtlety
when "within" crosses a zone cut). Whilst it can generate a
*.bar.example.com RR for "the rest of the zone" as per Ed's
draft, it's not going to answer to foo.baz.bar.example.com where
baz does not exist. But is this a problem? IE I thought the tree
iteration was for where subdomains do not have SPF records, not for
where subdomains do not exist.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 13:44:04 -0600
Lines: 33
References: <20050118211141.2884.qmail@xuxa.iecc.com>
	<41EDB677.2090209@ehsco.com>
	<Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
	<Pine.LNX.4.61.0501190735350.32749@netcore.fi>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 20:49:13 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <Pine.LNX.4.61.0501190735350.32749@netcore.fi> (Pekka Savola's
 message of "Wed, 19 Jan 2005 07:40:40 +0200 (EET)")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <Pine.LNX.4.61.0501190735350.32749@netcore.fi> Pekka Savola <pekkas@netcore.fi> writes:

> On Wed, 18 Jan 2005, John R Levine wrote:
>> There are still substantial numbers of Microsoft customers using software
>> that they shipped three, four, even six years ago.  This shouldn't
>> surprise anyone, since there are still plenty of people using versions of
>> every other kind of software that were shipped years ago.
>
> Probably.  But how many of those SMTP servers which need to make these
> lookups, or how many DNS servers (providing information about that
> site's zone) are behind such firewalls?

SPF is not just used in SMTP servers.  For example, SpamAssassin does
SPF checks and it is often run after the email has been delivered.
There is at least one version that runs after POP/IMAP.

For Microsoft's CallerID/SenderID, it is my understanding that they
primarily intended it to be part of the MUA.  Imagine every future
copy of Outlook having SenderID support built into it.

So, the answer to your question is that, yes, there are a lot of
machines that would be trying to run these checks from behind these
broken firewalls.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 13:58:42 -0600
Lines: 40
References: <20050118171058.5588.qmail@xuxa.iecc.com>
	<7758A8E6B6E3773F9590D32E@Satori.nominet.org.uk>
	<41ED76CA.9050808@verisignlabs.com>
	<3148F5967C784997FD53BBB6@Satori.nominet.org.uk>
	<a06200704be141b737280@[192.168.1.103]>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 21:04:06 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <a06200704be141b737280@[192.168.1.103]> (Edward Lewis's message
 of "Wed, 19 Jan 2005 10:16:46 -0500")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <a06200704be141b737280@[192.168.1.103]> Edward Lewis <Ed.Lewis@neustar.biz> writes:

> There seems to be commonly held belief that if DNS were to feature the
> ability to answer with data for all names in a zone (present or not),
> the mail protocol designers would be more happy than they are now.

I think it is more than just mail that would benefit.  For example, I
think the RP RR would be more useful if it could be returned for all
names in a domain.  To a lesser extent, the LOC/GPOS RRs could also be
used.  

> [changes needed to make a new form wildcard snipped]
>                                                      My point is that
> this is a change to the code algorithm, meaning that a change of this
> magnitude would mean that we wind up with all of today's DNS servers
> being members of the obsolete corps.  (If you think dealing with only
> yesterday's code as obsolete...)

A couple of things.  Like new RRs, the only servers that would need to
be upgraded for this new form of wildcarding would be those that want
to use it.

Also, *if* the new form of wildcarding could be simulated on the
client side, the transition would be easier.  The client would do the
query, and if the query returned the data, or didn't indicate that the
server supported the new form of wildcarding, then the client could go
do the ugly stuff to simulate it.

Otherwise, yeah, it will take years (decades?) before this new form of
wildcarding could be reliably used.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 14:05:47 -0600
Lines: 30
References: <20050118171058.5588.qmail@xuxa.iecc.com>
	<x4acr6bkl0.fsf@footbone.schlitt.net>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 21:10:41 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <x4acr6bkl0.fsf@footbone.schlitt.net> (wayne@schlitt.net's
 message of "Tue, 18 Jan 2005 13:31:23 -0600")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <x4acr6bkl0.fsf@footbone.schlitt.net> wayne <wayne@schlitt.net> writes:

> [large snip]
>
> Create TXT00-TXT99, all with the TXT RR format.


No one has objected to this idea, so I'll raise it again.

Should we create a bunch of TXT RRs so that people can use them
without worrying about filling up the 512 byte UDP packet?

Remember, *IF* the spf-classic I-D advances with the creation of the
new SPF RR type, and *IF* name server authors think it is worth while
to support the SPR record, then it would be trivial to create these
extra TXT RRs at the same time.  The SPF RR is, after all, just a
clone of the TXT RR.

We could start out small, say only TXT0-TXT9, and if those start
filling up, create TXT10-TXT99.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 14:32:03 -0600
Lines: 68
References: <20050118214225.549E213E12@sa.vix.com>
	<x4u0pd9r63.fsf@footbone.schlitt.net>
	<4ADE1E98E70F1948511B9323@Satori.nominet.org.uk>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 21:38:40 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <4ADE1E98E70F1948511B9323@Satori.nominet.org.uk> (Alex Bligh's
 message of "Wed, 19 Jan 2005 19:25:26 +0000")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <4ADE1E98E70F1948511B9323@Satori.nominet.org.uk> Alex Bligh <alex@alex.org.uk> writes:

> --On 19 January 2005 13:04 -0600 wayne <wayne@schlitt.net> wrote:
>
>> Ok, I confess I don't understand how wildcards and DNSSEC works, but
>> current wildcards are server side only.  So, we could just have an
>> option enable expanded wildcards that defaults to "off".  So, if
>> someone has "foo.*.bar.example.com. IN A 1.2.3.4", that would remain
>> as it is.  The meaning, however, could change for those that want to
>> change it.
>
> Genuine question: what is the perceived advantage of "new type of wildcard"
> over preprocessing?

Good question, and the answer I think is that there isn't much
different between this new kind of wildcard and preprocessing.  Call
it a new preprocessing directive, if you want and start the directive
with a $.

No matter what you call it, I think it would be quite useful to
standardize it's functionality.

One advantage of generating these on the fly ("wildcard") is that
there would be less space taken up in memory, on disk and during zone
transfers compared with preprocessing.


> I know one answer: if the "new wildcard" matches non-existent LABELS,
> and the preprocessing cannot decompose the directive into a selection
> of traditional RR's and wildcards, then preprocessing isn't going to
> work and you are stuck with synthesis (and, with DNSSEC, online signing).
>
> But is there a current known case where this is problematic?

Not that I can think of.  


> foo.&.bar.example.com  (for "&" = new wildcard)
>
> such as I believe is wanted by the SPF folks could be decomposed
> by preprocessing into foo.<label>.bar.example.com records for all
> instances of <label> within bar.example.com. (note config subtlety
> when "within" crosses a zone cut). Whilst it can generate a
> *.bar.example.com RR for "the rest of the zone" as per Ed's
> draft, it's not going to answer to foo.baz.bar.example.com where
> baz does not exist. But is this a problem? IE I thought the tree
> iteration was for where subdomains do not have SPF records, not for
> where subdomains do not exist.

The zone cut stuff in the spf-classic draft is there for both when the
domain exists, and when it doesn't.  Paypal probably wants to be able
to say that "securty.paypal.com" should be rejected as being from
paypal, even if "security.paypal.com" exists.  This is especially a
problem when dealing with the domain used by the SMTP HELO/EHLO
commands since many people generate invalid domain names.  Email
receivers need to be able to distinguish between a "normal"
misconfiguration, and something that the domain owner says should
never happen.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 21:38:19 +0100
Lines: 16
References: <20050118171058.5588.qmail@xuxa.iecc.com><x4acr6bkl0.fsf@footbone.schlitt.net> <x4ekgh9obo.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 21:43:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>No one has objected to this idea, so I'll raise it again.

>Should we create a bunch of TXT RRs so that people can use them
>without worrying about filling up the 512 byte UDP packet?

Is it possible in very condensed way to describe why SPF needs such a
kludge?  That is, SPF could not by using a different naming conventions like
filtering on suffixes, obtain similar results?

Anders R

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 13:07:12 -0800 (PST)
Lines: 44
References: <x4mzv59pbv.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 22:08:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <x4mzv59pbv.fsf@footbone.schlitt.net>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 19 Jan 2005, wayne wrote:

> SPF is not just used in SMTP servers.  For example, SpamAssassin does
> SPF checks and it is often run after the email has been delivered.

SpamAssassin in most cases is integrated as part of MDA and in some 
instances (mimedefang) called as part of its processing.

> There is at least one version that runs after POP/IMAP.
> For Microsoft's CallerID/SenderID, it is my understanding that they
> primarily intended it to be part of the MUA.  Imagine every future
> copy of Outlook having SenderID support built into it.

I'm heavily against this. There is no way they can reliably do path 
authentication of previous server after email was already delivered -
this is just completely against the entire concept of LMAP/MARID.

> So, the answer to your question is that, yes, there are a lot of
> machines that would be trying to run these checks from behind these
> broken firewalls.

In addition it has been position of SPF Community that SenderID is not
part of SPF and that we should not try to acomodate in in any way because
it has way too many problems and uses SPF records incorrectly.

As such we should not be trying to accomodate situations where SID maybe
used as part of SPF Draft specification, especially where we already know
the firewall implementation itself is broken and its vendors fault. 

I still firmly believe that it would be best that SPF start moving and 
using new RR type right away and set deadline (like it was done for
6BONE) for when use of TXT would be depreciated.

-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 13:33:33 -0800 (PST)
Lines: 62
References: <x4acr59n3w.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 22:40:34 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <x4acr59n3w.fsf@footbone.schlitt.net>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 19 Jan 2005, wayne wrote:

> In <4ADE1E98E70F1948511B9323@Satori.nominet.org.uk> Alex Bligh <alex@alex.org.uk> writes:
> 
> > --On 19 January 2005 13:04 -0600 wayne <wayne@schlitt.net> wrote:
> >
> >> Ok, I confess I don't understand how wildcards and DNSSEC works, but
> >> current wildcards are server side only.  So, we could just have an
> >> option enable expanded wildcards that defaults to "off".  So, if
> >> someone has "foo.*.bar.example.com. IN A 1.2.3.4", that would remain
> >> as it is.  The meaning, however, could change for those that want to
> >> change it.
> >
> > Genuine question: what is the perceived advantage of "new type of wildcard"
> > over preprocessing?
> 
> Good question, and the answer I think is that there isn't much
> different between this new kind of wildcard and preprocessing.  Call
> it a new preprocessing directive, if you want and start the directive
> with a $.

Please dont call it that. "$" has special meaning already, for example
"$ORIGIN". As for the rest - yes its kind of like pre-processing and you 
could possibly simulate wildcard with special script before loading zone.

> No matter what you call it, I think it would be quite useful to
> standardize it's functionality.
I agree.
 
> One advantage of generating these on the fly ("wildcard") is that
> there would be less space taken up in memory, on disk and during zone
> transfers compared with preprocessing.
Agreed.
 
> > draft, it's not going to answer to foo.baz.bar.example.com where
> > baz does not exist. But is this a problem? IE I thought the tree
> > iteration was for where subdomains do not have SPF records, not for
> > where subdomains do not exist.

That is possible because I've presented it and I'm slightly more in favor 
of having wildcard with new functionality just for when host exists but
has no RR of that type, so that would not overlap with regular '*', that
seems less prone to problems with existing dns specs and to confusion
with existing '*' to me. It also makes it easier when finding it in 
zonecut based on NODATA answer.

> The zone cut stuff in the spf-classic draft is there for both when the
> domain exists, and when it doesn't. 
And there is nothing that stops somebody who wants this from entering
both new wildcard and '*' record.

-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 13:48:03 -0800 (PST)
Lines: 55
References: <x4u0pd9r63.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 22:51:04 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <x4u0pd9r63.fsf@footbone.schlitt.net>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 19 Jan 2005, wayne wrote:

> In <20050118214225.549E213E12@sa.vix.com> Paul Vixie <paul@vix.com> writes:
> 
> >> >> There's no need for "new" wildcards.
> >
> > i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.
> 
> I agree with Paul here.
Same (and I'd like to emphasise again that it needs to be new wildcard 
type and not expansion of meaning of '*')
 
> > right now, a nonterminal "*" is meaningless to the wildcard algorythm.  it
> > will have to remain meaningless in case someone is using this encoding and
> > depending on it to be meaningless or "just an asterisk label, not special".
> >
> > to add nonterminal wildcards or rrtype-specific wildcards, we will have to
> > define a new encoding that is currently not just meaningless but invalid.
> 
> Ok, I confess I don't understand how wildcards and DNSSEC works,

Entire zone is signed together and thus needs to be downloaded and
client needs to be able to interpret wildcards there.

> but current wildcards are server side only.  So, we could just have an
> option enable expanded wildcards that defaults to "off".  So, if
> someone has "foo.*.bar.example.com. IN A 1.2.3.4", that would remain
> as it is. 

First of all above is FQDN and not interprted/expanded as wildcard.
What I proposed for new wildcards to support prefixes is that be
interprted only at the end of host, i.e. 'sub.%'. If somebody needs
'sub.%.host' then they can do it by moving host into its own
zone and making appropriate NS deligation.

> The meaning, however, could change for those that want to
> change it.  The option would need to be per-zone and there would need
> to be some way of communicating this option to secondar NSs.  One
> really ugly solution to this would be to create a "EWLD" RR type to
> denote that this zone wishes to use extended wildcards.  Like the SOA
> record, the "EWLD" RR would need to be at the zone origin.

I don't see such a solution as being very good one.

--
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 22:53:38 +0100
Lines: 75
References: <Pine.LNX.4.44.0501191258080.7992-100000@sokol.elan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 23:00:51 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <Pine.LNX.4.44.0501191258080.7992-100000@sokol.elan.net>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


Not to pick on this particular mail but we are moving out of scope 
further and further.

I've kept quiet for a long time since some discussion of SPF and its 
distant cousins are inevitable to get a clear understanding about DNS 
properties.

Please try to to keep the discussion on DNS requirements, protocol and 
properties and observe some self-dicipline.

Thanks,

--Olaf
  DNSEXT Co-Chair




william(at)elan.net wrote:

>On Wed, 19 Jan 2005, wayne wrote:
>
>  
>
>>SPF is not just used in SMTP servers.  For example, SpamAssassin does
>>SPF checks and it is often run after the email has been delivered.
>>    
>>
>
>SpamAssassin in most cases is integrated as part of MDA and in some 
>instances (mimedefang) called as part of its processing.
>
>  
>
>>There is at least one version that runs after POP/IMAP.
>>For Microsoft's CallerID/SenderID, it is my understanding that they
>>primarily intended it to be part of the MUA.  Imagine every future
>>copy of Outlook having SenderID support built into it.
>>    
>>
>
>I'm heavily against this. There is no way they can reliably do path 
>authentication of previous server after email was already delivered -
>this is just completely against the entire concept of LMAP/MARID.
>
>  
>
>>So, the answer to your question is that, yes, there are a lot of
>>machines that would be trying to run these checks from behind these
>>broken firewalls.
>>    
>>
>
>In addition it has been position of SPF Community that SenderID is not
>part of SPF and that we should not try to acomodate in in any way because
>it has way too many problems and uses SPF records incorrectly.
>
>As such we should not be trying to accomodate situations where SID maybe
>used as part of SPF Draft specification, especially where we already know
>the firewall implementation itself is broken and its vendors fault. 
>
>I still firmly believe that it would be best that SPF start moving and 
>using new RR type right away and set deadline (like it was done for
>6BONE) for when use of TXT would be depreciated.
>
>  
>


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 16:46:08 -0800
Lines: 66
References: <20050118171058.5588.qmail@xuxa.iecc.com>
	 <x4acr6bkl0.fsf@footbone.schlitt.net> <x4ekgh9obo.fsf@footbone.schlitt.net>
	 <00a201c4fe66$d0474ef0$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: IETF DNSEXT WG <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 01:56:19 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Anders Rundgren <anders.rundgren@telia.com>
In-Reply-To: <00a201c4fe66$d0474ef0$80c5a8c0@rsaedoscymkikx>
X-Mailer: Evolution 2.0.1 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 2005-01-19 at 21:38 +0100, Anders Rundgren wrote:
> > No one has objected to this idea, so I'll raise it again.
> 
> > Should we create a bunch of TXT RRs so that people can use them
> > without worrying about filling up the 512 byte UDP packet?
> 
> Is it possible in very condensed way to describe why SPF needs such a
> kludge?  That is, SPF could not by using a different naming conventions like
> filtering on suffixes, obtain similar results?

SPF uses TXT RR for constructing active content.  Scripts are put into
TXT RR to instruct DNS clients where to do additional lookups. This
script offers macro expansions, redirection, includes, exists, CIDR
notation, and data-set descriptors across perhaps 10 TXT RR, which may
then necessitate any number of other lookups to resolve both addresses
and the existence of other RR records.  Essentially, these scripts offer
authorization for servers that may be in the outbound path of a mail
domain.  (Path Registration.)  This constructed data-set exceeds the
typical scope of a DNS reply.

This scope includes possible ancillary domains and may heavily load TXT
RR as indicated by the required sequence of 10 TXT RR lookups within
various domains to resolve the entire data-set.  To revise the syntax
for these scripts, having yet another TXT RR to burn becomes required,
otherwise this laden script creates overflow conditions when versions
collide.  This is just dealing with a single application usurping the
TXT RR.  Wait for this to become a popular technique.

On top of these scripting woes, the reliance upon the traditional
wildcard does not afford an assurance that a miscreant will not
purposely create a mailbox domain causing a wildcard to not return the
intended default (a closed empty set).  

I would not want to encourage use of TXT records in this manner or this
scheme in general.  There is a general need to establish policy within a
much smaller scope.  This could simply signal various supported
conventions within a single domain.  These signals may be "all emails
are signed", or "all MTAs have a valid HELO".  In the case of CSV, this
is an SRV record prefixed with label.  "Seek and ye shall find" is not
without undesired client-side overhead, but this is still no where near
the overhead being entertained.

Although some may make a case for considering TXT to be good choice for
new DNS extensibility, the use of scripting will likely lead to
inappropriate scopes for replies and create undesired risks as these
scripts inevitably expand in both size and complexity.  A good design
should have a well constrained DNS reply.  Having a means to resolve a
query with a _prefix.&.example.com type of syntax where resolvers are
assured to obtain the desired response would be a useful tool.  I am not
offering a proposal, this is simply stating an ideal.

-Doug






 


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 20:04:12 -0600
Lines: 56
References: <20050118171058.5588.qmail@xuxa.iecc.com>
	<x4acr6bkl0.fsf@footbone.schlitt.net>
	<x4ekgh9obo.fsf@footbone.schlitt.net>
	<00a201c4fe66$d0474ef0$80c5a8c0@rsaedoscymkikx>
	<1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 03:15:22 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org> (Douglas
 Otis's message of "Wed, 19 Jan 2005 16:46:08 -0800")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis <dotis@mail-abuse.org> writes:

> On Wed, 2005-01-19 at 21:38 +0100, Anders Rundgren wrote:
>> > No one has objected to this idea, so I'll raise it again.
>> 
>> > Should we create a bunch of TXT RRs so that people can use them
>> > without worrying about filling up the 512 byte UDP packet?
>> 
>> Is it possible in very condensed way to describe why SPF needs such a
>> kludge?  That is, SPF could not by using a different naming conventions like
>> filtering on suffixes, obtain similar results?

The consise answer:  SPF *doesn't* need the extra clones of the TXT
RR.  My suggestion to create them is entirely due to the strawman
argument in draft-ymbk-dns-choices that the TXT record space is
limited.  It is limited only because no one has expanded it.

Longer answer:  See my original post at:
http://article.gmane.org/gmane.ietf.dnsext/6513



> [...] and data-set descriptors across perhaps 10 TXT RR, which may
> then necessitate any number of other lookups [...]

*sigh*

This is incorrect and shows that Doug Otis has obviously not read the
draft.  Please read the draft before commenting on it.



> [more of the long rant deleted]
>
> I would not want to encourage use of TXT records in this manner or this
> scheme in general.  [...]

Right, instead, with CSV, you encourage the use of SRV records in a
manner totally inconsistent with the SRV RR's description.  Go ahead
and use SRV records for all I care Doug, but don't be a hypocrite.


> [...]                                                           I am not
> offering a proposal, this is simply stating an ideal.

Uh, you aren't offering CSV as a proposal?  That's news to me.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Danny Mayer <mayer@gis.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 20:41:58 -0500
Lines: 17
References: <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
 <20050118211141.2884.qmail@xuxa.iecc.com>
 <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com> <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: "Eric A. Hall" <ehall@ehsco.com>,namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 03:34:30 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
To: Pekka Savola <pekkas@netcore.fi>,John R Levine <johnl@iecc.com>
In-Reply-To: <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
References: <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
 <20050118211141.2884.qmail@xuxa.iecc.com>
 <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
X-Rcpt-To: <namedroppers@ops.ietf.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 12:40 AM 1/19/2005, Pekka Savola wrote:

>We've been there with ECN.  We're there with different DNS equipment 
>breaking AAAA (or anything except A) records.  We'll continue to get there.

And wer're there now with EDNS0 even though it's been in the protocols
for 5 years and still firewalls don't understand the DNS UDP packets can
be larger than 512 bytes.

Danny


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Danny Mayer <mayer@gis.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 21:16:46 -0500
Lines: 56
References: <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <20050118211141.2884.qmail@xuxa.iecc.com>
 <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
 <Pine.LNX.4.61.0501190735350.32749@netcore.fi> <Pine.BSI.4.56.0501190145590.19226@tom.iecc.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 Thu Jan 20 03:34:28 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
To: "John R Levine" <johnl@iecc.com>,"Pekka Savola" <pekkas@netcore.fi>
In-Reply-To: <Pine.BSI.4.56.0501190145590.19226@tom.iecc.com>
References: <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <20050118211141.2884.qmail@xuxa.iecc.com>
 <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
 <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
X-Rcpt-To: <namedroppers@ops.ietf.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 01:49 AM 1/19/2005, John R Levine wrote:
> > Probably.  But how many of those SMTP servers which need to make these
> > lookups, or how many DNS servers (providing information about that
> > site's zone) are behind such firewalls?
>
>DNS servers, probably not many.  SMTP servers, lots of them.  They're
>running Exchange, if they weren't behind a firewall they wouldn't last
>five minutes.
>
> > There's no doubt there's breakage out there, but the point is whether
> > we need to care about it.
>
>As Dan B. noted, the MS firewall is the biggest single collection of RR
>brokenware, but there's plenty more in the form of obsolete versions of
>BIND and other DNS software that people are still running.
>
>I'm not saying that we should give up and never ever add a new RR type,
>but I am saying that requiring a new RR is in 2005 a major bar to
>widespread deployment.

I think this is being overblown. You need to look at the interaction vector.
What DNS servers need to know about the new RRs?

The two endpoints:
one the SMTP server receiving the request and the other the domain that
is purporting to be the sender. They have every incentive to upgrade their
DNS Servers to support the new type. If they don't support it then the
query will fail anyway.
The only other ones that are involved in the lookup are:
the root servers, which really don't care about the type as they will only
hand you a referral anyway and in any case are regularly upgrade to support
new types;
the TLD's which again will just hand out a referral and are also
upgraded regularly.

  What other DNS's need to be involved and for what?

Danny

>Regards,
>John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for 
>Dummies",
>Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
>"I dropped the toothpaste", said Tom, crestfallenly.
>
>--
>to unsubscribe send a message to namedroppers-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:46:14 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 19 Jan 2005 21:33:57 -0500
Lines: 18
References: <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <20050118211141.2884.qmail@xuxa.iecc.com> <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com> <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <4.3.1.2.20050119210906.02699400@pop.gis.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 Jan 20 03:37:59 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Danny Mayer" <mayer@gis.net>
In-Reply-To: <4.3.1.2.20050119210906.02699400@pop.gis.net>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> I think this is being overblown. You need to look at the interaction vector.
> What DNS servers need to know about the new RRs?

Only the ones the serve them, but unfortunately the caches in front of
every client that want to use them need to know about them too.  In theory
caches should treat unknown RR types reasonably, in practice, a lot of
them don't.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Thu, 20 Jan 2005 04:06:57 +0100
Lines: 29
References: <20050118171058.5588.qmail@xuxa.iecc.com><x4acr6bkl0.fsf@footbone.schlitt.net><x4ekgh9obo.fsf@footbone.schlitt.net><00a201c4fe66$d0474ef0$80c5a8c0@rsaedoscymkikx><1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org> <x41xcgamar.fsf@footbone.schlitt.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 Jan 20 04:12:41 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>wayne wrote:
>The consise answer:  SPF *doesn't* need the extra clones of the TXT
>RR.  My suggestion to create them is entirely due to the strawman
>argument in draft-ymbk-dns-choices that the TXT record space is
>limited.  It is limited only because no one has expanded it.

"the TXT record space is limited"

Is this really the case? I cannot find any such limitations.

Is it not rather the selection mechanisms used by various protocols
that is the culprit?  In addition to limitations in the select itself w r t wildcarding,

Yahoo's DomainKeys do not have any such problems as they selected a suffix scheme:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html

It appears that creating new types because you have a "bad select" that
gives you things you do not want, is a rather unusual way of solving problems. 

Is this problem BTW for real?  That is, is POBOX.COM admitting they have a
problem with SPF?

Anders R

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 22:12:37 -0600
Lines: 54
References: <20050118171058.5588.qmail@xuxa.iecc.com>
	<x4acr6bkl0.fsf@footbone.schlitt.net>
	<x4ekgh9obo.fsf@footbone.schlitt.net>
	<00a201c4fe66$d0474ef0$80c5a8c0@rsaedoscymkikx>
	<1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org>
	<x41xcgamar.fsf@footbone.schlitt.net>
	<003e01c4fe9d$1e1ec4b0$80c5a8c0@rsaedoscymkikx>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 05:18:19 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <003e01c4fe9d$1e1ec4b0$80c5a8c0@rsaedoscymkikx> (Anders
 Rundgren's message of "Thu, 20 Jan 2005 04:06:57 +0100")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <003e01c4fe9d$1e1ec4b0$80c5a8c0@rsaedoscymkikx> "Anders Rundgren" <anders.rundgren@telia.com> writes:

>>wayne wrote:
>>The consise answer:  SPF *doesn't* need the extra clones of the TXT
>>RR.  My suggestion to create them is entirely due to the strawman
>>argument in draft-ymbk-dns-choices that the TXT record space is
>>limited.  It is limited only because no one has expanded it.
>
> "the TXT record space is limited"
>
> Is this really the case? I cannot find any such limitations.

According to dns-choices, yes, the space is limited.  See section 3.1.


> Is it not rather the selection mechanisms used by various protocols
> that is the culprit?  In addition to limitations in the select itself w r t wildcarding,
>
> Yahoo's DomainKeys do not have any such problems as they selected a suffix scheme:
> http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html

The terminology used in dns-choices for this is "prefix" rather than
"suffix".  It is also argued against in dns-choices.


> It appears that creating new types because you have a "bad select" that
> gives you things you do not want, is a rather unusual way of solving problems. 
>
> Is this problem BTW for real?  That is, is POBOX.COM admitting they have a
> problem with SPF?

I do not believe that there is any serious problem with SPF's use of
TXT RRs.  I have done studies (posted to the MARID list) that shows
that the vast majority of SPF records are very short and that there
are not many domains that have TXT RRsets that are already close to
the 512B UDP DNS limit.  In cases where the RRset is already pretty
full, a short SPF record of "v=spf1 redirect=_spf.%{d}" will solve the
problem, with the cost of one more DNS lookup (and therefore one less
DNS lookup that can be used on the redirected record).


Again, my suggestion to create additional TXT RRs of TXT0-TXT9 is
solely to addressed the claimed problems as found in dns-choices.  SPF
will survive just fine without them.


-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Wed, 19 Jan 2005 20:18:23 -0800
Lines: 68
References: <20050118171058.5588.qmail@xuxa.iecc.com>
	 <x4acr6bkl0.fsf@footbone.schlitt.net> <x4ekgh9obo.fsf@footbone.schlitt.net>
	 <00a201c4fe66$d0474ef0$80c5a8c0@rsaedoscymkikx>
	 <1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org>
	 <x41xcgamar.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 05:23:42 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <x41xcgamar.fsf@footbone.schlitt.net>
X-Mailer: Evolution 2.0.1 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 2005-01-19 at 20:04 -0600, wayne wrote:
> In <1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis <dotis@mail-abuse.org> writes:
> 
> > On Wed, 2005-01-19 at 21:38 +0100, Anders Rundgren wrote:
> >> > No one has objected to this idea, so I'll raise it again.
> >> 
> >> > Should we create a bunch of TXT RRs so that people can use them
> >> > without worrying about filling up the 512 byte UDP packet?
> >> 
> >> Is it possible in very condensed way to describe why SPF needs such a
> >> kludge?  That is, SPF could not by using a different naming conventions like
> >> filtering on suffixes, obtain similar results?

> > [...] and data-set descriptors across perhaps 10 TXT RR, which may
> > then necessitate any number of other lookups [...]
> 
> This is incorrect and shows that Doug Otis has obviously not read the
> draft.  Please read the draft before commenting on it.

I said this to explain the desire to have more TXT records or the desire
to redefine the Class field.  This is only related to a problem created
by attempts to use the current wildcard and thus usurping a TXT RR.

pobox still lists
http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt

as the current specification for the SPF record.  This draft says 10
lookups is required.  How can you say it is now less?  Did you change
the version of the record?  What draft was applied when publishing and
which is applied when reading?  I did not see a limit on the number of
sequential TXT RR in the "alternative" draft?  Hard to tell who is using
which definition.  : (

I said this to illustrate that these records may use a substantial
portion of the packet and hence the danger created attempting to use a
common label or a wildcard scheme.  The current wildcard scheme can not
be used to assert policy, so this issue of duplicate records types
should be dropped.

> > [...] I am not offering a proposal, this is simply stating an ideal.
> 
> Uh, you aren't offering CSV as a proposal?  That's news to me.

I did not want to imply I was proposing a DNS wildcard scheme.  The CSV
proposal does not utilize a wildcard.  In fact, it can not, so the CSV
proposal will not interfere with the use of this record type.  There
will never come a time when someone will be lamenting there should be
100 duplicate SRV record types, even if you don't like how something is
defined for this particular label.

Suggesting a needing more TXT RR or Class designators is fruitless.  A
new wildcard that can handle a prefix, not collide with other record
types, or empty labels, would offer less overhead.  This changes how
resolvers track the name space, how records are exchanged between
servers, and of course how things are signed.  Using a label prefix is
really the only current workable alternative.

-Doug





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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Danny Mayer <mayer@gis.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Thu, 20 Jan 2005 00:36:34 -0500
Lines: 24
References: <4.3.1.2.20050119210906.02699400@pop.gis.net>
 <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <20050118211141.2884.qmail@xuxa.iecc.com>
 <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
 <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <4.3.1.2.20050119210906.02699400@pop.gis.net> <Pine.BSI.4.56.0501192132480.25619@tom.iecc.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 Thu Jan 20 06:46:46 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
To: "John R Levine" <johnl@iecc.com>
In-Reply-To: <Pine.BSI.4.56.0501192132480.25619@tom.iecc.com>
References: <4.3.1.2.20050119210906.02699400@pop.gis.net>
 <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <20050118211141.2884.qmail@xuxa.iecc.com>
 <41EDB677.2090209@ehsco.com>
 <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
 <Pine.LNX.4.61.0501190735350.32749@netcore.fi>
 <4.3.1.2.20050119210906.02699400@pop.gis.net>
X-Rcpt-To: <namedroppers@ops.ietf.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 09:33 PM 1/19/2005, John R Levine wrote:
> > I think this is being overblown. You need to look at the interaction 
> vector.
> > What DNS servers need to know about the new RRs?
>
>Only the ones the serve them, but unfortunately the caches in front of
>every client that want to use them need to know about them too.  In theory
>caches should treat unknown RR types reasonably, in practice, a lot of
>them don't.

Exactly which caches are you referring to? Unless you are doing forwarding
you shouldn't need to worry and if you are you should stop doing that
anyway as it really doesn't buy you much. It's the local DNS that needs to
understand the RR type as well as the clients themselves. If you are not
talking about DNS servers then it's irrelevant here.

Danny


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: 20 Jan 2005 00:59:37 -0500
Lines: 40
References: <4.3.1.2.20050119210906.02699400@pop.gis.net>
 <Pine.LNX.4.61.0501190735350.32749@netcore.fi> <20050118211141.2884.qmail@xuxa.iecc.com>
 <41EDB677.2090209@ehsco.com> <Pine.BSI.4.56.0501182046590.28669@tom.iecc.com>
 <Pine.LNX.4.61.0501190735350.32749@netcore.fi> <4.3.1.2.20050119210906.02699400@pop.gis.net>
 <4.3.1.2.20050120003057.026df7b8@pop.gis.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 Jan 20 07:04:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Danny Mayer" <mayer@gis.net>
In-Reply-To: <4.3.1.2.20050120003057.026df7b8@pop.gis.net>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > > What DNS servers need to know about the new RRs?
> >
> >Only the ones the serve them, but unfortunately the caches in front of
> >every client that want to use them need to know about them too.  In theory
> >caches should treat unknown RR types reasonably, in practice, a lot of
> >them don't.
>
> Exactly which caches are you referring to?

Uh, the ones in front of the clients, like I said.  Surely you aren't
proposing that DNS clients should run without caches and hammer on the
servers.  The cache may well be on the same host as the client, but it's
still a cache and it can screw up.

> Unless you are doing forwarding you shouldn't need to worry and if you
> are you should stop doing that anyway as it really doesn't buy you much.
> It's the local DNS that needs to understand the RR type as well as the
> clients themselves. If you are not talking about DNS servers then it's
> irrelevant here.

If only life were that simple.  In an ideal world, everyone who wrote a
DNS cache or firewall proxy would have read and understood RFC 3597, and
caches and proxies would handle all RR types properly and transparently.
Unfortunately, in this world, things are a mess.  As I've pointed out in
several previous messages, hosts behind MS firewalls can't query for any
RR types other than the ones the firewall explictly supports, and I gather
that other caches have been known to screw up unexpected RRs as well.
That's the problem, that's why you have to be sure that the cache and, if
there is one, firewall in front of the client can handle new RRs, too.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Thu, 20 Jan 2005 07:14:33 +0100
Lines: 46
References: <20050118171058.5588.qmail@xuxa.iecc.com><x4acr6bkl0.fsf@footbone.schlitt.net><x4ekgh9obo.fsf@footbone.schlitt.net><00a201c4fe66$d0474ef0$80c5a8c0@rsaedoscymkikx><1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org><x41xcgamar.fsf@footbone.schlitt.net><003e01c4fe9d$1e1ec4b0$80c5a8c0@rsaedoscymkikx> <x4mzv491sa.fsf@footbone.schlitt.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 Jan 20 07:20:03 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>wayne wrote
>> "the TXT record space is limited"
>>
>> Is this really the case? I cannot find any such limitations.

>According to dns-choices, yes, the space is limited.  See section 3.1.

I believe it is talking about something else than about storing huge amounts of
properly named TXT records and then retrieving them which was my concern.

>> Yahoo's DomainKeys do not have any such problems as they selected a suffix scheme:
>> http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html

>The terminology used in dns-choices for this is "prefix" rather than
>"suffix".  It is also argued against in dns-choices.

The suffix scheme described in dns-choices is *unknown* by the development community.

No, dns-choices avoided describing this scheme as it solves most
real problems.  Prefxes are leftmost elements only.  In DomainKeys
 "_domainkey" (aka the "real" datatype) can serve as prefix AND suffix
depending on the query.


>> Is this problem BTW for real?  That is, is POBOX.COM admitting they have a
>> problem with SPF?

>I do not believe that there is any serious problem with SPF's use of
>TXT RRs.  I have done studies (posted to the MARID list) that shows
>that the vast majority of SPF records are very short and that there
>are not many domains that have TXT RRsets that are already close to
>the 512B UDP DNS limit.  In cases where the RRset is already pretty
>full, a short SPF record of "v=spf1 redirect=_spf.%{d}" will solve the
>problem, with the cost of one more DNS lookup (and therefore one less
>DNS lookup that can be used on the redirected record).

I'm in no way certain on this but it is possible that SPF by using a
"midfix" scheme a la DomainKeys could do much better.

Anders

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: wayne <wayne@schlitt.net>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Thu, 20 Jan 2005 09:16:51 -0600
Lines: 35
References: <20050118171058.5588.qmail@xuxa.iecc.com>
	<x4acr6bkl0.fsf@footbone.schlitt.net>
	<x4ekgh9obo.fsf@footbone.schlitt.net>
	<00a201c4fe66$d0474ef0$80c5a8c0@rsaedoscymkikx>
	<1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org>
	<x41xcgamar.fsf@footbone.schlitt.net>
	<1106194703.9675.186.camel@SJC-Office-DHCP-156.mail-abuse.org>
Reply-To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 16:31:24 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-Reply-To: <1106194703.9675.186.camel@SJC-Office-DHCP-156.mail-abuse.org> (Douglas
 Otis's message of "Wed, 19 Jan 2005 20:18:23 -0800")
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture,
 linux)
Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net;
X-SA-Exim-Connect-IP: 206.222.212.237
X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200)
X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

In <1106194703.9675.186.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis <dotis@mail-abuse.org> writes:

> On Wed, 2005-01-19 at 20:04 -0600, wayne wrote:
>
>> > [...] and data-set descriptors across perhaps 10 TXT RR, which may
>> > then necessitate any number of other lookups [...]
>> 
>> This is incorrect and shows that Doug Otis has obviously not read the
>> draft.  Please read the draft before commenting on it.
>
> I said this to explain the desire to have more TXT records or the desire
> to redefine the Class field.  This is only related to a problem created
> by attempts to use the current wildcard and thus usurping a TXT RR.
>
> pobox still lists
> http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt
>
> as the current specification for the SPF record.

That draft was not brought forth to be discussed on this mailing
list.  It is old.  For better or worse, I do not control Meng's
website.  I've asked Meng before to change it, and I'll ask him again.
If you are not sure what is being discussed on this mailing list,
please read the archives.



-wayne


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Thu, 20 Jan 2005 16:39:41 +0000
Lines: 37
References: <dotis@mail-abuse.org>
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 17:46:47 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: Message from Douglas Otis <dotis@mail-abuse.org> 
	of "Wed, 19 Jan 2005 16:46:08 PST."
	<1106181968.9675.87.camel@SJC-Office-DHCP-156.mail-abuse.org> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

doug wrote:

> On top of these scripting woes, the reliance upon the traditional
> wildcard does not afford an assurance that a miscreant will not
> purposely create a mailbox domain causing a wildcard to not return the
> intended default (a closed empty set).  
> 
> I would not want to encourage use of TXT records in this manner or this
> scheme in general.  There is a general need to establish policy within a
> much smaller scope.  ...

i agree with this analysis, but i still don't understand why we're talking
about SPF at all.  SPF as it is today will not be changed because of the
installed base.  (in fact, without a pre-existing installed base, SPF as
it is could not, today, be created, at least not by an open standards
process.)  what's at issue here is not therefore "what should SPF have been."

SPF as it is proposed to be changed (with extra lookups to discover SOA's)
does not yet exist and has no installed base.  for various reasons covered
elsewhere in this thread, using SOA's in this way is a layering violation
and is unlikely to become an ietf standard.

that appears to be the end of the line for namedroppers, other than the
interesting side discussion of "should we create per-rrtype wildcards,
nonterminal wildcards, and name-range wildcards?" which is not likely to
produce a definitive standard in time to help the SPF people figure out
how to leverage their existing installed base by adding more functionality.

can the chairs please ask "is there a WG item lurking in all this text?"

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:46:14 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: wcard clarify
Date: Thu, 20 Jan 2005 11:44:18 -0500
Lines: 26
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ed.lewis@neustar.biz
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 17:55:32 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

For some reason last fall, the wcard-04 document never made it into 
the ID repository.  I am about to make edits to -04 that was 
distributed on the list, producing what I will label -05.

What I will do, to make the version numbers line up, is try and 
submit -04 again.  No one need comment on it, you can if you will, as 
I already have some edits in the queue.

If you see it and want to think about it, think about the 
implications of DNSSEC on the draft.  Going back in versions, the 
original draft included DNSSEC, dropped it in an effort to make this 
draft go faster, then say the draft hit a spin cycle and DNSSEC 
passed it again.  So, putting DNSSEC considerations back in isn't 
that far fetched.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Meng Weng Wong <mengwong@dumbo.pobox.com>
Subject: Re: confusion caused by http://spf.pobox.com/rfcs.html
Date: Thu, 20 Jan 2005 13:45:37 -0500
Lines: 31
References: <x4d5w086d3.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 19:55:20 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
Content-Disposition: inline
In-Reply-To: <x4d5w086d3.fsf@footbone.schlitt.net>
User-Agent: Mutt/1.3.25i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

ok, send me the new HTML and i will put it in... i'll send a
post to spf-council about doing a dev server.

On Thu, Jan 20, 2005 at 09:31:20AM -0600, wayne wrote:
| 
| Hi Meng
| 
| The web page http://spf.pobox.com/rfcs.html still lists the Lentczner
| draft of Oct 2004 as the "current SPF Protocol Specification" and
| still says that a "libspf2" version will be available shortly.
| 
| I know I've asked you to update the libspf2 part last Nov, and I guess
| I had assumed that you would update the "current spec" part after the
| council meetings.  I realize that you are very busy right now with the
| EL contract stuff, but could you please update that page?  It is
| causing confusion in the IETF.
| 
| Also, if you could review the current draft and tell me what needs to
| be changed, I would greatly appreciate it.  Again, I realize that you
| are very busy right now, but if the IETF decides to advance it,
| changes will be harder.
| 
| 
| -wayne
| 

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-04.txt
Date: Thu, 20 Jan 2005 15:52:49 -0500
Lines: 92
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 22:02:20 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: i-d-announce@ietf.org
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Clarifying the Role of Wild Card Domains in the Domain Name System
	Author(s)	: E. Lewis
	Filename	: draft-ietf-dnsext-wcard-clarify-04.txt
	Pages		: 18
	Date		: 2005-1-20
	
The definition of wild cards is recast from the original in RFC 1034,
in words that are more specific and in line with RFC 2119.  This
document is meant to supplement the definition in RFC 1034 and to
alter neither the spirit nor intent of that definition.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-wcard-clarify-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-wcard-clarify-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:	<2005-1-20161710.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-04.txt

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

Content-Type: text/plain
Content-ID:	<2005-1-20161710.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:46:14 2006
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>
Subject: Weird Wildcards Work item  (on wildcards vs RR types, was Faux
  wildcards)
Date: Thu, 20 Jan 2005 16:25:16 -0500
Lines: 67
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Thu Jan 20 22:51:17 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
To: namedroppers@ops.ietf.org
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


There seems to be in some peoples mind  a "need" for mechanism to do a
wild-card "like" thing.

Without having clear requirements and usage examples it is hard to judge what
is wanted by the different people that have posted on the "Faux wildcards" and
"wildcards vs RR types" topic.  On the other hand we think that, given that we
have been going in circles, continuing on list will not lead us anywhere.

The chairs would like to propose the following path forward.


We assume that there will be a number of stake holders for such a
"Weird Wildcard Workitem"  and we would like them to take some time
to produce the following:

1. Requirement statement
2. Draft rules for proposed mechanism the rules must address at least
    the following questions:
	a. is this both/either a terminal or non terminal

	b. does this match:
		only existing names
		only non-existing names
		both

	c. Is this mechanism terminated by
		existing name
		delegation
	   if the answer is "delegation" then answer sub question
		how does same type at a name affect expansion 	
		
	d. Is this mechanism expanded to one or multiple labels
	
	e. If answer is multiple levels how are multiple expansion statements
	   for the same type handled.

3. Usage example or two.

4. List of active participants

Issues like how this is expressed in zone files and zone transfer do not
have to be included at this point, nor do issues like DNSSEC or
dynamic update interaction.


After this has been drafted we'll verify if this work can be done within
charter of this group and if there are sufficient people available that
actually are willing and able to do the work.

So essentially we are asking a small requirements-design team to form
that will do their work on the 0th version.  In order to bootstrap this
process stakeholders can contact Olafur (ogud at ogud.com) who will subscribe
them to a mailing list. The list will be discontinued and the archives of
the mailing list will be made available once version 0 is available.

We hope that the working group can have an in depth, in scope and
focused discussion on such version 0.

	Olafur and Olaf


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: DNS container objects & virtual data types
Date: Fri, 21 Jan 2005 08:08:01 +0100
Lines: 37
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Fri Jan 21 08:17:52 2005
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

DNS container objects
=====================
Disregarding the discussion about overloading, misuse etc. I suggest
that DNS RRs objects that does not have defined semantics, which today
spells TXT and later will include XML and BINary as well, should merely
be regarded as "container objects".

Container objects' sole mission is to hold external representations of
objects associated with virtual DNS data types.

DNS virtual data types
======================
A "virtual" DNS data type is a data type that is identified by a unique DNS 
label-set, preferably in the form of a translated URI.  Virtual data types
- Have globally unique names
- Do not rely on a particular registry
- Are equally applicable to private and public data types
- Can be used instantly
- Operate at the same speed as intrinsic DNS data types

[arg,]unique-name[.arg]    container-type   external-representation

Due to the fact that virtual data types are compatible with the existing
DNS infrastructure, there is nothing to "solve" or overcome, except
maybe some mental hurdles.  It seems that three different external
representations should cover most real-world applications.

It is important to note that this scheme is by no means new, it is simply the
de-facto standard in a documented and to some extent refined format.

Anders R

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: David Blacka <davidb@verisignlabs.com>
Subject: Re: Weird Wildcards Work item  (on wildcards vs RR types, was Faux
  wildcards)
Date: Fri, 21 Jan 2005 12:11:39 -0500
Organization: VeriSign, Inc.
Lines: 87
References: <6.2.0.14.2.20050120161507.04493db8@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-From: owner-namedroppers@ops.ietf.org Fri Jan 21 18:22:43 2005
Return-path: <owner-namedroppers@ops.ietf.org>
Received-SPF: unknown (Address does not pass the Sender Policy Framework)
  SPF=HELO;
  sender=[10.131.244.227];
  remoteip=::ffff:172.25.170.10;
  remotehost=;
  helo=[10.131.244.227];
  receiver=mail.verisignlabs.com;
Received-SPF: unknown (IP address lookup failed.?)
  SPF=MAILFROM;
  sender=davidb@verisignlabs.com;
  remoteip=::ffff:172.25.170.10;
  remotehost=;
  helo=[10.131.244.227];
  receiver=mail.verisignlabs.com;
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
To: namedroppers@ops.ietf.org
In-Reply-To: <6.2.0.14.2.20050120161507.04493db8@localhost>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Ólafur Gudmundsson/DNSEXT co-chair wrote:
> 
> There seems to be in some peoples mind  a "need" for mechanism to do a
> wild-card "like" thing.
> 
> Without having clear requirements and usage examples it is hard to judge 
> what
> is wanted by the different people that have posted on the "Faux 
> wildcards" and
> "wildcards vs RR types" topic.  On the other hand we think that, given 
> that we
> have been going in circles, continuing on list will not lead us anywhere.

While I'm not personally invested in a new wildcard mechanism, I would
like to attempt to contribute to the discussion of what the issues
are at the risk of restating the obvious.

It seems to me that when non-experts look at wildcards they come to
one of two conclusions:

1. Wildcards don't match enough.

2. Wildcards match too much.


Don't match enough:

My experience has generally shown that when a naive user is introduced
to wildcards, they generally expect the wildcards to apply in more
situations than they actually do, leading to long-standing common
errors (c.f. RFC 1034, section 4.3.3).  The classic wildcard MX:

   $ORIGIN example.com
   *     IN MX  10 a
   a     IN A   1.2.3.4
   b     IN A   1.2.3.5
   mail  IN MX  b

The naive user generally expects the wildcard to match <c.example.com,
MX> (which it will), <a.example.com, MX> (which it won't), and
possibly even <b.a.example.com, MX>, but not <mail.example.com, MX>.

That is, a possibly more natural interpretation of the wildcard is one
of: this is the default MX record for the zone, use it when no other
MX in the zone applies.


Match too much:

This typically comes up when folks struggle with wildcards interacting
with DNS records that use so-called "name hacks", like the SRV.  "Why
can't I have a wildcard SRV?", they ask.  Why cannot a DNS server
exhibit a great deal of control over how a wildcard matches?  So we
see proposals that look like:

   _http._tcp.*.example.com. IN SRV ....

where the expected behavior is that <_http._tcp.foo.example.com, SRV>
matches, but <bar.example.com., SRV> does not, and
<_smtp._tcp.foo.example.com., SRV> certainly does not.

The limits of how much control this wildcard mechanism should have are
not typically well explored by such proposals.  However, the example
above might be considered a lower bound of control.  An upper bound
might be to use regular expressions as wildcard matching rules. (Not
that regular expressions represent a real upper limit -- any
arbitrarily complex language could be defined).

While I personally cannot think of many interesting uses for an
expressive (say regular expression-based) selectively matching
wildcard, my gut feeling is that there would be.

I do not necessarily think that there is a call for multiple new
wildcard mechanisms.  The first issue (match too little) could be
handled by a zone pre-processor (by which I mean that the desired
semantics are *expressible* using current DNS, but just verbose),
and/or a single new mechanism could encompass both behavioral issues.

-- 
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:46:14 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: Weird Wildcards Work item  (on wildcards vs RR types, was
 Faux   wildcards)
Date: Fri, 21 Jan 2005 14:19:15 -0500
Lines: 58
References: <6.2.0.14.2.20050120161507.04493db8@localhost>
 <41F137CB.3090302@verisignlabs.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 Fri Jan 21 20:29:38 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <41F137CB.3090302@verisignlabs.com>
To: David Blacka <davidb@verisignlabs.com>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Very tangentially -

At 12:11 -0500 1/21/05, David Blacka wrote:

>I do not necessarily think that there is a call for multiple new
>wildcard mechanisms.  The first issue (match too little) could be
>handled by a zone pre-processor (by which I mean that the desired
>semantics are *expressible* using current DNS, but just verbose),
>and/or a single new mechanism could encompass both behavioral issues.

BTW, we ought to rewrite the SRV document to fix the 
misunderstandings it engenders.  E.g., I tried to load an SRV record 
to a name without underscored "prefixes" and it worked in BIND 9.2.2. 
(That was just a handy implementation/build.)

The SRV naming "convention" doesn't change the query processing.

 From that RFC:

#        _Service._Proto.Name TTL Class SRV Priority Weight Port Target
...
#   Name
#       The domain this RR refers to.  The SRV RR is unique in that the
#       name one searches for is not this name; the example near the end
#       shows this clearly.

The name queried for is still "_Service._Proto.Name", it is not 
"Name" (as stated in the RFC).

Later,

#   In this example, a client of the "foobar" service in the
#  "example.com." domain needs an SRV lookup of
#  "_foobar._tcp.example.com."

Basically, what the SRV did was create a convention by which 
applications would look up specific things in the DNS - which is what 
is supposed to be the case.

The SRV RR isn't broken, the description of it is.

I was thinking about this while reading David's message.  One 
underlying problem is the misperception that host name = domain name 
(and vice versa for the non-mathematical coding types).  1123 is not 
1034/1035.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Eric A. Hall" <ehall@ehsco.com>
Subject: Re: Weird Wildcards Work item  (on wildcards vs RR types, was Faux
  wildcards)
Date: Fri, 21 Jan 2005 14:23:54 -0500
Lines: 65
References: <6.2.0.14.2.20050120161507.04493db8@localhost> <41F137CB.3090302@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 Fri Jan 21 20:30:20 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
To: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <41F137CB.3090302@verisignlabs.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On 1/21/2005 12:11 PM, David Blacka wrote:

> Don't match enough:
> 
> My experience has generally shown that when a naive user is introduced
> to wildcards, they generally expect the wildcards to apply in more
> situations than they actually do, leading to long-standing common
> errors (c.f. RFC 1034, section 4.3.3).  The classic wildcard MX:
> 
>    $ORIGIN example.com
>    *     IN MX  10 a
>    a     IN A   1.2.3.4
>    b     IN A   1.2.3.5
>    mail  IN MX  b
> 
> The naive user generally expects the wildcard to match <c.example.com,
> MX> (which it will), <a.example.com, MX> (which it won't), and
> possibly even <b.a.example.com, MX>, but not <mail.example.com, MX>.
> 
> That is, a possibly more natural interpretation of the wildcard is one
> of: this is the default MX record for the zone, use it when no other
> MX in the zone applies.

This has long been a problem, and I've long been planning to write an I-D
on ways to deal with it.

Personally I think the best way to do this is to define a $DEFAULT
zonefile directive, with the value applying to any domain name which did
not have the declared RRtype[s] explicitly defined. For example, "$DEFAULT
MX 0 mailhost.example.com." would mean "all defined domain names have a
default MX that points to mailhost.example.com, unless there is an
explicit MX RR defined for that domain name". The use of a zone directive
solves the problem elegantly, in that it can be used for any domain name
that the zone is authoritative for. The big problem with this approach is
that zone directives aren't really supported; even though directives are
(somewhat) defined in STD13, they aren't really supported in transfers,
and there are a number of server implementations that don't really embrace
the concept either. Personally I still think that this is the best way to
go, and that secondary work items (like adding explicit support for zone
directives to xfers) is important and necessary anyway, and would be
useful for other work efforts (some of my i18n work made use of directives
also, and suffered from the same problems).

Another path I had explored here was defining a zone-cut RR that would
essentially append additional attributes to the SOA RR (or any names that
ended with the same suffix as the defined RR). The big problem here is
that there's a lot of sub-typing invovled, and that's actually more work
in the end, I think. For example, defining a default mail server means "ZC
[MX 0 mailhost.example.com.]" with the MX RR being formally sub-typed.
Going this route is feasible, but at minimum requires that every new RR be
added to the sub-type list, and at maximum requires significant amounts of
data-typing and inheritance rules. That's probably good too, if it were
ever to get done, and I have had such a need for other projects too, but
it's actually a lot more work.

-- 
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:46:14 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: Weird Wildcards Work item  (on wildcards vs RR types, was
 Faux   wildcards)
Date: Fri, 21 Jan 2005 14:36:49 -0500
Lines: 31
References: <6.2.0.14.2.20050120161507.04493db8@localhost>
 <41F137CB.3090302@verisignlabs.com> <41F156CA.7030004@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 21 20:41:12 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <41F156CA.7030004@ehsco.com>
To: "Eric A. Hall" <ehall@ehsco.com>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 14:23 -0500 1/21/05, Eric A. Hall wrote:

>Personally I think the best way to do this is to define a $DEFAULT
...
>that the zone is authoritative for. The big problem with this approach is
>that zone directives aren't really supported; even though directives are
>(somewhat) defined in STD13, they aren't really supported in transfers,

...do they need to be?  Once you've expanded the directive (think 
$GENERATE, $TTL, $ORIGIN), there's no need to push it to other 
servers.

>and there are a number of server implementations that don't really embrace
>the concept either. Personally I still think that this is the best way to

...the concept of zone files, yeah.  That's the problem with zone 
file directives.   But there's no reason a zone file implementation 
couldn't try it out.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Eric A. Hall" <ehall@ehsco.com>
Subject: Re: Weird Wildcards Work item  (on wildcards vs RR types, was Faux
   wildcards)
Date: Fri, 21 Jan 2005 14:53:15 -0500
Lines: 43
References: <6.2.0.14.2.20050120161507.04493db8@localhost> <41F137CB.3090302@verisignlabs.com> <41F156CA.7030004@ehsco.com> <a06200709be1709a99fd2@[10.31.32.183]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 21 20:58:50 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
To: Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <a06200709be1709a99fd2@[10.31.32.183]>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



On 1/21/2005 2:36 PM, Edward Lewis wrote:

> At 14:23 -0500 1/21/05, Eric A. Hall wrote:

>>that zone directives aren't really supported; even though directives are
>>(somewhat) defined in STD13, they aren't really supported in transfers,
>
> ...do they need to be?  Once you've expanded the directive (think
> $GENERATE, $TTL, $ORIGIN), there's no need to push it to other
> servers.

It's certainly possible for the master to expand the directive prior to
transfer (and there wouldn't be any difference in the data that the
replication partners served out), but in the general case it would be more
efficient to have the servers be able to exchange meta-data explicitly,
rather than the expanded data. Things like large blocks of textual data
(like SPF, or worse, Sender-ID), which you don't really need/want to
duplicate for each and every entry in the zone.

>>and there are a number of server implementations that don't really embrace
>>the concept either. Personally I still think that this is the best way to
> 
> ...the concept of zone files, yeah.  That's the problem with zone 
> file directives.   But there's no reason a zone file implementation 
> couldn't try it out.

I don't see zone directives as necessarily being tied to zone "files";
they are a useful construct for zones in general. I mean, there are
servers that support things like variable-expansion and default values
already, and a generalized "zone directive" (as specifically opposed to a
"zone file directive") would be useful to formalize.

-- 
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:46:14 2006
From: "william(at)elan.net" <william@elan.net>
Subject: Re: Weird Wildcards Work item  (on wildcards vs RR types, was Faux
   wildcards)
Date: Fri, 21 Jan 2005 12:07:17 -0800 (PST)
Lines: 60
References: <a06200709be1709a99fd2@[10.31.32.183]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: "Eric A. Hall" <ehall@ehsco.com>, David Blacka <davidb@verisignlabs.com>,
        <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Fri Jan 21 21:10:04 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
To: Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <a06200709be1709a99fd2@[10.31.32.183]>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Fri, 21 Jan 2005, Edward Lewis wrote:

> At 14:23 -0500 1/21/05, Eric A. Hall wrote:
> 
> >Personally I think the best way to do this is to define a $DEFAULT
> ...
> >that the zone is authoritative for. The big problem with this approach is
> >that zone directives aren't really supported; even though directives are
> >(somewhat) defined in STD13, they aren't really supported in transfers,
> 
> ...do they need to be?  Once you've expanded the directive (think 
> $GENERATE, $TTL, $ORIGIN), there's no need to push it to other 
> servers.

Yes. Directive would work best for synthesized wildcard done as 
preprocesing, i.e. if we have this in zone file:
 $DEFAULT	IN	MX	0 mail
 B		IN	A	127.0.0.1
 C		IN	A	127.0.0.2
 MAIL		IN	A	127.0.0.5	
Then after processing the actual zone file that is loaded by server is:
 B		IN	A	127.0.0.1
 B		IN	MX	0 mail
 C		IN	A	127.0.0.2
 C		IN	MX	0 mail
 MAIL		IN	A	127.0.0.2
 MAIL		IN	MX	0 mail
We also might want to have directive $NODEFAULT that would cause not using
default value for particular RR and leaving it as is (i.e. nodata):
 $NODEFAULT	IN	MX	mail
For above this would be usefull in order not to produce last line (MAIL IN MX)
Possibly $NODEFAULT should be called $NODATA directive (to explicitely set that
particular record exist but there is not such RR type for it).

> >and there are a number of server implementations that don't really embrace
> >the concept either. Personally I still think that this is the best way to
> 
> ...the concept of zone files, yeah.  That's the problem with zone 
> file directives.   But there's no reason a zone file implementation 
> couldn't try it out.

Well, if we're going with zone processing directive, it should be done so
that when zone is transfered to secondary server (or for DNSSEC signing), 
its the data after preprocessing that is seen, i.e. the secondary dns 
server would not need to do its own pre-processing (and would not 
necessarily need to have been updated to understand this directive), 
although the directive could be left in there, so that secondary dns 
server could if it wanted recognize wildcarded RR from real one.

-- 
William Leibzon
Elan Networks
william@elan.net


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: Weird Wildcards Work item
Date: Fri, 21 Jan 2005 13:30:11 -0800
Lines: 16
References: <6.2.0.14.2.20050120161507.04493db8@localhost>
	 <41F137CB.3090302@verisignlabs.com> <41F156CA.7030004@ehsco.com>
	 <a06200709be1709a99fd2@[10.31.32.183]>  <41F15DAB.7070505@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 21 22:42:53 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Eric A. Hall" <ehall@ehsco.com>
In-Reply-To: <41F15DAB.7070505@ehsco.com>
X-Mailer: Evolution 2.0.1 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Meta defaults for RR types add type selectivity, but this seems to lack
prefix selectivity.  Won't existence issues at a resolver remain without
including a unique prefix?  

Meta instructions created with '&' syntax, as example:

sel-d.sel-c.&.sel-b.sel-a TYPE  Data

-Doug


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: Kevin Darcy <kcd@daimlerchrysler.com>
Subject: Re: DNS container objects & virtual data types
Date: Fri, 21 Jan 2005 21:59:33 -0500
Lines: 56
References: <002201c4ff87$f2c04050$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 04:13:56 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701
X-Accept-Language: en-us, en
To: namedroppers@ops.ietf.org
In-Reply-To: <002201c4ff87$f2c04050$80c5a8c0@rsaedoscymkikx>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Anders Rundgren wrote:

>DNS container objects
>=====================
>Disregarding the discussion about overloading, misuse etc. I suggest
>that DNS RRs objects that does not have defined semantics, which today
>spells TXT and later will include XML and BINary as well, should merely
>be regarded as "container objects".
>
>Container objects' sole mission is to hold external representations of
>objects associated with virtual DNS data types.
>
>DNS virtual data types
>======================
>A "virtual" DNS data type is a data type that is identified by a unique DNS 
>label-set, preferably in the form of a translated URI.  Virtual data types
>- Have globally unique names
>- Do not rely on a particular registry
>- Are equally applicable to private and public data types
>- Can be used instantly
>- Operate at the same speed as intrinsic DNS data types
>
>[arg,]unique-name[.arg]    container-type   external-representation
>
>Due to the fact that virtual data types are compatible with the existing
>DNS infrastructure, there is nothing to "solve" or overcome, except
>maybe some mental hurdles.  It seems that three different external
>representations should cover most real-world applications.
>
>It is important to note that this scheme is by no means new, it is simply the
>de-facto standard in a documented and to some extent refined format.
>
What about the problem of scalability? If everyone uses these "container 
objects" to describe data specific to their particular app, and the 
"container objects" show up under a limited number of RR types, then 
every app client is going to have to wade through every other app's 
"container objects" of that "container-type" to find the particular ones 
that they require. Surely this is far less efficient than having 
different RR types that apps can query specifically.

Also, how are "collisions" -- a container object whose external 
representation appears to belong to one app, even though it is actually 
belongs to a different app -- to be prevented, in the absence of some 
sort of central registry?

                                                                         
                                              - Kevin




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: "Christian Huitema" <huitema@windows.microsoft.com>
Subject: Little endians, big endians, and 16 bit eggs
Date: Fri, 21 Jan 2005 20:56:10 -0800
Lines: 35
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 06:02:20 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Little endians, big endians, and 16 bit eggs
Thread-Index: AcUAMBTyfZc3G7gjR4GC/MJcgCikswADKH+A
To: <namedroppers@ops.ietf.org>
X-OriginalArrivalTime: 22 Jan 2005 04:55:43.0701 (UTC) FILETIME=[A0E12850:01C5003E]
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

OK, the real title of the reference papers was "On Holy Wars and a Plea
For Peace", and it did not refer to 16 bits eggs. Anyhow, let's please
first acknowledge the semantic equivalence between:

Name =3D example.net, Prefix =3D --myNewPseudoType, type =3D TXT, =
content =3D
string
And =20
Name =3D example.net, Prefix =3D null, type =3D myNewType(1234), content =
=3D
string

Sure, there are differences, and it is worth noting them:

- The "prefix" case does not support wildcards (but there are
workarounds)
- There is a fear that some servers do not support new types

But the main difference is about control. Prefixes can be made up on the
fly by whoever thinks about them, while types must be registered through
a rather lengthy and contentious defined IETF process.

It does not have to be so. If this group really believes that inventors
of new protocols should use new types instead of cooking up prefixes,
then it is perhaps time to make sure that record types can be allocated
easily, maybe just as easily as TCP ports. And, by the way, TCP ports
also are 16 bit long.

-- Christian Huitema

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:14 2006
From: John Levine <johnl@iecc.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: 22 Jan 2005 06:03:38 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 45
References: <cssmpc$11g4$1@sf1.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: huitema@windows.microsoft.com
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 07:10:18 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <cssmpc$11g4$1@sf1.isc.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>But the main difference is about control. Prefixes can be made up on
>the fly by whoever thinks about them, while types must be registered
>through a rather lengthy and contentious defined IETF process.

Au contraire.  If I want to invent a new RR type and use it among
friends, I can do so.  I only need to register it if I want to use it
widely and be confident that it won't collide with other uses.  Since
RR numbers are 16 bits, if I pick a number far away from the currently
assigned ones, the chances are good that I can use it for a long time
without anyone else stumbling into it.

By my reading of RFC 2782, the prefixes on SRV names are supposed to
come out of the IANA services list which used to be RFC 1700 and now
is http://www.iana.org/assignments/service-names.  Again, I can invent
whatever names I want for private use, but for public use I'd better
register the name to avoid collisions.  The name space for prefixes is
certainly larger than 16 bits, but I'd argue that 16 bits already
makes the chance of accidental collision low enough that the
difference isn't important.

To the extent that DNS software complies with RFC 3597 and passes
through unknown names and RRs without crashing or mangling them, I can
use either private RRs or SRV names just like I can use private TCP
ports so long as the hosts on each end agree what they mean.  The
practical difference is that at this point the chances that DNS
software will do the right thing with a funky name prefix are a lot
better than with a funky RR.

So I can't help but ask: does Microsoft have a schedule to bring their
DNS software into compliance with RFC 3597?  It sure would help
simplify the arguments about what to do.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: DNS container objects & virtual data types
Date: Sat, 22 Jan 2005 07:16:46 +0100
Lines: 56
References: <002201c4ff87$f2c04050$80c5a8c0@rsaedoscymkikx> <41F1C195.9090200@daimlerchrysler.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 07:22:31 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Kevin Darcy" <kcd@daimlerchrysler.com>,
	<namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Kevin Darcy wrote:
>>It is important to note that this scheme is by no means new, it is simply the
>>de-facto standard in a documented and to some extent refined format.

>What about the problem of scalability? If everyone uses these "container 
>objects" to describe data specific to their particular app, and the 
>"container objects" show up under a limited number of RR types, then 
>every app client is going to have to wade through every other app's 
>"container objects" of that "container-type" to find the particular ones 
>that they require. Surely this is far less efficient than having 
>different RR types that apps can query specifically.

This assumes that your queries are of the type *.domain.
Using more targeted selections you should only get your own stuff.
More to read:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html

>Also, how are "collisions" -- a container object whose external 
>representation appears to belong to one app, even though it is actually 
>belongs to a different app -- to be prevented, in the absence of some 
>sort of central registry?

It is good that you brought up this issue.  If you look what the CSV people
have done you will note that they in addition to redefining an "intrinsic" DNS
type (SRV), also have made the "unusual" words _client and _service 
become *reserved*.  I.e. the central registry did not prevent these guys from
screwing up at all!!!  The IETF has no law enforcement arm.

If you name your objects with URIs (translated) there is a good chance
that they will be app-specific as it does not make sense for other
developers to hijack your URI.  If they do it will only affect their own
community.  URIs have become the de-facto way of separating definitions
on the Internet so I don't think we have a problem.  What always is
a problem is to parse data created by another party (DNS admin).
Using XML objects this will be slightly simpler.   XML is though just
one of the options.  BINary is another.  Maybe a real STRing
(UTF-8) would fill out the selection if container objects?

A thing that also is much better catered for by virtual types is versioning.
Complex systems evolve and that often calls for a revised data object.
Using a virtual data type you give the revised type a new URI and
then apps may look for the highest version first and then go down
until there is a match.  Caching this info limits the need to do this
all the time.  SPF's solution to this problem is simply horrible.

The DNS type stuff is a *very* dated design.  It is about time to take
DNS into the 21st century!

believes at least
Anders

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: DNS spec compliancy and how to get there
Date: 22 Jan 2005 06:50:29 -0000
Lines: 18
References: <Pine.LNX.4.61.0501190740480.32749@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 07:53:56 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Pekka Savola writes:
> This strikes to me that we need pretty urgently to have some kind of 
> "[minimum] requirements for DNS implementations [that wish to be 
> compliant to DNS specs]" (like hosts requirements, router 
> requirements, or IPv6 host requirements documents).

RFC 1123, Requirements for Internet Hosts, already says ``A name server
may acquire [records] that the server doesn't know how to convert to
printable format ... this data must be preserved.''

---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:46:15 2006
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: 22 Jan 2005 06:58:56 -0000
Lines: 15
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 08:02:07 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Christian Huitema writes:
> But the main difference is about control.

No. The main difference is that new types create giant interoperability
problems in the real world. Getting the IETF to allocate a new DNS type
is far easier than (for example) wiping out BIND 8.1.

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

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 09:13:30 +0100
Lines: 63
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 09:23:47 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Christian Huitema" <huitema@windows.microsoft.com>,
	<namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Christian,
If you look at my DomainKeys example you can see that prefixes
is not the only possible way.  "Midfixes" does it all and without
requiring any DNS updates.  Look under "performance":
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html
There may be use-cases that don't apply to midfixes.

Since you hopefully represent Microsoft, how about supporting
an XML companion to TXT?  DNS must be the only IT system
in the world that does not support XML!

What "this group" thinks about prefix is not important, the "market"
has already done its choice.  What's missing are guidelines.
Here is an attempt at least:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00183.html

Anders

----- Original Message ----- 
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: <namedroppers@ops.ietf.org>
Sent: Saturday, January 22, 2005 05:56
Subject: Little endians, big endians, and 16 bit eggs


OK, the real title of the reference papers was "On Holy Wars and a Plea
For Peace", and it did not refer to 16 bits eggs. Anyhow, let's please
first acknowledge the semantic equivalence between:

Name = example.net, Prefix = --myNewPseudoType, type = TXT, content =
string
And  
Name = example.net, Prefix = null, type = myNewType(1234), content =
string

Sure, there are differences, and it is worth noting them:

- The "prefix" case does not support wildcards (but there are
workarounds)
- There is a fear that some servers do not support new types

But the main difference is about control. Prefixes can be made up on the
fly by whoever thinks about them, while types must be registered through
a rather lengthy and contentious defined IETF process.

It does not have to be so. If this group really believes that inventors
of new protocols should use new types instead of cooking up prefixes,
then it is perhaps time to make sure that record types can be allocated
easily, maybe just as easily as TCP ports. And, by the way, TCP ports
also are 16 bit long.

-- Christian Huitema

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <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:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 09:18:27 +0100
Lines: 26
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <20050122065856.36906.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 09:24:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "D. J. Bernstein" <djb@cr.yp.to>, <namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

"D. J. Bernstein" <djb@cr.yp.to> wrote:

>Christian Huitema writes:
>> But the main difference is about control.

Yes, indeed.  The ability to introduce a new type whenever you
need and not asking for a "permission".

>No. The main difference is that new types create giant interoperability
>problems in the real world.

There are no such problems if you create unique prefixes which
is trivial by using transklated URIs.

> Getting the IETF to allocate a new DNS type
>is far easier than (for example) wiping out BIND 8.1.

How does TXT + prefixes wipe out BIND 8.1?

Anders

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Andras Salamon <andras@dns.net>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 11:39:01 +0200
Lines: 14
References: <cssmpc$11g4$1@sf1.isc.org> <20050122060338.17045.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 12:13:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
In-Reply-To: <20050122060338.17045.qmail@xuxa.iecc.com>
User-Agent: Mutt/1.5.6i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Sat, Jan 22, 2005 at 06:03:38AM -0000, John Levine wrote:
> By my reading of RFC 2782, the prefixes on SRV names are supposed to
> come out of the IANA services list

I agree.  However, Christian Huitema was suggesting a TXT record in his
example, not a SRV record.

-- Andras Salamon                   andras@dns.net

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Andras Salamon <andras@dns.net>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 13:02:10 +0200
Lines: 33
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 12:15:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
User-Agent: Mutt/1.5.6i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Fri, Jan 21, 2005 at 08:56:10PM -0800, Christian Huitema wrote:
> Anyhow, let's please
> first acknowledge the semantic equivalence between:
> 
> Name = example.net, Prefix = --myNewPseudoType, type = TXT, content =
> string
> And  
> Name = example.net, Prefix = null, type = myNewType(1234), content =
> string

Agreed, these are largely equivalent.  Also somewhat equivalent would be

Name = example.net, Prefix = null, class = someNewClass, type =
someNewType, content = string

However, there _is_ a semantic difference since you are associating
the data with different domain names.  As you point out this mostly
affects wildcards, but there are also situations where queries for
--myNewPseudoType "records" for example.net could result in responses
of "string" in the one case, NXDOMAIN in a second case and "NOERROR,
0 answers" in a third, requiring extra client logic to handle the
NXDOMAIN case.  After all, --myNewPseudoType.example.net not existing
doesn't say anything about example.net existing or not.  In comparison,
if the new RRtype solution returns NXDOMAIN then we know example.net
does not exist, simplifying client-side code.

-- Andras Salamon                   andras@dns.net

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: John Levine <johnl@iecc.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: 22 Jan 2005 16:17:08 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 28
References: <20050122093901.GB1290@dns.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: andras@dns.net
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 17:25:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <20050122093901.GB1290@dns.net>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>> By my reading of RFC 2782, the prefixes on SRV names are supposed to
>> come out of the IANA services list
>
>I agree.  However, Christian Huitema was suggesting a TXT record in his
>example, not a SRV record.

True, but if you're using prefixes, regardless of what record types
you're (re)using, you need some sort of registry if you want to be
sure that nobody else will use your prefix to mean something else.  I
suppose you could use the URI trick to get uniqueness from domain
names, but I have my doubts about how 

The issue of how hard it is to get something into the registry is a
separate question from what it is you're registering.  I agree that in
retrospect it should have been easier to register new RR types so that
people wouldn't have written DNS software that assumes the set of RR
types is forever fixed.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.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:46:15 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 16:14:06 +0000
Lines: 21
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.win
 deploy.ntdev.microsoft.com> <001a01c5005a$463963b0$80c5a8c0@rsaedoscymkikx>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 17:25:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Anders Rundgren <anders.rundgren@telia.com>,
	Christian Huitema <huitema@windows.microsoft.com>,
	namedroppers@ops.ietf.org
In-Reply-To: <001a01c5005a$463963b0$80c5a8c0@rsaedoscymkikx>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 22 January 2005 09:13 +0100 Anders Rundgren 
<anders.rundgren@telia.com> wrote:

> DNS must be the only IT system in the world that does not support XML!

Is that a complaint or an endorsement?

Serious point: DNS is/was a low level protocol which did a fair job
of turning requests for hostnames into IP addresses with a reasonably
small number of bytes transmitted. The larger the edifice is built,
the more one worries about the humble foundations.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 17:59:36 +0100
Lines: 30
References: <20050122161708.1577.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Cc: <andras@dns.net>
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 18:05:28 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "John Levine" <johnl@iecc.com>, <namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>John L wrote:
>True, but if you're using prefixes, regardless of what record types
>you're (re)using, you need some sort of registry if you want to be
>sure that nobody else will use your prefix to mean something else.  I
>suppose you could use the URI trick to get uniqueness from domain
>names, but I have my doubts about how 

URI are used in numerous other contexts so the only trick is to
agree on a URI-to-DNS-label-translator

>The issue of how hard it is to get something into the registry is a
>separate question from what it is you're registering.  I agree that in
>retrospect it should have been easier to register new RR types so that
>people wouldn't have written DNS software that assumes the set of RR
>types is forever fixed.

Looking at W2KS DNS GUI server I don't agree.  I only supports a limited
set of types.  And since most people actually only need a text-something
it makes no sense to create a new text-something over and over again.

The URI-suffix (not prefix) covers all readonable needs. And it costs
nothing to implement or support either.

Anders

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: 22 Jan 2005 12:37:40 -0500
Lines: 46
References: <20050122161708.1577.qmail@xuxa.iecc.com>
 <001301c500a3$c4f6e030$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org, andras@dns.net
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 18:43:18 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Anders Rundgren" <anders.rundgren@telia.com>
In-Reply-To: <001301c500a3$c4f6e030$80c5a8c0@rsaedoscymkikx>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> >suppose you could use the URI trick to get uniqueness from domain
> >names, but I have my doubts about how
>
> URI are used in numerous other contexts so the only trick is to
> agree on a URI-to-DNS-label-translator

Ahem, to finish my sentence, how likely it is that people will configure
long hard to type names into their DNS zones.  I realize URI based labels
are common in XML, but there's a lot more people updating DNS zones by
hand than writing XML files by hand.

> >retrospect it should have been easier to register new RR types so that
> >people wouldn't have written DNS software that assumes the set of RR
> >types is forever fixed.
>
> Looking at W2KS DNS GUI server I don't agree.  I only supports a limited
> set of types.  And since most people actually only need a text-something
> it makes no sense to create a new text-something over and over again.

Actually, it's been a long time since I've seen a type that should be a
text something.  TXT records are just the ticket for unstructured textual
data, which few applications use.  SPF records, for example, are a highly
structured list of operators and typed operands, with the operand types
including DNS names, IP addresses, CIDR ranges, macros that expand to DNS
names, and probably a few other things I've forgotten.  Every DNS client
that uses SPF has to parse the text up into the operators and operands,
and one of the many unanswered questions about SPF is how robust the
parsers are in the face of accidentally or deliberately invalid data.

If I were doing something like SPF, I'd want a record type that was a list
of operator/operand pairs with the operators probably being a single byte,
and the operands being in an appropriate native coding, e.g. five binary
bytes for an IPv4 CIDR and a list of null-terminated strings for a DNS
name.  That both avoids the application level parser and forces some
degree of validation as the data goes into the record.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: John Levine <johnl@iecc.com>
Subject: Re: DNS container objects & virtual data types
Date: 22 Jan 2005 17:45:09 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 31
References: <00df01c50049$f4d9e360$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: anders.rundgren@telia.com
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 18:50:06 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <00df01c50049$f4d9e360$80c5a8c0@rsaedoscymkikx>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>It is good that you brought up this issue.  If you look what the CSV
>people have done you will note that they in addition to redefining an
>"intrinsic" DNS type (SRV), also have made the "unusual" words
>_client and _service become *reserved*.  I.e. the central registry
>did not prevent these guys from screwing up at all!!!  The IETF has
>no law enforcement arm.

Aw, come on.  If CSV heads down the standards track, we'll arrange to
register the names it uses, or maybe to switch to appropriate names
that are already registered if there are any.  I would have thought it
would be obvious that first you do the experiments, then you register
the names they use if the experiments look promising.  We think CSV is
swell, but nobody's used CSV enough to know if there are horrible
gotchas that we haven't discovered yet.

> A thing that also is much better catered for by virtual types is
> versioning.

I think it's a feature of DNS that versioning is hard.  The more
versions of something that simultaneously exist, the less likely it is
that implementations will interoperate reliably.

R's,
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:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 18:47:49 +0100
Lines: 44
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.win deploy.ntdev.microsoft.com> <001a01c5005a$463963b0$80c5a8c0@rsaedoscymkikx> <51FD91EA429F9FADF359144D@Satori.nominet.org.uk>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 18:53:19 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Alex Bligh" <alex@alex.org.uk>,
	"Christian Huitema" <huitema@windows.microsoft.com>,
	<namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>Serious point: DNS is/was a low level protocol which did a fair job
>of turning requests for hostnames into IP addresses with a reasonably
>small number of bytes transmitted. The larger the edifice is built,
>the more one worries about the humble foundations.

Since needs have changed quite a bit since DNS was created,
so should DNS.  If every web-page drags down 10K and up,
averaging on 100K using TCP, why should 512 bytes UDP be
all a DNS server manages to do?

XML is today the de-facto config-language.  It is even used
in mobile phones.  So imo DNS is indeed one of the most dated
things in the entire Internet space.   That also includes ideas such
as having a central registry for app-data types.  App-data is not protocols
or ports.

There may be problems with prefix,suffix schemes but I cannot find
much substance like that
-you always get *all* TXT records
-you cannot allocate more than about 203 TXT records

DUAL MORAL STANDARDS

The worst is, that things like iab-dns-choices have created a
bad morale among developers that now must (in order to pass
as RFC) support:
TXT to be able to rollout
NEW-specific to please IETF

Then they must also write in the I-D that "TXT is the 'interim' solution,
we expect all to switch to NEW asap".  Since the "interim" works
why should this ever happen?  It is a blatant lie IMNSHO.

"app-data" types should not have to be published at all outside
their user community.

thinks
Anders

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: sthaug@nethelp.no
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 19:22:06 +0100
Lines: 37
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 19:26:30 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: anders.rundgren@telia.com
In-Reply-To: Your message of "Sat, 22 Jan 2005 18:47:49 +0100"
X-Mailer: Mew version 1.05+ on Emacs 19.34.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> XML is today the de-facto config-language.  It is even used
> in mobile phones.

I have no problem with XML being used in mobile phone. I strongly
disagree with any claim that XML is *the* de-facto configuration
language.

> So imo DNS is indeed one of the most dated
> things in the entire Internet space.

RFC 791         September 1981
RFC 1035        November 1987

Both IP and DNS have changed since they were developed, and they will
change again. I don't believe "one of the most dated things in the
entire Internet space" is a reasonable characterization of DNS.

> DUAL MORAL STANDARDS
> 
> The worst is, that things like iab-dns-choices have created a
> bad morale among developers that now must (in order to pass
> as RFC) support:
> TXT to be able to rollout
> NEW-specific to please IETF

Is the problem here the IETF, or the companies that develop systems
and applications that make it extremely difficult to introduce new
RR types?

Steinar Haug, Nethelp consulting, sthaug@nethelp.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:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 22:27:43 +0100
Lines: 63
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx> <88517.1106418126@bizet.nethelp.no>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Cc: <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Sat Jan 22 22:39:33 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: <sthaug@nethelp.no>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>I have no problem with XML being used in mobile phone. I strongly
>disagree with any claim that XML is *the* de-facto configuration
>language.

Let put it this way.  The majority of systems intrduced the last
three years use XML.

>> So imo DNS is indeed one of the most dated
>> things in the entire Internet space.

>RFC 791         September 1981
>RFC 1035        November 1987

>Both IP and DNS have changed since they were developed, and they will
>change again. I don't believe "one of the most dated things in the
>entire Internet space" is a reasonable characterization of DNS.

As a directory system it is certainly lagging at least.  512 bytes?  
That suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucks!

>> DUAL MORAL STANDARDS
>> 
>> The worst is, that things like iab-dns-choices have created a
>> bad morale among developers that now must (in order to pass
>> as RFC) support:
>> TXT to be able to rollout
>> NEW-specific to please IETF

>Is the problem here the IETF

It is the IETF who have created the incentive for dual standards.

> or the companies that develop systems
>and applications that make it extremely difficult to introduce new
>RR types?

The DNS specifications does not contain any kind of RFC
that supports a _smooth_ introduction of new RR types. 

IF it should work there must be a way to publish not only a puni16-bit number
but the environment as well so that DNS admin GUIs knows what to do.

This will never happen as:
1. There is no _proven_ need for new RR types except for things that only deals with DNS itself
2. Such a scheme would use XML and that seems to be something the DNS community
don't understand at all
3. It will take forever and be extremely hard to agree on

The problem is BTW really buried in the archaic DNS system itself.  Other
extension mechanisms allow the introduction of private data here thinking
of X.509 extensions.

>Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Won't hire :-)



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 10:46:37 +1100
Lines: 101
References: <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
Cc: sthaug@nethelp.no, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 01:18:31 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Anders Rundgren" <anders.rundgren@telia.com>
In-reply-to: Your message of "Sat, 22 Jan 2005 22:27:43 BST."
             <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


> >I have no problem with XML being used in mobile phone. I strongly
> >disagree with any claim that XML is *the* de-facto configuration
> >language.
> 
> Let put it this way.  The majority of systems intrduced the last
> three years use XML.
> 
> >> So imo DNS is indeed one of the most dated
> >> things in the entire Internet space.
> 
> >RFC 791         September 1981
> >RFC 1035        November 1987
> 
> >Both IP and DNS have changed since they were developed, and they will
> >change again. I don't believe "one of the most dated things in the
> >entire Internet space" is a reasonable characterization of DNS.
> 
> As a directory system it is certainly lagging at least.  512 bytes?  
> That suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucks!
> 
> >> DUAL MORAL STANDARDS
> >> 
> >> The worst is, that things like iab-dns-choices have created a
> >> bad morale among developers that now must (in order to pass
> >> as RFC) support:
> >> TXT to be able to rollout
> >> NEW-specific to please IETF
> 
> >Is the problem here the IETF
> 
> It is the IETF who have created the incentive for dual standards.
> 
> > or the companies that develop systems
> >and applications that make it extremely difficult to introduce new
> >RR types?
> 
> The DNS specifications does not contain any kind of RFC
> that supports a _smooth_ introduction of new RR types. 

	RFC 103[345] basically said that new RRs should be treated
	as opaque blobs by servers that don't understand them.  It
	said don't use compression pointers in new RRs.  It said
	you should expect to see new RRs.  This is all that is
	required for a cache / firewall to query, store and pass
	new RRs.  It still required the authoritative servers that
	served the new RRs to be updated and applications that
	wanted to use the new RRs to be know about them.

	We went ahead and used compression pointers when we shouldn't
	have.  We didn't treat new RRs as opaque blobs.  By doing
	this we did cause lots of problem when we introduced new
	RRs.  This created the *myth* that adding new RRs was hard.
	It really isn't hard to add new RRs.  We just went about
	it the wrong way.  We also learned not to do this.

	RFC 3597 reinforced what was in RFC 103[345] taking into
	account that we had failed to follow RFC 103[345] for a
	while and added a default presentation format.  This provided
	a standard method to add new RRs to authoritative servers
	that don't know the new RR format.

	The problems people are reporting today are non-compliance
	problems.  The way to fix non-compliance problems is to
	remove the offending software / hardware.

> IF it should work there must be a way to publish not only a puni16-bit number
> but the environment as well so that DNS admin GUIs knows what to do.
> 
> This will never happen as:
> 1. There is no _proven_ need for new RR types except for things that only dea
> ls with DNS itself
> 2. Such a scheme would use XML and that seems to be something the DNS communi
> ty
> don't understand at all
> 3. It will take forever and be extremely hard to agree on
> 
> The problem is BTW really buried in the archaic DNS system itself.  Other
> extension mechanisms allow the introduction of private data here thinking
> of X.509 extensions.
> 
> >Steinar Haug, Nethelp consulting, sthaug@nethelp.no
> 
> Won't hire :-)
> 
> 
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 16:58:01 -0800
Lines: 91
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.win deploy.ntdev.microsoft.com>
	 <001a01c5005a$463963b0$80c5a8c0@rsaedoscymkikx>
	 <51FD91EA429F9FADF359144D@Satori.nominet.org.uk>
	 <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 02:05:43 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Anders Rundgren <anders.rundgren@telia.com>
In-Reply-To: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx>
X-Mailer: Ximian Evolution 1.4.6 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Sat, 2005-01-22 at 09:47, Anders Rundgren wrote:
> On Sat, 2005-01-22 at 08:14, Alex Bligh wrote:
>
> > Serious point: DNS is/was a low level protocol which did a fair job
> > of turning requests for hostnames into IP addresses with a reasonably
> > small number of bytes transmitted. The larger the edifice is built,
> > the more one worries about the humble foundations.
> 
> Since needs have changed quite a bit since DNS was created,
> so should DNS.  If every web-page drags down 10K and up,
> averaging on 100K using TCP, why should 512 bytes UDP be
> all a DNS server manages to do?

A smaller packet size does two things, it ensures the packet can be
handled, and constrains the amount of UDP traffic.  The number of
interactions within DNS depends upon a sequence of low latency events
from perhaps many sources.  There are additional burdens created with
changes to IP and DNS that make this MTU restriction more of an
imperative.  Due to this pressure, perhaps someday the MTU for DNS may
be safely increased without incurring additional problems.   Until then,
this would suggest, to accommodate changes to the underlying transport,
new resource records should be assured to be smaller and not larger.

TCP connections require maintaining state for 5 packets of setup and
tear down in addition to the data packets, thus adding a delay of at
least 3 round trips.  Should TCP be employed for a common reply, the
ability to sustain DNS service would be reduced by this added overhead.

> XML is today the de-facto config-language.  It is even used
> in mobile phones.  So imo DNS is indeed one of the most dated
> things in the entire Internet space.   That also includes ideas such
> as having a central registry for app-data types.  App-data is not protocols
> or ports.

Prefixing script with the conventional XML headers would be prohibitive.
Such as the following 370 bytes: 
 <?xml version="1.0" encoding="UTF-8" standalone='yes'?>
 <root xmlns="urn:ietf:params:xml:schema:widget-01" 
        xmlns:m2="urn:ietf:params:xml:widget-02" 
        xmlns:m3="urn:ietf:params:xml:widget-03" 
        xmlns:m4="urn:ietf:params:xml:widget-04" 
        xmlns:m5="urn:ietf:params:xml:widget-05" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema"; 
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>

This header could be replaced by applying a convention for such a header
to preface the resource record or via a standardized token that replaces
such a header.  Just using an XML header would be prohibitive.  The XML
language itself represents about a 20% increase in script related
encoding.  Hardly a good fit when attempting to constrain record size.

> There may be problems with prefix,suffix schemes but I cannot find
> much substance like that
> -you always get *all* TXT records
> -you cannot allocate more than about 203 TXT records

I think a label prefix, virtual or otherwise, will be needed.  Ideally a
record should fit within only a fraction of the available packet.

> DUAL MORAL STANDARDS
> 
> The worst is, that things like iab-dns-choices have created a
> bad morale among developers that now must (in order to pass
> as RFC) support:
>
> TXT to be able to rollout
> NEW-specific to please IETF

Alas, neither of these techniques solves the underlying problem.  The
choice dilemma is predicated upon an expectation wildcards may be used
to assert policy within any possible sub-domain.

> Then they must also write in the I-D that "TXT is the 'interim' solution,
> we expect all to switch to NEW asap".  Since the "interim" works
> why should this ever happen?  It is a blatant lie IMNSHO.
> 
> "app-data" types should not have to be published at all outside
> their user community.

Labeling conventions allow communities to coexist.  A case made for
usurping a TXT record seems flawed.

-Doug



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Danny Mayer <mayer@gis.net>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 20:34:48 -0500
Lines: 19
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <001a01c5005a$463963b0$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 03:12:48 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
To: "Anders Rundgren" <anders.rundgren@telia.com>,
 "Christian Huitema" <huitema@windows.microsoft.com>,
 <namedroppers@ops.ietf.org>
In-Reply-To: <001a01c5005a$463963b0$80c5a8c0@rsaedoscymkikx>
References: <DAC3FCB50E31C54987CD10797DA511BA0CD8E5EE@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
X-Rcpt-To: <namedroppers@ops.ietf.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 03:13 AM 1/22/2005, Anders Rundgren wrote:
>Since you hopefully represent Microsoft, how about supporting
>an XML companion to TXT?  DNS must be the only IT system
>in the world that does not support XML!

No, we, NTP, don't and won't support XML either. That's a huge
overhead just to transfer data. If you want XML in the transferred
data, now you are talking about a much higher level of usage of
TCP which has a much larger overhead just to transfer A records
for example, not withstanding EDNS0.

Danny


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Danny Mayer <mayer@gis.net>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sat, 22 Jan 2005 21:01:46 -0500
Lines: 100
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx>
 <88517.1106418126@bizet.nethelp.no> <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
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 Sun Jan 23 03:12:48 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Sender: mayer@pop.gis.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
To: "Anders Rundgren" <anders.rundgren@telia.com>,<sthaug@nethelp.no>
In-Reply-To: <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx>
 <88517.1106418126@bizet.nethelp.no>
X-Rcpt-To: <namedroppers@ops.ietf.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 04:27 PM 1/22/2005, Anders Rundgren wrote:
> >I have no problem with XML being used in mobile phone. I strongly
> >disagree with any claim that XML is *the* de-facto configuration
> >language.
>
>Let put it this way.  The majority of systems intrduced the last
>three years use XML.

What kind of systems? DNS is part of the base infrastructure of
the Internet. How many of these systems even have to do with the
base infrastructure? If you want to discuss configuration languages,
that's off-topic. You can use any language you want to tell your
DNS server what the records are you want to serve.

> >> So imo DNS is indeed one of the most dated
> >> things in the entire Internet space.
>
> >RFC 791         September 1981
> >RFC 1035        November 1987
>
> >Both IP and DNS have changed since they were developed, and they will
> >change again. I don't believe "one of the most dated things in the
> >entire Internet space" is a reasonable characterization of DNS.
>
>As a directory system it is certainly lagging at least.  512 bytes?
>That suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucks!

512? See EDNS0.

> >> DUAL MORAL STANDARDS
> >>
> >> The worst is, that things like iab-dns-choices have created a
> >> bad morale among developers that now must (in order to pass
> >> as RFC) support:
> >> TXT to be able to rollout
> >> NEW-specific to please IETF
>
> >Is the problem here the IETF
>
>It is the IETF who have created the incentive for dual standards.
>
> > or the companies that develop systems
> >and applications that make it extremely difficult to introduce new
> >RR types?
>
>The DNS specifications does not contain any kind of RFC
>that supports a _smooth_ introduction of new RR types.

See the unknown record type - RFC 3597.

>IF it should work there must be a way to publish not only a puni16-bit number
>but the environment as well so that DNS admin GUIs knows what to do.

GUI admins for DNS is off topic. That's a function of the DNS implementation.

>This will never happen as:
>1. There is no _proven_ need for new RR types except for things that only 
>deals with DNS itself

Neither SRV nor NAPTR are DNS specific RR types.

>2. Such a scheme would use XML and that seems to be something the DNS 
>community
>don't understand at all

The DNS community see you advocating sending large amounts of data for
simple requests, forcing the servers to use TCP and greatly increasing the
load not just on the servers but on the networks for no preceived gain. If
you want to contribute a way of reducing the garbage requests that DNS
gets, it would be a big help.

>3. It will take forever and be extremely hard to agree on

You need to decide EXACTLY you want first. There's almost never a
possibility of going back and revisiting the requirements once it's
agreed upon.

>The problem is BTW really buried in the archaic DNS system itself.  Other
>extension mechanisms allow the introduction of private data here thinking
>of X.509 extensions.

No, the problem is in thinking the XML should fit everything. If all you have
is a hammer then everything is a nail. You need to look at the objectives
of DNS not your minor application. It's minor in the sense that A, NS
and MX volume swamp almost every other type of request made including
the fact that your application will still need to make those lookups as well
as it's own.

Have you thought about the effect your recommendation would make on
the root servers, TLD's, memory, cache, network utilization, etc? The
list goes on.

Danny


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 03:57:24 +0000
Lines: 12
References: <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 05:05:20 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> 
	of "Sat, 22 Jan 2005 16:14:06 GMT."
	<51FD91EA429F9FADF359144D@Satori.nominet.org.uk> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> Serious point: DNS is/was a low level protocol which did a fair job
> of turning requests for hostnames into IP addresses with a reasonably
> small number of bytes transmitted. The larger the edifice is built,
> the more one worries about the humble foundations.

after EDNS0, the foundations are just fine, thanks.  "more weight."

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Dean Anderson <dean@av8.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 00:56:18 -0500 (EST)
Lines: 95
References: <20050122060338.17045.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org, <huitema@windows.microsoft.com>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 07:01:53 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: dean@cirrus.av8.net
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050122060338.17045.qmail@xuxa.iecc.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On 22 Jan 2005, John Levine wrote:

> >But the main difference is about control. Prefixes can be made up on
> >the fly by whoever thinks about them, while types must be registered
> >through a rather lengthy and contentious defined IETF process.
> 
> Au contraire.  If I want to invent a new RR type and use it among
> friends, I can do so. 

You can do whatever you want among friends, including not using standard
protocols.  Of course, other groups may come along and use the same type
codes (intentionally or unintentionally)  and standardize the codes for
their defined use, rather severely "crimping your style", as it were.

Sometimes the reasons are proprietary. Sometimes not. The proprietary
reasons I can understand, if I don't agree with them.  But sometimes the
reasons are technically unsound. This is now without doubt the case with
SPF.  The juggernaut rolls on.  The MARID group found the SPF scheme to
have insurmountable technical problems, and shut down.  Yet, the SPF
proponents forged ahead despite the unresolved technical problems, and
indeed, pretending as though there are no problems. This unfortunately is
a common activity among the radical anti-spam crowd.  Examples include the
so-called "reverse DNS check", the "pop-before-smtp check", and other
failed anti-spam measures too numerous to list, that were described as the
way to end spam.

In presenting the SPF classic draft to this group, it is asserted that the
draft should be considered and standardized because some thousands of
domains (among millions) are using SPF. No mention was made that most of
the SPF-using domains are __spammer__ domains.  The number of users
pointing guns at their feet and pulling the trigger is no reason to
standardize the caliber of gun used to blow off toes.  The responsible
thing is to tell those users not to shoot themselves (or others) in the
foot. The irresponsible thing is to standardize the weapon used for
self-inflicted wounds, merely because some number of people have shot
themselves in the foot on the fervent irrational faith that doing so will
end spam.

Theorem 1:
"DNS is not suitable for authentication purposes."

Theorem 2:
"Any scheme that depends on DNS for its security is fundamentally 
unsound."

That includes (but clearly isn't limited to)
	Reverse DNS checking for spam
	RMX
	SPF
	Any other DNS Email Authentication scheme.

It is interesting that the common thread of Dr. Levine's involvement in 
DNSEXT has gone from 
	SPF I-D for review: draft-schlitt-spf-classic-00.txt
	Zone cut
	Engineering SPF
	wildcards vs. RR types, was Faux wildcards
	Little endians, big endians, and 16 bit eggs

Each of these discussons have the common thread of finding a new way to 
break or abuse DNS.  Perhaps the theorems 1 and 2 above should be studied 
more closely.

First, we discused RMX. That draft was rejected. Then, the idea was
resurrected again as SPF, ignoring the failures of demonstrated for RMX.  
In fact, a special group was created to standardize this. In spite of that
the MARID working group concluded that it couldn't overcome substantial
technical faults. Now, SPF is again resurrected, on yet another IETF
group, again ignoring the two previous failures.

Word has it on the old ietf-mxcomp list that the IETF may create a "DNS
Email Authentication" working group, apparently to specifically ignore the
Theorems 1 and 2 above by including the oxymoron in the name of the group.

So, perhaps merely refusing to ratify a draft is insufficent. Perhaps a
stronger statement on why the idea shouldn't merit further consideration 
unless a number of conditions are met first is necessary to stop the waste 
of time on such things.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   





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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Pekka Savola <pekkas@netcore.fi>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 10:11:06 +0200 (EET)
Lines: 22
References: <200501222346.j0MNkb9M048240@drugs.dv.isc.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Anders Rundgren <anders.rundgren@telia.com>, sthaug@nethelp.no,
   namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 09:19:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Mark Andrews <Mark_Andrews@isc.org>
In-Reply-To: <200501222346.j0MNkb9M048240@drugs.dv.isc.org>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Sun, 23 Jan 2005, Mark Andrews wrote:
> 	The problems people are reporting today are non-compliance
> 	problems.  The way to fix non-compliance problems is to
> 	remove the offending software / hardware.

Hence, IMHO, it seems critical to have a concise document describing 
what MUST be implemented (and why), what is optional, etc.

If we would have a draft or RFC of 15-20 pages and could show it to 
the offenders, and people buying DNS equipment could request it in 
CFTs (see RFC3871).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Andras Salamon <andras@dns.net>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 10:15:01 +0200
Lines: 39
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx> <88517.1106418126@bizet.nethelp.no> <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 09:54:24 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
Content-Disposition: inline
In-Reply-To: <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
User-Agent: Mutt/1.5.6i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Sat, Jan 22, 2005 at 10:27:43PM +0100, Anders Rundgren wrote:
> As a directory system it is certainly lagging at least.  512 bytes?  

DNS has a specific purpose, as defined in the RFCs.  It is not a generic
"directory system".
    http://www.dns.net/dnsrd/rfc/

See also draft-klensin-dns-role-05.txt for a good overview of how the
"DNS community" sees the function of DNS.

There have been several efforts to set up alternatives, for instance
LDAP and various X.500 directories (for instance, see the above list
of RFCs for the history of some of these).  I'm still waiting for
widespread deployment of a next generation directory system which can
handle infrastructure directory duties as well as DNS.

> The DNS specifications does not contain any kind of RFC
> that supports a _smooth_ introduction of new RR types. 

You are right.  To introduce a new RR type you have to publish an RFC
describing it.  Takes a bit of work.

> 1. There is no _proven_ need for new RR types except for things that only deals with DNS itself

That is debatable.  It depends on what function you think DNS fulfils.
Again, see draft-klensin-dns-role-05.txt.

> 2. Such a scheme would use XML and that seems to be something the DNS community
> don't understand at all

Methinks you judge too quickly.

-- Andras Salamon                   andras@dns.net

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 10:17:53 +0100
Lines: 63
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 10:23:34 2005
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Slightly related to XML but also applies to schemes like DomainKeys
as a public key indeed is a "fat" object.

I'm NOT pretending to be an expert on this topic (or DNS at all actually)
so I humbly try to put the facts (or issues) on the table.

Historic background:
When DNS was created network resources were scarce.  Currently people are
downloading entire movies over intercontinental Internet connections.  That is,
2005 <<>> 1987.

Trend:
That it is possible to save bytes by using "smart coding" is indeed true but have
lately become out of fashion.  The reason for that is that data objects today
often are much more complex than they were in the early days of the Internet.
In addition, the "environment" has become more volatile which means that
revisions are more and more frequent.

Consequences:
Put together these things have more or less united the IT industry to use objects
that are [to some extent] self-describing and can be parsed automatically.  This
have lead to XML and XML Schema respectively.  Using XML Schemas
you would preferably assign a new namespace to a revised data type so
that there would be no question about what you actually are dealing with.
Using XML Schemas allows BOTH ends to auto-parse BTW!

Efficiency:
XML and other textual representations cannot be accused of being efficient.  There
is often a 200-500% overhead for the simple stuff (integers, flags) and a 40% for
blob data (BASE64).

THE QUESTION:
Does this (fat-object) paradigm fit DNS?
A majority of the NameDroppers seem to say no.

Here is a list of workarounds for people that would like to indeed move
the DNS infrastructure a bit closer to the "other world" (Web Services).

1.
according to Paul Vixie:
   after EDNS0, the foundations are just fine, thanks.  "more weight."

But the namedroppers seem skeptical about this and even claim that
firewalls don't accept this.  Hard to know for me.

2
Another possibility could be:
You retrieve the authoritative nameservers and in turn call
these using TCP.  That is, you don't put any major load on
the infrastructure at large only on the server you have a
contract with or run on your own.  Is that a viable scheme?

BTW, I have "ordered" an XML RR from IANA.  Putting the
famous process to test.... :-)

br
Anders rundgren

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 12:39:16 +0000
Lines: 30
References: <20050123035724.E444913960@sa.vix.com>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 13:50:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org
In-Reply-To: <20050123035724.E444913960@sa.vix.com>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 23 January 2005 03:57 +0000 Paul Vixie <paul@vix.com> wrote:

> after EDNS0, the foundations are just fine, thanks.  "more weight."

I'm not sure that means buildings of any and every type should be built on
top of them though. There may be other types of foundations better suited
to certain types of architecture (pun intended).

As an example, I am not sure whether DNS (alone, rather than over some
other protocol) is the right basis for a directory service where (a) it is
necessary to securely authenticate both client and resolver to eachother,
where there are many to many relationships for large values of "many", and
(b) it is necessary to move large amounts of directory data (c) it is
necessary to encrypt the wire protocol against snooping (d) subsecond
lookup latency is not that important. Whilst I'm sure one *could*
reengineer DNS to do that, I think I'd prefer to do it over https:// with
some certificate management scheme. Sometimes I wonder whether some of the
proposed DNS variants (e.g. carrying large amounts of XML) would not be
better done with a one stage indirection at the DNS layer, and a solution
using some other well known protocol.

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 15:19:36 +0100
Lines: 59
References: <20050123035724.E444913960@sa.vix.com> <89621D32D279B49AA05CE1B1@Satori.nominet.org.uk>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 15:25:48 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Alex Bligh" <alex@alex.org.uk>, "Paul Vixie" <paul@vix.com>,
	<namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Regarding b) "large objects" I wonder if the1987 definition is valid also 2005.
I would expect that public key stuff  to be less than 4K and so
would most likely XML schemes as well.   4K seems like a reasonable
object these days.

A factor of 8 in 18 years is IMHO a *very* modest improvement.

It seems that no reengineering is necessary either.  Assuming that EDNS0
is applicable.  Or reverting to a scheme where you using UDP
get the authoritative NSs and then with TCP get the "fat" object
directly from the source.

Regarding the other things, at least I agree.

Anders R

----- Original Message ----- 
From: "Alex Bligh" <alex@alex.org.uk>
To: "Paul Vixie" <paul@vix.com>; <namedroppers@ops.ietf.org>
Cc: "Alex Bligh" <alex@alex.org.uk>
Sent: Sunday, January 23, 2005 13:39
Subject: Re: Little endians, big endians, and 16 bit eggs 




--On 23 January 2005 03:57 +0000 Paul Vixie <paul@vix.com> wrote:

> after EDNS0, the foundations are just fine, thanks.  "more weight."

I'm not sure that means buildings of any and every type should be built on
top of them though. There may be other types of foundations better suited
to certain types of architecture (pun intended).

As an example, I am not sure whether DNS (alone, rather than over some
other protocol) is the right basis for a directory service where (a) it is
necessary to securely authenticate both client and resolver to eachother,
where there are many to many relationships for large values of "many", and
(b) it is necessary to move large amounts of directory data (c) it is
necessary to encrypt the wire protocol against snooping (d) subsecond
lookup latency is not that important. Whilst I'm sure one *could*
reengineer DNS to do that, I think I'd prefer to do it over https:// with
some certificate management scheme. Sometimes I wonder whether some of the
proposed DNS variants (e.g. carrying large amounts of XML) would not be
better done with a one stage indirection at the DNS layer, and a solution
using some other well known protocol.

Alex

--
to unsubscribe send a message to namedroppers-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:46:15 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 16:04:04 +0000
Lines: 50
References: <anders.rundgren@telia.com>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 17:13:09 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "Anders Rundgren" <anders.rundgren@telia.com> 
	of "Sat, 22 Jan 2005 18:47:49 +0100."
	<002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> Since needs have changed quite a bit since DNS was created,
> so should DNS.

the needs dns meets have not changed in any way.

> If every web-page drags down 10K and up, averaging on 100K using TCP,
> why should 512 bytes UDP be all a DNS server manages to do?

sounds like you think the web "is" the internet.  it's not.  the internet
is much, much larger than the web.  (and as others have pointed out, EDNS
relaxed the 512-octet limit.)

> XML is today the de-facto config-language.  It is even used in mobile
> phones.  So imo DNS is indeed one of the most dated things in the
> entire Internet space.  That also includes ideas such as having a
> central registry for app-data types.  App-data is not protocols or
> ports.

dns is the world's first and, and still the only, distributed coherent
autonomous reliable database.  it's quite an achievement, and i think
you ought to show a little more respect toward that achievement.  for
example, you ought to admit the possibility that its simplicity is what
makes dns possible at all.

> "app-data" types should not have to be published at all outside their
> user community.

this, i almost agree with.  i'm happy to see the ietf asking namedroppers@
for review on app-data rrtypes, but that's just a "model check" to ensure
that the rdata encoding is reasonable and that the query/response pattern
will work.  the expected (demanded?) result should be approval, possibly
with modifications but always approval.

with SRV, we sort of snuck it through, largely because we didn't think the
namedroppers@ community was the right forum for deciding how applications
should discover their servers, and because we (the authors) felt that we
knew quite a bit about how to format a new rdata.  SRV could not be
standardized today, because the ietf has vastly increased the number of
people who could say "no".  this is a real pity, and shows the ietf's age
in a dark way.  rrtype review should be of rdata format and query pattern,
and the expected result should be approval, possibly with modifications.

we need to start adding one new rrtype per month (or so) just to show that
we can.  perhaps this would be a good first-year focus for DNS-MODA.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 16:29:24 +0000
Lines: 61
References: <anders.rundgren@telia.com>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 17:33:53 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "Anders Rundgren" <anders.rundgren@telia.com> 
	of "Sun, 23 Jan 2005 10:17:53 +0100."
	<004b01c5012c$6e7be7d0$80c5a8c0@rsaedoscymkikx> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> THE QUESTION:
> Does this (fat-object) paradigm fit DNS?

no.

> A majority of the NameDroppers seem to say no.

and rightly so.

dns is a udp app, probably the most popular udp app in the wide area (though
on LANs, nfs and smb are going to be more popular).  since the guaranteed
minimum maximum MTU has not changed (576 for V4) and is still small (1280 for
V6), any udp app for the wide area should be trying to avoid fragmentation.

that means dns will never be useful for fat objects.  don't dispair, though:
there are a lot of thin/dense objects whose need for a reliable, autonomous,
distributed, hierarchical database is met perfectly by dns, or which will be
met perfectly by secure dns.

> Here is a list of workarounds for people that would like to indeed move
> the DNS infrastructure a bit closer to the "other world" (Web Services).
> 
> 1.
> according to Paul Vixie:
>    after EDNS0, the foundations are just fine, thanks.  "more weight."
> 
> But the namedroppers seem skeptical about this and even claim that
> firewalls don't accept this.  Hard to know for me.

some firewalls don't allow it.  these are not the norm, and when faced with
a bug report about it, firewall vendors and operators fix the problem --
dns sails on.  the fingerpointing is always toward the violator of the spec.

> 2
> Another possibility could be:
> You retrieve the authoritative nameservers and in turn call
> these using TCP.  That is, you don't put any major load on
> the infrastructure at large only on the server you have a
> contract with or run on your own.  Is that a viable scheme?

no.  tcp requires state.  state quotas are a vulnerability in the face of
a DoS attack.  tcp must remain a fallback for queries, and be reserved in
the common case for updates and zone transfers.  doesn't matter who runs
the servers, if they're supposed to stay "up" then you can't depend on
them to have room for another tcp protocol control block in the common case.

> BTW, I have "ordered" an XML RR from IANA.  Putting the
> famous process to test.... :-)

i hope they turn you down.  XML would be as bad as TXT.  without subclassing,
every consumer would have to retrieve an arbitrarily large rrset, which is
not "the dns way" to do this.  note that RP and MX share an rdata format but
are used by different applications.  some new application-specific rrtypes
should be defined as having an XML payload, probably carried in a TXT-like
rdata format.  but the rrtype should be be by application, not rdata format.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 16:33:27 +0000
Lines: 15
References: <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 17:38:36 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> 
	of "Sun, 23 Jan 2005 12:39:16 GMT."
	<89621D32D279B49AA05CE1B1@Satori.nominet.org.uk> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> > after EDNS0, the foundations are just fine, thanks.  "more weight."
> 
> I'm not sure that means buildings of any and every type should be built on
> top of them though. There may be other types of foundations better suited
> to certain types of architecture (pun intended).

i agree, but you should all take a look at the following, just the same:

<http://www.doxpara.com/dns_bh/Black_Ops_DNS_BH_files/v3_document.htm>

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: John Levine <johnl@iecc.com>
Subject: Re: Retrieving large DNS objects
Date: 23 Jan 2005 16:36:20 -0000
Organization: I.E.C.C., Trumansburg NY USA
Lines: 25
References: <004b01c5012c$6e7be7d0$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Cc: anders.rundgren@telia.com
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 17:40:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: <004b01c5012c$6e7be7d0$80c5a8c0@rsaedoscymkikx>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>You retrieve the authoritative nameservers and in turn call these
>using TCP.  That is, you don't put any major load on the
>infrastructure at large only on the server you have a contract with
>or run on your own.  Is that a viable scheme?

Seems pointless to me.  If you know you're going to find a server
using traditional UDP DNS, open a TCP session, give it a key, and it
gives you back a blob of XML, we already have a widely deployed scheme
called http to do that.  It's got caches, alleged session security,
content negotiation, all the trendy bells and whistles.

What would be the advantage of shoehorning the XML into DNS?


-- 
Regards,
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
johnl@iecc.com, Mayor, http://johnlevine.com, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 12:13:12 -0500
Lines: 52
References: <004b01c5012c$6e7be7d0$80c5a8c0@rsaedoscymkikx>
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 Sun Jan 23 18:19:12 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <004b01c5012c$6e7be7d0$80c5a8c0@rsaedoscymkikx>
To: "Anders Rundgren" <anders.rundgren@telia.com>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 10:17 +0100 1/23/05, Anders Rundgren wrote:

>Does this (fat-object) paradigm fit DNS?

No.

It's hard to quantify in what way this proposal is wrong.

Applications have needs to search through and for data that is 
complex, dynamic, and large.  The DNS does not provide this and it 
shouldn't.

"Closed communities" and "open communities" are very different and 
have different needs.  The "science" differs between closed and open 
communities.  But there is a way to melt the two together.  The basic 
strategy is to create "lowest common denominator" (LCD) services for 
the open community and let the closed communities build upon that.

A community may be a company or it may be an application. 
Communities need not be topologically related.  This drives the need 
for a LCD open community tools.  This is why there is resistance to 
make the DNS too feature-rich.

>2
>Another possibility could be:
>You retrieve the authoritative nameservers and in turn call
>these using TCP.  That is, you don't put any major load on
>the infrastructure at large only on the server you have a
>contract with or run on your own.  Is that a viable scheme?

No.

There's a reason why UDP is the workhorse transport.  And it would be 
unwise to design the protocol that treats name servers differently. 
(I.e., the DNS is not aware of "contracts.")

>BTW, I have "ordered" an XML RR from IANA.  Putting the
>famous process to test.... :-)

Hope you followed the process documented in RFC 2929 and RFC 2434.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 18:10:03 +0100
Lines: 37
References: <20050123162924.32A1B13960@sa.vix.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 Jan 23 18:19:12 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Paul Vixie" <paul@vix.com>, <namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Paul Vixie wrote:

>> THE QUESTION:
>> Does this (fat-object) paradigm fit DNS?

>no.

Not even 4K seems OK?

>> BTW, I have "ordered" an XML RR from IANA.  Putting the
>> famous process to test.... :-)

>i hope they turn you down.

Well, then we can dismiss iab-dns-choices right now.
From DOA to EIP :-)

>XML would be as bad as TXT.  without subclassing,
>every consumer would have to retrieve an arbitrarily large rrset

What does this really mean?  You get ALL TXT records and it is
the clients who do the actual select?

If that is NOT the case (which I doubt as I cannot find any support for
that in RFCs) the "structured prefix/suffix" is an easier solution.
Avtually you HAVE to use this for NAPTR etc. as
"all NAPTRs are not equal".

So if we anyway must prefix/suffx why not use that all the way?

Anders R

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 18:43:56 +0100
Lines: 52
References: <20050123163620.7977.qmail@xuxa.iecc.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 Jan 23 18:49:00 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "John Levine" <johnl@iecc.com>, <namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>>You retrieve the authoritative nameservers and in turn call these
>>using TCP.  That is, you don't put any major load on the
>>infrastructure at large only on the server you have a contract with
>>or run on your own.  Is that a viable scheme?

>Seems pointless to me.  If you know you're going to find a server
>using traditional UDP DNS, open a TCP session, give it a key, and it
>gives you back a blob of XML, we already have a widely deployed scheme
>called http to do that.  It's got caches, alleged session security,
>content negotiation, all the trendy bells and whistles.

>What would be the advantage of shoehorning the XML into DNS?

To "find the server" is incorrect.
1. You find the nameserver using standard methods.
2. Now the trauma comes.  how do you identity this unique
object you are looking for?

Your solution:
goto IANA and get an RR.
wait an indefinite time for MSFT to support that in their admin GUI.
If you don't represent a major manufacturer/app you will NEVER get any support.
To *force* people to abandon these tools is a mission that I take no
interest in, irrespective of what I think of Microsoft.  Unless you find
a pleasure in creating things that can only be used by a handful
experts please do that but don't expect everyone else to follow.

Other solution:
1. Define a suitable RR ONCE.  The XML RR.
That *may* get MSFT support.  By using XML Schema import you
can create a "subclassed" GUI admin for *app-defined* XML data.
Does input validation and syntax check in spite of not knowing
what it is.

======================================
IANA and the IETF have nothing matching in the pipe-line
======================================

2. Use a structured prefix (created automatically if you have the
schema at hand) needed to access to your particular XML object.
This object may indeed indirect to http or be direct.  Which method
you end-up using has probly quite a bit with the app to do.
A dynamic thing will use http.  A static one will use direct data unless
it is really huge.

Anders

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 18:05:12 +0000
Lines: 89
References: <anders.rundgren@telia.com>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 19:10:30 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "Anders Rundgren" <anders.rundgren@telia.com> 
	of "Sun, 23 Jan 2005 18:10:03 +0100."
	<011301c5016e$621a7aa0$80c5a8c0@rsaedoscymkikx> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> >> Does this (fat-object) paradigm fit DNS?
> 
> >no.
> 
> Not even 4K seems OK?

that depends on whether you have read and whether you agree with the
kent/mogul "fragmentation considered harmful" report, which is online:

<http://research.compaq.com/wrl/techreports/abstracts/87.3.html>

for me, 4K is a fine exception case but on average i think 1500 is
still the right upper bound for wide area udp.  remember that a
fragments of a udp datagram are transmitted back to back with no
congestion awareness (like tcp has.)  congestion awareness requires
state, and statefulness in dns is bad for any number of reasons.

as evidence that i used to be able to do technical work instead of
just arguing on this mailing list, i refer you to RFC 2671, wherein:

| 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
|        reassembly buffer.  Choosing 1280 on an Ethernet connected
|        requestor would be reasonable.  The consequence of choosing too
|        large a value may be an ICMP message from an intermediate
|        gateway, or even a silent drop of the response message.

> >i hope they turn you down.
> 
> Well, then we can dismiss iab-dns-choices right now.
> From DOA to EIP :-)

honestly, the iab has smart and wonderful people on it, but i don't
wait on them and they don't wait on me.  i'm far more interested in
what rob austein thinks as a BIND9 architect than in what he thinks
as an IAB member.  <flame about ivory tower propellerheads elided>.

> >XML would be as bad as TXT.  without subclassing,
> >every consumer would have to retrieve an arbitrarily large rrset
> 
> What does this really mean?  You get ALL TXT records and it is
> the clients who do the actual select?

in the dark recesses of time, a smart and reasonable guy inside DEC
tried to subclass TXT by making the first "segment" be RFCXXXX and
the second segment be an IANA-assigned application identifier.  in
private communications, i explained that if this led to the existence
of something like

   FOO.DEC.COM IN TXT	RFCXXXX APP1 "whatever app1 is looking for"
		  TXT	RFCXXXX APP2 "whatever app2 is looking for"
		  TXT	RFCXXXX APP3 "whatever app3 is looking for"
		  TXT	RFCXXXX APP4 "whatever app4 is looking for"
		  TXT	RFCXXXX APP5 "whatever app5 is looking for"

then all five apps would have to retrieve the whole rrset and look
for the things they wanted, which would be hellishly expensive if
the number of apps became large or even moderate, or the amount of
data needed by any one app became large or even moderate.  i said
that it was a damned shame DNS didn't have subclassing, such that a
query could actually select a sub-rrset.  i recommended subdomains:

   APP1.FOO.DEC.COM IN TXT	"whatever app1 is looking for"
   APP2.FOO.DEC.COM IN TXT	"whatever app2 is looking for"
   APP3.FOO.DEC.COM IN TXT	"whatever app3 is looking for"
   APP4.FOO.DEC.COM IN TXT	"whatever app4 is looking for"
   APP5.FOO.DEC.COM IN TXT	"whatever app5 is looking for"

and as you all know, this is how SRV was done.  but it doesn't work
well with wildcards since wildcards aren't nonterminal.  if we had
nonterminal wildcards then TXT, and even something like XML (although
XML is just text, and an application wanting XML can just put it in),
to be used as generic containers without pain or inefficiency.

> If that is NOT the case (which I doubt as I cannot find any support for
> that in RFCs) the "structured prefix/suffix" is an easier solution.
> Avtually you HAVE to use this for NAPTR etc. as
> "all NAPTRs are not equal".
> 
> So if we anyway must prefix/suffx why not use that all the way?

there really ought to be a FAQ on this topic.  i know we've been down this
road any number of times.  i wish i had an online whitepaper or archive
i could point you at.  but, see above.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 18:17:43 +0000
Lines: 66
References: <anders.rundgren@telia.com>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 19:22:21 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from "Anders Rundgren" <anders.rundgren@telia.com> 
	of "Sun, 23 Jan 2005 18:43:56 +0100."
	<015401c50173$1e1226a0$80c5a8c0@rsaedoscymkikx> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> >What would be the advantage of shoehorning the XML into DNS?
> 
> To "find the server" is incorrect.
> 1. You find the nameserver using standard methods.
> 2. Now the trauma comes.  how do you identity this unique
> object you are looking for?

i guess you'd put it in the GET command that you send to the indicated server.

> Your solution:
> goto IANA and get an RR.
> wait an indefinite time for MSFT to support that in their admin GUI.

that's just silly.  no implementation, not even BIND with 90% or more of
the market, has the power to halt innovation.  we added SRV.  during the
years when MSFT didn't support SRV, folks didn't use MSFT's products to
carry SRV.  eventually the market catches on.  that's how it's supposed
to work, though it's bad that all these dns-aware firewalls and NATs are
refusing to carry opaque rrtypes that they don't recognize.  even those
NAT boxes eventually caught onto SRV though, since the market demanded it.
(and soon we will begin educating the NAT market about DNSSEC metatypes.)

> If you don't represent a major manufacturer/app you will NEVER get any
> support.  To *force* people to abandon these tools is a mission that I
> take no interest in, irrespective of what I think of Microsoft.
> Unless you find a pleasure in creating things that can only be used by
> a handful experts please do that but don't expect everyone else to
> follow.

my old boss (ken olsen of DEC) once wondered why anyone would ever want
to have a computer in their home.  now DEC is gone, because compaq and
HP both knew the answer to that question.  it sounds as if you'd like to
cede control over DNS evolution to a bunch of NAT and firewall vendors.
you won't find a lot of fellow travellers here for that road.

> Other solution:
> 1. Define a suitable RR ONCE.  The XML RR.
> That *may* get MSFT support.  By using XML Schema import you
> can create a "subclassed" GUI admin for *app-defined* XML data.
> Does input validation and syntax check in spite of not knowing
> what it is.
> 
> ======================================
> IANA and the IETF have nothing matching in the pipe-line
> ======================================
> 
> 2. Use a structured prefix (created automatically if you have the
> schema at hand) needed to access to your particular XML object.
> This object may indeed indirect to http or be direct.  Which method
> you end-up using has probly quite a bit with the app to do.
> A dynamic thing will use http.  A static one will use direct data unless
> it is really huge.

i need to check through my personal e-mail archives and figure out who
owes me the beer i bet somebody about when the proposal would finally
come to just redo DNS in XML.

listen, though.  DNS was here 20 years before XML became "the fad", and
DNS will still be here 20 years after XML has been replaced by a dozen
more fads.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 20:36:28 +0100
Lines: 66
References: <20050123180512.B62A2139B5@sa.vix.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 Jan 23 20:42:42 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Paul Vixie" <paul@vix.com>, <namedroppers@ops.ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Paul Vixie wrote:
> <flame about ivory tower propellerheads elided>.
Propellrheads don't ask questions. They know it all by "default".
I try (not successful but anyhow) to suggest and ask to make sure
that the XML RR I-D and URI-typing I-Ds won't be too bad.

>> What does this really mean?  You get ALL TXT records and it is
>> the clients who do the actual select?

Now it gets interesting!

>in the dark recesses of time, a smart and reasonable guy inside DEC
>tried to subclass TXT by making the first "segment" be RFCXXXX and
>the second segment be an IANA-assigned application identifier.  in
>private communications, i explained that if this led to the existence
>of something like

>   FOO.DEC.COM IN TXT RFCXXXX APP1 "whatever app1 is looking for"
>  TXT RFCXXXX APP2 "whatever app2 is looking for"
>  TXT RFCXXXX APP3 "whatever app3 is looking for"
>  TXT RFCXXXX APP4 "whatever app4 is looking for"
>  TXT RFCXXXX APP5 "whatever app5 is looking for"

>then all five apps would have to retrieve the whole rrset and look
>for the things they wanted, which would be hellishly expensive if
>the number of apps became large or even moderate, or the amount of
>data needed by any one app became large or even moderate.  i said
>that it was a damned shame DNS didn't have subclassing, such that a
>query could actually select a sub-rrset.  i recommended subdomains:

>   APP1.FOO.DEC.COM IN TXT "whatever app1 is looking for"
 >  APP2.FOO.DEC.COM IN TXT "whatever app2 is looking for"
>   APP3.FOO.DEC.COM IN TXT "whatever app3 is looking for"
 >  APP4.FOO.DEC.COM IN TXT "whatever app4 is looking for"
 >  APP5.FOO.DEC.COM IN TXT "whatever app5 is looking for"

>and as you all know, this is how SRV was done.  but it doesn't work
>well with wildcards since wildcards aren't nonterminal.

I recommend this one:

[arguments.]"unique type id".yourdomain IN TXT "data matching type id" 
(
Although not suitable for every app.  This one work wonders for Web Services
and DomainKeys.  Supports wild-carding also.  As-is.  Like listing
all domainkeys. 

If this variant work for the app in question, I don't see any reason for
getting a specific RR.  At least not with respect to RRset. AFAIK.

>if we had nonterminal wildcards then TXT, and even something like XML (although
>XML is just text, and an application wanting XML can just put it in),
>to be used as generic containers without pain or inefficiency.

There are a lot of things that does not need this but I don't see any
contradictions so let there be more powerful wildcards!

Particularly if that gives us yet another reason for *NOT* using iab-dns-choices...

Anders R

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Sun, 23 Jan 2005 19:51:51 +0000
Lines: 17
References: <20050123163327.A71E913960@sa.vix.com>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 20:56:26 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org
In-Reply-To: <20050123163327.A71E913960@sa.vix.com>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 23 January 2005 16:33 +0000 Paul Vixie <paul@vix.com> wrote:

> i agree, but you should all take a look at the following, just the same:
>
> <http://www.doxpara.com/dns_bh/Black_Ops_DNS_BH_files/v3_document.htm>

Indeed. But "can do" != "should do" :-)

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "John R Levine" <johnl@iecc.com>
Subject: Re: Retrieving large DNS objects
Date: 23 Jan 2005 15:16:48 -0500
Lines: 45
References: <20050123163620.7977.qmail@xuxa.iecc.com>
 <015401c50173$1e1226a0$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 21:21:30 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Anders Rundgren" <anders.rundgren@telia.com>
In-Reply-To: <015401c50173$1e1226a0$80c5a8c0@rsaedoscymkikx>
Cleverness: None detected
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> >gives you back a blob of XML, we already have a widely deployed scheme
> >called http to do that.  It's got caches, alleged session security,
> >content negotiation, all the trendy bells and whistles.
>
> >What would be the advantage of shoehorning the XML into DNS?
>
> To "find the server" is incorrect.
> 1. You find the nameserver using standard methods.
> 2. Now the trauma comes.  how do you identity this unique
> object you are looking for?
>
> Your solution:
> goto IANA and get an RR.

Oh, my.  I thought the point I was making was so blindingly obvious that I
wouldn't have to spell it out, but I guess I do.

Your thought here is to have a scheme where you hand a service a URI, it
makes a UDP call to find the address of a second server, it contacts that
second server via TCP which gives you back a blob of XML corresponding to
that URI, is it not?  That scheme has already been invented.  It's called
http, it's used all over the world.  It needs no new DNS record types, no
new servers, no new anything, since as you have probably noted, we all use
it now.

You may argue "but it's not in the DNS."  Quite right.  It doesn't need to
be in the DNS.  Since there is no XML data in the DNS (and probably never
will be), no applications expect to do XML lookups in DNS.  They use http,
because that's where the XML is.

Coding more complex data with XML and fetching it with http is a perfectly
reasonable idea.  The IIM message signing proposal fetches per-user keys
that way.  But putting it in the DNS would be pointless and
counterproductive, since http maps URIs to XML right now,

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Retrieving large DNS objects
Date: Sun, 23 Jan 2005 21:31:38 +0100
Lines: 73
References: <20050123163620.7977.qmail@xuxa.iecc.com> <015401c50173$1e1226a0$80c5a8c0@rsaedoscymkikx> <Pine.BSI.4.56.0501231347380.20128@tom.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Cc: <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Sun Jan 23 21:36:42 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "John R Levine" <johnl@iecc.com>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

John,
You did not answer the things that talked in advantage to XML, here thinking
of the GUI and the support you may get from the IT industry supporting
a lot of non-experts (=MSFT).

Yahoo specifies DomainKeys in DNS.  Does this make Yahoo stupid?

XML schemas instead of TXT would add less than 100bytes to
the 200-350 already in place.  Can't see that would kill XML.

Note I don't object at all to use http.  But that does not exclude XML.
IBM have a draft on that although they have managed to make an
XML object that is specific instead of universal.  They will get no
support from the business on this one.  They should have used TXT.

Why did they do a crummy design that goes nowhere? They were afraid that
they would be banned if using TXT.

Anders

----- Original Message ----- 
From: "John R Levine" <johnl@iecc.com>
To: "Anders Rundgren" <anders.rundgren@telia.com>
Cc: <namedroppers@ops.ietf.org>
Sent: Sunday, January 23, 2005 21:16
Subject: Re: Retrieving large DNS objects


> >gives you back a blob of XML, we already have a widely deployed scheme
> >called http to do that.  It's got caches, alleged session security,
> >content negotiation, all the trendy bells and whistles.
>
> >What would be the advantage of shoehorning the XML into DNS?
>
> To "find the server" is incorrect.
> 1. You find the nameserver using standard methods.
> 2. Now the trauma comes.  how do you identity this unique
> object you are looking for?
>
> Your solution:
> goto IANA and get an RR.

Oh, my.  I thought the point I was making was so blindingly obvious that I
wouldn't have to spell it out, but I guess I do.

Your thought here is to have a scheme where you hand a service a URI, it
makes a UDP call to find the address of a second server, it contacts that
second server via TCP which gives you back a blob of XML corresponding to
that URI, is it not?  That scheme has already been invented.  It's called
http, it's used all over the world.  It needs no new DNS record types, no
new servers, no new anything, since as you have probably noted, we all use
it now.

You may argue "but it's not in the DNS."  Quite right.  It doesn't need to
be in the DNS.  Since there is no XML data in the DNS (and probably never
will be), no applications expect to do XML lookups in DNS.  They use http,
because that's where the XML is.

Coding more complex data with XML and fetching it with http is a perfectly
reasonable idea.  The IIM message signing proposal fetches per-user keys
that way.  But putting it in the DNS would be pointless and
counterproductive, since http maps URIs to XML right now,

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: Retrieving large DNS objects
Date: Mon, 24 Jan 2005 11:07:50 +0100
Organization: RIPE NCC
Lines: 44
References: <20050123180512.B62A2139B5@sa.vix.com>
	<01a301c50182$d68c6ab0$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: paul@vix.com, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Jan 24 11:21:43 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Anders Rundgren" <anders.rundgren@telia.com>
In-Reply-To: <01a301c50182$d68c6ab0$80c5a8c0@rsaedoscymkikx>
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.000415 / -5.9
X-RIPE-Signature: 1c07a6130789835afca7b3f11f029381
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Sun, 23 Jan 2005 20:36:28 +0100
"Anders Rundgren" <anders.rundgren@telia.com> wrote:

> 
>  I recommend this one:
> 
>  [arguments.]"unique type id".yourdomain IN TXT "data matching type id" 
>  (
>  Although not suitable for every app.  This one work wonders for Web Services
>  and DomainKeys.  Supports wild-carding also.  As-is.  Like listing
>  all domainkeys. 
> 
>  If this variant work for the app in question, I don't see any reason for
>  getting a specific RR.  At least not with respect to RRset. AFAIK.


I do not immediately see how this scheme supports "wild-cards" in the
presence of delegations. An I-D on this idea would actually help to
structure the discussion and would lift this from "mailistware" to
something more tangible [*]



> There are a lot of things that does not need this but I don't see any
> contradictions so let there be more powerful wildcards!

See:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00182.html


-- Olaf

[*] I'd reckon that such an I-D would be more in scope for DNSOP than
DNSEXT, but we'll worry about that when its there.


---------------------------------| 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:46:15 2006
From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
Subject: Re: Weird Wildcards Work item (on wildcards vs RR types, was Faux wildcards)
Date: Mon, 24 Jan 2005 13:39:27 +0100
Lines: 20
References: <a06200709be1709a99fd2@[10.31.32.183]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Mon Jan 24 13:47:44 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs
X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol
To: "IETF DNSEXT WG" <namedroppers@ops.ietf.org>
In-reply-to: Your message of "Fri, 21 Jan 2005 14:36:49 EST."
             <a06200709be1709a99fd2@[10.31.32.183]> 
X-Organization: Uni Bielefeld, Technische Fakultaet
X-Phone: +49 521 106 2902
Content-ID: <3166.1106570366.1@grimsvotn.TechFak.Uni-Bielefeld.DE>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Edward Lewis <Ed.Lewis@neustar.biz> wrote:

> >that zone directives aren't really supported; even though directives are
> >(somewhat) defined in STD13, they aren't really supported in transfers,
> 
> ...do they need to be?  Once you've expanded the directive (think 
> $GENERATE, $TTL, $ORIGIN), there's no need to push it to other 
> servers.

they don't have to be supported for XFR, but having a standardized zone
format also allows us to distribute zone contents by other protocols. Having
the root zone available via ftp is one example.

-Peter

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Ben Laurie <ben@algroup.co.uk>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Mon, 24 Jan 2005 14:15:28 +0000
Lines: 24
References: <20050118211330.4589.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, alex@alex.org.uk
X-From: owner-namedroppers@ops.ietf.org Mon Jan 24 15:25:02 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: John Levine <johnl@iecc.com>
In-Reply-To: <20050118211330.4589.qmail@xuxa.iecc.com>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

John Levine wrote:
>>>There's no need for "new" wildcards.
>>
>>I'm not (yet) sure whether "new" wildcards is a protocol change, or
>>an "ease of use config option" on servers (i.e. an application change)
> 
> 
> It's only a protocol change if you use AXFR or IXFR to synchronize
> servers.  It doesn't affect normal DNS client-server interactions at
> all.

Or if you use DNSSEC.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Ben Laurie <ben@algroup.co.uk>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Mon, 24 Jan 2005 14:22:16 +0000
Lines: 23
References: <20050118214225.549E213E12@sa.vix.com>	<x4u0pd9r63.fsf@footbone.schlitt.net>	<4ADE1E98E70F1948511B9323@Satori.nominet.org.uk> <x4acr59n3w.fsf@footbone.schlitt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Mon Jan 24 15:28:06 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
In-Reply-To: <x4acr59n3w.fsf@footbone.schlitt.net>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

wayne wrote:
> One advantage of generating these on the fly ("wildcard") is that
> there would be less space taken up in memory, on disk and during zone
> transfers compared with preprocessing.

This clashes with DNSSEC again (since a requirement is that the signing 
key should not be needed on the server).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: wildcards vs. RR types, was Faux wildcards
Date: Mon, 24 Jan 2005 15:15:45 +0000
Lines: 23
References: <20050118211330.4589.qmail@xuxa.iecc.com>
 <41F50300.7010103@algroup.co.uk>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Mon Jan 24 16:22:48 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Ben Laurie <ben@algroup.co.uk>, John Levine <johnl@iecc.com>
In-Reply-To: <41F50300.7010103@algroup.co.uk>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 24 January 2005 14:15 +0000 Ben Laurie <ben@algroup.co.uk> wrote:

>> It's only a protocol change if you use AXFR or IXFR to synchronize
>> servers.  It doesn't affect normal DNS client-server interactions at
>> all.
>
> Or if you use DNSSEC.

Even then they aren't a protocol change if they are essentially
synthesis by macro expansion (or whatever), are generated prior
to signing, and can be decomposed into a combination of existing
wildcards and existing non-wildcard RRs (those are certainly
sufficient conditions, they may not all be necessary conditions).

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Scott Rose" <scottr@nist.gov>
Subject: RE: rfc2538bis to working group document
Date: Mon, 24 Jan 2005 11:47:01 -0500
Lines: 51
References: <20050117115718.3a23093c.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 Jan 24 17:53:27 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: <namedroppers@ops.ietf.org>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <20050117115718.3a23093c.olaf@ripe.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: scottr@nist.gov
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


I read the document and don't have any qualms about making this a WG
document at all.  One question though is will the Open Issues (Section 7) be
resolved before (or during) last call?  Is there any progress on these
items?

Scott


> -----Original Message-----
> From: owner-namedroppers@ops.ietf.org
> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf M. Kolkman
> Sent: Monday, January 17, 2005 5:57 AM
> To: namedroppers@ops.ietf.org
> Subject: rfc2538bis to working group document
>
>
>
> Dear Colleagues,
>
> Unless there are no objections by the end of this week Simon will post
> draft-josefsson-rfc2538bis-01.txt asdraft-ietf-dnsext-rfc2538bis-00.txt,
> thereby making the document a working group document (as it is
> on our charter).
>
> Shortly after the posting, and before the next meeting we will issue
> a last call on this document.
>
> Please review the document and send feedback to Simon and this list.
>
> See http://josefsson.org/rfc2538bis/ for document history.
>
> -- 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/>
>


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: bmanning@vacation.karoshi.com
Subject: Re: XML == BEER
Date: Mon, 24 Jan 2005 17:32:42 +0000
Lines: 15
References: <anders.rundgren@telia.com> <015401c50173$1e1226a0$80c5a8c0@rsaedoscymkikx> <20050123181743.F3DA113960@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 Mon Jan 24 18:39:22 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>
Content-Disposition: inline
In-Reply-To: <20050123181743.F3DA113960@sa.vix.com>
User-Agent: Mutt/1.4.1i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Sun, Jan 23, 2005 at 06:17:43PM +0000, Paul Vixie wrote:
> i need to check through my personal e-mail archives and figure out who
> owes me the beer i bet somebody about when the proposal would finally
> come to just redo DNS in XML.

	don't think it was beer per-se, but we did have this
	discussion.

--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:46:15 2006
From: bmanning@vacation.karoshi.com
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Mon, 24 Jan 2005 17:43:00 +0000
Lines: 40
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx> <88517.1106418126@bizet.nethelp.no> <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: sthaug@nethelp.no, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Jan 24 18:50:34 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Anders Rundgren <anders.rundgren@telia.com>
Content-Disposition: inline
In-Reply-To: <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
User-Agent: Mutt/1.4.1i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

> Let put it this way.  The majority of systems intrduced the last
> three years use XML.

	and the life expectancy of these systems is?

> >Both IP and DNS have changed since they were developed, and they will
> >change again. I don't believe "one of the most dated things in the
> >entire Internet space" is a reasonable characterization of DNS.
> 
> As a directory system it is certainly lagging at least.  512 bytes?  

	DNS is not a directory system...  :)

> The DNS specifications does not contain any kind of RFC
> that supports a _smooth_ introduction of new RR types. 

	yet.
 
> 1. There is no _proven_ need for new RR types except for things that only deals with DNS itself
> 2. Such a scheme would use XML and that seems to be something the DNS community
> don't understand at all
> 3. It will take forever and be extremely hard to agree on

	your assertions are interesting, but lack credibility.
	there are -proven- needs for new RR types (among other DNS attributes)
	Such new things will not all use XML (its too heavy-weight) but some
	may.
	Forever is a -very long- time.  But if its couched in terms of
	the life expectancy of "the majority of systems intrduced in the
	last three years" ... you may be right.

so....  repeat after me... "The DNS is not a directory system"

--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:46:15 2006
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: RE: wildcards vs. RR types, was Faux wildcards
Date: Mon, 24 Jan 2005 11:52:03 -0800
Lines: 42
Mime-Version: 1.0
Content-Type: text/plain
Cc: namedroppers@ops.ietf.org, alex@alex.org.uk
X-From: owner-namedroppers@ops.ietf.org Mon Jan 24 21:02:23 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "'Ben Laurie'" <ben@algroup.co.uk>, John Levine <johnl@iecc.com>
X-Mailer: Internet Mail Service (5.5.2657.72)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Ben Laurie

> John Levine wrote:
> >>>There's no need for "new" wildcards.
> >>
> >>I'm not (yet) sure whether "new" wildcards is a protocol 
> change, or an 
> >>"ease of use config option" on servers (i.e. an application change)
> > 
> > 
> > It's only a protocol change if you use AXFR or IXFR to synchronize 
> > servers.  It doesn't affect normal DNS client-server 
> interactions at 
> > all.
> 
> Or if you use DNSSEC.


Or if you use DNSSEC and the NXT-n record does not take account of this 

There are two possible paths here, the first is to write an NXT-n record
that meets this requirement. If there is going to be a killer app for DNSSEC
then signing email security policy records is most likely to be it.

The second is to simply expand out the macros and design in a means of
dealling with security policies that are assigned to a non existent node
separately. One way that this could be done would be to identify a
distinguished node _default that can be used for the default prefix.


My personal technical preference would be to have an appropriate NXT-n
record and avoid the need to do the macro expansion.




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Simon Josefsson <jas@extundo.com>
Subject: Re: rfc2538bis to working group document
Date: Mon, 24 Jan 2005 20:51:07 +0100
Lines: 70
References: <20050117115718.3a23093c.olaf@ripe.net>
	<ANECIHCPCBDLLEJLCOPGGEPFDDAA.scottr@nist.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Mon Jan 24 21:02:24 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Scott Rose" <scottr@nist.gov>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050124:scottr@nist.gov::DcYaFtSoAfXMef1S:1Ed2
X-Hashcash: 1:21:050124:namedroppers@ops.ietf.org::u1Uus3HNdM4RFMgM:002
In-Reply-To: <ANECIHCPCBDLLEJLCOPGGEPFDDAA.scottr@nist.gov> (Scott Rose's
	message of "Mon, 24 Jan 2005 11:47:01 -0500")
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
X-Virus-Scanned: ClamAV 0.80/680/Mon Jan 24 00:16:15 2005
	clamav-milter version 0.80j
	on yxa.extundo.com
X-Virus-Status: Clean
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Scott,

The open issues were discussed in:

http://article.gmane.org/gmane.ietf.dnsext/6392

I have not received any substantial comment on that message.

I am working on incorporating the proposed changes right now.

Regards,
Simon

"Scott Rose" <scottr@nist.gov> writes:

> I read the document and don't have any qualms about making this a WG
> document at all.  One question though is will the Open Issues (Section 7) be
> resolved before (or during) last call?  Is there any progress on these
> items?
>
> Scott
>
>
>> -----Original Message-----
>> From: owner-namedroppers@ops.ietf.org
>> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf M. Kolkman
>> Sent: Monday, January 17, 2005 5:57 AM
>> To: namedroppers@ops.ietf.org
>> Subject: rfc2538bis to working group document
>>
>>
>>
>> Dear Colleagues,
>>
>> Unless there are no objections by the end of this week Simon will post
>> draft-josefsson-rfc2538bis-01.txt asdraft-ietf-dnsext-rfc2538bis-00.txt,
>> thereby making the document a working group document (as it is
>> on our charter).
>>
>> Shortly after the posting, and before the next meeting we will issue
>> a last call on this document.
>>
>> Please review the document and send feedback to Simon and this list.
>>
>> See http://josefsson.org/rfc2538bis/ for document history.
>>
>> -- 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/>
>>
>
>
> --
> to unsubscribe send a message to namedroppers-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:46:15 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Mon, 24 Jan 2005 22:17:00 -0500 (EST)
Lines: 39
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx>
 <88517.1106418126@bizet.nethelp.no> <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
 <20050123081501.GA7092@dns.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 Jan 25 04:32:29 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: Andras Salamon <andras@dns.net>
In-Reply-To: <20050123081501.GA7092@dns.net>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Sun, 23 Jan 2005, Andras Salamon wrote:

> > The DNS specifications does not contain any kind of RFC
> > that supports a _smooth_ introduction of new RR types.
>
> You are right.  To introduce a new RR type you have to publish an RFC
> describing it.  Takes a bit of work.

Not necessarily.  RFC2929 sets aside about half of the type code space
as "Specification Required".  RFC2434 and 2434bis both define
"specification required" as: "Values and their meaning must be
documented in an RFC or other permanent and readily available
reference, in sufficient detail so that interoperability between
independent implementations is possible."

Presumably an academic paper, a book, or even a tech report would
suffice as 'permanent and readily available'.  So might a legislative
act or a published decision of a court of law.  Even a New York Times
article might meet that standard.  As to the specific standard IANA
applies, I'm not certain: I've repeatedly asked that question of Doug
Barton, IANA manager, and I have yet to get an unequivocal answer.

All that said, even publishing an RFC to get a typecode isn't that big
of a deal.  Three new typecodes were assigned by RFC3755.  The
individual submission that led to 3755 was first published on 27
February 2003.  The initial IANA assignments were made on 3 November
2003, approximately 8 months later, after the doc passed the IESG.

The IPSECKEY and SSHFP RRs have also been assigned.  IPSECKEY was
approved by the IESG on 28 September 2004 -- IANA made that assignment
on 20 December, less than two months later.

-- 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:46:15 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Mon, 24 Jan 2005 23:23:11 -0500
Lines: 54
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx>
 <88517.1106418126@bizet.nethelp.no>
 <004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
 <20050123081501.GA7092@dns.net> <Pine.GSO.4.55.0501242155090.5573@filbert>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: Andras Salamon <andras@dns.net>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 25 05:32:40 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <Pine.GSO.4.55.0501242155090.5573@filbert>
To: Samuel Weiler <weiler@tislabs.com>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 22:17 -0500 1/24/05, Samuel Weiler wrote:
>On Sun, 23 Jan 2005, Andras Salamon wrote:
>
>>  > The DNS specifications does not contain any kind of RFC
>>  > that supports a _smooth_ introduction of new RR types.
>>
>>  You are right.  To introduce a new RR type you have to publish an RFC
>>  describing it.  Takes a bit of work.

The ATMA RR type is not defined in an RFC.  Here is the definition:
     ftp://ftp.atmforum.com/pub/approved-specs/af-saa-0069.000.pdf

This is probably a historical oddity, but it can happen.

>Presumably an academic paper, a book, or even a tech report would
>suffice as 'permanent and readily available'.  So might a legislative
>act or a published decision of a court of law.  Even a New York Times
>article might meet that standard.  As to the specific standard IANA
>applies, I'm not certain: I've repeatedly asked that question of Doug
>Barton, IANA manager, and I have yet to get an unequivocal answer.

Those examples are far fetched.  The intent is that the definition be 
readily and freely available.  The ATM Forum has charged or required 
membership for access to some documents.  But, as far as I know, 
there has never been a charge to retrieve the document mentioned 
above.  (I am not an authority on the ATM Forum modes of operation.)

>All that said, even publishing an RFC to get a typecode isn't that big
>of a deal.  Three new typecodes were assigned by RFC3755.  The
>individual submission that led to 3755 was first published on 27
>February 2003.  The initial IANA assignments were made on 3 November
>2003, approximately 8 months later, after the doc passed the IESG.
>
>The IPSECKEY and SSHFP RRs have also been assigned.  IPSECKEY was
>approved by the IESG on 28 September 2004 -- IANA made that assignment
>on 20 December, less than two months later.

I think that is an overly rosy picture.  The time it takes from IESG 
approval to IANA reserving the number is usually quite short.  But it 
is the work up to IESG approval has historically taken quite a lot of 
time.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: Little endians, big endians, and 16 bit eggs
Date: Tue, 25 Jan 2005 10:14:03 +0100
Organization: RIPE NCC
Lines: 46
References: <002101c500aa$7e96a790$80c5a8c0@rsaedoscymkikx>
	<88517.1106418126@bizet.nethelp.no>
	<004e01c500c9$3707c610$80c5a8c0@rsaedoscymkikx>
	<20050123081501.GA7092@dns.net>
	<Pine.GSO.4.55.0501242155090.5573@filbert>
	<a06200702be1b7240c2c4@[10.31.32.104]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: weiler@tislabs.com, andras@dns.net, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 25 10:22:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <a06200702be1b7240c2c4@[10.31.32.104]>
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,BIZ_TLD
X-RIPE-Spam-Status: N 0.002248 / -3.6
X-RIPE-Signature: a3aeda675dceac199918cea6f25d6ca6
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Mon, 24 Jan 2005 23:23:11 -0500
Edward Lewis <Ed.Lewis@neustar.biz> wrote:

> 
>  I think that is an overly rosy picture.  The time it takes from IESG 
>  approval to IANA reserving the number is usually quite short.  But it 
>  is the work up to IESG approval has historically taken quite a lot of 
>  time.


As a working group we cannot do much to speed up that particular part of the
process.

However, the IESG will come to the DNSEXT group for assessment of
these proposals.

<our charter>

 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.

</our charter>

IMHO this is something this group should be able to do within a few
weeks. The earlier such proposals hit this group the better. 

(Note the "not require any special processing", what has been causing debate
over the last weeks is just that: the need for special processing to
find the zonecut.)


-- 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:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Retrieving large DNS objects
Date: Tue, 25 Jan 2005 10:11:33 +0100
Lines: 45
References: <20050123180512.B62A2139B5@sa.vix.com><01a301c50182$d68c6ab0$80c5a8c0@rsaedoscymkikx> <20050124110750.760af6d0.olaf@ripe.net>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "Paul Vixie" <paul@vix.com>, <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 25 10:22:32 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Olaf M. Kolkman" <olaf@ripe.net>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Olaf M. Kolkman wrote:
>>  If this variant work for the app in question, I don't see any reason for
>>  getting a specific RR.  At least not with respect to RRset. AFAIK.

>I do not immediately see how this scheme supports "wild-cards" in the
>presence of delegations.

To be fully honest; I don't know either as I am not fully aware of the problem
with wild-cards and delegation.  Is it possible to get a minimal info on this?
I would very much appreciate that.

Anyway, the target apps I work with "Web Services", don't really need wild-cards,
they just look for something they know (a specific object) somewhere where they
have been (OOB) told to look (in a partner domain).  So do most public key stuff
as well although they do usually not depend on any OOB info.

> An I-D on this idea would actually help to structure the discussion and would lift
>this from "mailistware" to something more tangible [*]

I don't plan to make an I-D here assuming that IANA will (as mr. Vixie
hopes) turn down the idea adding yet another TXT-like "container" RR.

I guess "whitepaperware" is considered as even worse than "mailistware"?
XML RR whitepaper: http://web.telia.com/~u18116613/XML-RR.pdf

Namedroppers prefer schemes where you first launch a new "DNS-aware"
app using TXT or hijack SRV (or something  equally stupid), and THEN
asks IANA for "granting" you a new RR and THEN IF you are successful with
IANA, ask your "user community" (which you may have no control of at all)
to change something that actually is working after writing an RFC (which
probably document-wise is entirely different from the rest of your app). 
To make it even more appetizing, MSFT probably don't intend to support any
new RR objects in their DNS GUI admin unless it becomes ubiquitous (or is
used by Windows...).  I can't blame them.  I would do exactly the same.
That's why I suggested an alternative route.  It may not fit everybody's need
but that is valid for the just described "solution" as well.

regaords
Anders R

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: Re: Retrieving large DNS objects
Date: Tue, 25 Jan 2005 11:36:15 +0100
Organization: RIPE NCC
Lines: 51
References: <20050123180512.B62A2139B5@sa.vix.com>
	<01a301c50182$d68c6ab0$80c5a8c0@rsaedoscymkikx>
	<20050124110750.760af6d0.olaf@ripe.net>
	<006601c502bd$df534ce0$80c5a8c0@rsaedoscymkikx>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: paul@vix.com, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Tue Jan 25 11:45:45 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Anders Rundgren" <anders.rundgren@telia.com>
In-Reply-To: <006601c502bd$df534ce0$80c5a8c0@rsaedoscymkikx>
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.000005 / -5.9
X-RIPE-Signature: c0ee0c3725242b7fc209a97dea24533f
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Tue, 25 Jan 2005 10:11:33 +0100
"Anders Rundgren" <anders.rundgren@telia.com> wrote:

> I don't plan to make an I-D here assuming that IANA will (as mr. Vixie
>  hopes) turn down the idea adding yet another TXT-like "container" RR.
> 
>  I guess "whitepaperware" is considered as even worse than "mailistware"?
>  XML RR whitepaper: http://web.telia.com/~u18116613/XML-RR.pdf

If you expect serious review of your proposal within IETF context
writing an I-D is the way.  And to be somewhat formal, as long as
"whitepaperware" does not have the appropriate copyright notices it is
out of scope. The main reasons for that are documented in the
introduction of RFC3667 to paraprhase: allow the IETF to take
ownership.

> Namedroppers prefer schemes where you first launch a new "DNS-aware"
> app using TXT or hijack SRV (or something  equally stupid), and THEN
> asks IANA for "granting" you a new RR and THEN IF you are successful with
> IANA, ask your "user community" (which you may have no control of at all)
> to change something that actually is working after writing an RFC (which
> probably document-wise is entirely different from the rest of your app). 

I do not share that perception. Namedroppers prefers rough consensus,
running code and a stable DNS.

> To make it even more appetizing, MSFT probably don't intend to support any
> new RR objects in their DNS GUI admin unless it becomes ubiquitous (or is
> used by Windows...).  I can't blame them.  I would do exactly the same.
> That's why I suggested an alternative route.  It may not fit everybody's need
> but that is valid for the just described "solution" as well.

Does this group try to engineer a solid architecture that is truly
interoperable or does it try to hack around implementations that do
not care about the existing standards anyway? ---a rhetoric question--
In the end its about making trade-offs and getting rough consensus on
them. Those trade-offs are best made when they are clearly summarized
and structured in an I-D.

--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:46:15 2006
From: "Anders Rundgren" <anders.rundgren@telia.com>
Subject: Re: Retrieving large DNS objects
Date: Tue, 25 Jan 2005 12:20:17 +0100
Lines: 93
References: <20050123180512.B62A2139B5@sa.vix.com><01a301c50182$d68c6ab0$80c5a8c0@rsaedoscymkikx><20050124110750.760af6d0.olaf@ripe.net><006601c502bd$df534ce0$80c5a8c0@rsaedoscymkikx> <20050125113615.3df5cb82.olaf@ripe.net>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Cc: <paul@vix.com>, <namedroppers@ops.ietf.org>
X-From: owner-namedroppers@ops.ietf.org Tue Jan 25 12:25:14 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Olaf M. Kolkman" <olaf@ripe.net>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Olaf,

I have no problems with the IETF taking ownership.

DomainKeys, SPF, IMM, CSV etc. though all indicate that my
perception of how things actually work differs from IETF's.

Off-list several parties have acknowledged the existence of
this "migration-from-the-interim-to-the-real-solution" trauma.
It is particularly a problem for the commercial sector which
simply doesn't have the time for doing things "the right way".
The so-called right way proponents do not acknowledge the
need for an easier route.   If there was one (well maybe there is...)
it would be judged by entirely different criterions than the right
way is. The question "how do you intend to control that the URIs
are properly used and deployed" is an indication of dual standards,
because it is equally applicable to the "right way" methodology.
The proper answer is of course simply: You cannot.

It is hard to see such information be put in an I-D unless it is
really just a "camouflaged pamphlet" like iab-dns-choices which
carefully avoids mentioning the migration problem.

Advice: Pamphlets are better off in other formats.  :-)

I do understand that real IETFers do not read PDFs.
OTOH, the majority of Internet SW developers have never
read an RFC either...

Anyway, I will keep the list informed on the progress with the XML RR
IANA reg.

Anders

----- Original Message ----- 
From: "Olaf M. Kolkman" <olaf@ripe.net>
To: "Anders Rundgren" <anders.rundgren@telia.com>
Cc: <paul@vix.com>; <namedroppers@ops.ietf.org>
Sent: Tuesday, January 25, 2005 11:36
Subject: Re: Retrieving large DNS objects


On Tue, 25 Jan 2005 10:11:33 +0100
"Anders Rundgren" <anders.rundgren@telia.com> wrote:

> I don't plan to make an I-D here assuming that IANA will (as mr. Vixie
>  hopes) turn down the idea adding yet another TXT-like "container" RR.
> 
>  I guess "whitepaperware" is considered as even worse than "mailistware"?
>  XML RR whitepaper: http://web.telia.com/~u18116613/XML-RR.pdf

If you expect serious review of your proposal within IETF context
writing an I-D is the way.  And to be somewhat formal, as long as
"whitepaperware" does not have the appropriate copyright notices it is
out of scope. The main reasons for that are documented in the
introduction of RFC3667 to paraprhase: allow the IETF to take
ownership.

> Namedroppers prefer schemes where you first launch a new "DNS-aware"
> app using TXT or hijack SRV (or something  equally stupid), and THEN
> asks IANA for "granting" you a new RR and THEN IF you are successful with
> IANA, ask your "user community" (which you may have no control of at all)
> to change something that actually is working after writing an RFC (which
> probably document-wise is entirely different from the rest of your app). 

I do not share that perception. Namedroppers prefers rough consensus,
running code and a stable DNS.

> To make it even more appetizing, MSFT probably don't intend to support any
> new RR objects in their DNS GUI admin unless it becomes ubiquitous (or is
> used by Windows...).  I can't blame them.  I would do exactly the same.
> That's why I suggested an alternative route.  It may not fit everybody's need
> but that is valid for the just described "solution" as well.

Does this group try to engineer a solid architecture that is truly
interoperable or does it try to hack around implementations that do
not care about the existing standards anyway? ---a rhetoric question--
In the end its about making trade-offs and getting rough consensus on
them. Those trade-offs are best made when they are clearly summarized
and structured in an I-D.

--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:46:15 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: Retrieving large DNS objects
Date: Wed, 26 Jan 2005 10:56:58 +0700
Lines: 43
References: <20050123162924.32A1B13960@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 Wed Jan 26 05:10:27 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Paul Vixie <paul@vix.com>
In-Reply-To: <20050123162924.32A1B13960@sa.vix.com> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        Sun, 23 Jan 2005 16:29:24 +0000
    From:        Paul Vixie <paul@vix.com>
    Message-ID:  <20050123162924.32A1B13960@sa.vix.com>

  | since the guaranteed
  | minimum maximum MTU has not changed (576 for V4)

Paul, you really know better I'm sure - that number isn't 576, it is 68.
576 is the "all hosts must be able to receive, reassembling if necessary,
datagrams this big" number.

The DNS packet size was never set to avoid fragmentation - it was set because
to send larger packets may mean that some hosts would be unable to receive
them, given that nothing requires that their IP stacks be able to handle that.

  | and is still small (1280 for V6),

Yes, though the v6 equivalent to 576 is 1500 I believe.

Two issues are important here - first though lots of things have grown
a lot in the past 20 years, packet sizes have not, they've barely changed
at all (factor of 3 increase probably).

  | any udp app for the wide area should be trying to avoid fragmentation.

Yes, fragmentation is not good.   It is indeed fortunate that many
people mistook the minimum required MTU as being 576, and so built
almost all links to at least that (in the past - these days nothing
that small gets deployed except on some - very few - end-links).
That had the effect that DNS packets all avoid fragmentation, which
is a very nice outcome, and something to keep encouraging, but it
neither is, nor ever was, fundamental - repeating a DNS query, when
a fragment of a reply is lost, is still cheaper than doing the whole
thing over TCP.

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:46:15 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: Weird Wildcards Work item (on wildcards vs RR types, was Faux wildcards)
Date: Wed, 26 Jan 2005 11:10:53 +0700
Lines: 43
References: <41F15DAB.7070505@ehsco.com>  <6.2.0.14.2.20050120161507.04493db8@localhost> <41F137CB.3090302@verisignlabs.com> <41F156CA.7030004@ehsco.com> <a06200709be1709a99fd2@[10.31.32.183]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Edward Lewis <Ed.Lewis@neustar.biz>,
   David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 05:29:05 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Eric A. Hall" <ehall@ehsco.com>
In-Reply-To: <41F15DAB.7070505@ehsco.com> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        Fri, 21 Jan 2005 14:53:15 -0500
    From:        "Eric A. Hall" <ehall@ehsco.com>
    Message-ID:  <41F15DAB.7070505@ehsco.com>

  | It's certainly possible for the master to expand the directive prior to
  | transfer (and there wouldn't be any difference in the data that the
  | replication partners served out), but in the general case it would be more
  | efficient to have the servers be able to exchange meta-data explicitly,
  | rather than the expanded data. Things like large blocks of textual data
  | (like SPF, or worse, Sender-ID), which you don't really need/want to
  | duplicate for each and every entry in the zone.

Personally, I don't know why systems wanting large blocks of textual
data want it in the DNS at all.   It just makes no sense.

The DNS is deliberately designed as a fast, cheap, low-overhead distributed
lookup mechanism (definitely not a directory, it has no search capabilities,
and should never grow them).

It is great for accessing precisely defined small blocks of data.

It is unfathomable to me why everyone keeps wanting to stick "large blocks
of textual data" in the DNS, when there are other protocols around that
do a great job of moving around those large blocks - of course they have
higher overheads and costs, but that can't really be avoided - dumping the
higher overheads and costs into the DNS so it can be mangled into carrying
these unreasonable data sets is a truly insane end goal.

Either use another existing protocol (if you need the low overheads of UDP,
TFTP allows data units to approx 32MB, and just about the same basic security
as the DNS currently has) or if there's nothing suitable - invent a new
protocol - as long as it runs over TCP or UDP, doing so is not really any
harder than updating DNS servers and clients to support something new, or
shouldn't be.

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:46:15 2006
From: Paul Vixie <paul@vix.com>
Subject: Re: Retrieving large DNS objects
Date: Wed, 26 Jan 2005 05:46:13 +0000
Lines: 49
References: <kre@munnari.OZ.AU>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 06:51:26 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
In-Reply-To: Message from Robert Elz <kre@munnari.OZ.AU> 
	of "Wed, 26 Jan 2005 10:56:58 +0700."
	<14748.1106711818@munnari.OZ.AU> 
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>   | since the guaranteed
>   | minimum maximum MTU has not changed (576 for V4)
> 
> Paul, you really know better I'm sure - that number isn't 576, it is
> 68.  576 is the "all hosts must be able to receive, reassembling if
> necessary, datagrams this big" number.
> 
> The DNS packet size was never set to avoid fragmentation - it was set
> because to send larger packets may mean that some hosts would be
> unable to receive them, given that nothing requires that their IP
> stacks be able to handle that.

i shouldn't've said "MTU".  i meant what you said, and i thought i
also said what you said.

>   | and is still small (1280 for V6),
> 
> Yes, though the v6 equivalent to 576 is 1500 I believe.
> 
> Two issues are important here - first though lots of things have grown
> a lot in the past 20 years, packet sizes have not, they've barely changed
> at all (factor of 3 increase probably).

it seems to me that the ratio of ethernet packet size to ethernet bit
frequency is now almost as granular as ATM-OC3.  10000000000/1500 vs.
155000000/53.  we all said 53 octets was too small at OC3 speeds, yet
here we are.  (i guess early experiences with teaching IP fragmentation
to fddi/ether bridges taught the ethernet industry Don't Do That, and
the rest is the future.)

>   | any udp app for the wide area should be trying to avoid fragmentation.
> 
> Yes, fragmentation is not good.   It is indeed fortunate that many
> people mistook the minimum required MTU as being 576, and so built
> almost all links to at least that (in the past - these days nothing
> that small gets deployed except on some - very few - end-links).
> That had the effect that DNS packets all avoid fragmentation, which
> is a very nice outcome, and something to keep encouraging, but it
> neither is, nor ever was, fundamental - repeating a DNS query, when
> a fragment of a reply is lost, is still cheaper than doing the whole
> thing over TCP.

yup.

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Olaf M. Kolkman" <olaf@ripe.net>
Subject: draft-ietf-dnsext-dnssec-opt-in
Date: Wed, 26 Jan 2005 09:50:00 +0100
Lines: 55
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 10:03:15 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: namedroppers@ops.ietf.org
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Dear Colleagues,

As we all know the OPT-IN draft was not approved for a standard track
document. Randy and Olafur (the chairs at that time) determined that
there was consensus that the proposal itself was technically solid
that there was no consensus that opt-in should become part of the
standard [1].

However, at the same time it was proposed that the document would
be published as informational with an appropriate boilerplate [2].

In WG meeting that took place after this message the question was
raised if OPT-IN should be published as experimental or informational
[3]. The working group never expressed its preference for either
informational or experimental RFC.

The task of writing a boilerplate was still on my list of things to
do and was slowly finding its way to the top of that list. At the
same time the "opt-in" phoenix raised from is ashes as
draft-blacka-dnssec-opt-in-01.txt.

This new version of "opt-in" is clearly intended to be published as
an experimental RFC and has draft-blacka-dnssec-experiments-00.txt as
normative reference.  Draft-blacka-dnssec-experiments has a wide
applicability and therefore my proposal is to accept
draft-blacka-experiments as a WG document and do careful review of
this methodology to perform experiments.

At the same time draft-blacka-opt-in is published as
draft-ietf-dnsext-dnssec-opt-in-07.  We want to limit ourselves to
review the proper application of the technique described in
"experiments". We have consensus on the technical solidity of the
"opt-in" proposal. The target of opt-in would _not_ be standards
track (there was no consensus for that) but experimental.
Unless feedback on this mail urges to do us otherwise the intention is 
to publish
the blacka-opt-in document as a new version of
draft-ietf-dnsext-opt-in, publish  draft-blacka-dnssec-experiments as
draft-ietf-dnssec-experiments and do a WGLC as soon as upcomming issues
on both documents have been resolved.

-- Olaf Kolkman     DNSEXT Co-Chair.

 [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01007.html
 [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01301.html
 [3] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01541.html




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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Alex Bligh <alex@alex.org.uk>
Subject: Re: Retrieving large DNS objects
Date: Wed, 26 Jan 2005 10:17:37 +0000
Lines: 19
References: <20050123162924.32A1B13960@sa.vix.com> 
 <14748.1106711818@munnari.OZ.AU>
Reply-To: Alex Bligh <alex@alex.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 11:27:58 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Elz <kre@munnari.OZ.AU>, Paul Vixie <paul@vix.com>
In-Reply-To: <14748.1106711818@munnari.OZ.AU>
X-Mailer: Mulberry/4.0.0a4 (Win32)
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



--On 26 January 2005 10:56 +0700 Robert Elz <kre@munnari.OZ.AU> wrote:

> It is indeed fortunate that many
> people mistook the minimum required MTU as being 576, and so built
> almost all links to at least that (in the past - these days nothing
> that small gets deployed except on some - very few - end-links).

Lower MTU would of course be helpful in order to support DNS in
IP tunneled over DNS. (ducks...)

Alex

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Ben Laurie <ben@algroup.co.uk>
Subject: Re: RFC 2538bis
Date: Wed, 26 Jan 2005 13:13:24 +0000
Lines: 155
References: <200410151949.PAA03947@ietf.org>	<ilu8ya7tyqm.fsf@latte.josefsson.org> <iluhdlzgwha.fsf@latte.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 14:22:45 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: Simon Josefsson <jas@extundo.com>
In-Reply-To: <iluhdlzgwha.fsf@latte.josefsson.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Simon Josefsson wrote:
> http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt
> 
> Feedback on the new material are especially appreciated.

2.1 Changing from "PGP cert" to "OpenPGP packet" allows things like 
encrypted messages to be stored in the DNS, which is probably not 
intended (though perhaps amusing).

3.1 (4) PGP -> OpenPGP.

3.2 The purpose-based name for a CRL is "Hostname of the issuing CA" - 
this strikes me as an error - it should be the DN of the CA certificate, 
surely?

3.3 Existing keyservers permit lookup by username only - it would be 
nice to preserve this functionality (though I'll confess I don't have a 
good suggestion for how!).

It might also be nice somewhere to mention that if the emails 
a.b@example.com and a@b.example.com both exist, they will transform to 
the same domain name, and so the OpenPGP packets for both emails should 
exist at that name, just for clarity.

3.4 for clarity it might help to say "Applications that receive an 
OpenPGP packet _containing encrypted or signed data_..."

6. If DNSSEC is used then the non-existence of a certificate can be 
securely asserted, but not with plain DNS. I think this should be mentioned.

> The document still mention three open issues.  I propose to resolve
> the open issues as follows.  If there are no objections, I will
> incorporate my proposals and publish -02.
> 
> If no further issues are brought up, I hope the document can be ready
> for last call before the next meeting.
> 
> Issue #1: Handling of X.509 or OpenPGP data that is larger than 64kb.
> This was discussed in section 4 of:
> 
> http://josefsson.org/gpgkeys_jkp/draft-josefsson-cert-openpgp.txt
> 
> However, it was pointed out that the specific proposal did not work
> (because if the RDATA is 65535 there is no room for other data).  A
> modified approach, that "chunk" the data appear to be feasible,
> though.
> 
> To illustrate the problem, Philip Zimmermann's PGP key is over 100kb
> large, and would not fit in a CERT RDATA field.
> 
> Because I am not aware of anyone except me who has discussed or
> proposed a solution to this problem, it may be that it is not
> considered a major issue.  Further, solving this appear to be
> complicated to describe.  And the need doesn't appear to be great.

An easy solution would be to allow a Certificate Type Value of INDIRECT, 
where the body of RR is the (HTTP?) URL from which the full certificate 
can be retrieved.

> Finally, should this turn out to be a critical problem in the future,
> the document could be updated again.
> 
> Proposal: Add the following text in a new section "Size limit":
> 
>    The RDATA field in DNS is restricted to 65535 octets (64kb).  This
>    means that each CERT RR cannot contain more than 64kb worth of
>    payload.
> 
> Issue #2:  Quoting the document:
> 
>    2.  Whether to enforce owner name guidelines with SHOULD/MUST.
> 
>        From David Shaw (on OpenPGP): "One of the things that struck me
>        when reading this draft is that while there are several
>        suggested ways to name keys in DNS, there is no one canonical
>        name as a SHOULD or MUST.  I suggest that the key fingerprint
>        be the canonical name, and all others be CNAMEs pointing to the
>        fingerprint name.".
> 
>        From Sean P.  Turner (on PKIX): "Should "recommended" be
>        "RECOMMENDED" in the 1st and 2nd sentences?"  referring to the
>        text in section 3 that recommend appropriate owner names.
> 
> Since this issue was brought up in both PKIX and OpenPGP WGs, I
> believe it should be addressed.  I'm inclined to agree with David's
> proposal.
> 
> Unless someone knows of a good reason, preferably in the form of a
> deployed use of the CERT RR, or an argument based on DNS traditions,
> that would violate making the (using the new terminology)
> purpose-based owner name rules a SHOULD, that is what I propose.
> 
> Proposal: Add "Implementations SHOULD use the purpose-based owner name
> guidelines described in this document, and MAY use CNAMEs at the
> content-based owner names, pointing to the purpose-based owner name.".

Agreed.

> Issue #3: Quoting the document:
> 
>    3.  Should the document suggest use of both full fingerprints, 4/8
>        byte OpenPGP key id owner names?  Perhaps only fingerprint
>        version.
> 
> This is slightly related to the previous issue.  It may be argued that
> the purposed-based owner name that SHOULD be used is the full OpenPGP
> key fingerprint (this is what David propose), and that the others MAY
> be CNAMEs.
> 
> However, I'm not sure this will work well.  Consider two full
> fingerprints that have the same 4 byte key id:
> 
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567
> bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567
> 
> Now, this won't work:
> 
> 01234567 IN CNAME aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567
> 01234567 IN CNAME bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567
> 
> and although:
> 
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567 IN CNAME 01234567
> bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567 IN CNAME 01234567
> 
> would work, it means that querying for either of the two full
> fingerprints will result in both keys under one name:
> 
> 01234567 IN CERT <key for aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa01234567>
> 01234567 IN CERT <key for bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb01234567>
> 
> which is inefficient, because both the client and the server knew the
> full fingerprint the client wanted.
> 
> Proposal: Mention this issue, and suggest that implementations MAY
> chose to not use CNAMEs in this situation (thus violating the MAY in
> issue #2), but rather serve the same key at several CERT RRs.

Agreed.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Simon Josefsson <jas@extundo.com>
Subject: Re: RFC 2538bis
Date: Wed, 26 Jan 2005 15:02:40 +0100
Lines: 162
References: <200410151949.PAA03947@ietf.org>
	<ilu8ya7tyqm.fsf@latte.josefsson.org>
	<iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 15:08:35 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Ben Laurie <ben@algroup.co.uk>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050126:ben@algroup.co.uk::m6Z2NjF2Iyy8Kjuc:4cwZ
X-Hashcash: 1:21:050126:namedroppers@ops.ietf.org::8Ogz0BUwEXEfSEU9:MjPl
In-Reply-To: <41F79774.4060402@algroup.co.uk> (Ben Laurie's message of "Wed,
	26 Jan 2005 13:13:24 +0000")
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
X-Virus-Scanned: ClamAV 0.80/680/Mon Jan 24 00:16:15 2005
	clamav-milter version 0.80j
	on yxa.extundo.com
X-Virus-Status: Clean
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Hello Ben, thanks for the feedback.

The updated document has been finished, but I'm having trouble getting
the I-D editor to accept it as a WG document.

Meanwhile, the live version is available from
<http://josefsson.org/rfc2538bis/>.

If the editor ask for a new copy, I'll send them the version that has
been updated as per your suggestions, but otherwise it will end up in
the next version.

Ben Laurie <ben@algroup.co.uk> writes:

> Simon Josefsson wrote:
>> http://josefsson.org/rfc2538bis/draft-josefsson-pkix-dns-00.txt
>> Feedback on the new material are especially appreciated.
>
> 2.1 Changing from "PGP cert" to "OpenPGP packet" allows things like 
> encrypted messages to be stored in the DNS, which is probably not 
> intended (though perhaps amusing).

This was discussed in the OpenPGP WG, see:

http://thread.gmane.org/gmane.ietf.openpgp/5458

and in particular

http://article.gmane.org/gmane.ietf.openpgp/5462

The problem with not allowing any packet is that then you need to
specify specifically which packets are permitted.  I tried that
approach in -00, which read:

   The PGP type indicates an OpenPGP data packet.  Two uses are to
   transfer public key material and revocation signatures.  The data is
   binary, and MUST NOT be encoded into an ASCII armor.  Public keys can
   use the OpenPGP public key packet (tag 6) or public subkey packet
   (tag 14), as described in section 5.5 of [5].  Revocation signatures
   can use an OpenPGP signature packet with a revocation signature type,
   i.e., signature type 0x20, 0x28 or 0x30, as described in section 5.2
   of [5].

However, it is not clear to me that the list of packets above is
exhaustive.  An incorrect list would be bad.  My OpenPGP knowledge is
too limited to assert an exhaustive list, so I am leaning toward the
text that was derived from Florian's proposal in the OpenPGP WG:

   The PGP type indicates an OpenPGP packet as described in [5] and its
   extensions and successors.  Two uses are to transfer public key
   material and revocation signatures.  The data is binary, and MUST NOT
   be encoded into an ASCII armor.  An implementation SHOULD process
   transferable public keys as described in section 10.1 of [5], but it
   MAY handle additional OpenPGP packets.

It does not seem to me that an CERT RRs with an encrypted packet
should be considered a syntax error, so this solution seem sufficient
to get interoperability.

I'm not completely sure, but this issue doesn't seem that different
from various X.509 variations (think degenerative v1 certificates, or
weird extensions), which supposedly are also permitted even though it
is practically useless.

> 3.1 (4) PGP -> OpenPGP.

Fixed, thanks.

> 3.2 The purpose-based name for a CRL is "Hostname of the issuing CA" - 
> this strikes me as an error - it should be the DN of the CA certificate, 
> surely?

Translated into a domain name how?

I admit the purpose-based X.50 owner name rules may be a bit sketchy.

I have only experience with them for S/MIME and TLS certificates.

> 3.3 Existing keyservers permit lookup by username only - it would be 
> nice to preserve this functionality (though I'll confess I don't have a 
> good suggestion for how!).

That would be the content-based owner name guideline, no?

RFC 2538 said you should put the OpenPGP key with user id
jas@extundo.com at the domain name jas.extundo.com.

> It might also be nice somewhere to mention that if the emails 
> a.b@example.com and a@b.example.com both exist, they will transform to 
> the same domain name, and so the OpenPGP packets for both emails should 
> exist at that name, just for clarity.

No, I think a.b@example.com should be put at a\.b.example.com and
a@b.example.com at a.b.example.com.  As far as I know, this is how
dots inside SOA RNAME has always been handled, and is what RFC 2538
refer to as the "standard translation".

See RFC 1035 section 5.3 for an example.

> 3.4 for clarity it might help to say "Applications that receive an 
> OpenPGP packet _containing encrypted or signed data_..."

Done.

> 6. If DNSSEC is used then the non-existence of a certificate can be 
> securely asserted, but not with plain DNS. I think this should be mentioned.

I added:

  <t>If <xref target="I-D.ietf-dnsext-dnssec-intro">DNSSEC</xref> is
    used then the non-existence of a CERT RR, and consequently
    certificates or revocation lists, can be securely asserted.
    Without DNSSEC, this is not possible.</t>

>> The document still mention three open issues.  I propose to resolve
>> the open issues as follows.  If there are no objections, I will
>> incorporate my proposals and publish -02.
>> If no further issues are brought up, I hope the document can be
>> ready
>> for last call before the next meeting.
>> Issue #1: Handling of X.509 or OpenPGP data that is larger than
>> 64kb.
>> This was discussed in section 4 of:
>> http://josefsson.org/gpgkeys_jkp/draft-josefsson-cert-openpgp.txt
>> However, it was pointed out that the specific proposal did not work
>> (because if the RDATA is 65535 there is no room for other data).  A
>> modified approach, that "chunk" the data appear to be feasible,
>> though.
>> To illustrate the problem, Philip Zimmermann's PGP key is over 100kb
>> large, and would not fit in a CERT RDATA field.
>> Because I am not aware of anyone except me who has discussed or
>> proposed a solution to this problem, it may be that it is not
>> considered a major issue.  Further, solving this appear to be
>> complicated to describe.  And the need doesn't appear to be great.
>
> An easy solution would be to allow a Certificate Type Value of INDIRECT, 
> where the body of RR is the (HTTP?) URL from which the full certificate 
> can be retrieved.

That seem to be a good idea to me.  It could be described and
registered in a separate document, though.

On the other hand, it may be so simple to do that it is worth adding.
Doing so would solve this currently unaddressed problem in the
document, a problem which do lead to some practical difficulties.

If you want to propose a section on it, and nobody objects, I think it
could be added.

Whether we can publish 2538bis as DRAFT or recycle at PROPOSED may be
a factor here.  I don't know what people's thoughts is on this.  My
feelings are that recycling at PROPOSED is fine, since 2538 has not
been widely deployed.

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:46:15 2006
From: Ben Laurie <ben@algroup.co.uk>
Subject: Re: RFC 2538bis
Date: Wed, 26 Jan 2005 14:42:48 +0000
Lines: 153
References: <200410151949.PAA03947@ietf.org>	<ilu8ya7tyqm.fsf@latte.josefsson.org>	<iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk> <ilu1xc8jnjz.fsf@latte.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 15:50:35 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: Simon Josefsson <jas@extundo.com>
In-Reply-To: <ilu1xc8jnjz.fsf@latte.josefsson.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Simon Josefsson wrote:
> Ben Laurie <ben@algroup.co.uk> writes:
> It does not seem to me that an CERT RRs with an encrypted packet
> should be considered a syntax error, so this solution seem sufficient
> to get interoperability.

OK.

> I'm not completely sure, but this issue doesn't seem that different
> from various X.509 variations (think degenerative v1 certificates, or
> weird extensions), which supposedly are also permitted even though it
> is practically useless.

Of course, you can put extensions into X.509 to do anything, its true.

>>3.2 The purpose-based name for a CRL is "Hostname of the issuing CA" - 
>>this strikes me as an error - it should be the DN of the CA certificate, 
>>surely?
> 
> Translated into a domain name how?

Well, one way would be to hash it. The hostname is unworkable, though - 
most CA certs don't include a hostname at all, and even if they did, it 
is likely to be ambiguous (which is acceptable, but inefficient).

Hmm. An issue is that then there's no difference between the cert and 
the CRL's names. Of course, a compliant cert says where the CRL is 
anyway, so perhaps we shouldn't even be including CRLs?

> I admit the purpose-based X.50 owner name rules may be a bit sketchy.
> 
> I have only experience with them for S/MIME and TLS certificates.

Then look at some TLS CA certs :-)

>>3.3 Existing keyservers permit lookup by username only - it would be 
>>nice to preserve this functionality (though I'll confess I don't have a 
>>good suggestion for how!).
> 
> 
> That would be the content-based owner name guideline, no?
> 
> RFC 2538 said you should put the OpenPGP key with user id
> jas@extundo.com at the domain name jas.extundo.com.

I meant their "real name" (e.g. "Simon Josefsson") not their email.

>>It might also be nice somewhere to mention that if the emails 
>>a.b@example.com and a@b.example.com both exist, they will transform to 
>>the same domain name, and so the OpenPGP packets for both emails should 
>>exist at that name, just for clarity.
> 
> No, I think a.b@example.com should be put at a\.b.example.com and
> a@b.example.com at a.b.example.com.  As far as I know, this is how
> dots inside SOA RNAME has always been handled, and is what RFC 2538
> refer to as the "standard translation".

Ah, excellent, withdrawn.

>>6. If DNSSEC is used then the non-existence of a certificate can be 
>>securely asserted, but not with plain DNS. I think this should be mentioned.
> 
> 
> I added:
> 
>   <t>If <xref target="I-D.ietf-dnsext-dnssec-intro">DNSSEC</xref> is
>     used then the non-existence of a CERT RR, and consequently
>     certificates or revocation lists, can be securely asserted.
>     Without DNSSEC, this is not possible.</t>

Agreed.

>>>The document still mention three open issues.  I propose to resolve
>>>the open issues as follows.  If there are no objections, I will
>>>incorporate my proposals and publish -02.
>>>If no further issues are brought up, I hope the document can be
>>>ready
>>>for last call before the next meeting.
>>>Issue #1: Handling of X.509 or OpenPGP data that is larger than
>>>64kb.
>>>This was discussed in section 4 of:
>>>http://josefsson.org/gpgkeys_jkp/draft-josefsson-cert-openpgp.txt
>>>However, it was pointed out that the specific proposal did not work
>>>(because if the RDATA is 65535 there is no room for other data).  A
>>>modified approach, that "chunk" the data appear to be feasible,
>>>though.
>>>To illustrate the problem, Philip Zimmermann's PGP key is over 100kb
>>>large, and would not fit in a CERT RDATA field.
>>>Because I am not aware of anyone except me who has discussed or
>>>proposed a solution to this problem, it may be that it is not
>>>considered a major issue.  Further, solving this appear to be
>>>complicated to describe.  And the need doesn't appear to be great.
>>
>>An easy solution would be to allow a Certificate Type Value of INDIRECT, 
>>where the body of RR is the (HTTP?) URL from which the full certificate 
>>can be retrieved.
> 
> 
> That seem to be a good idea to me.  It could be described and
> registered in a separate document, though.
> 
> On the other hand, it may be so simple to do that it is worth adding.
> Doing so would solve this currently unaddressed problem in the
> document, a problem which do lead to some practical difficulties.

It would prevent the publication of the public PGP keyring, which seems 
a shame!

BTW, CRLs are often well over 64 kB, too.

> If you want to propose a section on it, and nobody objects, I think it
> could be added.

You'll need to change "certificate or CRL" in 2 to "certificate, CRL or 
URL", add in 2.1

   4    IPKIX    The URL of an X.509 data object
   5    ISPKI    The URL of an SPKI certificate
   6    IPGP     The URL of an OpenPGP packet

Then text:

The IPKIX, ISPKI and IPGP types indicate a URL which will serve the 
content that would have been in the "certificate, CRL or URL" field of 
the corresponding (PKIX, SPKI or PGP) packet types. These packet types 
MUST be used when the content is too large to fit in the CERT RR, and 
MAY be used at the implementations discretion. They SHOULD NOT be used 
where the entire UDP packet would have fit in 512 bytes.

Not religious about that last sentence, but it seems like a good idea.

> Whether we can publish 2538bis as DRAFT or recycle at PROPOSED may be
> a factor here.  I don't know what people's thoughts is on this.  My
> feelings are that recycling at PROPOSED is fine, since 2538 has not
> been widely deployed.

I guess we're not in a huge rush.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: "Eric A. Hall" <ehall@ehsco.com>
Subject: Re: Weird Wildcards Work item (on wildcards vs RR types, was Faux
 wildcards)
Date: Wed, 26 Jan 2005 10:09:59 -0500
Lines: 51
References: <41F15DAB.7070505@ehsco.com>  <6.2.0.14.2.20050120161507.04493db8@localhost> <41F137CB.3090302@verisignlabs.com> <41F156CA.7030004@ehsco.com> <a06200709be1709a99fd2@[10.31.32.183]> <7982.1106712653@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Edward Lewis <Ed.Lewis@neustar.biz>,
	David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 16:16:55 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: <7982.1106712653@munnari.OZ.AU>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On 1/25/2005 11:10 PM, Robert Elz wrote:
>     Date:        Fri, 21 Jan 2005 14:53:15 -0500
>     From:        "Eric A. Hall" <ehall@ehsco.com>
>     Message-ID:  <41F15DAB.7070505@ehsco.com>
> 
>   | It's certainly possible for the master to expand the directive prior to
>   | transfer (and there wouldn't be any difference in the data that the
>   | replication partners served out), but in the general case it would be more
>   | efficient to have the servers be able to exchange meta-data explicitly,
>   | rather than the expanded data. Things like large blocks of textual data
>   | (like SPF, or worse, Sender-ID), which you don't really need/want to
>   | duplicate for each and every entry in the zone.
> 
> Personally, I don't know why systems wanting large blocks of textual
> data want it in the DNS at all.   It just makes no sense.
> 
> The DNS is deliberately designed as a fast, cheap, low-overhead distributed
> lookup mechanism (definitely not a directory, it has no search capabilities,
> and should never grow them).

http://www.ehsco.com/misc/I-Ds/draft-hall-dns-data-04.txt pretty much
demonstrates that I agree with this I think. If you check the MARID
archives, you'll find my position to have been pretty clear there too,
especially as it pertains to XML in the DNS.

> It is unfathomable to me why everyone keeps wanting to stick "large blocks
> of textual data" in the DNS, when there are other protocols around that
> do a great job of moving around those large blocks

Well for one thing, we've done a poor job of getting out the message that
DNS is a lightweight naming service. For another, we've done a poor job of
providing a distributed directory that provides what folks want.

But that's pretty much irrelevant to the point that you are replying to.
Obviously there is a need for something like $DEFAULT directives, even for
small RRs like MX, and moreso for things like SPF and Sender-ID,
regardless of whether or not they should exist in the first place. OTOH, I
can see some value in the argument that people should be made to suffer
for their mistakes, and in that case, replicating meta-data is not only
unneeded but counterproductive.

-- 
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:46:15 2006
From: Simon Josefsson <jas@extundo.com>
Subject: Re: RFC 2538bis
Date: Wed, 26 Jan 2005 17:38:39 +0100
Lines: 119
References: <200410151949.PAA03947@ietf.org>
	<ilu8ya7tyqm.fsf@latte.josefsson.org>
	<iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk>
	<ilu1xc8jnjz.fsf@latte.josefsson.org> <41F7AC68.7060504@algroup.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 17:49:17 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Ben Laurie <ben@algroup.co.uk>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050126:ben@algroup.co.uk::uJMNbms2RES4qU6a:C7A5
X-Hashcash: 1:21:050126:namedroppers@ops.ietf.org::3e+wUHowpyeVGfjg:WPjW
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
X-Virus-Scanned: ClamAV 0.80/680/Mon Jan 24 00:16:15 2005
	clamav-milter version 0.80j
	on yxa.extundo.com
X-Virus-Status: Clean
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Ben Laurie <ben@algroup.co.uk> writes:

>>> 3.2 The purpose-based name for a CRL is "Hostname of the issuing
>>> CA" - 
>>> this strikes me as an error - it should be the DN of the CA
>>> certificate, surely?
>> Translated into a domain name how?
>
> Well, one way would be to hash it. The hostname is unworkable, though - 
> most CA certs don't include a hostname at all, and even if they did, it 
> is likely to be ambiguous (which is acceptable, but inefficient).
>
> Hmm. An issue is that then there's no difference between the cert and 
> the CRL's names. Of course, a compliant cert says where the CRL is 
> anyway, so perhaps we shouldn't even be including CRLs?

I have removed it.

If anyone distribute CRLs through CERT RRs and care about this issue,
let me know.

>> I admit the purpose-based X.50 owner name rules may be a bit sketchy.
>> I have only experience with them for S/MIME and TLS certificates.
>
> Then look at some TLS CA certs :-)

I meant S/MIME user certificates and TLS server certificates.

I'm not sure there is a good use case for ever storing CA certificates
in the DNS.  (Except for self-signed user/server certificates.)
Perhaps for OCSP or CMP?  I dunno.

All this seem to be speculation, so it doesn't belong in the document
yet, I think.

>>> 3.3 Existing keyservers permit lookup by username only - it would
>>> be nice to preserve this functionality (though I'll confess I don't
>>> have a good suggestion for how!).
>> That would be the content-based owner name guideline, no?
>> RFC 2538 said you should put the OpenPGP key with user id
>> jas@extundo.com at the domain name jas.extundo.com.
>
> I meant their "real name" (e.g. "Simon Josefsson") not their email.

Oh, I see.

I don't see any way to achieve this, the DNS do not handle
directory-like searches.  I don't see keyservers going away, though,
so this functionality isn't critical.

I agree it would be a nice addition, if there were a proposal on how
to do it, though.

>>> An easy solution would be to allow a Certificate Type Value of
>>> INDIRECT, where the body of RR is the (HTTP?) URL from which the
>>> full certificate can be retrieved.
>> That seem to be a good idea to me.  It could be described and
>> registered in a separate document, though.
>> On the other hand, it may be so simple to do that it is worth
>> adding.
>> Doing so would solve this currently unaddressed problem in the
>> document, a problem which do lead to some practical difficulties.
>
> It would prevent the publication of the public PGP keyring, which seems 
> a shame!
>
> BTW, CRLs are often well over 64 kB, too.

Indeed.

>> If you want to propose a section on it, and nobody objects, I think it
>> could be added.
>
> You'll need to change "certificate or CRL" in 2 to "certificate, CRL or 
> URL", add in 2.1
>
>   4    IPKIX    The URL of an X.509 data object
>   5    ISPKI    The URL of an SPKI certificate
>   6    IPGP     The URL of an OpenPGP packet

One objection would be that it doesn't scale well.  Every certificate
format would now need two sub-types.  One direct, and one indirect.

However, I don't anticipate the IETF standardizing hundreds of
certificate-like formats in the short term, though, so it may be
acceptable.

Btw, is the size issue relevant for SPKI certificates?  I have never
seen large (>>20kb) SPKI blobs.  SPKI is EXPERIMENTAL too, so I don't
think we cannot normatively reference it.  It may be better to keep it
reserved for when SPKI become a PROPOSED standard.

> Then text:
>
> The IPKIX, ISPKI and IPGP types indicate a URL which will serve the 
> content that would have been in the "certificate, CRL or URL" field of 
> the corresponding (PKIX, SPKI or PGP) packet types. These packet types 
> MUST be used when the content is too large to fit in the CERT RR, and 
> MAY be used at the implementations discretion. They SHOULD NOT be used 
> where the entire UDP packet would have fit in 512 bytes.
>
> Not religious about that last sentence, but it seems like a good idea.

Some discussion about the owner names for these types is probably
needed as well.

What do people think about this indirect proposal?  It is similar in
style as the existing "private URI" mechanism, but more formal.

Unless anyone object, I'll add this, as it resolve a known practical
problem with CERT RR.

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:46:15 2006
From: Ben Laurie <ben@algroup.co.uk>
Subject: Re: RFC 2538bis
Date: Wed, 26 Jan 2005 17:24:38 +0000
Lines: 131
References: <200410151949.PAA03947@ietf.org>	<ilu8ya7tyqm.fsf@latte.josefsson.org>	<iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk>	<ilu1xc8jnjz.fsf@latte.josefsson.org> <41F7AC68.7060504@algroup.co.uk> <iluvf9kgn74.fsf@latte.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 18:33:49 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: Simon Josefsson <jas@extundo.com>
In-Reply-To: <iluvf9kgn74.fsf@latte.josefsson.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Simon Josefsson wrote:
> Ben Laurie <ben@algroup.co.uk> writes:
> 
> 
>>>>3.2 The purpose-based name for a CRL is "Hostname of the issuing
>>>>CA" - 
>>>>this strikes me as an error - it should be the DN of the CA
>>>>certificate, surely?
>>>
>>>Translated into a domain name how?
>>
>>Well, one way would be to hash it. The hostname is unworkable, though - 
>>most CA certs don't include a hostname at all, and even if they did, it 
>>is likely to be ambiguous (which is acceptable, but inefficient).
>>
>>Hmm. An issue is that then there's no difference between the cert and 
>>the CRL's names. Of course, a compliant cert says where the CRL is 
>>anyway, so perhaps we shouldn't even be including CRLs?
> 
> I have removed it.
> 
> If anyone distribute CRLs through CERT RRs and care about this issue,
> let me know.

Seems fair to me.

>>>I admit the purpose-based X.50 owner name rules may be a bit sketchy.
>>>I have only experience with them for S/MIME and TLS certificates.
>>
>>Then look at some TLS CA certs :-)
> 
> I meant S/MIME user certificates and TLS server certificates.
> 
> I'm not sure there is a good use case for ever storing CA certificates
> in the DNS.  (Except for self-signed user/server certificates.)

That alone sounds like a good case - particularly if served over DNSSEC!

> Perhaps for OCSP or CMP?  I dunno.
> 
> All this seem to be speculation, so it doesn't belong in the document
> yet, I think.

I'm not sure what you want to remove now?

>>>>3.3 Existing keyservers permit lookup by username only - it would
>>>>be nice to preserve this functionality (though I'll confess I don't
>>>>have a good suggestion for how!).
>>>
>>>That would be the content-based owner name guideline, no?
>>>RFC 2538 said you should put the OpenPGP key with user id
>>>jas@extundo.com at the domain name jas.extundo.com.
>>
>>I meant their "real name" (e.g. "Simon Josefsson") not their email.
> 
> 
> Oh, I see.
> 
> I don't see any way to achieve this, the DNS do not handle
> directory-like searches.  I don't see keyservers going away, though,
> so this functionality isn't critical.
> 
> I agree it would be a nice addition, if there were a proposal on how
> to do it, though.

I'll think about it.

>>>If you want to propose a section on it, and nobody objects, I think it
>>>could be added.
>>
>>You'll need to change "certificate or CRL" in 2 to "certificate, CRL or 
>>URL", add in 2.1
>>
>>  4    IPKIX    The URL of an X.509 data object
>>  5    ISPKI    The URL of an SPKI certificate
>>  6    IPGP     The URL of an OpenPGP packet
> 
> 
> One objection would be that it doesn't scale well.  Every certificate
> format would now need two sub-types.  One direct, and one indirect.

Its a bit otherwise, which has the same effect :-)

> However, I don't anticipate the IETF standardizing hundreds of
> certificate-like formats in the short term, though, so it may be
> acceptable.
> 
> Btw, is the size issue relevant for SPKI certificates?  I have never
> seen large (>>20kb) SPKI blobs.  SPKI is EXPERIMENTAL too, so I don't
> think we cannot normatively reference it.  It may be better to keep it
> reserved for when SPKI become a PROPOSED standard.

I don't know enough about SPKI to answer this.

>>Then text:
>>
>>The IPKIX, ISPKI and IPGP types indicate a URL which will serve the 
>>content that would have been in the "certificate, CRL or URL" field of 
>>the corresponding (PKIX, SPKI or PGP) packet types. These packet types 
>>MUST be used when the content is too large to fit in the CERT RR, and 
>>MAY be used at the implementations discretion. They SHOULD NOT be used 
>>where the entire UDP packet would have fit in 512 bytes.
>>
>>Not religious about that last sentence, but it seems like a good idea.
> 
> Some discussion about the owner names for these types is probably
> needed as well.

It would be exactly the same as for the corresponding direct type.

> What do people think about this indirect proposal?  It is similar in
> style as the existing "private URI" mechanism, but more formal.

The private URI allows you to specify a packet format with a URI, so it 
isn't really the same thing.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Simon Josefsson <jas@extundo.com>
Subject: Re: RFC 2538bis
Date: Wed, 26 Jan 2005 18:43:39 +0100
Lines: 80
References: <200410151949.PAA03947@ietf.org>
	<ilu8ya7tyqm.fsf@latte.josefsson.org>
	<iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk>
	<ilu1xc8jnjz.fsf@latte.josefsson.org> <41F7AC68.7060504@algroup.co.uk>
	<iluvf9kgn74.fsf@latte.josefsson.org> <41F7D256.2030301@algroup.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Wed Jan 26 18:50:48 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Ben Laurie <ben@algroup.co.uk>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050126:ben@algroup.co.uk::hlirDLBj5kiqw3IN:1M49
X-Hashcash: 1:21:050126:namedroppers@ops.ietf.org::1ZOFQZKAyEQNBfAK:3j57
In-Reply-To: <41F7D256.2030301@algroup.co.uk> (Ben Laurie's message of "Wed,
	26 Jan 2005 17:24:38 +0000")
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
X-Virus-Scanned: ClamAV 0.80/680/Mon Jan 24 00:16:15 2005
	clamav-milter version 0.80j
	on yxa.extundo.com
X-Virus-Status: Clean
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Ben Laurie <ben@algroup.co.uk> writes:

>>>>I admit the purpose-based X.50 owner name rules may be a bit sketchy.
>>>>I have only experience with them for S/MIME and TLS certificates.
>>>
>>>Then look at some TLS CA certs :-)
>> I meant S/MIME user certificates and TLS server certificates.
>> I'm not sure there is a good use case for ever storing CA
>> certificates
>> in the DNS.  (Except for self-signed user/server certificates.)
>
> That alone sounds like a good case - particularly if served over DNSSEC!

Doing that would still be allowed, through the S/MIME and TLS owner
name guideline.

>> Perhaps for OCSP or CMP?  I dunno.
>> All this seem to be speculation, so it doesn't belong in the
>> document
>> yet, I think.
>
> I'm not sure what you want to remove now?

I meant that _adding_ a purpose based owner name recommendation for CA
certificates is not baked enough to be put into the document.

>>>>If you want to propose a section on it, and nobody objects, I think it
>>>>could be added.
>>>
>>> You'll need to change "certificate or CRL" in 2 to "certificate,
>>> CRL or URL", add in 2.1
>>>
>>>  4    IPKIX    The URL of an X.509 data object
>>>  5    ISPKI    The URL of an SPKI certificate
>>>  6    IPGP     The URL of an OpenPGP packet
>> One objection would be that it doesn't scale well.  Every
>> certificate
>> format would now need two sub-types.  One direct, and one indirect.
>
> Its a bit otherwise, which has the same effect :-)

Yes.  I think your approach is good.

>>>Then text:
>>>
>>> The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
>>> content that would have been in the "certificate, CRL or URL" field
>>> of the corresponding (PKIX, SPKI or PGP) packet types. These packet
>>> types MUST be used when the content is too large to fit in the CERT
>>> RR, and MAY be used at the implementations discretion. They SHOULD
>>> NOT be used where the entire UDP packet would have fit in 512
>>> bytes.
>>>
>>>Not religious about that last sentence, but it seems like a good idea.
>> Some discussion about the owner names for these types is probably
>> needed as well.
>
> It would be exactly the same as for the corresponding direct type.

I'll try to add something.

>> What do people think about this indirect proposal?  It is similar in
>> style as the existing "private URI" mechanism, but more formal.
>
> The private URI allows you to specify a packet format with a URI, so it 
> isn't really the same thing.

You could have the packet format be an URI.  I.e., the RDATA would be:

http://josefsson.org/my-cert-rr-uri-proposal.txt\0http://josefsson.org/cert.txt

But your proposal is more practical.

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:46:15 2006
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: Weird Wildcards Work item (on wildcards vs RR types, was Faux
	wildcards)
Date: Wed, 26 Jan 2005 15:38:12 -0800
Lines: 72
References: <41F15DAB.7070505@ehsco.com>
	 <6.2.0.14.2.20050120161507.04493db8@localhost>
	 <41F137CB.3090302@verisignlabs.com> <41F156CA.7030004@ehsco.com>
	 <a06200709be1709a99fd2@[10.31.32.183]>   <7982.1106712653@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 00:48:28 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: Robert Elz <kre@munnari.OZ.AU>
In-Reply-To: <7982.1106712653@munnari.OZ.AU>
X-Mailer: Evolution 2.0.1 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Wed, 2005-01-26 at 11:10 +0700, Robert Elz wrote:
>
> Personally, I don't know why systems wanting large blocks of textual
> data want it in the DNS at all.   It just makes no sense.

Agreed; does path registration make sense either?

> The DNS is deliberately designed as a fast, cheap, low-overhead
> distributed lookup mechanism (definitely not a directory, it has no
> search capabilities, and should never grow them).

I agree DNS should not be changed to offer features found with a
directory.  There is a sizable difference between a name tree and a file
system.  Publishing assertions at the top of a domain could allow a
means for establishing security enhancements for various protocols,
however.  Before creating a proposal, it seems exploring the basics
could be helpful.

A means to reflect higher information at lower nodes was the concept
behind the limited wildcard mechanism.  Locating a name for a RR remains
unused within inverse lookup.  DNSSEC adds the NXT mechanism.

It would seem there are few ways to ensure a wildcard is reliable for
asserting policy however.  Is there any solution beyond DNSSEC?

Are there viable options without changing resolvers?
a) DNSSEC
b) Global RR Type acting as an inverse lookup
c) Special prefix returning first RR within hierarchy
d) Special wildcard symbol with RR type independence

> It is great for accessing precisely defined small blocks of data.

These assertions could be contained within a single bit, or even by the
existence of a record.

> It is unfathomable to me why everyone keeps wanting to stick "large
> blocks of textual data" in the DNS, when there are other protocols
> around that do a great job of moving around those large blocks - of
> course they have higher overheads and costs, but that can't really be
> avoided - dumping the higher overheads and costs into the DNS so it
> can be mangled into carrying these unreasonable data sets is a truly
> insane end goal.

This bulky DNS information was to support a distributive system
accepting exchanges from anonymous sources.  (Dangerous by being active
as to illicit staging for corrupting caches.) 

> Either use another existing protocol (if you need the low overheads of
> UDP, TFTP allows data units to approx 32MB, and just about the same
> basic security as the DNS currently has) or if there's nothing
> suitable - invent a new protocol - as long as it runs over TCP or UDP,
> doing so is not really any harder than updating DNS servers and
> clients to support something new, or shouldn't be.

Agreed; the hundreds of possible lookups required to support path
registration makes DNS a very poor choice.

This still leaves a fundamental problem and the actual reason for the
ballyhoo over record types.  How to reliably announce new policy with
respect to all names within a specific domain?  With such a mechanism,
possibilities for transitioning protocols becomes more apparent.

-Doug



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Niall O'Reilly <niall.oreilly@ucd.ie>
Subject: Re: RFC 2538bis
Date: Thu, 27 Jan 2005 09:44:56 +0000
Lines: 44
References: <200410151949.PAA03947@ietf.org>
 <ilu8ya7tyqm.fsf@latte.josefsson.org> <iluhdlzgwha.fsf@latte.josefsson.org>
 <41F79774.4060402@algroup.co.uk> <ilu1xc8jnjz.fsf@latte.josefsson.org>
 <41F7AC68.7060504@algroup.co.uk> <iluvf9kgn74.fsf@latte.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Cc: Niall O'Reilly <niall.oreilly@ucd.ie>, Ben Laurie <ben@algroup.co.uk>,
 namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 10:53:52 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-reply-to: <iluvf9kgn74.fsf@latte.josefsson.org>
To: Simon Josefsson <jas@extundo.com>
X-Mailer: Apple Mail (2.619)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


On 26 Jan 2005, at 16:38, Simon Josefsson wrote:

>> I meant their "real name" (e.g. "Simon Josefsson") not their email.
>
> Oh, I see.
>
> I don't see any way to achieve this, the DNS do not handle
> directory-like searches.  I don't see keyservers going away, though,
> so this functionality isn't critical.
>
> I agree it would be a nice addition, if there were a proposal on how
> to do it, though.

No. That's a distraction.

It's not just that "the DNS do not handle directory-like searches".

The proper place in the DNS hierarchy to advertise a real name is 
undefined.
Any definition would have to include a strategy for avoiding collisions 
with
other instances of any particular name.  Whatever the necessary 
scattering
scheme might be, it would make retrieval "interesting", to say the 
least!

Still, it's that time of the year, and nine weeks from tomorrow is an
auspicious date. 8-)

Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Ben Laurie <ben@algroup.co.uk>
Subject: Re: RFC 2538bis
Date: Thu, 27 Jan 2005 10:10:19 +0000
Lines: 47
References: <200410151949.PAA03947@ietf.org> <ilu8ya7tyqm.fsf@latte.josefsson.org> <iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk> <ilu1xc8jnjz.fsf@latte.josefsson.org> <41F7AC68.7060504@algroup.co.uk> <iluvf9kgn74.fsf@latte.josefsson.org> <1A1D161F-7048-11D9-891B-000393B02BAC@ucd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 11:18:24 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
To: Niall O'Reilly <niall.oreilly@ucd.ie>
In-Reply-To: <1A1D161F-7048-11D9-891B-000393B02BAC@ucd.ie>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Niall O'Reilly wrote:
> 
> On 26 Jan 2005, at 16:38, Simon Josefsson wrote:
> 
>>> I meant their "real name" (e.g. "Simon Josefsson") not their
>>> email.
>> 
>> 
>> Oh, I see.
>> 
>> I don't see any way to achieve this, the DNS do not handle 
>> directory-like searches.  I don't see keyservers going away,
>> though, so this functionality isn't critical.
>> 
>> I agree it would be a nice addition, if there were a proposal on
>> how to do it, though.
> 
> 
> No. That's a distraction.
> 
> It's not just that "the DNS do not handle directory-like searches".
> 
> The proper place in the DNS hierarchy to advertise a real name is 
> undefined.

I was thinking along the lines of having a root name under which real 
names were stored. Of course, there could be more than one, just as 
there are multiple PGP keyservers.

> Any definition would have to include a strategy for
> avoiding collisions with other instances of any particular name.
> Whatever the necessary scattering scheme might be, it would make
> retrieval "interesting", to say the least!

Collisions aren't an issue, you just have multiple RRs at the name.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Simon Josefsson <jas@extundo.com>
Subject: Re: RFC 2538bis
Date: Thu, 27 Jan 2005 11:57:23 +0100
Lines: 47
References: <200410151949.PAA03947@ietf.org>
	<ilu8ya7tyqm.fsf@latte.josefsson.org>
	<iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk>
	<ilu1xc8jnjz.fsf@latte.josefsson.org> <41F7AC68.7060504@algroup.co.uk>
	<iluvf9kgn74.fsf@latte.josefsson.org>
	<1A1D161F-7048-11D9-891B-000393B02BAC@ucd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Ben Laurie <ben@algroup.co.uk>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 12:07:02 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Niall O'Reilly" <niall.oreilly@ucd.ie>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050127:ben@algroup.co.uk::OklcEphHNFbgdX9V:3JWa
X-Hashcash: 1:21:050127:namedroppers@ops.ietf.org::a6otTOhOFFu7mbcr:0vK6
X-Hashcash: 1:21:050127:niall.oreilly@ucd.ie::WDo8/23VKmqDJWqS:Ef2D
In-Reply-To: <1A1D161F-7048-11D9-891B-000393B02BAC@ucd.ie> (Niall O'Reilly's
	message of "Thu, 27 Jan 2005 09:44:56 +0000")
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
X-Virus-Scanned: ClamAV 0.80/680/Mon Jan 24 00:16:15 2005
	clamav-milter version 0.80j
	on yxa.extundo.com
X-Virus-Status: Clean
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Niall O'Reilly <niall.oreilly@ucd.ie> writes:

> On 26 Jan 2005, at 16:38, Simon Josefsson wrote:
>
>>> I meant their "real name" (e.g. "Simon Josefsson") not their email.
>>
>> Oh, I see.
>>
>> I don't see any way to achieve this, the DNS do not handle
>> directory-like searches.  I don't see keyservers going away, though,
>> so this functionality isn't critical.
>>
>> I agree it would be a nice addition, if there were a proposal on how
>> to do it, though.
>
> No. That's a distraction.
>
> It's not just that "the DNS do not handle directory-like searches".
>
> The proper place in the DNS hierarchy to advertise a real name is 
> undefined.

I don't see why it is impossible to define a way, without studying the
problem further...

I agree with you that this is a distraction, and probably beyond the
scope of 2538, though.

But given DNSSEC NSEC walking, you can get a pretty good telephone
book system.  Type 'S' and the NSEC chain allow a client to show all
entries close to S.

> Any definition would have to include a strategy for avoiding collisions
> with
> other instances of any particular name.

Right.  The strategy might be as simple as not trying to avoid
collisions, and returning multiple data items, one for each match.

Regards,
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:46:15 2006
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: RFC 2538bis
Date: Thu, 27 Jan 2005 11:59:00 -0500
Lines: 41
References: <200410151949.PAA03947@ietf.org>
 <ilu8ya7tyqm.fsf@latte.josefsson.org>
 <iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk>
 <ilu1xc8jnjz.fsf@latte.josefsson.org> <41F7AC68.7060504@algroup.co.uk>
 <iluvf9kgn74.fsf@latte.josefsson.org>
 <1A1D161F-7048-11D9-891B-000393B02BAC@ucd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: Simon Josefsson <jas@extundo.com>, "Niall O'Reilly" <niall.oreilly@ucd.ie>,
        Ben Laurie <ben@algroup.co.uk>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 18:13:00 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-Reply-To: <1A1D161F-7048-11D9-891B-000393B02BAC@ucd.ie>
To: "Niall O'Reilly" <niall.oreilly@ucd.ie>
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 9:44 +0000 1/27/05, Niall O'Reilly wrote:
>The proper place in the DNS hierarchy to advertise a real name is undefined.

(I'm not sure if you infer that there should be one...but here's the 
knee-jerk rant:)

There is no proper place in the DNS hierarchy to "advertise" anything.

It's like walking through a library (the old kind, with bookcases, 
shelves, and books) blindfolded and with one of them tracking 
numbers.  You travel to where the book identified by the tracking 
number is and reach for it.

It's either "there" or not at all there.  There is no fuzziness.

>Any definition would have to include a strategy for avoiding collisions with
>other instances of any particular name.  Whatever the necessary scattering
>scheme might be, it would make retrieval "interesting", to say the least!

That's an application problem, not a DNS problem beyond the desire to 
keep the books in the library easy to lift off the shelves by even 
the "weakest" customers of the library.

>Still, it's that time of the year, and nine weeks from tomorrow is an
>auspicious date. 8-)

Maybe I ought to submit an ID on the DNS SEARCH RR for then.

;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Niall O'Reilly <niall.oreilly@ucd.ie>
Subject: Re: RFC 2538bis
Date: Thu, 27 Jan 2005 17:42:24 +0000
Lines: 57
References: <200410151949.PAA03947@ietf.org>
 <ilu8ya7tyqm.fsf@latte.josefsson.org> <iluhdlzgwha.fsf@latte.josefsson.org>
 <41F79774.4060402@algroup.co.uk> <ilu1xc8jnjz.fsf@latte.josefsson.org>
 <41F7AC68.7060504@algroup.co.uk> <iluvf9kgn74.fsf@latte.josefsson.org>
 <1A1D161F-7048-11D9-891B-000393B02BAC@ucd.ie>
 <a06200703be1ec8a627d4@[10.31.32.104]>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Cc: Niall O'Reilly <niall.oreilly@ucd.ie>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 18:48:47 2005
Return-path: <owner-namedroppers@ops.ietf.org>
In-reply-to: <a06200703be1ec8a627d4@[10.31.32.104]>
To: Edward Lewis <Ed.Lewis@neustar.biz>
X-Mailer: Apple Mail (2.619)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

<agreement class="violent">

On 27 Jan 2005, at 16:59, Edward Lewis wrote:

> There is no proper place in the DNS hierarchy to "advertise" anything.
>
> It's like walking through a library (the old kind, with bookcases, 
> shelves, and books) blindfolded and with one of them tracking numbers. 
>  You travel to where the book identified by the tracking number is and 
> reach for it.
>
> It's either "there" or not at all there.  There is no fuzziness.

Absolutely.

Keeping your metaphor, what I meant by "advertise" was the process of 
selecting
the tracking number in order to place the book on the right shelf -- a 
combination
of what my colleagues over in the library building call "cataloguing" 
and "shelving".
If I get that part right, someone else who understands the cataloguing 
system can
actually find ("retrieve") the book.  In the sense that this is 
arbitrary, there
is indeed no "proper" place.  In the sense that the scheme is 
documented and well
understood by the parties involved, there _is_ a "proper" place.

More concretely, my telephone number has one very well defined "proper" 
place
in the DNS hierarchy where I "advertise" its "properties" for 
"retrieval"
in a useful way by others.  I could choose some other place to enter 
the RRs with
the same RHS data, but doing so would frustrate the "standard" 
retrieval process.

Enough for now ...

</agreement>

Best regards,

Niall O'Reilly
University College Dublin Computing Services

1.7.0.2.6.1.7.1.3.5.3.e164.arpa
PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-00.txt
Date: Thu, 27 Jan 2005 15:53:44 -0500
Lines: 92
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 21:59:58 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: i-d-announce@ietf.org
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Storing Certificates in the Domain Name System (DNS)
	Author(s)	: S. Josefsson
	Filename	: draft-ietf-dnsext-rfc2538bis-00.txt
	Pages		: 13
	Date		: 2005-1-27
	
Cryptographic public key are frequently published and their
   authenticity demonstrated by certificates.  A CERT resource record
   (RR) is defined so that such certificates and related certificate
   revocation lists can be stored in the Domain Name System (DNS).

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-rfc2538bis-00.txt".

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<2005-1-27143916.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-00.txt

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

Content-Type: text/plain
Content-ID:	<2005-1-27143916.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:46:15 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-nsec3-00.txt
Date: Thu, 27 Jan 2005 15:53:40 -0500
Lines: 92
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 22:00:01 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: i-d-announce@ietf.org
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: DNSSEC Hash Authenticated Denial of Existence
	Author(s)	: B. Laurie, et al.
	Filename	: draft-ietf-dnsext-nsec3-00.txt
	Pages		: 17
	Date		: 2005-1-27
	
The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
   used to provide authenticated denial of existence of DNS ownernames
   and types; however, it permits any user to traverse a zone and obtain
   a listing of all ownernames.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-nsec3-00.txt".

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<2005-1-27143910.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-nsec3-00.txt

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

Content-Type: text/plain
Content-ID:	<2005-1-27143910.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:46:15 2006
From: Samuel Weiler <weiler@tislabs.com>
Subject: rfc2538bis IANA considerations
Date: Thu, 27 Jan 2005 17:02:38 -0500 (EST)
Lines: 74
References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr>
 <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain>
 <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert>
 <iluzn1we2it.fsf@latte.josefsson.org> <Pine.GSO.4.55.0411051429350.8454@filbert>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Thu Jan 27 23:15:05 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: weiler@filbert
To: namedroppers@ops.ietf.org
In-Reply-To: <Pine.GSO.4.55.0411051429350.8454@filbert>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

All-in-all, I think 2538bis is in good shape.  I sent some editorial
comments to Simon.  Here are some slightly more substantive ones re:
algorithm numbers.

On Fri, 5 Nov 2004, Samuel Weiler wrote:

> > If I remember correctly, RFC 2538 uses the same IANA name space as the
> > rest of DNSSEC for the key algorithms.  Perhaps someone is using ECC
> > for X.509 or OpenPGP data.  So a specification for ECC, and an entry
> > in the IANA DNSKEY key algorithm registry, seem useful.
>
> I'm surprised that no one caught this when we were bickering over the
> RFC3755 IANA registry format.  I don't have any problems with CERT
> reusing the registry, but as you're working on 2538bis, you might want
> to check the IANA considerations section in 3755 and the registry
> itself to see if any changes are needed.  2538bis might want to cite
> 3755, too.  In any case, I think it would be good to add a note in the
> registry mentioning that CERT uses these numbers, also:
>
> http://www.iana.org/assignments/dns-sec-alg-numbers

To avoid confusing future users of the algorithm registry, I suggest:

-- Ask IANA to add a citation to 2538bis for algorithm 0 -- it's
   already marked reserved, but 2538 explains why it needs to
   remain reserved.  You might even rename it to 'CERT RR private'
   or somesuch.

-- Ask IANA to add the CERT RR to the list of type codes that use this
   registry.  That may encourage the next fool who comes along and
   wants to change or reuse the registry to remember CERT, as we
   forgot to do in 2004.

-- Can CERTs use private algorithms (type 253/254)?  If so, do you
   still want to use the same encoding as for KEY/DNSKEY, with the
   algorithm in the RDATA?  Some explicit mention of the private
   algorithms might be a good idea, in any case.  Also note David
   Blacka's DNSSEC experiment draft, which encourages use of
   the private algorithms.

-- Given that 3755 added applicablility columns to the algorithm
   registry (see the registry itself and 3755 for details), do you
   want another column for CERT, along with a requirement that new
   algorithm definitions say whether they can be used for CERTs or
   not?  If you want to reuse all algorithms registers, the doc should
   say that (and the registry probably should, too).  Suggested
   registry text for the 'reuse all' option might be:

OLD:  The KEY, SIG, DNSKEY, RRSIG, and DS RRs use an 8-bit number used
      to identify the security algorithm being used.

      Some algorithms are usable only for zone signing (DNSSEC), some
      only for transaction security mechanisms (SIG(0) and TSIG), and
      some for both.  Those usable for zone signing may appear in
      DNSKEY, RRSIG, and DS RRs.  Those usable for SIG(0) and TSIG may
      appear in SIG and KEY RRs.

NEW:  The KEY, SIG, DNSKEY, RRSIG, DS, and CERT RRs use an 8-bit
      number used to identify the security algorithm being used.

      All algorithm numbers in this registry may be used in CERT RRs.
      Some algorithms are not usable for zone signing (DNSSEC) and
      some are not usable for transaction security mechanisms (SIG(0)
      and TSIG).  Only those usable for zone signing may appear in
      DNSKEY, RRSIG, and DS RRs.  Only those usable for SIG(0) and
      TSIG may appear in SIG and KEY RRs.

-- 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:46:15 2006
From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: RFC 2538bis
Date: Fri, 28 Jan 2005 11:04:26 +0700
Lines: 47
References: <CDC442E1-708A-11D9-891B-000393B02BAC@ucd.ie>  <200410151949.PAA03947@ietf.org> <ilu8ya7tyqm.fsf@latte.josefsson.org> <iluhdlzgwha.fsf@latte.josefsson.org> <41F79774.4060402@algroup.co.uk> <ilu1xc8jnjz.fsf@latte.josefsson.org> <41F7AC68.7060504@algroup.co.uk> <iluvf9kgn74.fsf@latte.josefsson.org> <1A1D161F-7048-11D9-891B-000393B02BAC@ucd.ie> <a06200703be1ec8a627d4@[10.31.32.104]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 28 05:19:05 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: "Niall O'Reilly" <niall.oreilly@ucd.ie>
In-Reply-To: <CDC442E1-708A-11D9-891B-000393B02BAC@ucd.ie> 
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        Thu, 27 Jan 2005 17:42:24 +0000
    From:        "Niall O'Reilly" <niall.oreilly@ucd.ie>
    Message-ID:  <CDC442E1-708A-11D9-891B-000393B02BAC@ucd.ie>

  | Keeping your metaphor, what I meant by "advertise" was the process of 
  | selecting the tracking number in order to place the book on the right
  | shelf

I think Ed's point was that this neither is, ever has been, or ever should
be, a function of the DNS.

  | combination of what my colleagues over in the library building call
  | "cataloguing" and "shelving".

The former is outside the DNS, the latter inside.

  | More concretely, my telephone number has one very well defined "proper" 
  | place in the DNS hierarchy

That's fine.

  | where I "advertise" its "properties" for "retrieval"
  | in a useful way by others.

Yes, you advertise, or some other thing does, the DNS does not.

With the DNS, you must know, from some other means, the precise key,
catalogue number, (domain name) before you start, from some other
mechanism.   That may be from digging it out of a URL, using the
domain name part of a From field body in an e-mail, following some
precise rule set out to convert some other data (IP address, phone
number) or whatever.

When you do the query, you get a relatively small answer that is
intended to tell you exactly what you wanted to know (there should
be no aspect of guessing, searching, or other speculation as to
whether the answer returned is really intended for you or not, if
you asked, and an answer was returned, that *is* your answer).

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:46:15 2006
From: Gilles Guette <gguette@irisa.fr>
Subject: coments on draft-ietf-dnsext-nsec3-00.txt
Date: Fri, 28 Jan 2005 08:27:12 +0100
Organization: Irisa/Inria - Rennes
Lines: 24
References: <200501272053.PAA23433@ietf.org>
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 Fri Jan 28 08:36:18 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: fr, en
To: ben@algroup.co.uk
In-Reply-To: <200501272053.PAA23433@ietf.org>
X-Virus-Scanned: by amavisd-new at irisa.fr
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

Hello,
I read your draft and maybe I missed something but with NSEC3 RR, how do 
you proove a NXDOMAIN ? Or how do you proove that the NSEC3 received is 
a covering NSEC3 ?

On the example given in the draft, if a resolver ask for "aa.example.com 
NS" it will receive the answer containing :

bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \
           SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \
           A TXT RRSIG NSEC3

How the resolver can deduce that this NSEC3 is a covering NSEC3 without 
the original ownername ?


Regards


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Roy Arends <roy@dnss.ec>
Subject: Re: coments on draft-ietf-dnsext-nsec3-00.txt
Date: Fri, 28 Jan 2005 09:11:36 +0100 (CET)
Lines: 32
References: <200501272053.PAA23433@ietf.org> <41F9E950.8090404@irisa.fr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-From: owner-namedroppers@ops.ietf.org Fri Jan 28 09:23:10 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: roy@trinitario.schlyter.se
To: namedroppers@ops.ietf.org
In-Reply-To: <41F9E950.8090404@irisa.fr>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Fri, 28 Jan 2005, Gilles Guette wrote:

> Hello,
> I read your draft and maybe I missed something but with NSEC3 RR, how do
> you proove a NXDOMAIN ? Or how do you proove that the NSEC3 received is
> a covering NSEC3 ?
>
> On the example given in the draft, if a resolver ask for "aa.example.com
> NS" it will receive the answer containing :
>
> bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \
>            SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \
>            A TXT RRSIG NSEC3
>
> How the resolver can deduce that this NSEC3 is a covering NSEC3 without
> the original ownername ?

It can't deduce the original ownername from a hashed ownername (well, it
is highly unlikely).

The resolver knows what it has send, i.e. a query for 'aa.example.com.
NS'. It will then compare HASH(aa.example.com) with the received NSEC3
record.

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:46:15 2006
From: Gilles Guette <gguette@irisa.fr>
Subject: Re: coments on draft-ietf-dnsext-nsec3-00.txt
Date: Fri, 28 Jan 2005 09:54:04 +0100
Organization: Irisa/Inria - Rennes
Lines: 143
References: <200501272053.PAA23433@ietf.org> <41F9E950.8090404@irisa.fr> <Pine.BSO.4.56.0501280859100.12761@trinitario.schlyter.se>
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------------030106070505050809050403"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 28 10:08:24 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: fr, en
To: Roy Arends <roy@dnss.ec>
In-Reply-To: <Pine.BSO.4.56.0501280859100.12761@trinitario.schlyter.se>
X-Virus-Scanned: by amavisd-new at irisa.fr
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------030106070505050809050403
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Roy Arends wrote:

>On Fri, 28 Jan 2005, Gilles Guette wrote:
>
>  
>
>>Hello,
>>I read your draft and maybe I missed something but with NSEC3 RR, how do
>>you proove a NXDOMAIN ? Or how do you proove that the NSEC3 received is
>>a covering NSEC3 ?
>>
>>On the example given in the draft, if a resolver ask for "aa.example.com
>>NS" it will receive the answer containing :
>>
>>bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \
>>           SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \
>>           A TXT RRSIG NSEC3
>>
>>How the resolver can deduce that this NSEC3 is a covering NSEC3 without
>>the original ownername ?
>>    
>>
>
>It can't deduce the original ownername from a hashed ownername (well, it
>is highly unlikely).
>  
>
OK

>The resolver knows what it has send, i.e. a query for 'aa.example.com.
>NS'.
>
OK

> It will then compare HASH(aa.example.com) with the received NSEC3
>record.
>  
>
Assuming that HASH(aa.example.com)= GFA.........

The resolver sends a query for 'aa.example.com. NS'

It receives the NSEC3 of a.example.com

If you compare this to the NSEC3 of a.example.com, HASH(aa.example.com) is not in the range [ bfe6ea21dee9d228889ae11fa58c4bd551d15801...
F519593E82969842A136E0F47814C881FA163833]

what is the resolver's behaviour then ?

Could you correct or finish this scenario ?




--------------030106070505050809050403
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Roy Arends wrote:<br>
<blockquote type="cite"
 cite="midPine.BSO.4.56.0501280859100.12761@trinitario.schlyter.se">
  <pre wrap="">On Fri, 28 Jan 2005, Gilles Guette wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello,
I read your draft and maybe I missed something but with NSEC3 RR, how do
you proove a NXDOMAIN ? Or how do you proove that the NSEC3 received is
a covering NSEC3 ?

On the example given in the draft, if a resolver ask for "aa.example.com
NS" it will receive the answer containing :

bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \
           SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \
           A TXT RRSIG NSEC3

How the resolver can deduce that this NSEC3 is a covering NSEC3 without
the original ownername ?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It can't deduce the original ownername from a hashed ownername (well, it
is highly unlikely).
  </pre>
</blockquote>
OK<br>
<blockquote type="cite"
 cite="midPine.BSO.4.56.0501280859100.12761@trinitario.schlyter.se">
  <pre wrap="">
The resolver knows what it has send, i.e. a query for 'aa.example.com.
NS'.</pre>
</blockquote>
OK<br>
<blockquote type="cite"
 cite="midPine.BSO.4.56.0501280859100.12761@trinitario.schlyter.se">
  <pre wrap=""> It will then compare HASH(aa.example.com) with the received NSEC3
record.
  </pre>
</blockquote>
<pre class="moz-signature" cols="72">
Assuming that HASH(aa.example.com)= GFA.........

The resolver sends a query for 'aa.example.com. NS'

It receives the NSEC3 of a.example.com

If you compare this to the NSEC3 of a.example.com, HASH(aa.example.com) is not in the range [ bfe6ea21dee9d228889ae11fa58c4bd551d15801...
F519593E82969842A136E0F47814C881FA163833]

what is the resolver's behaviour then ?

Could you correct or finish this scenario ?


</pre>
</body>
</html>

--------------030106070505050809050403--


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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Roy Arends <roy@dnss.ec>
Subject: Re: coments on draft-ietf-dnsext-nsec3-00.txt
Date: Fri, 28 Jan 2005 10:06:18 +0100 (CET)
Lines: 43
References: <200501272053.PAA23433@ietf.org> <41F9E950.8090404@irisa.fr>
 <Pine.BSO.4.56.0501280859100.12761@trinitario.schlyter.se> <41F9FDAC.6030809@irisa.fr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 28 10:13:56 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: roy@trinitario.schlyter.se
To: Gilles Guette <gguette@irisa.fr>
In-Reply-To: <41F9FDAC.6030809@irisa.fr>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Fri, 28 Jan 2005, Gilles Guette wrote:

> Assuming that HASH(aa.example.com)= GFA.........
>
> The resolver sends a query for 'aa.example.com. NS'
>
> It receives the NSEC3 of a.example.com
>
> If you compare this to the NSEC3 of a.example.com, HASH(aa.example.com) is not in the range [ bfe6ea21dee9d228889ae11fa58c4bd551d15801...
> F519593E82969842A136E0F47814C881FA163833]
>
> what is the resolver's behaviour then ?

Short answer: the resolver will give a 'servfail' or similar error.

The long answer:

If the resolver sends a query for 'aa.example.com. NS',
it will NOT receive the NSEC3 of HASH(a.example.com).
It will receive (given that aa.example.com does not exist) the covering
NSEC3 over HASH(aa.example.com).

Before a zone is being served by an NSEC3 capable authoritative server:
1) Hashes are made for every ownername
2) Hashes are canonically ordered
3) NSEC3's are added, so that:
 (1st hash) NSEC3 (2nd hash)
 (2nd hash) NSEC3 (3rd hash)
 (Nth hash) NSEC3 (N+1th hash)
 (last hash) NSEC3 (1st hash)

4) zone is signed

In that way, HASH(aa.example.com), given it doesn't exist, will always hit
an interval, therefor will always be treated as non-existant.

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:46:15 2006
From: Gilles Guette <gguette@irisa.fr>
Subject: Re: coments on draft-ietf-dnsext-nsec3-00.txt
Date: Fri, 28 Jan 2005 10:24:42 +0100
Organization: Irisa/Inria - Rennes
Lines: 38
References: <200501272053.PAA23433@ietf.org> <41F9E950.8090404@irisa.fr> <Pine.BSO.4.56.0501280859100.12761@trinitario.schlyter.se> <41F9FDAC.6030809@irisa.fr> <Pine.BSO.4.56.0501280955170.12761@trinitario.schlyter.se>
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 Fri Jan 28 10:31:28 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: fr, en
To: Roy Arends <roy@dnss.ec>
In-Reply-To: <Pine.BSO.4.56.0501280955170.12761@trinitario.schlyter.se>
X-Virus-Scanned: by amavisd-new at irisa.fr
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


>If the resolver sends a query for 'aa.example.com. NS',
>it will NOT receive the NSEC3 of HASH(a.example.com).
>It will receive (given that aa.example.com does not exist) the covering
>NSEC3 over HASH(aa.example.com).
>
>Before a zone is being served by an NSEC3 capable authoritative server:
>1) Hashes are made for every ownername
>2) Hashes are canonically ordered
>3) NSEC3's are added, so that:
> (1st hash) NSEC3 (2nd hash)
> (2nd hash) NSEC3 (3rd hash)
> (Nth hash) NSEC3 (N+1th hash)
> (last hash) NSEC3 (1st hash)
>
>4) zone is signed
>
>In that way, HASH(aa.example.com), given it doesn't exist, will always hit
>an interval, therefor will always be treated as non-existant.
>
>Roy
>
>  
>
OK. When a name server receives a query for a non existant name, it must 
compute the hash of this name,
and send the covering NSEC3.

Thanks for explanation, maybe this can be written in the draft after the 
example.



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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Roy Arends <roy@dnss.ec>
Subject: Re: coments on draft-ietf-dnsext-nsec3-00.txt
Date: Fri, 28 Jan 2005 10:31:51 +0100 (CET)
Lines: 22
References: <200501272053.PAA23433@ietf.org> <41F9E950.8090404@irisa.fr>
 <Pine.BSO.4.56.0501280859100.12761@trinitario.schlyter.se> <41F9FDAC.6030809@irisa.fr>
 <Pine.BSO.4.56.0501280955170.12761@trinitario.schlyter.se> <41FA04DA.2090101@irisa.fr>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Fri Jan 28 10:38:16 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-X-Sender: roy@trinitario.schlyter.se
To: Gilles Guette <gguette@irisa.fr>
In-Reply-To: <41FA04DA.2090101@irisa.fr>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On Fri, 28 Jan 2005, Gilles Guette wrote:

> OK. When a name server receives a query for a non existant name, it must
> compute the hash of this name,
> and send the covering NSEC3.
>
> Thanks for explanation, maybe this can be written in the draft after the
> example.

Good point !

Will add this to the draft.

Thanks,

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:46:15 2006
From: Carl Malamud <carl@media.org>
Subject: I-D ACTION:draft-malamud-keyword-discovery-00.txt (fwd)
Date: Fri, 28 Jan 2005 13:58:20 -0800 (PST)
Organization: Memory Palace Press
Lines: 159
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM1106949500-21229-0_
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Fri Jan 28 23:10:12 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
X-Winch: Warn 9.5i
X-Mailer: ELM [version 2.4ME+ PL94 (25)]
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk


--ELM1106949500-21229-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Hi Folks -

My relevant AD suggested this list as the venue for discussion of the 
attached I-D.  Comments to the list or privately to me would be quite
welcome.  

Regards,

Carl

--ELM1106949500-21229-0_
Content-Transfer-Encoding: 7bit
Content-Type: message/rfc822
Content-Description: Forwarded message from Internet-Drafts@ietf.org

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by bulk.resource.org (8.12.2/8.12.2) with ESMTP id j0SLMIRr026003
	for <carl@media.org>; Fri, 28 Jan 2005 13:22:21 -0800 (PST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CudBa-0000IS-Dg; Fri, 28 Jan 2005 15:57:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CudAq-00089t-NE
	for i-d-announce@megatron.ietf.org; Fri, 28 Jan 2005 15:57:00 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12526
	for <i-d-announce@ietf.org>; Fri, 28 Jan 2005 15:56:58 -0500 (EST)
Message-ID: <200501282056.PAA12526@ietf.org>
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Fri, 28 Jan 2005 15:56:58 -0500
Subject: I-D ACTION:draft-malamud-keyword-discovery-00.txt
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-ID: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=subscribe>
Sender: i-d-announce-bounces@ietf.org
Errors-To: i-d-announce-bounces@ietf.org
Return-Path: <i-d-announce-bounces@ietf.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Attaching Meaning to Solicitation Class Keywords
	Author(s)	: C. Malamud
	Filename	: draft-malamud-keyword-discovery-00.txt
	Pages		: 10
	Date		: 2005-1-28
	
This Internet-Draft proposes a mechanism for finding information
   about solicitation class keywords which are defined in RFC 3865, the
   No Soliciting SMTP Service Extension.  The mechanism uses a DNS NAPTR
   Resource Record to associate a URI with a solicitation class keyword.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malamud-keyword-discovery-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-malamud-keyword-discovery-00.txt".

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


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

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

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

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

Content-Type: text/plain
Content-ID: <2005-1-28152550.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-malamud-keyword-discovery-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-malamud-keyword-discovery-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-1-28152550.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--




--ELM1106949500-21229-0_--

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



From owner-namedroppers@ops.ietf.org  Fri Dec 29 10:46:15 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-insensitive-05.txt
Date: Mon, 31 Jan 2005 15:43:12 -0500
Lines: 91
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Mon Jan 31 21:51:44 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: i-d-announce@ietf.org
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Domain Name System (DNS) Case Insensitivity Clarification
	Author(s)	: D. Eastlake
	Filename	: draft-ietf-dnsext-insensitive-05.txt
	Pages		: 12
	Date		: 2005-1-31
	
Domain Name System (DNS) names are "case insensitive". This document
   explains exactly what that means and provides a clear specification
   of the rules. This clarification updates RFCs 1034 and 1035.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-insensitive-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-insensitive-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:	<2005-1-31155153.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-insensitive-05.txt

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

Content-Type: text/plain
Content-ID:	<2005-1-31155153.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/>