Bind9

tets · 11-04-2021, 02:56 AM

Hello,

I've encountered a strange problem with zone transfer. I'm an admin of Bind9 DNS server that is acting as a slave for few domains. One of the domains is not transfering (other from the same master transfers fine).

Bind9 error in the log is:
'xfer-in: error: transfer of 'domain.com/IN' from XXX.XXX.XXX.XXX#53: failed while receiving responses: FORMERR'

When I try "dig AXFR @XXX.XXX.XXX.XXX domain.com" the error is:

Code:

;; Got bad packet: bad bitmap
1195 bytes

and a hex dump.

Tried tshark while running the "dig AXFR", seems fine until:

Code:

<Root>: type NXT, class Unknown, next domain name <Root>
            Name: <Root>
            Type: NXT (Next Domain) (30)
            Class: Unknown (0x77c2)
            Time to live: 134219008 (1553 days, 11 hours, 3 minutes, 28 seconds)
            Data length: 256
            Next Domain Name: <Root>
            RR type in bit map: MB (MailBox domain name)
            RR type in bit map: NULL RR
            RR type in bit map: PTR (domain name PoinTeR)
            RR type in bit map: HINFO (host information)
            RR type in bit map: NXT (Next Domain)
            RR type in bit map: NIMLOC (Nimrod Locator)
            RR type in bit map: SRV (Server Selection)
            RR type in bit map: A6 (OBSOLETE - use AAAA)
            RR type in bit map: SSHFP (SSH Key Fingerprint)
            RR type in bit map: Unknown (53)
            RR type in bit map: Unknown (54)
            RR type in bit map: RKEY
            RR type in bit map: TALINK (Trust Anchor LINK)
            RR type in bit map: OPENPGPKEY (OpenPGP Key)
            RR type in bit map: Unknown (63)
            RR type in bit map: HTTPS (HTTPS Specific Service Endpoints)
            RR type in bit map: Unknown (66)
            RR type in bit map: Unknown (68)
            RR type in bit map: Unknown (70)
            ...
            ...
            RR type in bit map: Unknown (2034)
            RR type in bit map: Unknown (2035)
            RR type in bit map: Unknown (2037)
[Malformed Packet: DNS]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

Output of "dig @XXX.XXX.XXX.XXX domain.com any" is OK, it's just the transfer that is failing.

I even tried:

Code:

perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new(); $r->nameservers("XXX.XXX.XXX.XXX"); for my $rr ($r->axfr("domain.com")) { $rr->print }'

that we found at https://lists.isc.org/pipermail/bind...ay/104613.html
No output, but tshark show exactly the same traffic as "dig AXFR".

I got my hands on the .zone file from master, named-checkzone said "OK".

Our Bind9 is version 9.16.15 on a Gentoo server.
The master server is also Bind9.

I'm out of ideas. Anyone encountered this problem? Any solution, please?
Let me know if you need more info.

Thank you

Tets

chrism01 · 11-04-2021, 11:32 PM

You could just read the hexdump (1195 chars isn't tooo bad

), but easier is likely to be using vim to look at the problematic file using https://chrispian.com/quick-vi-tip-s...en-characters/ to show/hide hidden (ctrl) chars.
The mesgs you are getting certainly seem to point at file corruption - can happen to anybody...

tets · 11-05-2021, 02:42 AM

Unfortunately, that's not the case. Admin on the master checked it as you suggested, even recreated the file from scratch. I, too, checked the original file he sent me - nothing weird in it. And we still have the same error.

Also - shouldn't named-checkzone show such mistake? named-checkzone was our first check and it said "OK".

Admin on the master even tried to transfer the zone to one of his computers (after allowing transfer on the master first of course) - and it transfered without a problem...

Thank you

Tets

tets · 11-05-2021, 06:18 AM

It is not the zone file. It must be something with our network. Transfer is OK from my private server, from master's admin computer, just not from our network.
My boss responsible for our firewall (Palo Alto) told me that it's not the firewall...

We'll investigate further.

Thanks again

Tets