Subject: Re: wildcards vs. RR types, was Faux wildcards

From: John Levine <[email-masked]>
Date: 18 Jan 2005 17:10:58 -0000

>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, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

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

---

From: John Levine <[email-masked]>
Date: 18 Jan 2005 21:13:30 -0000

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

---

From: John Levine <[email-masked]>
Date: 19 Jan 2005 02:37:54 -0000

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 19 Jan 2005 13:07:12 -0800 (PST)

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
[email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 19 Jan 2005 22:53:38 +0100

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 Jan 2005 16:39:41 +0000

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 Jan 2005 11:52:03 -0800

> [mailto:[email-masked]] On Behalf Of Ben Laurie

> John Levine wrote:
> >>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)
> > 
> > 
> 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.