Re: DNSSEC and DLZ

--===============6193586806464866850==
Content-Type: multipart/alternative; boundary=001a114b3d144cb359052838365e

--001a114b3d144cb359052838365e
Content-Type: text/plain; charset=UTF-8

Hi Evan,

On 31 Dec 2015 8:34 p.m., "Evan Hunt" <[email protected]> wrote:
> No, I'm afraid that still wouldn't work.  DLZ databases cannot answer
> DNSSEC queries, except as a back-end server for zone transfers.
>
> To serve DNSSEC, if you're answering a query for a name that doesn't
exist,
> you have to be able to prove that the name doesn't exist.  That involves
> searching backward through the database for the closest previous record,
> and then lookuping the NSEC record that's there, or using deliberately
> obscure cryptographic hashing to find the associated NSEC3 record, and a
> DLZ database can do neither -- the required database primitives simply
> don't exist.

Bother.

>From what I recall of porting the BDBHPT driver to dlopen(), yes what you
say makes a lot of sense.

> (There is a new mechanism called DynDB being introduced in the upcoming
> BIND 9.11 which will be able to answer DNSSEC queries from an external
> database; it was developed by Red Hat as part of their FreeIPA project.
> However, the only DynDB driver that's been written so far is one they
> developed for LDAP.)

I had a quick look through the DynDB and its LDAP driver source last night
- and it looks similar in structure to DLZ but with more supporting calls.

I'd like to have a stab at porting at least one of the DLZ drivers - is
there any reference documentation I can draw upon?

Thanks,
Mark.

--001a114b3d144cb359052838365e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Hi Evan,</p>
<p dir=3D"ltr">On 31 Dec 2015 8:34 p.m., &quot;Evan Hunt&quot; &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br>
&gt; No, I&#39;m afraid that still wouldn&#39;t work.=C2=A0 DLZ databases c=
annot answer<br>
&gt; DNSSEC queries, except as a back-end server for zone transfers.<br>
&gt;<br>
&gt; To serve DNSSEC, if you&#39;re answering a query for a name that doesn=
&#39;t exist,<br>
&gt; you have to be able to prove that the name doesn&#39;t exist.=C2=A0 Th=
at involves<br>
&gt; searching backward through the database for the closest previous recor=
d,<br>
&gt; and then lookuping the NSEC record that&#39;s there, or using delibera=
tely<br>
&gt; obscure cryptographic hashing to find the associated NSEC3 record, and=
 a<br>
&gt; DLZ database can do neither -- the required database primitives simply=
<br>
&gt; don&#39;t exist.</p>
<p dir=3D"ltr">Bother.</p>
<p dir=3D"ltr">From what I recall of porting the BDBHPT driver to dlopen(),=
 yes what you say makes a lot of sense.</p>
<p dir=3D"ltr">&gt; (There is a new mechanism called DynDB being introduced=
 in the upcoming<br>
&gt; BIND 9.11 which will be able to answer DNSSEC queries from an external=
<br>
&gt; database; it was developed by Red Hat as part of their FreeIPA project=
.<br>
&gt; However, the only DynDB driver that&#39;s been written so far is one t=
hey<br>
&gt; developed for LDAP.)</p>
<p dir=3D"ltr">I had a quick look through the DynDB and its LDAP driver sou=
rce last night - and it looks similar in structure to DLZ but with more sup=
porting calls.</p>
<p dir=3D"ltr">I&#39;d like to have a stab at porting at least one of the D=
LZ drivers - is there any reference documentation I can draw upon?</p>
<p dir=3D"ltr">Thanks,<br>
Mark.</p>

--001a114b3d144cb359052838365e--


--===============6193586806464866850==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============6193586806464866850==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Bind-dlz-testers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bind-dlz-testers

--===============6193586806464866850==--