Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Aug 2004 08:10:50 -0700

> On Thursday 26 August 2004 8:12 am, Jim Fenton wrote:
> > Can anyone
> > clear up whether adding the prefix breaks wildcards, or 
> were they already
> > broken?
> 
> Since I don't know what you mean by "broken", I can't comment 
> to whether or 
> not wildcards are "already broken".  BUT,  if you publish:
>  
>   *.example.com. IN TXT "v=spf1 ..."
>   *.example.com. IN TXT"spf2.0/pra ..."
> 
> Then, if a query for "host.example.com IN TXT" would match 
> the wildcard, the a 
> query for "_marid.host.example.com IN TXT" would ALSO match 
> the wildcard.
> 
> So, the problem isn't that wildcards and marid records don't 
> work, it is just 
> that when using wildcards, the _marid prefix no longer gets 
> you *just* the 
> spf2.0/pra record.  I.e. the current status quo.

While David is right, there is also the corollary that *.example.com
will only match nodes that do not exist at all. So there are two issues,
do wildcards work as expected, is the wildcard useful at all. The matching
behavior means that the wildcard is not useful for the use cases given.

i.e. if we have

a.example.com

*.example.com. IN TXT "v=spf1 ..."

Will match _marid.b.example.com, b.example.com but not a.example.com 
regardless of whether a has TXT records or not.

So you can't use a wildcard to give a default SPF record for DNS
names of hosts that exist. Only the hosts that don't exist will match.

I don't know what happens for _marid.a.example.com, I think it should
not match but one of the DNS people can say for sure.

IF _marid.a.example.com did match the wildcard then it would be a way
to make the wildcards useful.

---

From: David Blacka <[email-masked]>
Date: Thu, 26 Aug 2004 12:00:21 -0400

> regardless of whether a has TXT records or not.

This is correct.

> not match but one of the DNS people can say for sure.

You are correct, it does not match.  The existence of names block wildcards at 
that name, and for any name below that name.  To be explict, if your zone 
has:
 
  *.example.com. IN TXT "spf2.0/..."
  a.example.com. IN A 1.2.3.4
 
but does not contain:
 
  b.example.com. 

Then queries for "b.example.com. IN TXT, _marid.b.example.com. IN TXT, 
something-else.b.example.com. IN TXT", will all return the TXT record.  
Queries for "a.example.com. IN TXT, _marid.a.example.com. IN TXT, 
anything-else.a.example.com. IN TXT" will not return the TXT record.

> to make the wildcards useful.

For some use cases.  It is true that wildcards are not useful as a default 
"fall-back" record solution.  They never were.

To my mind, the paramount issue of wildcard wrt MARID is that for folks who 
*currently* use wildcards (i.e., for wildcard MX records), the MARID solution 
should be deployable, and it is, with or without a _marid prefix.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: Rand Wacker <[email-masked]>
Date: Thu, 26 Aug 2004 08:56:23 -0700 (PDT)

Phillip brings up a very good point here because if the desire for
wildcards is to make it easy for sites to indicate where mail *does not*
come from for hosts under their domain, then this application is pretty
moot because every sane MTA on the planet /already/ rejects mail for this
there is no resolvable FQDN (why bother accepting a message if you know up
front you couldn't ever reply to it).

-Rand

---

From: Rand Wacker <[email-masked]>
Date: Thu, 26 Aug 2004 08:56:23 -0700 (PDT)

-Rand

---

From: David Blacka <[email-masked]>
Date: Thu, 26 Aug 2004 12:00:21 -0400

This is correct.

 
 
but does not contain:
 
  b.example.com.