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.
>
> Tony.
> --
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
named-xfer?
Hello, I have to fetch some zones from http://www.zonedit.com/ but it seems, named-xfer does not more exist in bind9. How can I now manualy download a zone? Thanks, Greetings and nice Day/Evening Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # http://www.tamay-dogan.net/ Michelle Konzack http://www.can4linux.org/ Apt. 917 http://www.flexray4linux.org/ 50, rue de Soultz Jabber linux4miche...@jabber.ccc.de 67100 Strasbourg/France IRC #Debian (irc.icq.com) Tel. DE: +49 177 9351947 ICQ #328449886Tel. FR: +33 6 61925193 signature.pgp Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named-xfer?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02-Apr-2009, at 18:33, Michelle Konzack wrote: Hello, I have to fetch some zones from http://www.zonedit.com/ but it seems, named-xfer does not more exist in bind9. How can I now manualy download a zone? dig IN AXFR zone @server file that will do it. HTH, Matt -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAknVPjUACgkQmFeRJ0tjIxGScwCglUdG03D0kpBtAuo7i7tJ1PIk kDUAmgN1qYmoGJWduaN0NcI9qYlj6oAs =8CUR -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
