spf-discuss
[Top] [All Lists]

Re: DNS Query Format

2005-03-24 11:59:12
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        *
************************************************************* *


<Prev in Thread] Current Thread [Next in Thread>