On Mon, 30 Mar 2015, Nico Williams wrote:
* Suffer from bloated caches full of negative replies for billions
of accounts.
Ditto.
Caches already need to have extensive policies for abuse queries and
when legitimatelly running out of resources and figuring out what to
flush. Let the DNS/cache implementors handle that - they've done a good
job so far. Similarly, trust the cache implementors to deal with many
_positive_ entries for large records.
* Make it more difficult for the final servers to detect abusive
clients that are doing dictionary (directory harvesting) attacks.
[ Yes email addresses are not secrets, but some opacity can be
useful. ]
Ditto.
That will just make the botnet slower and more distributed. Any
sufficiently busy domain won't really be able to slow down the botnet.
Think of gmail or yahoo, how much rate limiting can they afford without
locking out real clients?
If none of the above are compelling, then going back to a lossless
I think they are quite compelling
I don't think these are compelling at all.
I'm not sure how the lossless helps either, unless either the DNS server
does fuzzy record returning (which I cannot see work with DNSEC) or
you move the lookup protocol outside DNS. Either way, this document and
an implementation in DNS does not gain anything by using
base32/lossless.
encoding may be a reasonable compromise. Otherwise, we can take
the view that:
* The multitude of addresses per user problem is not a problem,
only a small specific number of addresses will support encryption
(those may need to appear in the public key "certificates" anyway).
[...]
Don't we need DANE for e-mail signature signing key verification too?
Yes you can use it for that too, but I'm not sure how this relates to
the current discussion.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
