Bind 8.2 Integration

Bind 8.2 Integration

[Andreas Jaeger]

Hi Zack, Mark and all others,

About half a year ago Zack and Mark looked at the integration of the
resolv code from bind 8.2 into glibc.  Since then nothing happened.
Was it just a lack of time or interest or did you encounter any
serious problems?

I'm considering to do the integration myself soonish and would
appreciate any help you can give me.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

Re: Bind 8.2 Integration

[Mark Kettenis]

   From: Andreas Jaeger <aj@suse.de>
   Date: 26 Nov 1999 13:48:12 +0100

   Hi Zack, Mark and all others,

   About half a year ago Zack and Mark looked at the integration of the
   resolv code from bind 8.2 into glibc.  Since then nothing happened.
   Was it just a lack of time or interest or did you encounter any
   serious problems?

At the time there appeared to be some serious problems, since there is
some support for strong cryptography in the BIND 8.2 distrubution.  It
turns out that not all of the cryptography code is needed in the
resolver library.  The idea is that if you want to use secure DNS the
cryptography isn't done in the resolver stub itself, but by a trusted
named.  So it seems that we do not need to provide any strong
cryptography in glibc.

However, the new res_sendsigned/res_nsendsigned interfaces, do use the
HMAC_MD5 algorithm which is integrated in the same framework as the
strong cryptography code.  It is easy to compile the cryptography
code (which lives in `src/lib/dst' in the BIND distribution) such that
it only supports the HMAC_MD5 algorithm but there may be some
problems:

 * The code provides hooks that make it easy to add strong
   encryption.  According to some interpretations of US export laws
   this is just as bad as actually providing the code for strong
   encryption.

 * The MD5 code included in BIND is ripped from Eric Young's SSL
   implementation and the license might not be acceptable.  It should
   not be too difficult to use the MD5 code already present in glibc
   instead.

You'll probably want to have an "official" FSF statement on these
issues before doing any real work.

   I'm considering to do the integration myself soonish and would
   appreciate any help you can give me.

Just ask :)  I did some serious code browsing and even started writing
a free (in the GPL sense) implementation of the DSA algorithm, but
more or less dropped it when I found out that this was not needed for
glibc.

Mark

Re: Bind 8.2 Integration

[Andreas Jaeger]

>>>>> Mark Kettenis writes:

 >    From: Andreas Jaeger <aj@suse.de>
 >    Date: 26 Nov 1999 13:48:12 +0100

 >    Hi Zack, Mark and all others,

 >    About half a year ago Zack and Mark looked at the integration of the
 >    resolv code from bind 8.2 into glibc.  Since then nothing happened.
 >    Was it just a lack of time or interest or did you encounter any
 >    serious problems?

 > At the time there appeared to be some serious problems, since there is
 > some support for strong cryptography in the BIND 8.2 distrubution.  It
 > turns out that not all of the cryptography code is needed in the
 > resolver library.  The idea is that if you want to use secure DNS the
 > cryptography isn't done in the resolver stub itself, but by a trusted
 > named.  So it seems that we do not need to provide any strong
 > cryptography in glibc.

 > However, the new res_sendsigned/res_nsendsigned interfaces, do use the
 > HMAC_MD5 algorithm which is integrated in the same framework as the
 > strong cryptography code.  It is easy to compile the cryptography
 > code (which lives in `src/lib/dst' in the BIND distribution) such that
 > it only supports the HMAC_MD5 algorithm but there may be some
 > problems:

I've avoided the res_sendsigned/res_nsendsigned interfaces completly
(and also the resfindzonecut interface).  This means that the
resulting libresolv can not be used by named, nslookup or dig.  But it
can be used instead of the old libresolv and we can export it.

The big advantage of this version of libresolv are it's
multi-threading features.  We don't have anymore a big lock which
allows only one thread in res_send.

Does any distribution link currently named, dig and nslookup from
bind8 or bind4 against libresolv from glibc?  I don't think so and
therefore we shouldn't have problem with a slightly reduced libresolv.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

Re: Bind 8.2 Integration

[Mark Kettenis]

   From: Andreas Jaeger <aj@suse.de>
   Date: 01 Dec 1999 17:14:52 +0100

   I've avoided the res_sendsigned/res_nsendsigned interfaces completly
   (and also the resfindzonecut interface).  This means that the
   resulting libresolv can not be used by named, nslookup or dig.  But it
   can be used instead of the old libresolv and we can export it.

Although I think that we should try to privide all functions in
<resolv.h> this is probably a good idea for now.  We can always add
those functions when people start compaining.  Removing them would be
a bigger problem.

Mark

Re: Bind 8.2 Integration

[Andreas Jaeger]

>>>>> Mark Kettenis writes:

Mark>    From: Andreas Jaeger <aj@suse.de>
Mark>    Date: 01 Dec 1999 17:14:52 +0100

Mark>    I've avoided the res_sendsigned/res_nsendsigned interfaces completly
Mark>    (and also the resfindzonecut interface).  This means that the
Mark>    resulting libresolv can not be used by named, nslookup or dig.  But it
Mark>    can be used instead of the old libresolv and we can export it.

Mark> Although I think that we should try to privide all functions in
Mark> <resolv.h> this is probably a good idea for now.  We can always add
Mark> those functions when people start compaining.  Removing them would be
Mark> a bigger problem.

I agree - and have another question.  Should we add the interfaces and
structures even if they're unused?  I'm in favor of only adding those
functions and structs that are needed - this way the user will notice
directly what's broken.

Is this ok?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de