On 23 Sep 2016, at 12:03, RW wrote:
On Thu, 22 Sep 2016 20:24:21 -0700 (PDT)
John Hardin wrote:
Lists shouldn't have said "caching", that confuses the issue. Caching
and recursion are two different, unrelated pieces.
Focus on the "recursion" and "no forwarding" parts of that
recommendation.
I've been wondering whether recursive is actually the correct term.
It is.
Please forgive any excess verbosity and/or didactic tone used below,
it's not that I believe that you need all the explication, but you're
not the least-knowledgeable reader of this list by a wide margin...
As I understand it there are two types of DNS lookup:
1. Iterative - where results are found by working down through
multiple servers from the root servers.
That is the behavior traditionally called "recursion." The resolver asks
a question of a root server and recursively asks the same question of
one or more up-tree servers to which it is referred by down-tree servers
(from the root up.) This is "recursive" because it feeds the result of a
query (a glue NS record) into a retry of the same query directed to the
host identified in that prior result. In some resolver implementations
the actual code logic for this is formally recursive, in that a function
calls itself with new arguments until it finally gets a proper final
answer to the query.
Historically, some particularly lame operating systems have had "stub"
DNS resolvers that know only how to ask one or more DNS servers for
resolution, and not how to do recursion on their own. As a result, those
systems have needed access to a DNS server that would do the recursion
for them and provide a final result, not a referral. Actual DNS servers
can be made to behave like lame stubs (usually selectively) and
"forward" some or all queries to fully recursive resolvers on behalf of
end-clients with truly incapable resolvers.
I have never seen the word "iterative" used to describe DNS recursion or
any other DNS resolution algorithm except in the context of a resolver
having multiple servers that it can query at a particular step of the
resolution process (i.e. multiple servers in /etc/resolv.conf or
multiple NS referral records being returned by a root or intermediate
nameserver.) It would also fit federated resolution models that can be
set up in some systems via a "name service switch" mechanism (i.e.
/etc/nsswitch.conf) which can use multiple name->address resolution
mechanisms other than DNS such as NIS, static files, NetInfo, etc.
2. Recursive - where a request is made to a single nameserver which
handles the whole look-up on behalf of a client.
In that case the client resolver is NOT being recursive, the nameserver
is being either recursive or is forwarding.
What this turns on is whether a forwarding server is a distinct
class of of nameserver or a type of recursive server. I think the
latter is most logical, since both provide a recursive interface.
I disagree, and have never seen that model/nomenclature for forwarding
servers used before.
A forwarding-only server is never recursive. It doesn't use a non-final
response to a query as a parameter to retry the same query with a
different server. Many servers that do forwarding ALSO do recursion,
either tactically to check another server's cache before doing the
slower work of recursion or strategically to resolve names that don't
have the a locally correct resolution connected to the global roots
(e.g. *.10.in-addr.arpa.)
Definitions of the term "recursive server" that I've seen contrast it
only with "authoritative server".
The dichotomy between "authoritative" and "recursive" servers is not
really correct and is almost orthogonal to the forwarding vs. recursion
behavior. Authoritative-only servers only answer queries about the zones
for which they are configured to be authoritative. Servers that provide
full resolution service to non-recursive client resolvers may be
recursive or forwarding or a mix of both, but forwarding isn't recursion
and recursion isn't forwarding, all they have in common is that they
both are strategies for finding final DNS answers for queries for which
the server is not authoritative.
One thing is certain, what you want is a name server that does
*iterative* lookups.
In your terms, yes, generally. For a mail server using DNSBLs of any
sort:
You want a nameserver that provides final answers to all queries from
your mail server, not referrals, because even recursion-capable OS stub
resolvers have limited and often problematic caching and recursion takes
time.
You want a nameserver that has a substantial and intelligently managed
name cache which adheres to DNS standards (i.e. honor TTLs) so that
recursion latency and stale records can both be avoided to the extent
possible.
You want a nameserver that never forwards queries to public-access
nameservers, particularly for DNSBLs because those servers are often
blocked but also for other queries because public-access nameservers
have a tendency to be "innovative" in how they answer queries that they
judge to be unuseful in some way. Public-access DNS resolution is a
service designed for web browsing, NOT server applications.
You want a nameserver that never forwards queries to any nameservers on
the other side of a router, firewall, or any other network device that
makes packet-forwarding decisions based on any logic above OSI-model
layer 2, because this slows response time. IOW: don't forward queries
off-LAN.
You want a nameserver that never forwards queries to any nameservers
more than a few miles away, because this also slows response time
inherently AND because if it's not physically close, it probably is de
facto riding over links with router-like latencies, even if it looks
like a LAN.
