188 lines
9.9 KiB
Plaintext
188 lines
9.9 KiB
Plaintext
$Id: TODO,v 1.1.1.1 1997/04/13 09:06:10 mrg 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--
|