ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.

Wed May 12 12:49:31 UTC 2021

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.stoffel at toshiba.com
Website: Service Now Self Service Portal

-----Original Message-----
From: Mark Andrews <marka at isc.org> 
Sent: Wednesday, May 12, 2021 8:40 AM
To: Stoffel, John (TAI) <John.Stoffel at toshiba.com>
Cc: Tony Finch <dot at dotat.at>; bind-users at 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.Stoffel at 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.stoffel at toshiba.com
> Website: Service Now Self Service Portal
> 
> 
> -----Original Message-----
> From: Tony Finch <fanf2 at hermes.cam.ac.uk> On Behalf Of Tony Finch
> Sent: Tuesday, May 11, 2021 7:13 PM
> To: Stoffel, John (TAI) <John.Stoffel at toshiba.com>
> Cc: bind-users at lists.isc.org
> Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
> 
> Stoffel, John (TAI) <John.Stoffel at 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  <dot at 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 at lists.isc.org
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bin
> d-users__;!!BiNunAf9XXY-!WndX01fI68KFdfkv8Dd1sUoCS6-HU0arHJIQ534Lx1jfrKSSFoxDg59xx1d-rriL9zwE$