Stephen Farrell wrote:
Folks,
We all (or almost all) seem to be assuming that the DNS is the
place to put SSP stuff.
I just wanted to raise the question to see if that's a requirement
or just a near-accidental part of the current design proposals.
So is using the DNS in fact necessary? If it is, we may need text
that explicitly says why at some stage.
If not, what are our requirements for where/how to publish SSP
stuff?
I'll throw out a few generic requirements:
1. Low-cost query/response, in terms of latency time and the number of
packets involved. UDP has a definite advantage over TCP here: it's
very nice to be able to send one packet, receive one packet, and have
the answer you need. With TCP you have 3-way handshake in each
direction, query, response, and then teardown.
2. Minimize DoS potential. SSP for a high-value domain is potentially a
high-value DoS target, especially since the unavailability of an SSP
record could make unsigned messages less suspicious.
3. Easily cached. If the infrastructure doesn't provide caching (ala
DNS), the records retrieved will need time-to-live values to allow
querying verifiers to maintain their own caches.
4. High availability. Multiple, geographically and topologically
diverse servers must be supported.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html