diff options
Diffstat (limited to 'contrib/bind/TODO')
| -rw-r--r-- | contrib/bind/TODO | 187 |
1 files changed, 187 insertions, 0 deletions
diff --git a/contrib/bind/TODO b/contrib/bind/TODO new file mode 100644 index 0000000..5f6a453 --- /dev/null +++ b/contrib/bind/TODO @@ -0,0 +1,187 @@ +$Id: TODO,v 8.3 1995/06/19 08:34:22 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. + +[Mark.Andrews@dms.CSIRO.AU 14dec94]: rfc952/rfc1123 host name compliance: + -> Test domain names to ensure that the name conforms to the form + specified by RFC952 as modified by RFC1123. + -> WARN if the domain name does not meet the conditions set by + rfc952/rfc1123 for the following resource records. + class == C_IN && type == T_A + class == C_IN && type == T_MX + -> REJECT this records on the primary server. + -> CNAME which doesn't match pointing to the above is also + illegal but harder to check. + +[paul@vix.com 30nov94]: cause NOTIFY to track the IETF process for it; + reorder ns_resp() again so that "Notify notimp" causes qdelete() + but the host source address checking and so on is still done. + +[paul@vix.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. + +[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"). + +[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). + +[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 ] + +[paul@vix.com 05jun94]: things i'm expecting to fix someday: + -> finish STATS (b+tree?), remove older A_RR-based tagging + -> (more?) svr4 changes from wisner@well, marc@cam, istewart@datlog + -> switch completely to posix-style signals + -> xfrnets directives should aggregate + -> syntactic sugar to use "mtime" of file as soa serial number + -> better support for "firewalls" (zohar@ibm, minnich@dupont) + -> attributes in TXT RR (cpw@lanl) + -> fix database consistency problems during zone reloads (Bob Heiney) + -> preliminary support for variable width subnet masks + -> failover isn't working very well for hesiod queries (gshapiro) + -> dig needs to be able to turn on RES_INSECURE{1,2} options + -> clean out old RR's that lay within a newly loaded zone file (heiney) + -> automatically refresh root.cache from the root servers periodically + -> Makefiles should use/pass CFLAGS rather than modifying CC + -> use Berkeley DB rather than malloc() for all database ops + -> include files should be generated from templates + -> use nvi-style port/* hierarchy, fewer portability #ifdef's + -> make __res static, add procedural interface to replace "extern"'ing + -> add hesiod/yp capable versions of get{pw,serv,???}by*() + -> add hesiod/yp to get{net,host}by*() + -> do something like solaris' /etc/nsswitch.conf (but in resolv.conf) + -> we should only need one copy of binary->text, text->binary, and + packet marshalling/unmarshalling. add general routines to -lresolv, + and rearrange the code to use them. + -> apps that want to do DNS queries should not have to learn res_query; + a higher level interface should be provided, that has its own cache + and/or shares with the server's DB-based one. + -> implement or integrate the next round of RFC's (coming soon). + +[paul@vix.com 05jun95]: more things i'm expecting to fix someday: + -> add "ndc checkconf" (i.e., "named -v") + +## ++Copyright++ 1993 +## - +## Copyright (c) 1993 +## The 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-- |
