On Thu, 2005-04-07 at 23:45 -0700, Matthew Elvey wrote:
Perhaps
*/
Q: What will that software now do?
/*
has an incorrect answer.
The FAQ has the following:
| Check the "additional info" section of the DNS SRV response for
| address records for the target string. If the actual IP address isn't
| among them, you've got a failure to authenticate. Give an appropriate
| error.
While it's likely the response will include add'l info with all the IPs
of the A record set, it's possible that the initial response won't; the
add'l info is optional, and some DNS servers may not send it. Couldn't
the domain name even be in a different domain from the EHLO's domain,
one for which the server isn't authoritative?
When the name server is authoritative for both SRV and where the A
record resides, there should not be a problem and should be a typical
scenario. If this is not the case, then applying A record copies (like
glue records) with the SRV record would be a solution. However, this
will represent a maintenance effort for the sender.
The strategy has been to put the burden onto the sender, rather than on
the recipient and is reflected within the FAQ. While it remains
possible the recipient may resolve addresses for targets provided by the
SRV record, the sender then risks being excluded by those that refuse
making these extra lookups. The FAQ clarifies that the name server
administrator should consider this. The CSV-CSA draft also advises this
additional data be checked for this reason.
The eventual and vital role CSV will play is protecting network
resources on a name basis. The ability to protect resources using names
solves many unpleasant problems created when relying upon the IP address
alone. The CSV name basis can prevent DoS attacks in conjunction with
domain signatures, for example. While CSV provides a compatible
(authenticated) name basis, the overhead associated with CSV must be
kept to a minimum. Making exceptions to encourage deployment will erode
CSV protective benefits.
-Doug