At 01:24 PM 3/24/2005 -0500, Radu wrote:
David MacQuigg wrote:
One more thought on this topic: Even though we see no advantage now in
having a DNS server reply with a PASS/FAIL, would it be a good idea to
include the IP address in the DNS query anyway? That will add a
negligible 4 bytes to the query, and will allow for some future use of
this information. This might be, for example, a daemon that alerts a
domain owner when an IP in their domain attempts an unauthorized use of
the domain name. ( A zombie catcher !! )
AFAIK, the ns_resolve takes only two useful parameters: a record type and
an ascii host name. I don't see how you could include an IP in the query
other than concatenating it to the host name. At that point, it just
becomes a unique host name (ie, uncacheable). Here's how the resolver
function is defined:
"
int res_query(const char *dname, int class, int type,
unsigned char *answer, int anslen);
The res_query() function queries the name server for the fully-quali-
fied domain name name of specified type and class. The reply is left
in the buffer answer of length anslen supplied by the caller.
"
I don't understand these functions, but there is a nice diagram of the DNS
message format in Figure 14.3 of Stevens, TCP/IP Illustrated. I see at
least two places where a few more bytes could be stuffed in. One, as you
suggest, is just appending it to the domain name in the "question"
field. That might require existing DNS servers to do something special,
like not choke on the extra data. The other place you might put an IP
address is in a second question block. Maybe this would be more easily
ignored by existing servers.
We need a DNS expert. There must be a way to do it. DNS is a very
versatile and well-designed database. The designers seem to have had
plenty of future extensions in mind.
This is an issue completely independent of our discussion on compiling SPF
records, so let's not let it slow down any work on the more important issue.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmquigg-spf(_at_)yahoo(_dot_)com *
*
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *