spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Troxel <>
Subject Re: DNS Terminology
Date Fri, 23 Sep 2016 20:15:42 GMT

Lindsay Haisley <> writes:

> Huh? So what's the problem with "recursion"? That's the name of the
> boolean configuration option in bind9. It's about as descriptive and
> clear a word as it can be.
> options {
>         directory "/var/cache/bind";
>         recursion yes;
>         allow-query { goodclients; };
>         etc ....
> };

I'm not sure how to parse your question, so this may not be useful to
you but it seems there is a lot of confusion.

To answer others: iteration and recursion describe implementation
techniques for programs, and are used for DNS in slightly fuzzy ways.
If a resolver iterates (in a loop, without function calls) from root
down to the others, that's not implemented with recursion (tail
recursion aside).  But the edge of when iteration vs recursion is the
right word is not the point.

In DNS, when sending a query, there is a "recursion desired" bit, and
replies have a "recursion available" bit.  Running "dig", I
get the following.  You can see the rd and ra flag bits set.  The query
went to ::1 (localhost in IPv6), and the final answer was returned.  The
nameserver running on the local machine did what is called recursive
processing, asking the root for org, and then asking org for,
and then asking for an A record (except some of this may have
been cached).  My nameserver is configured without any "forwarder"
lines, so it asks each of these places directly.  Note that you cannot
figure out from the dig output whether the server did
recursion/iteration from the root or forwarded the query to someplace
that did.

With a forwarder, my resolver would have sent the original query
someplace else, with the "rd" bit set, and that other place would have
done the multiple lookups, and returned a reply, which my server would
then have returned.

The "recursion yes" in bind instructs the local server that it is
permitted to accept queries for which it doesn't have the answer and do
the iterative lookup.  Generally one sets that not in general, but in an
ACL limited to one's own machines.

If a forwarder is not configured (again, should be ACLed to own
machines) and recursion is not enabled, then trying to do a recursive
query results in a refusal.  (This is a a bit messy to configure when a
resolver should do recursive processing for local hosts and be
authoritative for some zone all at the same time.)

As others have said, the big point is that if queries to BLs are
forwarded to some server that also does lookups for other people, that
risks exceeding per-IP-address limits.

; <<>> DiG 9.10.3-P4 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24737
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 10

; EDNS: version: 0, flags:; udp: 4096
;			IN	A

;; ANSWER SECTION:		1800	IN	A		1800	IN	A

;; AUTHORITY SECTION:		75135	IN	NS		75135	IN	NS		75135	IN	NS		75135	IN	NS		75135	IN	NS

;; ADDITIONAL SECTION:		158234	IN	A		158234	IN	A		158234	IN	AAAA	2620:0:2e60::33		158234	IN	A		158234	IN	AAAA	2001:1838:f000::6		322	IN	A		322	IN	AAAA	2001:610:3:200a:192:87:36:2		158234	IN	A		158234	IN	AAAA	2620:171:802:752d::1

;; Query time: 14 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Sep 23 16:06:03 EDT 2016
;; MSG SIZE  rcvd: 372

View raw message