>>>>> "Brad" == Brad Dameron <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
