Michael,
The basic issue is that not all DNS servers handle unknown RR equally
the same doing a recursion (how SERVFAIL, NOERROR, NXDOMAIN are handled).
RFC 3597 ("Handling of Unknown DNS Resource Record (RR) Types") touches
base on this problem and offers the recommendation to handling unknown
RR. But not all servers support RFC 3597 and even if the end points do
support 3597, you don't know how the middle servers are going to react.
Since this IETF document was published in 2003, there will be a lot of
servers that still don't support it. This is of NT 4.0, W2K and W3K3
DNS servers. Older versions of BIND also had issues. Although, there
are patches or undocumentated low level support for some to offer some
support, this doesn't guarantee mixed DNS setups and/or request
propagation would follow RFC 3597.
That said, I do support a primary RR type for SSP with a TXT fallback.
--
HLS
Michael Thomas wrote:
John L wrote:
percentages are "normal" vs. "unusual", but my cursory look a
long time ago suggested that it met the 80-20 rule.
You are certainly correct that most zones are pretty flat, but this
sounds like a DOS attack waiting to happen, send out junk with long
bogus addresses and watch the system on the other end chew up its
cache crawling up to the SOA. That's why we arbitrarily limited the
walk in CSV to five levels.
No, it circumvents that problem. It goes like this:
1) query for the name _policy._domainkey.sub.domain.attack.foo.com
2) if you don't get a ssp rr, check to see if it gave
you a NS or SOA authority records.
o If they're available and it's a parent domain of domain
you're querying from, query that label.
3) done.
Thus for:
baz(_at_)sub(_dot_)domain(_dot_)attack(_dot_)foo(_dot_)com
query: _policy._domainkey.sub.domain.attack.foo.com
which returns:
>> NXDOMAIN or NODATA and an authority section SOA of
foo.com. 10800 IN SOA dns-rtp2-2-l.
postmaster.foo.com. 8004725 7200 1800 86
Take the authority domain and try again:
policy._domainkey.sub.foo.com
>> v=DKIM1; o=~; t=y; r=abuse(_at_)foo(_dot_)com
You never go any further than this.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html