From: william(at)elan.net
Date: Sun Mar 20 2005 - 23:35:54 EST
On Sun, 20 Mar 2005, David MacQuigg wrote:
> Alan,
>
> Thanks for your description of DNS, and your willingness to help with
my dumb
> questions. I guess we lost track of the question somewhere in this long
> thread. The question is -- Why doesn't SPF make more extensive use of the
> built-in recursion capability of DNS?
>
> This question was motivated by the struggle I'm seeing over the
question of
> how many DNS queries to allow. The rr.com example had difficulty fitting
> within the allowed 10 queries. Radu suggests "flattening" all records to
> just a list of IPs. That might be inconvenient for a domain that wishes to
> "delegate" all responsibility for these records to their subdomains.
>
> The seemingly obvious solution is that rr.com answer all queries to
> nameservers in any of their subdomains, using the recursion mechanism
in DNS.
> That way, the DNS records maintained by each subdomain can be very simple,
> and you don't run into any 10-query limit at rr.com. I must be missing
> something, because it seems too simple.
No, that is not how DNS works as Alan tried to explain (and he can do it
better then I can, since I'm usually too technical). First of all dns
redirect is triggered by specific dns records, i.e. NS and nothing else
Are you saying a TXT record for austin.rr.com cannot be cached at rr.com?
(and spf redirects and sublookups are completely different and nothing
that can be easily implemented within dns),
Understood. What I'm suggesting is that we can eliminate the *need* for
most of the SPF redirects and sublookups if we make better use of simple
non-recursive records at the lowest subdomains, and rely on DNS to gather
everything into one big cache at the top domain.
2nd the recursion is available
by dns server run by ISP for its customers - these are often called "caching"
dns servers and servers that keep actual dns domain records are separate ones
and not and typically would have recursion disabled.
Is there a reason a DNS server for a domain should not cache DNS records
for all its subdomains?
3rd is that SPF is aimed
as email security solution that would not require many updates to email
servers and to DNS servers so that it could be deployed quicker - that is
why SPF decided to (ab)use TXT records (not something I agree with BTW)
and anything that would require changes to DNS protocol and DNS server
software will take long time (2-5 years) to become wide used.
What protocol or software changes you are referring to? Do we need to
change anything about the DNS protocol to allow recursion at rr.com? Are
there many DNS servers that don't support recursion? Surely the big
domains that would benefit from caching their subdomains will have
full-featured DNS servers.
I think O'Really has good book on DNS ("DNS & BIND" its 3rd or 4th edition
now) and there are number of good references at
<http://www.dns.net/dnsrd/>http://www.dns.net/dnsrd/
and if you're engineer you can just go ahead and read RFCs (particularly
RFC1034), so please do read more on dns if you really want to talk about it.
I have DNS & BIND, 4th ed. The dns.net website is excellent. I'm still
coming to the same conclusion, however. DNS recursion, with caching at the
rr.com level, is exactly what rr.com needs to decentralize and simplify
their huge setup, while keeping the DNS traffic to a minimum.
RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES, 1987.
4.3.1. Queries and responses
Recursive service is helpful in several situations:
- a network where we want to concentrate the cache rather than
having a separate cache for each client.
If I am still misunderstanding this, please give me a specific section in
this document (or some other).
Terry Fielder raised an interesting point in the "DNS load" thread. Things
can get out-of-sync when we rely on caching. He doesn't want even a few
hours of delay when he has to move a server. Isn't there some mechanism to
force a refresh of the cache at rr.com? This could be done immediately
after moving the austin.rr.com server.
I like Anky Bakun's suggestion of a Best Practices document. The fancy
mechanisms are there *if you must*, but 99% of the time, a simple list of
static IPs will be sufficient.
-- 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 *
************************************************************* *