If dig (and named) would just print the record that broke things, it would help a lot more. Or print more debug info on the parsing to show where it went off the rails... I found it interesting that perl Net::DNS would pull down the records, and kept going even though there was a problem.
In any case, Tony was a huge huge help and it got me going enough so I could do a binary search and find the bad record. John Sr. Storage Architect TOSHIBA AMERICA, INC. 290 Donald Lynch Blvd – Suite 201 Marlborough, MA 01752 508-736-5499 (mobile) E-Mail: john.stof...@toshiba.com Website: Service Now Self Service Portal -----Original Message----- From: Mark Andrews <ma...@isc.org> Sent: Wednesday, May 12, 2021 8:40 AM To: Stoffel, John (TAI) <john.stof...@toshiba.com> Cc: Tony Finch <d...@dotat.at>; bind-users@lists.isc.org Subject: Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer. There is enough information to reproduce. Dig does have +besteffort but it doesn’t recover from this. You don’t want default handling to accept broken records so just skipping isn’t good behavior. It should be possible to extend +besteffort to print bad records in unknown format. -- Mark Andrews > On 12 May 2021, at 22:17, Stoffel, John (TAI) <john.stof...@toshiba.com> > wrote: > > Tony, > A big thanks to you for your suggestion on using the Perl Net::DNS module, > using that, I was then able to run named-checkzone on the dumped file > (35,000+ lines!) to find the one bad record which was making things crap out. > I'm back a bit on bind versions, but not that far back, so I would have > expected bind to just ignore that bogus record instead of crapping out. > > Unfortunately, I don't think I saved a copy of the bad record so I could file > a bug report, too busy trying to make things work. > > Cheers, > John > > > Sr. Storage Architect > TOSHIBA AMERICA, INC. > 290 Donald Lynch Blvd - Suite 201 > Marlborough, MA 01752 > 508-736-5499 (mobile) > E-Mail: john.stof...@toshiba.com > Website: Service Now Self Service Portal > > > -----Original Message----- > From: Tony Finch <fa...@hermes.cam.ac.uk> On Behalf Of Tony Finch > Sent: Tuesday, May 11, 2021 7:13 PM > To: Stoffel, John (TAI) <john.stof...@toshiba.com> > Cc: bind-users@lists.isc.org > Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on > named xfer. > > Stoffel, John (TAI) <john.stof...@toshiba.com> wrote: >> >> And it does dump some errors too, which hopefully will give me an >> idea of where my crappy bad record is located, and no use hiding crap: > > yuck, this looks like no fun... > >> http://www.cisco.toshiba.com. 3600 IN CNAME redirect.toshiba.com. >> http://www.cisco.toshiba.com. 3600 IN RRSIG CNAME 8 4 3600 >> 20210517093721 20210507083721 38628 t >> oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN >> hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ C6zJn9HHdC9o2dwBoGpknTwJM >> DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM= ;; Got >> bad packet: bad bitmap >> 16358 bytes > > does it print more hexdump? who knows where the problem might be in 16KB of > wire-format DNS... > > I would try another DNS AXFR client that might not give up so easily, e.g. > if you have a handy copy of perl and Net::DNS, put your Windows DNS > server IP address into this one-liner instead of 127.0.0.1 > > perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new(); > $r->nameservers("127.0.0.1"); for my $rr ($r->axfr("toshiba.com")) { > $rr->print }' > > The bit of the hexdump you pasted shows another similar CNAME and its RRSIG, > so it isn't very enlightening. > >> 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73 F............tos > header.... RR counts qname = zone name >> 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69 hiba.com......ci > 00fc = axfr >> 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10 tibank.......... > backpointer to zone = c00c 0005 = cname > > citibank looks like it follows cisco alphabetically which suggests the > zone transfer might be in canonical order, which could perhaps make it > easier to find the stray NXT / TYPE30 record(s) > >> 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00 ...redirect..... > cname target c01d = backpointer to citibank >> 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e ................ > 2e = rrsig type covered = 0005 (cname) >> 10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68 .`.9Q`..A...tosh >> 69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54 iba.com....2..*T >> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae e..(....A..`.... > > etc. > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> > https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!TxYeCrR > ieZyIcOGlb6sXZGm2RAMoSAa_FQxkoFEaSb2XkNsrzZa1Jjd7CvB-n6i-tTNB$ > Fisher, German Bight: Variable, becoming mainly west, 2 to 4. Slight or > moderate in Fisher, smooth or slight in German Bight. Showers, fog patches. > Moderate, occasionally very poor. > > _______________________________________________ > Please visit > https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bin > d-users__;!!BiNunAf9XXY-!WndX01fI68KFdfkv8Dd1sUoCS6-HU0arHJIQ534Lx1jfr > KSSFoxDg59xx1d-rriL9zwE$ to unsubscribe from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at > https://urldefense.com/v3/__https://www.isc.org/contact/__;!!BiNunAf9XXY-!WndX01fI68KFdfkv8Dd1sUoCS6-HU0arHJIQ534Lx1jfrKSSFoxDg59xx1d-rg_Z_OUM$ > for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bin > d-users__;!!BiNunAf9XXY-!WndX01fI68KFdfkv8Dd1sUoCS6-HU0arHJIQ534Lx1jfrKSSFoxDg59xx1d-rriL9zwE$ _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
