+$Id: TODO,v 4.9.1.2 1993/05/17 09:59:01 vixie Exp $
+
+Things to do. Each entry should contain the proposer, date proposed,
+and an explaination of what's being proposed. New ones are added at
+the bottom. Note that the author/coordinator of BIND does not
+neccessarily endorse all of the proposals listed herein; if you did
+not get explicit "buy-in" then your changes may not be accepted even
+if they appear in proposal form here in this file.
+
+[vixie@pa.dec.com 06Jan93]: syntax checking in db_load.c
+ currently there is little or no syntax checking in db_load.c.
+ you can see this in action if you add an HINFO RR with only
+ one word of info -- the second field in the database is trash,
+ and is sent out in zone transfers or responses as trash. such
+ records should be ignored as errors much as "cname and other data"
+ is. (kre@munnari.oz.au comments: This should turn into "rewrite
+ db_load.c" - probably using yacc or something (though that doesn't
+ matter) so that it approximates the syntax its supposed to implement.)
+
+[mark@comp.vuw.ac.nz 26apr93]: support classes other than IN.
+ Allow specification of zones in classes other than "IN" in
+ the named.boot file---allow an optional "/class" on the "primary" and
+ "secondary" directives. Also fix zone transfers so only data in the
+ class requested is transfered.
+
+[vixie@pa.dec.com 25apr93]: clean up debugging
+ replace all "#ifdef DEBUG...fprintf(...)...#endif" with dprintf(...)
+ which would be a macro that only expands to an fprintf() if DEBUG is
+ set. dprintf(x, (args)) with x as the log level. perhaps change log
+ levels to be symbolic, and perhaps make them a mask instead of a limit.
+
+[vixie@pa.dec.com 25apr93]: clean up #ifdef's and portability
+ feature #ifdef's should be limited to whole functions, which will be
+ called no matter what and would only be non-empty if the feature is
+ enabled. allow feature ifdef's in .h files, though.
+
+ portability #ifdef's should be limited to whole functions, too. add
+ a new portability.c module that implements anything which varies from
+ system to system.
+
+ add a second portability.h-like file that is included _before_ all the
+ system includes. portability.h as it stands is included _after_ all
+ system includes, which is convenient for most things but not all.
+
+ add and use function prototypes. make everything static that can be.
+ externs should only be in .h files (add more .h files, per module if
+ needed, to cover these). add "export" keyword (null define) to make
+ it clear which names are exported and which are static. all top-blevel
+ names in a module must be "export" or "static".
+
+[sater@cs.vu.nl 26apr93]: sortlist improvement
+ Improve the code around the sortlist area to better cope with parallel
+ networks of different speeds. The -i hack I sent to you could function
+ as inspiration only.
+
+[kre@munnari.oz.au 26apr93]: add an INN style control interface
+ to replace sending signals. With that expand debugging to
+ permit monitoring of actions taken on a single query
+ (query through control port, full traced as it occurs)
+ or all queries that reference some particular name or
+ zone, or which are forwarded, or asked, of some
+ particluar server. Allow reloads & dumps of a single
+ zone, rather than the whole universe. Allow selective
+ cache pruning (to edit away bad data that's been obtained
+ from somewhere)
+
+[kre@munnari.oz.au 26apr93]: add a syntax to zone files (non rfc
+ standard, but I don't care) to permit RR's to age away
+ at some particular time, and others to become active at
+ some particular time (probably with a syntax something
+ like "<[date]" or "@[date]" preceding, or in the
+ former case, replacing, the TTL field of the record).
+ Approaching "date" in the "<[date]" case, the TTL's on
+ the record would be decreased, so no data cached anywhere
+ will remain valid after "date", after "date", this RR
+ would simply be inoperative (essentially identical to
+ a comment). In the "@[date]" case (or perhaps ">[date]"
+ for symmetry) the RR would be ignored until "date" at
+ which time the "@[date]" field would simply be ignored.
+ Both annotations could be used together (with
+ appropriate interpretations depending on which date is
+ earlier than the other). Annotations on RR's in a zone
+ would cause the SOA parameters to be automatically
+ adjusted in zone transfers (and SOA requests) so that
+ secondary servers would also hand out the same values
+ (dropping the TTL down low as a "<[date]" approaches,
+ and forcing a new zone transfer at "date").
+
+[Paul: I know you said that you'd like to wait for the IETF DNS WG to "bless"
+an official load balancing scheme, but I'll be adding my shuffle A records to
+BIND 4.9 for use here at U-M anyhow. The code mods to existing source files
+are minimal since the bulk of the work is done in a separate .c I added.
+If you don't want SA records to move into 4.9.1 unless they become official,
+please just toss this first entry. --bryan@umich.edu]
+
+[bryan@umich.edu 25apr93]: add "shuffle A" records
+ There are several schemes for adding some kind of load balancing
+ capability to the DNS. Our "Shuffle Address" (SA) records are one
+ stab at this, and since they're in use at U-M, I need to add them
+ so we can use BIND 4.9 here.
+
+[bryan@umich.edu 25apr93]: add AFSDB records
+ AFSDB records were proposed in RFC xxxx. We use them here at the
+ University of Michigan, so I need to add them for our copy of
+ BIND 4.9.
+
+[bryan@umich.edu 25apr93]: small fix to resolver's p_cdname()
+ The current copy of p_cdname() in the resolver does not work
+ for query responses larger than 512 bytes (which can happen when
+ using TCP). A very small modification changes the "sanity check"
+ argument (the second one) to dn_expand() from "msg + 512" to
+ "cp + MAXCDNAME". (This showed up very recently.)
+
+[gshapiro@wpi.wpi.edu and vixie@pa.dec.com 26apr93]: access control
+ "xfrnets" is ok but what we really need is full access control per
+ zone rather than a global list of acceptable client nets. this is
+ especially important if you send /etc/passwd via zone transfer.
+
+[gdmr@dcs.ed.ac.uk 26Apr93]: hesiod support
+ Get Hesiod working properly: add HSprimary and primary/HS, HSsecondary
+ and secondary/HS; patch up inter-class leaks (4.8.3 had LOTS!);
+ add -C class-specifier to named-xfer.
+
+[Aside: I see you have some HS "support" in named-xfer already, but it won't
+work when there are IN- and HS-class zones at the same level in the name tree.
+My fix to 4.8.3 had named pass named-xfer a -C <class-number> option.]
+
+[gdmr@dcs.ed.ac.uk 26Apr93]: SA RR's
+ Add shuffle-address (SA) support. We need this, so I'll attempt to add
+ it in if nobody else does, but it would be better if the original SA
+ author did the work...
+
+[jaffe@noc.rutgers.edu 26apr93]: negative caching
+ Negative caching - I've already implemented this in 4.9<beta> and
+ am willing to send you the code any time you tell me you're ready
+ to accept it. It's basically used to keep track of "unknown" hosts
+ for a short time so that you don't waste time processing a lot of
+ requests for a host you already know doesn't exist. Mostly useful
+ on machines that support large mailing lists...
+
+[postel@isi.edu anant@isi.edu 28apr93]: negative caching
+ Paul:
+ We'ed like to have included in 4.9.1
+ our implemention for negative caching.
+ --jon & Anant.
+
+[steve@uunet.uu.net 26apr93]: TXT RR improvements
+ - fix TXT records so that they can deal properly with multiple
+ strings (e.g., ``foo IN TXT "aaa" "bbb"''). This
+ results in a fair number of smallish changes throughout the
+ code and also throughout various tools (e.g., nslookup).
+
+[steve@uunet.uu.net 26apr93]: X25, ISDN, RT support
+ - add X25, ISDN, and RT records, for sake of completeness (I already
+ have code that should do this, at least for 4.8.3). At least, I
+ figure this should go in unless someone nuked these RR types while
+ I wasn't looking... (-:
+
+[steve@uunet.uu.net 26apr93]: core dump on invalid address formats
+ - dotted quints (A.B.C.D.E) in A records may make named dump core.
+
+[vixie@pa.dec.com 02may93]: better nameserver tracking, plus data tagging
+ Currently every A RR in the online database (cache or zones in
+ memory) has some fields which are used to track attributes of the
+ name server if this A RR happens to be that of a name server. This
+ is neccessary since we need to keep track of nameserver RTT and sort
+ our queries appropriately to try "fast" or "close" nameservers before
+ we try distant or slow ones. However, due to the way C structures
+ work, this information is maintained for other RR types and for A RR's
+ which are not addresses of nameservers. I propose adding a separate
+ database that tracks neighboring nameservers; no field would be needed
+ in a databuf (RR) to point to this since we can search it by address.
+ Multi-homed nameservers (i.e., with nameservers on hosts which have
+ more than one network interface) would be single-datum, multiple-key.
+ Information to be retained about other nameservers would include RTT
+ as well as error statistics, packet statistics, and so on. This
+ database would be dumpable in the same way that the main cache is
+ now dumpable -- that is, using a signal. At some point we can
+ consider adding SNMP query capability to this database. But most
+ importantly, we can keep in each databuf (RR) the source address of
+ the nameserver which sent us the data -- thus allowing the cache
+ dump to include a tag on each RR that says where it came from. This
+ will help a lot in tracking down corrupt data. Other than continuing
+ to manage the source pool and integrate other folks' patches, this
+ feature may be my only contribution to BIND 4.9.1.
+
+[kyle@uunet.uu.net 16may93]: need an option to die if primary zone file missing
+ as of 4.9, a server will not forward a query if it is itself on the
+ NS list for the relevant domain. this means that if a primary server
+ cannot load its zone file, it will not be able to answer queries in
+ that zone -- it won't even forward them. this is arguably correct,
+ since it prevents bad forwarding loops when two or more servers are
+ all unable to load the zone (primary or secondary, with secondary
+ failures being the more common). what is needed is real loop detection
+ such that reasonable non-looping queries can be forwarded. what we're
+ likely to actually get is an option that causes named to just syslog
+ and die if it can't load a primary zone file. note that at present,
+ named is running somewhat bare-assed since an expired zone in a
+ secondary (or missing zone file in a primary) will cause that named
+ to return SERVFAIL for all queries to that zone. if your screwed up
+ primary/secondary server is also the forwarding server for a collection
+ of hosts, those hosts will get SERVFAIL's back from queries to the
+ affected domains, and depending on the age of their resolvers, they
+ might not try other servers after they get the first SERVFAIL.
+ [ this entry was written by Paul Vixie after getting a problem report
+ from Kyle after uu.net disappeared in a brief but ugly way. --vix ]
+
+[vixie@pa.dec.com 16may93]: inet_addr needs to die
+ to be replaced by calls to inet_aton, which doesn't confuse the
+ broadcast address with bad addresses.
+
+## ++Copyright++ 1993
+## -
+## Copyright (c) 1993 Regents of the University of California.
+## All rights reserved.
+##
+## Redistribution and use in source and binary forms, with or without
+## modification, are permitted provided that the following conditions
+## are met:
+## 1. Redistributions of source code must retain the above copyright
+## notice, this list of conditions and the following disclaimer.
+## 2. Redistributions in binary form must reproduce the above copyright
+## notice, this list of conditions and the following disclaimer in the
+## documentation and/or other materials provided with the distribution.
+## 3. All advertising materials mentioning features or use of this software
+## must display the following acknowledgement:
+## This product includes software developed by the University of
+## California, Berkeley and its contributors.
+## 4. Neither the name of the University nor the names of its contributors
+## may be used to endorse or promote products derived from this software
+## without specific prior written permission.
+##
+## THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+## ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+## IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+## ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+## FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+## DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+## OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+## HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+## LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+## OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+## SUCH DAMAGE.
+## -
+## Portions Copyright (c) 1993 by Digital Equipment Corporation.
+##
+## Permission to use, copy, modify, and distribute this software for any
+## purpose with or without fee is hereby granted, provided that the above
+## copyright notice and this permission notice appear in all copies, and that
+## the name of Digital Equipment Corporation not be used in advertising or
+## publicity pertaining to distribution of the document or software without
+## specific, written prior permission.
+##
+## THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+## WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+## OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
+## CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+## DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+## PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+## ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+## SOFTWARE.
+## -
+## --Copyright--