1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
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--
|
