home *** CD-ROM | disk | FTP | other *** search
/ PC-Online 1996 May / PCOnline_05_1996.bin / linux / source / n / bind / bind-4.001 / bind-4~ / bind-4.9.3-BETA9 / TODO < prev   
Text File  |  1994-07-19  |  9KB  |  170 lines

  1. $Id: TODO,v 4.9.1.8 1994/07/19 22:51:24 vixie Exp $
  2.  
  3. Things to do.  Each entry should contain the proposer, date proposed, and an
  4. explaination of what's being proposed.  New ones are added at the bottom.
  5. Note that the author/coordinator of BIND does not neccessarily endorse all
  6. of the proposals listed herein; if you did not get explicit "buy-in" then
  7. your changes may not be accepted even if they appear in proposal form here
  8. in this file.
  9.  
  10. [vixie@vix.com 25apr93]: clean up #ifdef's and portability
  11.     feature #ifdef's should be limited to whole functions, which will be
  12.     called no matter what and would only be non-empty if the feature is
  13.     enabled.  allow feature ifdef's in .h files, though.
  14.  
  15.     portability #ifdef's should be limited to whole functions, too.  add
  16.     a new portability.c module that implements anything which varies from
  17.     system to system.
  18.  
  19.     add a second portability.h-like file that is included _before_ all the
  20.     system includes.  portability.h as it stands is included _after_ all
  21.     system includes, which is convenient for most things but not all.
  22.  
  23. [sater@cs.vu.nl 26apr93]: sortlist improvement
  24.     Improve the code around the sortlist area to better cope with parallel
  25.     networks of different speeds. The -i hack I sent to you could function
  26.     as inspiration only.
  27.  
  28. [kre@munnari.oz.au 26apr93]: add an INN style control interface
  29.     to replace sending signals.  With that expand debugging to
  30.     permit monitoring of actions taken on a single query
  31.     (query through control port, full traced as it occurs)
  32.     or all queries that reference some particular name or
  33.     zone, or which are forwarded, or asked, of some
  34.     particluar server.   Allow reloads & dumps of a single
  35.     zone, rather     than the whole universe.  Allow selective
  36.     cache pruning (to edit away bad data that's been obtained
  37.     from somewhere)
  38.  
  39. [kre@munnari.oz.au 26apr93]: add a syntax to zone files (non rfc
  40.     standard, but I don't care) to permit RR's to age away
  41.     at some particular time, and others to become active at
  42.     some particular time (probably with a syntax something
  43.     like     "<[date]"  or  "@[date]"   preceding, or in the
  44.     former case, replacing, the TTL field of the record).
  45.     Approaching "date" in the "<[date]" case, the TTL's on
  46.     the record would be decreased, so no data cached anywhere    
  47.     will remain valid after "date", after "date", this RR
  48.     would simply be inoperative (essentially identical to
  49.     a comment).  In the "@[date]" case (or perhaps ">[date]"
  50.     for symmetry) the RR would be ignored until "date" at
  51.     which time the "@[date]" field would simply be ignored.
  52.     Both annotations could be used together (with
  53.     appropriate interpretations depending on which date is
  54.     earlier than the other).   Annotations on RR's in a zone
  55.     would cause the SOA parameters to be automatically
  56.     adjusted in zone transfers (and SOA requests) so that
  57.     secondary servers would also hand out the same values
  58.     (dropping the TTL down low as a "<[date]" approaches,
  59.     and forcing a new zone transfer at "date").
  60.  
  61. [steve@uunet.uu.net 26apr93]: TXT RR improvements
  62.     - fix TXT records so that they can deal properly with multiple
  63.     strings (e.g., ``foo    IN    TXT    "aaa" "bbb"'').  This
  64.     results in a fair number of smallish changes throughout the
  65.     code and also throughout various tools (e.g., nslookup).
  66.  
  67. [kyle@uunet.uu.net 16may93]: need an option to die if primary zone file missing
  68.     as of 4.9, a server will not forward a query if it is itself on the
  69.     NS list for the relevant domain.  this means that if a primary server
  70.     cannot load its zone file, it will not be able to answer queries in
  71.     that zone -- it won't even forward them.  this is arguably correct,
  72.     since it prevents bad forwarding loops when two or more servers are
  73.     all unable to load the zone (primary or secondary, with secondary
  74.     failures being the more common).  what is needed is real loop detection
  75.     such that reasonable non-looping queries can be forwarded.  what we're
  76.     likely to actually get is an option that causes named to just syslog
  77.     and die if it can't load a primary zone file.  note that at present,
  78.     named is running somewhat bare-assed since an expired zone in a
  79.     secondary (or missing zone file in a primary) will cause that named
  80.     to return SERVFAIL for all queries to that zone.  if your screwed up
  81.     primary/secondary server is also the forwarding server for a collection
  82.     of hosts, those hosts will get SERVFAIL's back from queries to the
  83.     affected domains, and depending on the age of their resolvers, they
  84.     might not try other servers after they get the first SERVFAIL.
  85.     [ this entry was written by Paul Vixie after getting a problem report
  86.       from Kyle after uu.net disappeared in a brief but ugly way.  --vix ]
  87.  
  88. [paul@vix.com 05jun94]: things i'm expecting to fix someday:
  89.     -> finish STATS (b+tree?), remove older A_RR-based tagging
  90.     -> (more?) svr4 changes from wisner@well, marc@cam, istewart@datlog
  91.     -> switch completely to posix-style signals
  92.     -> xfrnets directives should aggregate
  93.     -> syntactic sugar to use "mtime" of file as soa serial number
  94.     -> better support for "firewalls" (zohar@ibm, minnich@dupont)
  95.     -> attributes in TXT RR (cpw@lanl)
  96.     -> fix database consistency problems during zone reloads (Bob Heiney)
  97.     -> preliminary support for variable width subnet masks
  98.     -> failover isn't working very well for hesiod queries (gshapiro)
  99.     -> dig needs to be able to turn on RES_INSECURE{1,2} options
  100.     -> clean out old RR's that lay within a newly loaded zone file (heiney)
  101.     -> automatically refresh root.cache from the root servers periodically
  102.     -> Makefiles should use/pass CFLAGS rather than modifying CC
  103.     -> use Berkeley DB rather than malloc() for all database ops
  104.     -> include files should be generated from templates
  105.     -> use nvi-style port/* hierarchy, fewer portability #ifdef's
  106.     -> make __res static, add procedural interface to replace "extern"'ing
  107.     -> add hesiod/yp capable versions of get{pw,serv,???}by*()
  108.     -> add hesiod/yp to get{net,host}by*()
  109.     -> do something like solaris' /etc/nsswitch.conf (but in resolv.conf)
  110.     -> we should only need one copy of binary->text, text->binary, and
  111.        packet marshalling/unmarshalling.  add general routines to -lresolv,
  112.        and rearrange the code to use them.
  113.     -> apps that want to do DNS queries should not have to learn res_query;
  114.        a higher level interface should be provided, that has its own cache
  115.        and/or shares with the server's DB-based one.
  116.     -> implement or integrate the next round of RFC's (coming soon).
  117.  
  118. ## ++Copyright++ 1993
  119. ## -
  120. ## Copyright (c) 1993
  121. ##    The Regents of the University of California.  All rights reserved.
  122. ## 
  123. ## Redistribution and use in source and binary forms, with or without
  124. ## modification, are permitted provided that the following conditions
  125. ## are met:
  126. ## 1. Redistributions of source code must retain the above copyright
  127. ##    notice, this list of conditions and the following disclaimer.
  128. ## 2. Redistributions in binary form must reproduce the above copyright
  129. ##    notice, this list of conditions and the following disclaimer in the
  130. ##    documentation and/or other materials provided with the distribution.
  131. ## 3. All advertising materials mentioning features or use of this software
  132. ##    must display the following acknowledgement:
  133. ##     This product includes software developed by the University of
  134. ##     California, Berkeley and its contributors.
  135. ## 4. Neither the name of the University nor the names of its contributors
  136. ##    may be used to endorse or promote products derived from this software
  137. ##    without specific prior written permission.
  138. ## 
  139. ## THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  140. ## ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  141. ## IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  142. ## ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  143. ## FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  144. ## DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  145. ## OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  146. ## HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  147. ## LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  148. ## OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  149. ## SUCH DAMAGE.
  150. ## -
  151. ## Portions Copyright (c) 1993 by Digital Equipment Corporation.
  152. ## 
  153. ## Permission to use, copy, modify, and distribute this software for any
  154. ## purpose with or without fee is hereby granted, provided that the above
  155. ## copyright notice and this permission notice appear in all copies, and that
  156. ## the name of Digital Equipment Corporation not be used in advertising or
  157. ## publicity pertaining to distribution of the document or software without
  158. ## specific, written prior permission.
  159. ## 
  160. ## THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
  161. ## WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
  162. ## OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
  163. ## CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
  164. ## DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
  165. ## PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
  166. ## ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
  167. ## SOFTWARE.
  168. ## -
  169. ## --Copyright--
  170.