[Pdns-users] Intermittent recursion failure due to timeout

[Brian Candler]

On 23/01/2018 21:00, Brian T wrote:
> I've been seeing intermittent lookup failures for 
> 'nova.clouds.archive.ubuntu.com <http://nova.clouds.archive.ubuntu.com>'.

Hmm:

$ dig +trace nova.clouds.archive.ubuntu.com

...

ubuntu.com.        172800    IN    NS    ns1.p27.dynect.net.
ubuntu.com.        172800    IN    NS    ns3.p27.dynect.net.
ubuntu.com.        172800    IN    NS    ns2.p27.dynect.net.
ubuntu.com.        172800    IN    NS    ns4.p27.dynect.net.
;; Received 198 bytes from 2001:501:b1f9::30#53(2001:501:b1f9::30) in 117 ms

clouds.archive.ubuntu.com. 60    IN    NS    piru.canonical.com.
;; Received 77 bytes from 2001:500:94:1::27#53(2001:500:94:1::27) in 46 ms

Ergh!

1. clouds.archive.ubuntu.com has only a *single* nameserver (haven't 
they read RFC2182?)

2. the single NS record has a ridiculously low TTL of 60 seconds

The A record for piru.canonical.com has a semi-reasonable TTL of 30 
minutes, although the NS records for canonical.com are cranked down to 
10 minutes in the zone:

$ dig +trace piru.canonical.com.

...

canonical.com.        172800    IN    NS    ns1.p27.dynect.net.
canonical.com.        172800    IN    NS    ns3.p27.dynect.net.
canonical.com.        172800    IN    NS    ns2.p27.dynect.net.
canonical.com.        172800    IN    NS    ns4.p27.dynect.net.
;; Received 186 bytes from 2001:502:8cc::30#53(2001:502:8cc::30) in 205 ms

piru.canonical.com.    1800    IN    A    91.189.95.68
canonical.com.        600    IN    NS    ns3.p27.dynect.net.
canonical.com.        600    IN    NS    ns2.p27.dynect.net.
canonical.com.        600    IN    NS    ns1.p27.dynect.net.
canonical.com.        600    IN    NS    ns4.p27.dynect.net.
; Received 138 bytes from 208.78.70.27#53(208.78.70.27) in 12 ms

This is pretty badly configured, and getting some failures to resolve is 
probably to be expected.

What I'd like to understand though is how many times pdns-recursor 
retries a query to an authoritative server, within that 5500ms timeout 
you've set (or the default 1500ms timeout), given that it has no other 
server to failover to.

Regards,

Brian Candler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20180123/c67bae80/attachment-0001.html>