[Pdns-dev] implement GSQLBackend::getDirectNSECx

[labs at hosting.de]

Hi Peter,

thanks for getting back to us that quickly.

 > Out of curiosity, why are you signing outside of PowerDNS instead of 
with PowerDNS itself?
 > ...
 > Second, have you looked at AXFRing the zones in from your signing 
solution, instead of mangling a presigned zone until PowerDNS likes it?
 > If you let PowerDNS do the AXFR in, all the throwing away of records 
etc. happens automatically.

As described, we created a signing server only reachable internally for 
security reasons. This means all private keys are stored on this system 
and all signing is done there. Since pdns synthesizes the DNSSEC records 
it is not possible, besides via AXFR, to export and transfer these 
records. Therefore we decided to use LDNS for signing.

 > Are you running into problems with the ‘synthesized’ NSEC(3)s?

Currently we have to create those empty traversals in order to get the 
correct NSEC records synthesized. Since signing with LDNS already gives 
us all necessary NSEC records it would be easier to just use those.

I get the decission to do as much as possible automatically for DNSSEC 
since it is a complex subject. On the other hand it would be nice if 
there would be still the possibility to have more control over the 
process if you want to in case you have a more complex nameserver setup 
in mind.

Best regards,
Sebastian


Am 21.02.2016 09:20, schrieb Peter van Dijk:
> Hello Sebastian,
>
> On 19 Feb 2016, at 17:38, labs at hosting.de wrote:
>
>> we use PowerDNS version 3.4 for our nameserver backend. Recently we 
>> have added a signing server which signs zones with ldns. Ldns creates 
>> both NSEC(3) and NSEC3PARAM records. As PowerDNS synthesizes these 
>> records we have to throw them away and create record ordernames and 
>> domain metadata to add the zone to our nameservers. We couldn't find 
>> much documentation about how to add presigned zones to a PowerDNS 
>> database, so it took a while to get this to work. Now we have a 
>> signing server that is tightly coupled to our nameserver even though 
>> both systems work completely independently.
>
> Out of curiosity, why are you signing outside of PowerDNS instead of 
> with PowerDNS itself?
>
> Second, have you looked at AXFRing the zones in from your signing 
> solution, instead of mangling a presigned zone until PowerDNS likes 
> it? If you let PowerDNS do the AXFR in, all the throwing away of 
> records etc. happens automatically.
>
>> While looking through the PowerDNS code we found the calls to 
>> UeberBackend::getDirectNSECx in PacketHandler::addNSEC and 
>> PacketHandler::addNSEC3 and noticed that UeberBackend::getDirectNSECx 
>> calls DNSBackend::getDirectNSECx for every backend. However, that 
>> method isn't implemented in the GSQLBackend, which we use.
>
> These methods are gone in version 4 - they were only used by the LMDB 
> backend for hacky reasons, and we dropped the LMDB backend in that form.
>
>> What we would like to do is implement GSQLBackend::getDirectNSECx to 
>> fetch NSEC(3) records from the database, if they are stored there, or 
>> else return false.
>
> Are you running into problems with the ‘synthesized’ NSEC(3)s?
>
>> Additionaly we would like to expand the PacketHandler::addNSEC3Param 
>> method to try to fetch the NSEC3PARAM record from the database before 
>> synthesizing one as well.
>>
>> What we would like to know is if you would be interested in those 
>> changes and would be willing to accept a corresponding pull request?
>
> We need to understand what problem is being solved before we’ll 
> consider this added complexity (ignoring, for a moment, that the -x 
> calls are not even present in 4).
>
> Kind regards,