[Pdns-dev] implement GSQLBackend::getDirectNSECx

[Peter van Dijk]

Hello Sebastian,

On 23 Feb 2016, at 13:18, labs at hosting.de wrote:

> Hello Peter,
>
>> Can you clarify what you mean by empty traversals? What is your full 
>> procedure for serving a lens-signed zone file with PowerDNS today?
>
> following an example of a zone signed by ldns. As you can see, it 
> contains not only RRSIG, but also 3 NSEC3 and the NSEC3PARAM record. 
> In order to publish the zone with pdns we have to remove these 4 
> records from the zone. Then we have to take the content of the 
> NSEC3PARAM record and add it to domainmetadata as a 'NSEC3PARAM' 
> entry, along with a 'PRESIGNED' entry. The zone contains one record at 
> its apex and one in sub2.sub1.dnssec-secured.com, but none in 
> sub1.dnssec-secured.com, so next we have to create a record of type 
> NULL for sub1.dnssec-secured.com, the empty traversal record. After 
> that we have to determine the ordername for the A, NS, SOA and the 
> empty traversal records, and have to remember to set the ordername to 
> NULL in our RRSIG and DNSKEY records (but to an empty string, not 
> NULL, for records on the apex if we sign with NSEC instead of NSEC3)

In theory, at least for non-presigned zones, pdnssec/pdnsutil 
rectify-zone should do all of this - create the NULL entries, set the 
ordernames, etc. I’m not sure you need NULL on the RRSIG and DNSKEY 
records by the way.

In second theory, loading your signed files into the bindbackend may be 
easier than all the database fiddling you are doing.

In practice, loading your signed files into a non-database name server 
like NSD or BIND, and then letting PowerDNS AXFR the zone in, will make 
the database right down to the last detail.

> If instead it would be possible to use the NSEC(3) and NSEC3PARAM 
> records as ldns creates them we wouldn't have to do all this. We could 
> just add the records to our database as they are and ignore the 
> ordername and metadata. This would save us work, would make our system 
> more robust and would be more secure when updating pdns.

Re metadata: yes, NSEC3PARAM and PRESIGNED could be ‘inferred’ from 
zone data. But nothing would save you from having to fill in ordername - 
PowerDNS needs those, no matter how many tweaks we do to accommodate 
your situation.

 From where I’m sitting, you really would be best off if you can AXFR 
the zones into PowerDNS. Maybe we can think about making sure 
‘pdnsutil load-zone’ does all of this correctly, but it would not be 
a big priority for us as the AXFR way already works well.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/