Jeff Macdonald wrote:
So I personally do not think this will be an issue.
I've seen it, with SPF records. A client may support TCP, but if the
firewall is set to not allow TCP packets for DNS, then you will have
the same issue.
So this issue exists. I'm getting support questions related to this
about once a quarter, up from once a year.
Yes, I have seen it too, but mostly with home tier gateways or bugs.
The point is in a modern operation, in lieu of bugs, the modern DNS
client/server needs to do it properly and DNS servers respond accordingly.
I've seen a customer report where our AVS mail bot w/ SPF worked fine
from the company network installation but not from his private home
setup. In the end, it was a bug in our DNS resolver that had an
uninitialized "UseTCP" setup variable hence random intermittent
non-zero (true) values. Apparently his home tier gateway DNS proxy
was immediately closing the port 53 TCP request. We confirmed it by
having him set the setup to use primary DNS server ip and not the
default PC DNS name servers. It worked fine. So fixing this resolved
his gateway DNS server not allowing TCP.
Again, my only point was that for the complexity we are dealing with,
we can't depend a DNS solution where we thinks bugs or low end setups
that do not support a DNS streaming protocol properly as show stoppers.
When the DNS client starts with UDP and fall back to TCP when the UDP
response contains a truncated datagram, I have not seen issues.
That said, I am not advocating this is the way to go. It needs to be
explored which is what we are doing and from a product standpoint we
offer the options to see what works for people.
Both ATPS and ASL are implemented for exploration. I personally prefer
ASL before its more management and more "packed" with information
providing a payoff with a DNS query.
If there is a 255 per domain length issue with this, there would be a
length issue in general. A domain using hugh length proper will see
other problems. Why would one use such an impractical ergonomics huge
length for their users? Sure its theoretically bound, but its
impractical to see such huge length domains.
Regarding ATPS, its already been proven that MD5 can be clobbered with
collision attacks which means you can get two equal hashes for two
different domains.
http://en.wikipedia.org/wiki/MD5#Security
To suggest the odds are low, is the same arguments for lengths being
very high.
Also, a MD5 is 32 characters. That would be a fixed amount for all
domains. That means this can potentially add a higher storage
requirement in DNS.
Using Pareto's Principle, most domains will not be 32 characters or
greater. So even given the two, you have more storage efficiency with
using the literal than the fixed 32 bytes MD5 hash.
Hence, I am not convince it is better because:
1) Its harder to manage, requires more tools, enforces key manager
frontends than a simple text editor,
2) Adds a predictable greater size requirement than the average,
3) MD5 has proven collision issues.
Again, that is my opinion. We added both extensions so we will see
how people go with this. The fact is, for ATPS, we had to give them a
MakeATPS.exe hashing tool. Something you don't need for ASL. Plus,
already, we had to add comments as values to help with the management
at this point. For example, dig the ATPS for gmail.com for our
winserver.com domain:
nslookup -query=txt
f74d39fa044aa309eaea14b9f57fe79c._atps.winserver.com
Non-authoritative answer:
f74d39fa044aa309eaea14b9f57fe79c._atps.winserver.com text =
"v=atps1; d=gmail.com;"
So that would be one suggest for Murray to add a "MAY" add a value for
their own management purposes. He should give his reasons which it
lowers the security bar for "Layman" hackers, but certainly it doesn't
nothing to stop the determine hacker who simply needs to look at a
DKIM-Signature d=domain and author-domain he wishes to exploit using
some sort of MITM DNS exploit.
For now, simplicity to work out the logistics.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops