[Pdns-users] Why prefer recursor answers over auth Authoritative answers?

Fri Feb 6 18:03:22 UTC 2009

I am sure allow-recursion-override is set to "no"; it may help to run
the latest code in both cases :

http://powerdns.com/en/downloads.aspx

pdns-2.9.22 and pdns-recursor-3.1.7

--Augie

On Fri, Feb 6, 2009 at 9:56 AM, David Sparks <dave at ca.sophos.com> wrote:
> Augie Schwer wrote:
>> We have many machines that have both the PowerDNS authoritative server
>> and the PowerDNS recursor; we don't have this problem. What version of
>> the auth. and recursive server are you running?  --Augie
>
> I'm running:
>
> pdns-2.9.21.2.tar.gz
> pdns-recursor-3.1.6.tar.bz2
>
> Are you sure you haven't set allow-recursion-override=yes?  Now that I know
> what to search for there are many people who have a similar problem with the
> auth server passing queries to the recursor when it should answer them itself.
>
> ds
>
>
>
>>
>> On Thu, Feb 5, 2009 at 1:22 PM, David Sparks <dave at ca.sophos.com> wrote:
>>> David Sparks wrote:
>>>> Why does PowerDNS auth server not answer queries that it is both authoritative
>>>> for, and has an answer for in its auth server when recursion is available and
>>>> requested?
>>> I've found a Debian bug report that suggests this is a long standing problem
>>> with Powerdns:
>>>
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357432
>>>
>>> Unfortunately that bug report is 3 years old and unanswered.
>>>
>>> Out of curiosity can someone fill me in on why Powerdns does a recursive
>>> resolve of a query and only falls back to its own auth server if the recursive
>>> query fails?  This seems incredibly bizarre ... and has tripped up others in
>>> the past.  There seems to be a design decision here that is solving a problem
>>> I don't know about (and the solution is causing me problems).
>>>
>>> Thanks!
>>>
>>> ds
>>>
>>>
>>>
>>>> Background:
>>>>
>>>> I have setup a PowerDNS installation to replace a BIND installation.  We have
>>>> run a split-horizon setup in BIND that has worked for many years.  Since
>>>> PowerDNS does not support this I intend to continue to run BIND to answer the
>>>> Internet queries, and PowerDNS will answer the internal for both auth and
>>>> recursive.
>>>>
>>>> PowerDNS auth server when queried for a record that it is both authoritative
>>>> for and exists will pass the query to the recursor if the recursion desired
>>>> flag is set (without doing any kind of lookup).  What this means is queries
>>>> that could and should be answered by PowerDNS are passed onto the Internet
>>>> auth server.  The answer from Internet auth server is from the wrong zone.
>>>>
>>>> This behavior can be worked around by setting "allow-recursion-override=yes"
>>>> but then delegated subdomains no longer work.  Why does the auth server pass
>>>> queries to the recursor instead of doing a first attempt to answer them?
>>>>
>>>>
>>>> Below is the output of 4 queries:
>>>>
>>>> A plain query to PowerDNS is wrong. (2006 SOA comes from Internet auth server)
>>>> A query to PowerDNS with +norec is right. (2007 SOA from PowerDNS)
>>>> PowerDNS with allow-recursion-override=yes is right. (2007 SOA from PowerDNS)
>>>> BIND9 is right. (2007 SOA from BIND internal view)
>>>>
>>>>
>>>> ------------------------------------------
>>>> allow-recursion-override=no - wrong answer
>>>> ~ # dig -t soa ahost.example.com @10.0.0.12
>>>>
>>>> ; <<>> DiG 9.4.1-P1 <<>> -t soa ahost.example.com @10.0.0.12
>>>> ; (1 server found)
>>>> ;; global options:  printcmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3198
>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;ahost.example.com.                 IN      SOA
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> example.com.               0       IN      SOA     ns1.example.com.
>>>> postmaster.example.com. 2006030201 3600 900 2419200 900
>>>>
>>>>
>>>> -----------------------------------------------------------
>>>> allow-recursion-override=no but +norec on dig: right answer
>>>> ~ # dig +norec -t soa ahost.example.com @10.0.0.12
>>>>
>>>> ; <<>> DiG 9.4.1-P1 <<>> +norec -t soa ahost.example.com @10.0.0.12
>>>> ; (1 server found)
>>>> ;; global options:  printcmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64492
>>>> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;ahost.example.com.                 IN      SOA
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> example.com.               60      IN      SOA     ns1.example.com.
>>>> hostmaster.example.com. 2007041200 60 60 60 60
>>>>
>>>> -------------------------------------------
>>>> allow-recursion-override=yes - right answer
>>>> ~ # dig -t soa ahost.example.com @10.0.0.11
>>>>
>>>> ; <<>> DiG 9.4.1-P1 <<>> -t soa ahost.example.com @10.0.0.11
>>>> ; (1 server found)
>>>> ;; global options:  printcmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40863
>>>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>> ;; WARNING: recursion requested but not available
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;ahost.example.com.                 IN      SOA
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> example.com.               60      IN      SOA     ns1.example.com.
>>>> hostmaster.example.com. 2007041200 60 60 60 60
>>>>
>>>> --------------------
>>>> BIND9 - right answer
>>>> ~ # dig -t soa ahost.example.com @10.0.0.19
>>>>
>>>> ; <<>> DiG 9.4.1-P1 <<>> -t soa ahost.example.com @10.0.0.19
>>>> ; (1 server found)
>>>> ;; global options:  printcmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63338
>>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;ahost.example.com.                 IN      SOA
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> example.com.               60      IN      SOA     ns1.example.com.
>>>> postmaster.example.com. 2007041200 60 60 60 60
>>>>
>>>>
>>>> DNS server legend:
>>>>
>>>> allow-recursion-override=yes    10.0.0.11
>>>> allow-recursion-override=no     10.0.0.12
>>>> bind9                           10.0.0.19
>
>

-- 
Augie Schwer    -    Augie at Schwer.us    -    http://schwer.us
Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072