Re: RE: rr.com and SPF records

From: william(at)elan.net
Date: Sat Mar 19 2005 - 15:27:44 EST

> On Fri, 18 Mar 2005, David MacQuigg wrote:
>
> > This is probably a naive question, but please understand, I'm an 
> electrical
> > engineer, not a DNS expert. My knowledge of DNS is from Chapter 14 in 
> TCP/IP
> > Illustrated, W.R.Stevens.
> >
> > As I understand it, DNS provides a "recursive query" capability whereby 
> one
> > query to a domain like rr.com will provide an authoritative answer for any
> > subdomain under rr.com. Even if the DNS server at rr.com doesn't have the
> > complete DNS records for all its subdomains, they will most likely be in a
> > local cache, since there will be frequent queries to rr.com for this
> > information.
> >
> > Seems like we should *require* that SPF queries set the RD bit (recursion
> > desired), and expect that any domain with as complex a setup as rr.com set
> > the RA bit (recursion available). Then DNS will do the recursion (not some
> > SPF checking program), and each subdomain will have its own very simple 
> SPF
> > record.
>
> Your understanding is very much incorrect (and I would recommend reading
> specific book on DNS rather then general one on TCP/IP if you want to
> understand DNS).
I just read some sections from "DNS & BIND", 4th ed.  This is much more 
detailed, and think Chapter 14 of TCP/IP provides a better summary of the 
basics we need for this discussion.  Of course, I could be misunderstanding 
something, and I would like to know if that is the case.  If you could 
refer me to a specific part of DNS & BIND, or some other reference, I'll be 
happy to read it.
> When somebody is talking about DNS server providing
> recursive capabilities what it means is that when you talk to a dns, that
> server if it encounters a reference to another server (NS) will do query
> itself and provide the answer to the client that asked - that is when RD
> bit is set on request. When its not set or when dns server is not recursive,
> then its up to the dns client to do proper dns lookup to the listed NS server.
This is my understanding also, with the one clarification that the 
recursive query only works with subdomains.  Instead of the above, I would 
say "when the client queries a DNS nameserver (NS), and NS doesn't have a 
current record for one of its subdomains, NS may itself query the 
nameserver from that subdomain, and provide the answer it gets from the 
subdomain as a response to the client, thus saving traffic to and from the 
client."
> DNS protocol being multi-tier tree can not support providing all subdomains
> as that would be both a security risk and would lead to serious slow-down
> in the lookup system.
This is where I am really puzzled.  It seems the *intent* of the recursive 
capability in DNS is to speed things up in exactly the scenario we are 
discussing with rr.com.  Say, for example, rr.com gets 10,000 queries per 
hour for SPF records from austin.rr.com.  Most likely it will have that 
information in its cache, and can respond directly without even querying 
its subdomain.  Even if a query to the subdomain is necessary, it is likely 
a lot faster than a query from the client to the subdomain.  ( Might even 
be a server in the same building.)  Having once queried its subdomain, 
rr.com can now respond to thousands of subsequent queries using only the 
data in its cache.
The bigger and more complex the setup under rr.com, the greater the 
advantage in using the recursive capabilities of DNS itself.  Keep the 
records in each subdomain very simple, one or two IP addresses, or maybe an 
IP block, and let the DNS server at rr.com put it all together 
automatically, in its cached records, using the recursion already available 
DNS.
This doesn't take care of the situation where some other domain, not under 
rr.com, wants to authorize some server under rr.com, but that odd situation 
is where we actually need SPF to do the recursion using 'include'.
I'm probably missing something important here, so please explain.

-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *