ietf-mxcomp
[Top] [All Lists]

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

2004-08-27 06:17:48

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(_at_)verisignlabs(_dot_)com> 
Sr. Engineer    VeriSign Applied Research


<Prev in Thread] Current Thread [Next in Thread>