[Pdns-users] nsupdate causes "Timeout from remote TCP client"

Darac Marjal mailinglist at darac.org.uk
Tue Jan 5 11:17:51 UTC 2021


Hello good people of pdns-users,

I appear to have got myself into a bit of a muddle with my home network,
and I'm hoping that a few more eyes on the problem might help :)

I am running dnsdist, pdns-recursor and pdns (authoritative) on one host
and isc-dhcp-server on another. The DHCP server is configured to send
DNS Updates to the DNS server but whenever it does, I get errors such as
the following in syslog:

    Jan 05 10:38:12 remy pdns_recursor[28667]: Timeout from remote TCP
client [::1]:39552
    Jan 05 10:41:03 remy pdns_recursor[28667]: Timeout from remote TCP
client [::1]:39768
    Jan 05 10:43:09 remy pdns_recursor[28667]: Timeout from remote TCP
client [::1]:39862

For PDNS, I have the following configuration (let me know if you think
anything else is relevant):

    local-address=::1,127.0.0.1
    local-port=5300
    trusted-notification-proxy=::1,127.0.0.1
    slave=yes
    master=yes
    dnsupdate=yes
    allow-dnsupdate-from=

❯ sudo pdnsutil show-zone local.darac.org.uk
This is a Master zone
Last SOA serial number we notified: 2021011166 == 2021011166 (serial in the database)
Metadata items: 
        ALLOW-AXFR-FROM 173.244.206.26
        ALLOW-AXFR-FROM 88.198.106.11
        ALLOW-AXFR-FROM 2607:f0d0:1005:72::100
        ALLOW-AXFR-FROM 2a01:4f8:d12:d01::10:100
        ALLOW-AXFR-FROM 82.70.33.62
        ALLOW-AXFR-FROM 192.168.101.254
        ALLOW-AXFR-FROM 2a02:8010:d008::1
        ALLOW-AXFR-FROM 2a02:8010:d008::202:b3ff:fec2:c80
        ALLOW-AXFR-FROM 127.0.0.1
        ALLOW-AXFR-FROM ::1
        ALLOW-DNSUPDATE-FROM    82.70.33.62
        ALLOW-DNSUPDATE-FROM    192.168.101.254
        ALLOW-DNSUPDATE-FROM    2a02:8010:d008::1
        ALLOW-DNSUPDATE-FROM    2a02:8010:d008:0:202:b3ff:fec2:c80
        ALLOW-DNSUPDATE-FROM    127.0.0.1
        ALLOW-DNSUPDATE-FROM    ::1
        ALSO-NOTIFY     192.168.101.254
        SOA-EDIT        INCEPTION-INCREMENT
        SOA-EDIT-API    DEFAULT
        TSIG-ALLOW-DNSUPDATE    dhcpdremy
Zone has NSEC semantics
keys: 
[ removed ]

For PDNS Recursor, I have the following config:

    allow-from=::1/128,127.0.0.1/8
    dnssec=validate
    dnssec-log-bogus=yes
    serve-rfc1918=yes
    forward-zones=...
    forward-zones+=local.darac.org.uk=[::1]:5300
    forward-zones-recurse=.=9.9.9.9
    local-address=::1,127.0.0.1
    local-port=5301
    log-common-errors=yes

And for dnsdist, I have the following config:

    addLocal('127.0.0.1:53',     {reusePort=true})
    addLocal('[::1]:53',         {reusePort=true})
    addLocal('192.168.101.8:53', {reusePort=true})
    addLocal('82.70.33.60:53',   {reusePort=true})
    setACL({'0.0.0.0/0', '::/0'})              -- Allow all IP access

    newServer({address='[::1]:5300',  name="remy",  pool='auth',   useClientSubnet=true})
    newServer({address='[::1]:5301',  name="remy",  pool='recursor'})

    -- Hosts allowed to recurse                                                                                                                                                                                                                     
    recursive_ips = newNMG()
    recursive_ips:addMask('127.0.0.0/8')
    recursive_ips:addMask('192.168.0.0/16')
    recursive_ips:addMask('2a02:8010:d008::/48')
    recursive_ips:addMask('::1/128')

    -- Hosts allowed to AXFR/IXFR
    allow_axfr_from = newNMG()
    -- Allow crush                                                                                                                                                                                                                                  
    allow_axfr_from:addMask('192.168.101.254')
    -- Allow localhost
    allow_axfr_from:addMask('127.0.0.0/8')
    allow_axfr_from:addMask('::1/128')

    -- If AXFR || IXFR from !allow_axfr_from, then Refused
    addAction(
        AndRule({
            OrRule({
                QTypeRule(DNSQType.AXFR),
                QTypeRule(DNSQType.IXFR),
                QTypeRule(DNSQType.SOA),
            }),
            NotRule(NetmaskGroupRule(allow_axfr_from))
        }), RCodeAction(DNSRCode.REFUSED))

    -- If Notify from !recursive_ips, then Refused
    addAction(
        AndRule({
            OrRule({
                OpcodeRule(DNSOpcode.Notify),
                OpcodeRule(DNSOpcode.Update)
            }),
            NotRule(NetmaskGroupRule(recursive_ips))
        }), RCodeAction(DNSRCode.REFUSED))

    addAction(
        AndRule({
            OrRule({
                OpcodeRule(DNSOpcode.Notify),
                OpcodeRule(DNSOpcode.Update)
            }),
            SuffixMatchNodeRule(remy_forward_zones)     -- includes 'local.darac.org.uk'
        }), PoolAction("auth"))
    addAction(
        OrRule({
            OpcodeRule(DNSOpcode.Notify),
            OpcodeRule(DNSOpcode.Update)
        }), RCodeAction(DNSRCode.REFUSED))

    -- If SOA || AXFR || IXFR, then -> Auth
    addAction(
      OrRule({
          QTypeRule(DNSQType.AXFR),
          QTypeRule(DNSQType.IXFR),
          QTypeRule(DNSQType.SOA),
      }), PoolAction("auth"))
    addAction(
        NetmaskGroupRule(recursive_ips),
        PoolAction('recursor'))
    ---- Else -> Auth
    addAction(AllRule(), PoolAction('auth'))

When I run an 'nsupdate' on "crush" (192.168.101.254), I can see the
update messages sent (using tcpdump) and they arrive at dnsdist (using
the console, I can see rule #2 increment a few times), but the zone
doesn't get updated and the nsupdate times out.

If anyone can spot something obvious, or advise where I can look for
further debugging, I'd be grateful.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20210105/9896cbc2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20210105/9896cbc2/attachment.sig>


More information about the Pdns-users mailing list