Bad compression pointer

NSD
1

Hi, first time posting to this list, and first time using NSD.

I decided to install 1.4.0-Alpha1 and everything seemed to install ok,
but I can't get it running correctly. I followed the instructions in
the README to the letter. There were no errors while installing.

The specific problem I have is when I try to dig
test.rilextechnologies.com I get the error:

;; Got bad packet: bad compression pointer
88 bytes
34 5a 85 00 00 01 00 02 00 01 00 00 04 74 65 73
74 11 72 69 6c 65 78 74 65 63 68 6e 6f 6c 6f 67
69 65 73 03 63 6f 6d 00 00 01 00 01 c0 0c 00 05
00 01 00 01 51 80 00 02 c3 73 c3 73 00 01 00 01
00 01 51 80 00 04 42 c2 77 82 c0 11 00 02 00 01
00 01 51 80 00 02 ec 6f

I was thinking that this might be an error in my configuration files,
but am unsure.

Let me know what you think or if you need more information.
Thanks

Dave

2

David Coursey wrote:

Hi, first time posting to this list, and first time using NSD.

I decided to install 1.4.0-Alpha1 and everything seemed to install ok,
but I can't get it running correctly. I followed the instructions in
the README to the letter. There were no errors while installing.

The specific problem I have is when I try to dig
test.rilextechnologies.com I get the error:

;; Got bad packet: bad compression pointer
88 bytes
34 5a 85 00 00 01 00 02 00 01 00 00 04 74 65 73
74 11 72 69 6c 65 78 74 65 63 68 6e 6f 6c 6f 67
69 65 73 03 63 6f 6d 00 00 01 00 01 c0 0c 00 05
00 01 00 01 51 80 00 02 c3 73 c3 73 00 01 00 01
00 01 51 80 00 04 42 c2 77 82 c0 11 00 02 00 01
00 01 51 80 00 02 ec 6f

I was thinking that this might be an error in my configuration files,
but am unsure.

Let me know what you think or if you need more information.

Definitely an NSD bug (it should never respond with bad packets), even though it may be triggered by strange zone files. Could you send me a copy of the zone and configuration file as well as the dig command you used?

Also, what platform are you running NSD on (OS, cpu, etc)?

Thanks,
Erik

3

I get that fairly often when I add a new domain. I have to restart
nsd. It also happens when there is some bad info in the zone file.
(I don't remember what triggers it, but I can try and duplicate it if
people want me to.)

4

I talked to David on IRC (freenode.net channel #dns) and advised him to:

1. Use 1.2.3 for production environment
2. Subscribe to the list if using an alpha version
3. Ask here

Anyway, I queried his server when he asked on IRC and got the bad compression
pointer myself. Seems to be something corrupt, but not running 1.4.0-alpha
myself, I've no experience with it. Here's what I got:

5

Peter Hessler wrote:

I get that fairly often when I add a new domain. I have to restart nsd. It also happens when there is some bad info in the zone file. (I don't remember what triggers it, but I can try and duplicate it if people want me to.)

Could you elaborate on this? NSD version, OS/platform, etc. Are you using mmap?

Also note that the name compression algorithm is completely different between 1.2.x and 1.4.0-alpha1.

Erik

6

nsd-1.4.0-alpha1 on OpenBSD/macppc -current (as of Sunday). Yes, I am
using mmap. Built from ports (after updating to 1.4.0-alpha1).

Looks like it always generates a similar error after an `nsdc reload`.
I put a copy of the output at http://theapt.org/nsd-compression.txt

If I can generate it another way, I'll let the list know.

7

Peter Hessler wrote:

nsd-1.4.0-alpha1 on OpenBSD/macppc -current (as of Sunday). Yes, I am using mmap. Built from ports (after updating to 1.4.0-alpha1).

Looks like it always generates a similar error after an `nsdc reload`. I put a copy of the output at http://theapt.org/nsd-compression.txt

Ok, looks like reload is a probable cause of the problem. I haven't done a lot of testing of this code path for 1.4.0-alpha1 (that's why it is alpha :slight_smile: ). I'll look into this tomorrow.

Thanks,
Erik

8

:Peter Hessler wrote:
:>nsd-1.4.0-alpha1 on OpenBSD/macppc -current (as of Sunday). Yes, I am
:>using mmap. Built from ports (after updating to 1.4.0-alpha1).
:>
:>Looks like it always generates a similar error after an `nsdc reload`.
:>I put a copy of the output at http://theapt.org/nsd-compression.txt
:
:Ok, looks like reload is a probable cause of the problem. I haven't
:done a lot of testing of this code path for 1.4.0-alpha1 (that's why it
:is alpha :slight_smile: ). I'll look into this tomorrow.
:
:Thanks,
:Erik
:

It is entirely possible that it is an endian problem. I wasn't able
to get nsd 1.2.3 to work on my macppc server (but I didn't try very
hard).

9

Peter Hessler wrote:

:Ok, looks like reload is a probable cause of the problem. I haven't :done a lot of testing of this code path for 1.4.0-alpha1 (that's why it :is alpha :slight_smile: ). I'll look into this tomorrow.
:
:Thanks,
:Erik
:

It is entirely possible that it is an endian problem. I wasn't able to get nsd 1.2.3 to work on my macppc server (but I didn't try very hard).

I was able to reproduce the compression bug on Linux/x86 so this particular problem is not endian related: NSD 1.4.0-alpha1 fails to reinitialize the compression tables after a database reload causing compression failures (and probably crashes and other weird problems). As a temporary workaround you can restart NSD instead of using reload. The reload bug will be fixed in NSD 2.0.0.

Do you have any more information on the problems of nsd 1.2.3 on macppc?

Thanks,
Erik