|
Re: RE: rr.com and SPF records
2005-03-20 17:31:12
Dave,
I certainly don't claim to be a DNS expert, but have lived with managing
DNS for my company's network for over 10 years. Naturally, implementation
choices in DNS environments vary, but in general, I think that most folks
gate recursion such that it is available for internal network users to use
for resolving requests and not something one generally enables for the
world to use.
Perhaps I am not entirely clear on what you are asking or suggesting in
your message, if so please forgive me. Put very simply, DNS provides a
hierarchical distributed system to ask a question and get an answer quickly
and efficiently for performing such functions as connecting a name to an IP
address. While it is not a perfect system, it seems one of the more solid
and reliable workhorse services used on the Internet.
From end to end the system can look a bit intimidating and somewhat
overwhelming, but it actually is pretty straight forward and logical once
one starts working with it.
Perhaps looking at an example where we need to establish a connection to
FOO.EXAMPLE.TLD might help answer your question (or minimally help me to
clear up my own confusion about what you are asking).
In our example, client software is going to begin by needing an IP address
for FOO.EXAMPLE.TLD, which is ultimately obtained in this case via
something called a resource record (RR) provided from a DNS server which
has authority for the EXAMPLE.TLD zone.
Your software will need to know how to get to a local DNS server that acts
as a local DNS resolver. In a consumer ISP environment, that comes from
the (generally one or two) DNS Server IPs provided by the consumer's ISP
which are configured into the customer's operating system during setup or
later by changing network settings for a customer's client device.
That resolving DNS server will generally be set up by an ISP to provide the
ISP's customers with recursive queries, such that when requests are made to
that DNS server, it does the lion's share of the work to discover and send
an answer back to the requesting software on the customer's client
device. That actually works out quite well, because these kinds of
resolving DNS servers will use caching to retain the answers they discover
for a period of time (called the time to live or TTL), so others who ask
the same question can get an answer far more rapidly.
So let's presume for this example that our DNS resolver is at
10.0.0.10. Our software poses the question "where is FOO.EXAMPLE.TLD" to
its configured DNS resolving server. Under normal circumstances the
10.0.0.10 DNS server is going to check its cache to see if it already knows
the answer to this and a few other questions. To simplify the discussion,
let us presume that no data exists in the local DNS server's cache.
That being the case, 10.0.0.10 is going to go to the root servers (a well
known set of DNS servers that are managed by a variety of entities around
the world and are known to DNS servers generally from a file loaded with
root IP address and name information that a DNS server checks when it
starts up) to check for the Start of Authority (SOA) and to get the Name
Server (NS) records for the ".TLD" zone.
Once 10.0.0.10 has that information, it will then go to the top level
domain name servers for ".TLD" which it was just provided by the root
servers to get the SOA and the appropriate NS records for "EXAMPLE.TLD" zone.
Once this is known, 10.0.0.10 will then go to the name servers responsible
for an authoritative answer for the EXAMPLE.TLD zone to find out the
address (A) record for "FOO.EXAMPLE.COM". The A record will provide
10.0.0.10 the IP address of FOO.EXAMPLE.TLD and that is what will get
returned to the software on the customer's client device that made the
original request.
Notice that the elegance of this system is that it is the 10.0.0.10
customer's DNS resolving server which does most of the work to get the
answer back to the customer's requesting software, distributing the
questions over a series of other servers and caching the answers for future
use as it gets them from various servers along the path to the answer.
Our example above could have just as easily been to request DNS TXT RR
records for FOO.EXAMPLE.COM, which would then have returned one or more TXT
records instead of the A record back to 10.0.0.10 which in turn would go
back to the requesting customer's client device to answer the question posed.
Getting back to your post, I hope I have explained clearly enough so you
can now see why it is really the local 10.0.0.10 DNS server that needs to
have the recursion available (RA) bit set on answer to the recursion
desired (RD) bit set on question for the requesting software on the
customer's client device, rather than the remote DNS server that provides
the final authoritative answer. It is generally in everyone's best
interests to want the local 10.0.0.10 server to do all that work to
distribute the processing load required to get the answer to the software
on the customer's client device.
When you asked about knowing all the sub domains for a domain (I think you
asked that), this is accomplished via a zone file transfer. I don't think
that most folks allow general access to that kind of information unless it
is for a third party DNS secondary server transfer. Because the original
requesting software will know a specific sub domain it may be checking, I
am a bit confused as to why you would want this available from the remote
server side.
OTOH, if you are asking does RR.COM cache internally, while I have no
knowledge to authoritatively answer that question, I would certainly
imagine they would. But why would RR.COM be scanning its own DNS TXT
records unless it was dealing with messages sent from within the RR.COM
universe? If you are asking that question, I am still apparently confused.
Most of the time, I am guessing, checking for SPF TXT records will come
from a remote DNS server looking to verify if such a record exists so as to
pass information along to an SPF record checking application to perform its
own SPF processing on an inbound message within its own network. For that,
it would use its own caching DNS server's recursive capability.
I think that I have interpreted what you were asking correctly and that
this helps provide something of an understandable and I hope reasonably
accurate answer to your question.
Best,
Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/
At 04:38 PM 3/20/2005, you wrote:
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 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
|
|