RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
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 Sent: Wednesday, May 12, 2021 8:40 AM To: Stoffel, John (TAI) Cc: Tony Finch ; 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) > 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 On Behalf Of Tony Finch > Sent: Tuesday, May 11, 2021 7:13 PM > To: Stoffel, John (TAI) > Cc: bind-users@lists.isc.org > Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on > named xfer. > > Stoffel, John (TAI) 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. 3600IN CNAME redirect.toshiba.com. >> http://www.cisco.toshiba.com. 3600IN 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 Ftos > headerRR 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.com2..*T >> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae e..(A..` > > etc.
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) > 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 On Behalf Of Tony Finch > Sent: Tuesday, May 11, 2021 7:13 PM > To: Stoffel, John (TAI) > Cc: bind-users@lists.isc.org > Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on > named xfer. > > Stoffel, John (TAI) 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. 3600IN CNAME redirect.toshiba.com. >> http://www.cisco.toshiba.com. 3600IN 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 Ftos > headerRR 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.com2..*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 > https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!TxYeCrRieZyIcOGlb6sXZGm2RAMoSAa_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://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 ___ 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
RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
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 On Behalf Of Tony Finch Sent: Tuesday, May 11, 2021 7:13 PM To: Stoffel, John (TAI) Cc: bind-users@lists.isc.org Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer. Stoffel, John (TAI) 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. 3600IN CNAME redirect.toshiba.com. > http://www.cisco.toshiba.com. 3600IN 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 Ftos headerRR 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.com2..*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 https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!TxYeCrRieZyIcOGlb6sXZGm2RAMoSAa_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://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
RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
Tony, Thank you so much for your help! Your suggestion to use Net::DNS really saved the day, because then I could do a brute force binary search to find the broken DNS record which was screwing me up. Once I deleted that record, all was well in the world, and my AXFR transfers happened just fine. I owe you a beer or two. Where in the UK are you located? My mom was from Hudderfield (Go Terriers) Looks like you're in Cambridge for your email, I think I've got a contact there I could get to draw you a few pints maybe. Thanks again, 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 On Behalf Of Tony Finch Sent: Tuesday, May 11, 2021 5:24 PM To: Stoffel, John (TAI) Cc: bind-users@lists.isc.org Subject: Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer. Stoffel, John (TAI) wrote: > failed while receiving responses: bad bitmap > > None of my googling has given me any hints on what this error could be. I had to look at the source, which told me it's to do with NXT records which are super obsolete, so I wonder what weird stuff is in the zone that might cause this. (The NXT record was a predecessor of NSEC; NXT was badly designed so it is unable to support all possible DNS RR types, which is why it needed replacing.) $ rg 'bad bitmap' lib/dns/result.c:137: "bad bitmap",/*%< 94 DNS_R_BADBITMAP */ $ rg BADBITMAP lib/dns/include/dns/result.h:132:#define DNS_R_BADBITMAP (ISC_RESULTCLASS_DNS + 94) lib/dns/rdata/generic/nxt_30.c:154: return (DNS_R_BADBITMAP); lib/dns/result.c:137: "bad bitmap",/*%< 94 DNS_R_BADBITMAP */ lib/dns/result.c:278: "DNS_R_BADBITMAP", Tony. -- f.anthony.n.finch https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!VH-JqRCMfVb-2Su9Du-D3OA4DlJi6q3lXIg4s9pjD9fwN1atleDmzsKASzloojK1C1WS$ Viking, North Utsire, South Utsire: Southerly or southeasterly 3 to 5 becoming variable 2 to 4, then northerly 5 to 7 later in Viking and northern North Utsire. Moderate or rough in Viking and northern North Utsire, slight or moderate elsewhere. Showers, fog patches. Moderate or good, occasionally very poor. ___ 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
RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
Stoffel, John (TAI) 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... > www.cisco.toshiba.com. 3600IN CNAME redirect.toshiba.com. > www.cisco.toshiba.com. 3600IN 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 Ftos headerRR 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.com2..*T > 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae e..(A..` etc. Tony. -- f.anthony.n.finchhttps://dotat.at/ 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://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
RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
Tony, Thank you for your help. I was going *insane* trying to figure out where this was coming from, and I had literally just pulled down the source to look at the code. So now it looks like I need to find and kill any and all NXT records in my domain. Sigh... So it's part of the DNSSEC setup, and it's not clear how to do an 'fsck' like scan on a Windows DNS server to look for problems like this. But trawling through my DNS tool on windows (which sucks... btw) I don't see any NXT records, though I see a ton of NSEC3 records. Does anyone have a clue how I can try to find these bad record(s)? I can do the following on my Linux secondary: dig AXFR foo.com @xxx.xxx.xxx.xxx > /tmp/foo.com 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: www.cisco.toshiba.com. 3600IN CNAME redirect.toshiba.com. www.cisco.toshiba.com. 3600IN 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 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73 Ftos 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69 hiba.com..ci 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10 tibank.. 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00 ...redirect. 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e 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.com2..*T 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae e..(A..` -Original Message- From: Tony Finch On Behalf Of Tony Finch Sent: Tuesday, May 11, 2021 5:24 PM To: Stoffel, John (TAI) Cc: bind-users@lists.isc.org Subject: Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer. Stoffel, John (TAI) wrote: > failed while receiving responses: bad bitmap > > None of my googling has given me any hints on what this error could be. I had to look at the source, which told me it's to do with NXT records which are super obsolete, so I wonder what weird stuff is in the zone that might cause this. (The NXT record was a predecessor of NSEC; NXT was badly designed so it is unable to support all possible DNS RR types, which is why it needed replacing.) $ rg 'bad bitmap' lib/dns/result.c:137: "bad bitmap",/*%< 94 DNS_R_BADBITMAP */ $ rg BADBITMAP lib/dns/include/dns/result.h:132:#define DNS_R_BADBITMAP (ISC_RESULTCLASS_DNS + 94) lib/dns/rdata/generic/nxt_30.c:154: return (DNS_R_BADBITMAP); lib/dns/result.c:137: "bad bitmap",/*%< 94 DNS_R_BADBITMAP */ lib/dns/result.c:278: "DNS_R_BADBITMAP", Tony. -- f.anthony.n.finch https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!VH-JqRCMfVb-2Su9Du-D3OA4DlJi6q3lXIg4s9pjD9fwN1atleDmzsKASzloojK1C1WS$ Viking, North Utsire, South Utsire: Southerly or southeasterly 3 to 5 becoming variable 2 to 4, then northerly 5 to 7 later in Viking and northern North Utsire. Moderate or rough in Viking and northern North Utsire, slight or moderate elsewhere. Showers, fog patches. Moderate or good, occasionally very poor. ___ 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
Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
Stoffel, John (TAI) wrote: > failed while receiving responses: bad bitmap > > None of my googling has given me any hints on what this error could be. I had to look at the source, which told me it's to do with NXT records which are super obsolete, so I wonder what weird stuff is in the zone that might cause this. (The NXT record was a predecessor of NSEC; NXT was badly designed so it is unable to support all possible DNS RR types, which is why it needed replacing.) $ rg 'bad bitmap' lib/dns/result.c:137: "bad bitmap",/*%< 94 DNS_R_BADBITMAP */ $ rg BADBITMAP lib/dns/include/dns/result.h:132:#define DNS_R_BADBITMAP (ISC_RESULTCLASS_DNS + 94) lib/dns/rdata/generic/nxt_30.c:154: return (DNS_R_BADBITMAP); lib/dns/result.c:137: "bad bitmap",/*%< 94 DNS_R_BADBITMAP */ lib/dns/result.c:278: "DNS_R_BADBITMAP", Tony. -- f.anthony.n.finchhttps://dotat.at/ Viking, North Utsire, South Utsire: Southerly or southeasterly 3 to 5 becoming variable 2 to 4, then northerly 5 to 7 later in Viking and northern North Utsire. Moderate or rough in Viking and northern North Utsire, slight or moderate elsewhere. Showers, fog patches. Moderate or good, occasionally very poor. ___ 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
ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
Hi, I'm setting up an ISC Bind 9.11.20-RedHat-9.11.20-5 on a CentOS 8.3.2011 server and I'm running into a problem transferring a domain from our primary to this new secondary. The primary is a Windows Server 2012R2 system. I have 300+ domains setup and most of them are working just fine, and I can see the data for them in /var/named/secondary/ files. But my main domain isn't transferring, I keep getting the following: May 11 20:06:42 foo-dns-p03 named[71418]: zone foo.com/IN: Transfer started. May 11 20:06:42 foo-dns-p03 named[71418]: transfer of 'foo.com/IN' from xxx.xxx.xxx.xxx#53: connected using yyy.yyy.yyy.yyy#39861 May 11 20:06:43 foo-dns-p03 named[71418]: transfer of 'foo.com/IN' from xxx.xxx.xxx.xxx#53: failed while receiving responses: bad bitmap May 11 20:06:43 foo-dns-p03 named[71418]: transfer of 'foo.com/IN' from xxx.xxx.xxx.xxx#53: Transfer status: bad bitmap May 11 20:06:43 foo-dns-p03 named[71418]: transfer of 'foo.com/IN' from xxx.xxx.xxx.xxx#53: Transfer completed: 19 messages, 2518 records, 309684 bytes, 0.355 secs (872349 bytes/sec) Which really implies to me that we have some issues on the source Windows DNS server, but it's not easy to find. Is there anyway I can relax named to access this domain transfer, even with a bad bitmap? Or is there a good way to bump up the logging so I can find out which record(s) are causing the problem so I can maybe fix them on the source? None of my googling has given me any hints on what this error could be.My config looks like this: options { listen-on port 53 { any; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any; }; recursion no; rrset-order { order random; }; dnssec-enable False; dnssec-validation False; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; print-time yes; }; }; zone "foo.com" IN { type slave; masters { xxx.xxx.xxx.xxx; } ; }; ___ 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