Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
gmysql backend, dig axfr results in "Got bad packet: bad label type" #5494
I am running the following packages on Centos 7 server
Every 2nd or 3rd AXFR for one of our zones fails with the below error, followed by 'some' number of bytes of data. In this example it was 3096 but it can be higher or lower.
Every time i get a failed axfr, this error shows in logs.
We are sending various zones to 3rd party DNS providers and this specific is 347311 bytes, 5391 lines, when successfully dumped to file.
Here is the query log output, looking again at the logs.. this message is logged every time I do a AXFR.
I tried with another zone, next biggest which is 142078 bytes and 2456 lines/records. The dig AXFR never fails.. perhaps the zone size causes a problem ? Seems odd that it's intermittent.
I can't share the tcpdump on github i'm afraid because it will expose too much data for a very important corporate zone.
This defect is almost certainly caused/triggered by the contents of the zone. Can you run pdnsutil check-zone _____.com?
here is output.. some dupes for CNAME and A records. Can fix them but wouldn't have thought they would cause AXFR to fail. We are upgrading from a old PDNS 2.x installation which runs the same zone and data... both are running in parallel and the axfr works fine against old server.
So to start with i had the following configuration, so i could control the axfr whitelist from the pdns configuration but in my trials i wasn't able to get the EDNS settings to work with
But since the above didn't work i moved the whitelist back to dnsdist i.e.
And this works as far as controlling who can instigate a AXFR.
But that is secondary to the main problem which seems to be that dnsdist is preventing a successful AXFR for one of our zones.
If i remove dnsdist and bind pdns to public_interface:53 then the
I stripped the dnsdist configuration right back to just below in case i had done something silly but this still fails the axfr.
I ran dnsdist in verbose mode but i couldn't see anything in logs during the failed axfr request. I don't think this has anything to do with the zone contents.. It works directly against pdns so there seems to be a bug in dnsdist. Please let me know what i can do to assist fix.
I couldn't reproduce this issue, but that's not surprising given that it seems to only fail for specific zones. If you can't share a network trace, could you try to look at it and describe its content? Specifically the differences between what dnsdist receives from the server and what it sends back to the client would be very useful.