generates bogus rrsigs #492

Closed
Habbie opened this Issue Apr 26, 2013 · 8 comments

Projects

None yet

1 participant

@Habbie
Member
Habbie commented Apr 26, 2013

This is Debian Bug #675410,
http://bugs.debian.org/675410

Sorry for posting this to pdns-users first before remembering that there is a bug tracker.

From: Florian Obser florian@narrans.de
To: Debian Bug Tracking System submit@bugs.debian.org
Subject: pdns-server: generates bogus rrsigs
Date: Fri, 01 Jun 2012 00:07:33 +0200

Package: pdns-server
Version: 3.1-1
Severity: important

Hi,
I first noticed this problem when I upgraded a 3.0 pdns-static deb
downloaded from powerdns.com to 3.1 by backporting/compiling the 3.1
sid source package to squeeze. The DNSKEYs were generated with the 3.0
pdns-static version. http://dnsviz.net/,
http://dnssec-debugger.verisignlabs.com/ and my local validating
unbound resolver were reporting bogus rrsigs after the upgrade.

To make sure this is not some upstream problem I removed my own
packages and installed pdns-static_3.1.20120511.2617-1_amd64.deb from
upstream. The RRSIGs are ok with that version.

Making sure this is not a problem with my own build I setup a wheezy
testsystem and imported a database dump from the production machine.
The RRSIGs are bogus again.

Testing with this script:

! /usr/bin/perl

use strict;
use warnings;
use 5.010;

use Net::DNS;

my $res = Net::DNS::Resolver->new(

nameservers => [qw(217.31.82.6)], # OK

nameservers => [qw(217.31.84.16)], # BROKEN
recurse     => 0,
debug       => 0,
dnssec      => 1

);

my $answer = $res->query('adns1.de', 'DNSKEY');

my @rrset = grep { ref($) eq 'Net::DNS::RR::DNSKEY'} $answer->answer;
my @rrsig = grep { ref($
) eq 'Net::DNS::RR::RRSIG'} $answer->answer;
foreach my $rr (@rrset) {
say $rr->string;
}
say '-' x 80;
foreach my $rr (@rrsig) {
say $rr->string;
}
my $rrsig = $rrsig[0];
say '-' x 80;
say 'verify: ', $rrsig->verify(@rrset, @rrset);

say $rrsig->vrfyerrstr;

I get this output for the wheezy pdns:

$ perl pdns_debug.pl
adns1.de. 86400 IN DNSKEY 257 3 7 (
AwEAAcGf3iRl4grAc6JH2uu2FZ85IR34OBZL
wUK3pTLPsGRtrYflNJSTE3Zz/G+8qQsygmLK
xs9IB+MPEOtsWtvCcthF5XPAs18imq6Os9zm
ocYsGMqZCIDVk91L+q0cF61xvt0pLodE1Lhk
PVw4trSlG/UrVttu21EDcCw6j+HgY16QhD0Z
f4TAiKolRcVb05WpVn7PAEyejMbqqAZJlthl
ylxqtAhP0OaTIK80HWKp/Tm13sMR9FqDG9Us
Yf9jyTeUoZ+9VEyY4xQOgj/p1kJu6tmCg0cy
azE72GnWaJmtcEgPvswARj+dud6ncYfcQhSy
gvut/9ELC6NSCPwdMgMCnKc=
) ; Key ID = 49353
adns1.de. 86400 IN DNSKEY 256 3 7 (
AwEAAc2DV53dOIqxlq+YijjMPoRHoPZzzYKn
JXcy491RJnTzaPiEGOLTvhpBMt7c+IOn9mRd
Ev3PU3m0WFbeb6Uv8VNf+dc2CTFPGBz8DUIS
3DEbcUJdoG/5U000f/Kqyjgahr5LQHHJGXU4
UAK3Jd1YeBKiCgx9mpE7xwCewspMhutB
) ; Key ID = 41009
adns1.de. 86400 IN DNSKEY 256 3 7 (
AwEAAcbLMvWxXjVvtEoIRg2IT7lzZUCDz9tC
2cI2oymrUUawiO0y5aFLQCHeWlr+5HwWjclX
O8WSavC+rCTV/QXA60OgGMupXVfO9eZgiaUg
nYcX7xTSdQxK4KKRJ3RHPXjWPvRWDpeIwOob
gPEB0DvuLBz8onmoEq+kVbpiwq5Hd2jr

) ; Key ID = 7997

adns1.de. 86400 IN RRSIG DNSKEY 7 2 86400 20120614000000 (
20120531000000 49353 adns1.de.
Eg1h4ZqRBOkrS3mcWD6qOJo+ARYO+RIscR40oscqrdyMq
ujrXLPHMiWuBCBitT0RvNS/FGKq6/pWhaNI/fkjjJmzhs
fsNSuUZpn6nDCzbCm+gJ4rRYlOacIu4pdS9qZdFnpI1XK
R+BoYN31Ih6i8AyEQq7Lwonf/kK9WfsNMGKJyXrOh1ooH
sC0L7TeHqrR7yHdYcUtvA8lFSPFBXYh8jZk9L9hu/XHTP
PaI2v0YBPNJUC7/2K1aOK8n10SzHRPSshlahoyFw8bHHB
K2GbYo2Jjhu6k2RhEj3VBSZ7jfKlvMoaocnqAG9+N5jAo

TAuD7xdefySCbb+IpkjI53Lvfig== )

verify: 0
key 1:RSA Verification failed key 2: keytag does not match key 3: keytag does not match

And this output for the production system:
$ perl pdns_debug.pl
adns1.de. 86400 IN DNSKEY 257 3 7 (
AwEAAcGf3iRl4grAc6JH2uu2FZ85IR34OBZL
wUK3pTLPsGRtrYflNJSTE3Zz/G+8qQsygmLK
xs9IB+MPEOtsWtvCcthF5XPAs18imq6Os9zm
ocYsGMqZCIDVk91L+q0cF61xvt0pLodE1Lhk
PVw4trSlG/UrVttu21EDcCw6j+HgY16QhD0Z
f4TAiKolRcVb05WpVn7PAEyejMbqqAZJlthl
ylxqtAhP0OaTIK80HWKp/Tm13sMR9FqDG9Us
Yf9jyTeUoZ+9VEyY4xQOgj/p1kJu6tmCg0cy
azE72GnWaJmtcEgPvswARj+dud6ncYfcQhSy
gvut/9ELC6NSCPwdMgMCnKc=
) ; Key ID = 49353
adns1.de. 86400 IN DNSKEY 256 3 7 (
AwEAAc2DV53dOIqxlq+YijjMPoRHoPZzzYKn
JXcy491RJnTzaPiEGOLTvhpBMt7c+IOn9mRd
Ev3PU3m0WFbeb6Uv8VNf+dc2CTFPGBz8DUIS
3DEbcUJdoG/5U000f/Kqyjgahr5LQHHJGXU4
UAK3Jd1YeBKiCgx9mpE7xwCewspMhutB
) ; Key ID = 41009
adns1.de. 86400 IN DNSKEY 256 3 7 (
AwEAAcbLMvWxXjVvtEoIRg2IT7lzZUCDz9tC
2cI2oymrUUawiO0y5aFLQCHeWlr+5HwWjclX
O8WSavC+rCTV/QXA60OgGMupXVfO9eZgiaUg
nYcX7xTSdQxK4KKRJ3RHPXjWPvRWDpeIwOob
gPEB0DvuLBz8onmoEq+kVbpiwq5Hd2jr

) ; Key ID = 7997

adns1.de. 86400 IN RRSIG DNSKEY 7 2 86400 20120614000000 (
20120531000000 49353 adns1.de.
AgJxEd8XbutXWRJj3oNbqvPjtl8IIdO+HmXqHTjad1m07
ZFWkowVAcPYlUuu7hV5lJ6sV0ExojeYp+BxCfYDJzUevw
UYplsudwHY6KAZGZzVzYHjXIWH0WLqdJYox9JKnOZ8JJb
dzumQiSm7treIMr2mAoSyxFo29nX1Fl5w9jeGpxAQA9v/
hSt+IbHjH1vyN1G2vgyj7CQdevbAAhKq4Qli0tyPh51H+
d5aw4WztYBkptJ6d5s+1chxtM3x/LPrIxrhhGXJLpjQqr
Sd1vtci7YtxI+e2tynVeNKwETKj+ncnXQKgpfLFzppe8S

pu+LqJ35QqJ6y/rytKySnsuBW/Q== )

verify: 1
No Error

(Please note that the externally visible production IP is not actually
running powerdns but nsd which gets it's data via AXFR)

Btw. I don't understand why pdns-backend-mysql is listed as pn, it is
in fact installed:

dpkg -l pdns-backend-mysql

ii pdns-backend-m 3.1-1 generic MySQL backend for PowerDNS

Thanks,
Florian

-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages pdns-server depends on:
ii adduser 3.113+nmu2
ii debconf [debconf-2.0] 1.5.43
ii libboost-program-options1.49.0 1.49.0-3
ii libboost-serialization1.49.0 1.49.0-3
ii libc6 2.13-32
ii libcrypto++9 5.6.1-6
ii libgcc1 1:4.7.0-8
ii liblua5.1-0 5.1.5-2
ii libpolarssl0 1.1.3-1
ii libsqlite3-0 3.7.11-3
ii libstdc++6 4.7.0-8
ii ucf 3.0025+nmu3
ii zlib1g 1:1.2.7.dfsg-1

pdns-server recommends no packages.

Versions of packages pdns-server suggests:
pn pdns-backend-mysql [pdns-backend] 3.1-1
pn pdns-recursor

-- debconf information excluded

@Habbie Habbie was assigned Apr 26, 2013
@Habbie Habbie closed this Apr 26, 2013
@Habbie
Member
Habbie commented Apr 26, 2013

Author: peter
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675410 has more details. This is apparently an issue with the Debian compile of PowerDNS - however, if just some compile flags can break RRSIG generation, that's a bug on our end.

@Habbie
Member
Habbie commented Apr 26, 2013

Author: anon
We have now nailed this down to an interoperability issue. Upstream's pdns-static is linked to botan; Debian PowerDNS isn't (there is an issue with the include files that prevents --with-botan-1.10 from working).

Debian's PowerDNS seems to choke on keys generated by botan.

@Habbie
Member
Habbie commented Apr 26, 2013

Author: peter
i.e. PolarSSL chokes on keys generated by Botan

@Habbie
Member
Habbie commented Apr 26, 2013

Author: peter
pdnssec test-algorithm(s) in r2705 demonstrates this issue when linked against Ubuntu 10.04's libbotan-1.8.2 and our included Polar, should make finding the issue somewhat easier.

@Habbie
Member
Habbie commented Apr 26, 2013

Author: peter
I have sent a concise reproduction scenario to the PolarSSL guys. Further reports as events warrant!

@Habbie
Member
Habbie commented Apr 26, 2013

Author: peter
r2720 fixes this. It turns out our Botan ISC export was broken. If there is a need for a fix tool, please let me know. Closing ticket!

@Habbie
Member
Habbie commented Apr 26, 2013

Author: peter
reopening, not because anything is wrong, but because a migration tool might be good to have!

@Habbie
Member
Habbie commented Apr 26, 2013

Author: peter
an export done with pdnssec compiled after the fix in r2720 will write out a corrected key. pdnssec binaries can be found inside the packages in the artifacts of the auth-svn-semistatic jobs at https://autotest.powerdns.com/

closing ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment