Lindsay Haisley <fmouse...@fmp.com> 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 apache.org", 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 apache.org, and then asking apache.org 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 <<>> apache.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24737 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 10 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;apache.org. IN A ;; ANSWER SECTION: apache.org. 1800 IN A 140.211.11.105 apache.org. 1800 IN A 88.198.26.2 ;; AUTHORITY SECTION: apache.org. 75135 IN NS ns1.no-ip.com. apache.org. 75135 IN NS ns2.no-ip.com. apache.org. 75135 IN NS ns4.no-ip.com. apache.org. 75135 IN NS ns2.surfnet.nl. apache.org. 75135 IN NS ns3.no-ip.com. ;; ADDITIONAL SECTION: ns4.no-ip.com. 158234 IN A 204.16.254.44 ns1.no-ip.com. 158234 IN A 204.16.255.55 ns1.no-ip.com. 158234 IN AAAA 2620:0:2e60::33 ns2.no-ip.com. 158234 IN A 204.16.254.6 ns2.no-ip.com. 158234 IN AAAA 2001:1838:f000::6 ns2.surfnet.nl. 322 IN A 192.87.36.2 ns2.surfnet.nl. 322 IN AAAA 2001:610:3:200a:192:87:36:2 ns3.no-ip.com. 158234 IN A 207.34.6.1 ns3.no-ip.com. 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
signature.asc
Description: PGP signature
