[Pdns-users] PDNS Resolver.

[James Cloos]

>>>>> "Brad" == Brad Dameron <Brad.Dameron at clearwire.com> writes:

Brad> pdns_recursor[4174]: Unable to parse packet from remote UDP client
Brad> XX.XX.XXX.XXX: Can't parse non-query packet with opcode=4
Brad> Oct 5 08:40:15 rs-2 pdns_recursor[4174]: Unable to parse packet from
Brad> remote UDP client XX.XX.XXX.XXX: Can't parse non-query packet with
Brad> opcode=4

A bit of googling tells me that opcode 4 is NOTIFY, used by MASTERs to
let their SLAVEs know it is time to do an AXFR or IXFR.

It is possible that customer specified your resolver's IP in an NS RR
for one of their zones?

Brad> pdns_recursor[4174]: Ignoring answer from 66.233.119.217 on server
Brad> socket!

Obviously pdns doesn't like getting replies send back to port 53....

Why your customer's box is doing that is an interesting question.

Brad> Unable to parse packet from remote UDP client 10.85.1.11: Error
Brad> parsing packet of 16 bytes (rd=0), out of bounds:
Brad> vector::_M_range_check

Given that you are serving wireless customers, could that be the result
of packet corruption on the radio link?

AFAICT from reading rfc1035, no query should be smaller than 17 octets,
and that only happens when querying RRs of the root zone.  Ie, doing a
dig . NS or a dig . SOA or similar.

If it was not due to packet corruption, perhaps it is a probe.  Such as
a UPD ping or traceroute.  Or maybe someone ran nmap or similar.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6