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

From: Alex Bligh <[email-masked]>
Date: Tue, 18 Jan 2005 17:46:04 +0000

--On 18 January 2005 17:10 +0000 John Levine <[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: wayne <[email-masked]>
Date: Tue, 18 Jan 2005 13:31:23 -0600

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

---

From: Peter Koch <[email-masked]>
Date: Tue, 18 Jan 2005 21:10:54 +0100

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

> 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 ...)

> 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

---

From: Alex Bligh <[email-masked]>
Date: Tue, 18 Jan 2005 20:37:46 +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)
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

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 18 Jan 2005 12:53:36 -0800 (PST)

> look very productive.  dns-choices can go ahead and become yet another

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.

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

---

From: David Blacka <[email-masked]>
Date: Tue, 18 Jan 2005 15:51:22 -0500

> 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    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Edward Lewis <[email-masked]>
Date: Tue, 18 Jan 2005 16:01:18 -0500

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

---

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

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Jan 2005 21:25:33 -0000

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

---

From: Alex Bligh <[email-masked]>
Date: Tue, 18 Jan 2005 21:37:08 +0000

> to introduce new wildcard behavior without client side changes, along

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)
>
> possible to spoof the existence of the wildcard match away, undetectably,
> however.

Hmmm... another challenge for authenticated denial review.

Alex

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Jan 2005 15:50:54 +0700

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

  | 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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Jan 2005 10:16:46 -0500

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

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 13:58:42 -0600

In <a06200704be141b737280@[192.168.1.103]> Edward Lewis <[email-masked]> 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

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 14:05:47 -0600

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 19 Jan 2005 21:38:19 +0100

>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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jan 2005 16:46:08 -0800

> 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

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 20:04:12 -0600

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

Uh, you aren't offering CSV as a proposal?  That's news to me.

-wayne

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 20 Jan 2005 04:06:57 +0100

>wayne wrote:

"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

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 22:12:37 -0600

> Is this really the case? I cannot find any such limitations.

According to dns-choices, yes, the space is limited.  See section 3.1.

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

> Is this problem BTW for real?  That is, is POBOX.COM admitting they have a

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jan 2005 20:18:23 -0800

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

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 20 Jan 2005 07:14:33 +0100

>wayne wrote

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

>"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.

>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

---

From: wayne <[email-masked]>
Date: Thu, 20 Jan 2005 09:16:51 -0600

In <[email-masked]> Douglas Otis <[email-masked]> writes:

> 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