mirror of
https://github.com/isc-projects/bind9.git
synced 2026-02-03 20:40:08 -05:00
Serveur DNS
e1747e09e7
grouping closely related statements and then separating them with a
single empty line.
Lines should not be longer than 79 characters, even if it requires
violating the indentation rules to do so. Since ANSI is assumed, the
best way to deal with strings that extend past column 79 is to break
them into two or more sections separated from each other by a newline
and indentation. (w/example)
Note that <isc/lang.h> should be included by any public
header file to get the ISC_LANG_BEGINDECLS and ISC_LANG_ENDDECLS
macros used so the correct name-mangling happens for function
declarations when C++ programs include the file. <isc/lang.h> should
be included for private header files or for public files that do not
declare any functions. (w/example)
Fixed < and > use in sample header file.
The config.h file must never be included by any public header file.
The comma operator should not be used to form compound statements.
(w/example)
Generally speaking, when a control statement (<CODE>if, for</CODE> or
<CODE>while</CODE>) has only a single action associated with it, then no
bracing is used around the statement. Exceptions include when the
compiler would complain about an ambiguous else clause, or when extra
bracing improves the readability (a judgement call biased toward not
having the braces).
Do not put a space after the "sizeof" operator name, and also
parenthesize its argument, as in <CODE>malloc(4 * sizeof(long))</CODE>.
Do not put a space after a cast. (w/example)
<H4>The Ternary Operator</H4> (w/example)
The ?: operator should mostly be avoided. It is tolerated when
deciding what value to pass as a parameter to a function, such as
frequently happens with printf, and also when a simple (non-compound)
value is being used in assignment or as part of a calculation.
In particular, using the ternary operator to specify a return value is
verboten. (Well, Bob didn't tell me *forbidden* when he first said this
to me long ago, but I got the impression he really did not like it.)
Variables should not have their values assigned or changed when being
passed as parameters, except perhaps for the increment and decrement
operators. (This came up when I found something much like this in one
of our files:
malloc(size = 20);
All public interfaces to functions, macros, typedefs, and
variables provided by the library, should use names of the form
{library}_{module}_{what}, such as:
isc_buffer_t /* typedef */
dns_name_setbuffer(name, buffer) /* function */
ISC_LIST_HEAD(list) /* macro */
isc_commandline_argument /* variable */
however, structures which are typedef'd generally have the name of the
typedef sans the final _t:
struct dns_rbtnode {
/* ... members ... */
}
Generally speaking macros are defined with all capital letters, but
this is not universally consistent (eg, numerous isc_buffer_{foo}
macros).
The {module} and {what} segments of the name do not have underscores
separating natural word elements, as demonstrated in
isc_commandline_argument and dns_name_setbuffer above. The {module}
part is usually the same as the basename of the source file, but
sometimes other {module} interfaces appear within one file, such as
dns_label_* interfaces in lib/dns/name.c. However, in the public
libraries the file name must be the same as some module interface
provided by the file; e.g., dns_rbt_* interfaces would not be declared
in a file named redblack.c (in lieu of any other dns_redblack_*
interfaces in the file).
The one notable exception to this naming rule is the interfaces
provided by <isc/util.h>. There's a large caveat associated with the
public description of this file that it is hazardous to use because it
pollutes the general namespace.
<H4>Shared Private Interfaces</H4>
When a module provides an interface for internal use by other modules
in the library, it should use the same naming convention
described for the public interfaces, except {library} and {module}
are separated by a double-underscore. This indicates that the name is
internal, its API is not as formal as the public API, and thus it
might change without any sort of notice.
|
||
|---|---|---|
| bin | ||
| doc | ||
| lib | ||
| make | ||
| util | ||
| .cvsignore | ||
| acconfig.h | ||
| aclocal.m4 | ||
| CHANGES | ||
| config.guess | ||
| config.h.in | ||
| config.h.win32 | ||
| config.status.win32 | ||
| config.sub | ||
| configure | ||
| configure.in | ||
| install-sh | ||
| ltconfig | ||
| ltmain.sh | ||
| Makefile.in | ||
| README | ||
| TODO | ||
| version | ||
BIND 9
BIND version 9 is a major rewrite of nearly all aspects of the
underlying BIND architecture. This re-architecting of BIND was
necessitated by the expected demands of:
- Domain name system growth, particularly in very large
zones such as .COM
- Protocol enhancements necessary to securely query and
update zones
- Protocol enhancements necessary to take advantage of
certain architectural features of IP version 6
These demands implied performance requirements that were not
necessarily easy to attain with the BIND version 8
architecture. In particular, BIND must not only be able to
run on multi-processor multi-threaded systems, but must take
full advantage of the performance enhancements these
architectures can provide. In addition, the underlying data
storage architecture of BIND version 8 does not lend itself to
implementing alternative back end databases, such as would be
desirable for the support of multi-gigabyte zones. As such
zones are easily foreseeable in the relatively near future,
the data storage architecture needed revision. The feature
requirements for BIND version 9 included:
- Scalability
Thread safety
Multi-processor scalability
Support for very large zones
- Security
Support for DNSSEC
Support for TSIG
Auditability (code and operation)
Firewall support (split DNS)
- Portability
- Maintainability
- Protocol Enhancements
IXFR, DDNS, Notify, EDNS0
Improved standards conformance
- Operational enhancements
High availability and reliability
Support for alternative back end databases
- IP version 6 support
IPv6 resource records (A6, DNAME, etc.)
Bitstring labels
APIs
BIND version 9 development has been underwritten by the following
organizations:
Sun Microsystems, Inc.
Hewlett Packard
Compaq Computer Corporation
IBM
Process Software Corporation
Silicon Graphics, Inc.
Network Associates, Inc.
U.S. Defense Information Systems Agency
USENIX Association
Stichting NLnet - NLnet Foundation
BIND 9.0.0b2
BIND 9.0.0b2 is the second public release of BIND 9 code. It will
be most useful to advanced users working with IPv6 or DNSSEC.
BIND 9.0.0b2 is not functionally complete, and is not a release
candidate for BIND 9.0.0. ISC anticipates a number of additional
beta releases between now and May, when BIND 9.0.0 is scheduled to
be released.
ISC does not recommend using BIND 9.0.0b2 for "production"
services.
We hope users of BIND 9.0.0b2 will provide feedback, bug fixes, and
enhancements. If you are not in a position to do so, it would
probably be better to wait until subsequent releases.
There have been many changes since beta 1; the highlights are:
Many more config file options are now implemented. See
doc/misc/options for a summary of the current implementation
status.
Portability improvements. In particular, this beta should work
much better than beta 1 on FreeBSD 3.4.
Bug fixes. Almost all bugs reported against beta 1 have been
fixed.
Some of the more significant items that will be implemented or
enhanced in a future beta are
DNSSEC validation
The server does not currently validate DNSSEC
signatures.
Notify
Notify is not yet implemented.
Selective Forwarding
Documentation
Future releases will contain a lot more documentation,
but a preliminary version of the Administrator's
Reference Manual is in the doc/arm subdirectory.
A detailed CHANGES file like that in BIND 4 and BIND 8
will be provided in future betas.
Building
BIND 9 currently requires a UNIX system with an ANSI C compiler,
basic POSIX support, and a good pthreads implementation.
We've had successful builds and tests on the following systems
AIX 4.3
COMPAQ Tru64 UNIX 4.0D
FreeBSD 3.4-STABLE
HP-UX 11
IRIX64 6.5
NetBSD current (with "unproven" pthreads)
Red Hat Linux 6.0, 6.1, 6.2
Solaris 2.6, 7, 8 (beta)
To build, just
./configure
make
Several environment variables that can be set before running
configure will affect compilation:
CC
The C compiler to use. configure tries to figure
out the right one for supported systems.
CFLAGS
C compiler flags. Defaults to include -g and/or -O2
as supported by the compiler.
STD_CINCLUDES
System header file directories. Can be used to specify
where add-on thread or IPv6 support is, for example.
Defaults to empty string.
STD_CDEFINES
Any additional preprocessor symbols you want defined.
Defaults to empty string.
"make install" will install "named" and the various BIND 9 libraries.
By default, installation is into /usr/local, but this can be changed
with the "--prefix" option when running "configure".
Shared libraries will be built if "--with-libtool" is added to the
"configure" command.
If you're planning on making changes to the BIND 9 source, you
should also "make depend". If you're using Emacs, you might find
"make tags" helpful.
Building with gcc is not supported, unless gcc is the vendor's usual
compiler (e.g. the various BSD systems, Linux).
Parts of the library can be tested by running "make test" from the
bin/tests subdirectory.
Bug Reports and Mailing Lists
Bugs reports should be sent to
bind9-bugs@isc.org
To join the BIND 9 Users mailing list, send mail to
bind9-users-request@isc.org
If you're planning on making changes to the BIND 9 source
code, you might want to join the BIND 9 Workers mailing list.
Send mail to
bind9-workers-request@isc.org
"named" command line options
-c <config_file>
-d <debug_level>
-f Run in the foreground.
-g Run in the foreground and log
to stderr, ignoring any "logging"
statement in in the config file.
-n <number_of_cpus>
-t <directory> Chroot to <directory> before running.
-u <username> Run as user <username> after binding
to privileged ports.
Use of the "-t" option while still running as "root" doesn't
enhance security on most systems. The way chroot() is defined
allows a process with root privileges to escape the chroot jail.
The "-u" option is not currently useful on Linux kernels older
than 2.3.99-pre3. Linux threads are actually processes sharing a
common address space. An unfortunate side effect of this is that
some system calls, e.g. setuid() that in a typical pthreads
environment would affect all threads only affect the calling
thread/process on Linux. The good news is that BIND 9 uses the
Linux kernel's capability mechanism to drop all root powers except
the ability to bind() to a privileged port. 2.3.99-pre3 and later
kernels allow a process to say that its capabilities should be
retained after setuid(). If BIND 9 is compiled with 2.3.99-pre3 or
later kernel .h files, the "-u" option will cause the server to
run with the specified user id, but it will retain the capability
to bind() to privileged ports.
On systems with more than one CPU, the "-n" option should be used
to indicate how many CPUs there are.
Note to Programmers
The APIs for the libraries in BIND 9 are not yet frozen.
We expect the existing library interfaces in the release to be
quite stable, however, and unless we've specifically indicated that
an interface is temporary, we don't anticipate major changes in
future releases.