[Pdns-users] PDNS Authoritative DNSSEC Question

[Chris]

Hi list,

I am playing around with DNSSEC and I seem to have created a strange 
problem for myself.

I am using PDNS 3.3-1 on Debian with the generic SQL backend and a MySQL 
database. The schema I was using previously didn't match the recommended 
one in the documentation, the 'type' column didn't allow NULL values. 
This zone in question has SRV records which appear to have an issue with 
this, other zones I have signed look fine.

To reproduce this I added another domain to test and here are the steps 
that I did.

1. Signed the zone:

# pdnssec --config-dir=/etc/powerdns --config-name=internal secure-zone 
r-9.net
Securing zone with rsasha256 algorithm with default key size
Zone r-9.net secured
Adding NSEC ordering information
Error: GSQLBackend unable to insert empty non-terminal rr _tcp.r-9.net 
in domain_id 3436: Failed to execute mysql_query, perhaps connection 
died? Err=1: Column 'type' cannot be null

The signing errored due to the 'type' column not allowing NULL. I 
updated the schema to allow this.

2. I disabled dnssec on the domain and enabled it again:

# pdnssec --config-dir=/etc/powerdns --config-name=internal 
disable-dnssec r-9.net
# pdnssec --config-dir=/etc/powerdns --config-name=internal secure-zone 
r-9.net
Securing zone with rsasha256 algorithm with default key size
Zone r-9.net secured
Adding NSEC ordering information

3. I set nsec3 narrow:

# pdnssec --config-dir=/etc/powerdns --config-name=internal set-nsec3 
r-9.net '1 1 10 ffee' narrow
NSEC3 (opt-out) set, please rectify-zone if your backend needs it

4. I now retrieve the DS records:

# /usr/bin/pdnssec --config-dir=/etc/powerdns --config-name=internal 
show-zone r-9.net
Zone is not presigned
Zone has NARROW hashed NSEC3 semantics, configuration: 1 1 10 ffee
keys:
ID = 33 (KSK), tag = 61424, algo = 8, bits = 2048       Active: 1 ( 
RSASHA256 )
KSK DNSKEY = r-9.net IN DNSKEY 257 3 8 
AwEAAartZfyxV2RFO5inETzWoxRoMmD3fmVF6H9bQvVXrWtSzDrfcr/z/33L3qFEDjOyx4JSzjJDmqVAkxg2IJOu97E6/QqbXgEVuAsHIzwJ54jesVzGS8zY4oIwAIfDNtDJxSXOF8lHoqZy+rSy/ljjvXc7p65e5LF01bJeaBvo8UcxBcjb+RLryCwtN2dR1NQePZyk2U3H7hOl/TzLjj18WvG/WHGk3DHrbxDWjHMDtlx/XrqP/uYjmbtaRb8X2wk891JjM2KenFKcbOCMj2Pt1/zULBG+oKCBUmCf4/fSd8KToaLlJDcdQII39IsUAr5er0FAfD3Ck/Hoyzjmysk/wu8= 
; ( RSASHA256 )
DS = r-9.net IN DS 61424 8 1 57b2f6345c9e6701ccc87a48e5648f305d2ced66 ; 
( SHA1 digest )
DS = r-9.net IN DS 61424 8 2 
10136d9b41dc5f1448c7d7433061417446640fd60d194693b84c9e3feea73cfd ; ( 
SHA256 digest )
DS = r-9.net IN DS 61424 8 3 
255737aaf8cdfd5f267769f06e4d00b33a273e88e57ea2268d761d898f8f418e ; ( 
GOST R 34.11-94 digest )
DS = r-9.net IN DS 61424 8 4 
7b2493b0a9f917533a015b4fb28791f4d2f57725ff31caef36daeb85b638a5618e2a37767c3ed1798c4810ab3ac18794 
; ( SHA-384 digest )
ID = 35 (ZSK), tag = 9334, algo = 8, bits = 1024        Active: 1 ( 
RSASHA256 )

 From what I can see the DS records should have a key tag of 61424.

5. I check using the verisign labs DNSSEC debugger to see if it passes, 
http://dnssec-debugger.verisignlabs.com/r-9.net.

I get a couple of errors and warnings, mainly: The DS RRset was not 
signed by any keys in the chain-of-trust

Using the same process as above on another domain with no SRV records 
results in no errors.

-------------------------

I checked on the registry (Verisign GRS) to make sure there are no extra 
DS records set, the relevant info from running an EPP 'InfoDomain' looks 
fine to me:

       <SecDnsExtFields>
         <keyTag>61424</keyTag>
         <alg>8</alg>
         <digestType>2</digestType>
<digest>10136D9B41DC5F1448C7D7433061417446640FD60D194693B84C9E3FEEA73CFD</digest>
         <flags>0</flags>
         <protocol>0</protocol>
         <keyAlg>0</keyAlg>
         <pubKey/>
         <maxSigLife>0</maxSigLife>
         <urgent>false</urgent>
         <removeAll>false</removeAll>
         <removeRecord>false</removeRecord>
         <chgRecord>false</chgRecord>
       </SecDnsExtFields>
       <SecDnsExtFields>
         <keyTag>61424</keyTag>
         <alg>8</alg>
         <digestType>3</digestType>
<digest>255737AAF8CDFD5F267769F06E4D00B33A273E88E57EA2268D761D898F8F418E</digest>
         <flags>0</flags>
         <protocol>0</protocol>
         <keyAlg>0</keyAlg>
         <pubKey/>
         <maxSigLife>0</maxSigLife>
         <urgent>false</urgent>
         <removeAll>false</removeAll>
         <removeRecord>false</removeRecord>
         <chgRecord>false</chgRecord>
       </SecDnsExtFields>
       <SecDnsExtFields>
         <keyTag>61424</keyTag>
         <alg>8</alg>
         <digestType>4</digestType>
<digest>7B2493B0A9F917533A015B4FB28791F4D2F57725FF31CAEF36DAEB85B638A5618E2A37767C3ED1798C4810AB3AC18794</digest>
         <flags>0</flags>
         <protocol>0</protocol>
         <keyAlg>0</keyAlg>
         <pubKey/>
         <maxSigLife>0</maxSigLife>
         <urgent>false</urgent>
         <removeAll>false</removeAll>
         <removeRecord>false</removeRecord>
         <chgRecord>false</chgRecord>
       </SecDnsExtFields>
       <SecDnsExtFields>
         <keyTag>61424</keyTag>
         <alg>8</alg>
         <digestType>1</digestType>
<digest>57B2F6345C9E6701CCC87A48E5648F305D2CED66</digest>
         <flags>0</flags>
         <protocol>0</protocol>
         <keyAlg>0</keyAlg>
         <pubKey/>
         <maxSigLife>0</maxSigLife>
         <urgent>false</urgent>
         <removeAll>false</removeAll>
         <removeRecord>false</removeRecord>
         <chgRecord>false</chgRecord>
       </SecDnsExtFields>

Has anyone run into this issue before? I suspect I am doing something 
wrong but I am not sure what...

Thanks