Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe)

[David Blacka <davidb@xxxxxxxxxxxxxxxx>]

On Thursday 26 August 2004 7:07 pm, william(at)elan.net wrote:

> In case we decide to have main record be located within subdomain prefix
> depending on the identity, then in order to achieve same effect with
> wildcards, we'd still have to place the record in root of the domain, i.e.
>  a._marid_pra.example.com. IN TXT "v=spf1 ip4:192.168.0.0/16 ~all"
>  *.example.com.	IN TXT "v=spf1 ip4:10.0.0.0/8 ~all"

You seem to be discussing a plan that I, at least, have not seen before.  All 
of the discussion that I have seen has been about actual *prefixes*, which 
isn't what you are showing here.

However, you are illustrating an important point about naming and wildcards 
which holds true even if your examples seem a bit odd to me.

IF scope is part of the prefix scheme (i.e., _pra._marid.a.example.com IN TXT 
"spf2.0/..."), that scope MUST also be present in the RDATA of the record: 
_pra._marid.a.example.com IN TXT "spf2.0/pra ...".  Any information important 
to the interpretation of the record must not solely rest within the name, 
because of this wildcard issue.  This is a general problem with DNS record 
subtyping and wildcards.

To put this another way: clients, when querying for a TXT record using a 
prefix scheme MAY get back TXT records for different protocols and scopes, 
and must be able to pick the correct record from the set.

> In my view this makes wildcards are bad choice for achieving scoping and
> identity separation. That is unless we decide that we don't need to support
> wildcards at all and in that case to avoid problems (as some will still
> do it seeing how its possiblems), the document would have to specifically
> say that you CAN NOT use wildcards or CAN NOT place records in anything
> but the specified scope/identity prefix.

What you are seeing is that prefixes (or subdomains, whatever) are a bad 
choice for *solely* dealing with scoping and identity separation.

-- 
David Blacka    <davidb@xxxxxxxxxxxxxxxx> 
Sr. Engineer    VeriSign Applied Research