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