[dnsdist] nsupdate passing through dnsdist gets dropped by pdns

Darac Marjal mailinglist at darac.org.uk
Wed Jan 6 16:35:20 UTC 2021


Hello all,

I'm having a bit of an issue debugging nsupdates through dnsdist, and
I'm hoping a few more eyes on my configuration to see if I'm doing
anything wrong.

I have a small network with, on one server (named "remy"):

  * dnsdist (v1.5.1) on port 53
  * pdns (v4.4.0) on port 5300
  * pdns-recursor (v4.4.2) on port 5301

I also have another server (named "crush") running isc-dhcp-server
(v4.4.1) which wants to send dnsupdates to remy. If I send the nsupdate
directly to pdns on port 5300, the update succeeds, but if I send it to
port 53, then pdns drops the message.

In dnsdist, I have

    newServer({address='[::1]:5300',  name="remy",  pool='auth',   useClientSubnet=true, checkName="darac.org.uk."})
    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')
    
    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('2a02:8010:d008::c0ff:ee:1')
    allow_axfr_from:addMask('82.70.33.60')
    allow_axfr_from:addMask('::1/128')
    
    -- Only Forward known zones to auth
    remy_forward_zones = newSuffixMatchNode()
    remy_forward_zones:add({
            '101.168.192.in-addr.arpa',
            'darac.org.uk',
            'local.darac.org.uk'
    })
    
    rl = newFrameStreamTcpLogger("127.0.0.2:8053")
    addAction(AllRule(), DnstapLogAction("dns", rl))
    addResponseAction(AllRule(), DnstapLogResponseAction("rdns", rl))
    
    -- 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)
        }), 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"))
    ---- RecursiveIPs can recurse
    addAction(
        NetmaskGroupRule(recursive_ips),
        PoolAction('recursor'))
    
    -- Otherwise (Public addresses?) go to Auth
    addAction(AllRule(), PoolAction('auth'))

Watching messages on the webserver, I can see that the "DNSOpcode.Update
-> auth" rule is applied, but then the number of "Drops" on the auth
server increments. On the pdns webmonitor "Remote hosts sending corrupt
packets" also increments. After a few seconds, the nsupdate times out.

Can anyone spot something I've done wrong, or suggest how I can go about
debugging this further (I can't seem to figure out, for example, why
pdns thinks the packet is corrupt).

Many thanks.



-------------- 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/dnsdist/attachments/20210106/f3dd64b6/attachment.sig>


More information about the dnsdist mailing list