theo writes
>> Are there any plans to incorporate bind-4.9.3 into NetBSD-1.0?  I would
>> be happy to do the necessary work (a simple matter of integrating NetBSD's
>> resolver modifications).
>
>I guess I'll do it, eventually. If you sit down before I do, send the
>diffs to me. But don't bother touching the resolver at all; I'm fairly
>sure that our resolver is in better shape than the standard bind one.

that's as may be now, but may only apply in the short term considering that
the past year has probably been the first time that bind maintenance has
been funded and coherently done. Paul Vixie is also going to be running a
root nameserver in future to broaden the experience base.

wrt to resolver something that may be worth flagging now, though I'm not
sure how many modules get into resolver-level programming:

>i'd like to let everybody know that several changes are coming in the next
>rev or two of BIND:
>
>1. _res will disappear.  all variables that can be set will be set
>   with functional interfaces rather than data interfaces.
>
>2. hesiod will appear.  as will NIS.  fallback methods will be specifiable.
>
>3. get{host,pw,serv,net}by*() will be stubs that talk to a local daemon
>   over a unix-domain socket; that daemon will have the actual DNS resolver
>   and NIS/Hesiod code in it.
>
>i mention this only because the following diff caught my eye.  code like
>this will stop working on the BIND resolver starting RSN (real soon now):
>
>>       register int res_retry = _res.retry;
>>
>> +     if ((_res.options & RES_INIT) == 0 && res_init() == -1)
>> +       return((nsmsg_t *)NULL);
>>   #ifdef DEBUG
>>       if (_res.options & RES_DEBUG)
>>           printf("_resolve: class = %d, type = %d\n", class, type);

now returning traffic back to interesting issues...

Danny Thomas



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