[Pdns-users] Intermittent recursion failure due to timeout

Brian Candler b.candler at pobox.com
Tue Jan 23 21:23:15 UTC 2018

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>'.


$ 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


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
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 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.


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

More information about the Pdns-users mailing list