upstream/opnsense-src
1
0
Fork 0
mirror of https://github.com/opnsense/src.git synced 2026-05-28 04:12:45 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

This commit was generated by cvs2svn to compensate for changes in r153816,

Browse source 
which included commits to RCS files with non-trunk default branches.
This commit is contained in:
Doug Barton 2005-12-29 04:22:58 +00:00
commit 51396b745e
284 changed files with 66097 additions and 38577 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

257
contrib/bind9/CHANGES
View file

@ -1,4 +1,261 @@
--- 9.3.2 released ---
--- 9.3.2rc1 released ---
1936. [bug] The validator could leak memory. [RT #15544]
1932. [bug] hpux: LDFLAGS was getting corrupted. [RT #15530]
--- 9.3.2b2 released ---
1930. [port] HPUX: ia64 support. [RT #15473]
1929. [port] FreeBSD: extend use of PTHREAD_SCOPE_SYSTEM.
1926. [bug] The Windows installer did not check for empty
passwords. BINDinstall was being installed in
the wrong place. [RT #15483]
1925. [port] All outer level AC_TRY_RUNs need cross compiling
defaults. [RT #15469]
1924. [port] libbind: hpux ia64 support. [RT #15473]
1923. [bug] ns_client_detach() called too early. [RT #15499]
--- 9.3.2b1 released ---
1917. [doc] funcsynopsisinfo wasn't being treated as verbatim
when generating man pages. [RT #15385]
1915. [bug] dig +ndots was broken. [RT #15215]
1914. [protocol] DS is required to accept mnemonic algorithms
(RFC 4034). Still emit numeric algorithms for
compatability with RFC 3658. [RT #15354]
1911. [bug] Update windows socket code. [RT #14965]
1910. [bug] dig's +sigchase code overhauled. [RT #14933]
1909. [bug] The DLV code has been re-worked to make no longer
query order sensitive. [RT #14933]
1905. [bug] Strings returned from cfg_obj_asstring() should be
treated as read-only. [RT #15256]
1901. [cleanup] Don't add DNSKEY records to the additional section.
1900. [bug] ixfr-from-differences failed to ensure that the
serial number increased. [RT #15036]
1896. [bug] Extend ISC_SOCKADDR_FORMATSIZE and
ISC_NETADDR_FORMATSIZE to allow for scope details.
1894. [bug] Recursive clients soft quota support wasn't working
as expected. [RT #15103]
1893. [bug] A escaped character is, potentially, converted to
the output character set too early. [RT #14666]
1892. [port] Use uintptr_t if available. [RT #14606]
1889. [port] sunos: non blocking i/o support. [RT #14951]
1887. [bug] The cache could delete expired records too fast for
clients with a virtual time in the past. [RT #14991]
1886. [bug] fctx_create() could return success even though it
failed. [RT #14993]
1884. [cleanup] dighost.c: move external declarations into <dig/dig.h>.
1883. [bug] dnssec-signzone, dnssec-keygen: handle negative debug
levels. [RT #14962]
1881. [func] Add a system test for named-checkconf. [RT #14931]
1877. [bug] Fix unreasonably low quantum on call to
dns_rbt_destroy2(). Remove unnecessay unhash_node()
call. [RT #14919]
1875. [bug] process_dhtkey() was using the wrong memory context
to free some memory. [RT #14890]
1874. [port] sunos: portability fixes. [RT #14814]
1873. [port] win32: isc__errno2result() now reports its caller.
[RT #13753]
1872. [port] win32: Handle ERROR_NETNAME_DELETED. [RT #13753]
1867. [bug] It was possible to trigger a INSIST in
dlv_validatezonekey(). [RT #14846]
1866. [bug] resolv.conf parse errors were being ignored by
dig/host/nslookup. [RT #14841]
1865. [bug] Silently ignore nameservers in /etc/resolv.conf with
bad addresses. [RT #14841]
1864. [bug] Don't try the alternative transfer source if you
got a answer / transfer with the main source
address. [RT #14802]
1863. [bug] rrset-order "fixed" error messages not complete.
1861. [bug] dig could trigger a INSIST on certain malformed
responses. [RT #14801]
1860. [port] solaris 2.8: hack_shutup_pthreadmutexinit was
incorrectly set. [RT #14775]
1858. [bug] The flush-zones-on-shutdown option wasn't being
parsed. [RT #14686]
1857. [bug] named could trigger a INSIST() if reconfigured /
reloaded too fast. [RT #14673]
1856. [doc] Switch Docbook toolchain from DSSSL to XSL.
[RT #11398]
1855. [bug] ixfr-from-differences was failing to detect changes
of ttl due to dns_diff_subtract() was ignoring the ttl
of records. [RT #14616]
1854. [bug] lwres also needs to know the print format for
(long long). [RT #13754]
1853. [bug] Rework how DLV interacts with proveunsecure().
[RT #13605]
1852. [cleanup] Remove last vestiges of dnssec-signkey and
dnssec-makekeyset (removed from Makefile years ago).
1850. [bug] Memory leak in lwres_getipnodebyaddr(). [RT #14591]
1849. [doc] All forms of the man pages (docbook, man, html) should
have consistant copyright dates.
1848. [bug] Improve SMF integration. [RT #13238]
1847. [bug] isc_ondestroy_init() is called too late in
dns_rbtdb_create()/dns_rbtdb64_create().
[RT #13661]
1846. [contrib] query-loc-0.3.0 from Stephane Bortzmeyer
<bortzmeyer@nic.fr>.
1845. [bug] Improve error reporting to distingish between
accept()/fcntl() and socket()/fcntl() errors.
[RT #13745]
1844. [bug] inet_pton() accepted more that 4 hexadecimal digits
for each 16 bit piece of the IPv6 address. The text
representation of a IPv6 address has been tighted
to disallow this (draft-ietf-ipv6-addr-arch-v4-02.txt).
[RT #5662]
1843. [cleanup] CINCLUDES takes precedence over CFLAGS. This helps
when CFLAGS contains "-I /usr/local/include"
resulting in old header files being used.
1842. [port] cmsg_len() could produce incorrect results on
some platform. [RT #13744]
1841. [bug] "dig +nssearch" now makes a recursive query to
find the list of nameservers to query. [RT #13694]
1839. [bug] <isc/hash.h> was not being installed.
1838. [cleanup] Don't allow Linux capabilities to be inherited.
[RT #13707]
1837. [bug] Compile time option ISC_FACILITY was not effective
for 'named -u <user>'. [RT #13714]
1836. [cleanup] Silence compiler warnings in hash_test.c.
1835. [bug] Update dnssec-signzone's usage message. [RT #13657]
1834. [bug] Bad memset in rdata_test.c. [RT #13658]
1833. [bug] Race condition in isc_mutex_lock_profile(). [RT #13660]
1832. [bug] named fails to return BADKEY on unknown TSIG algorithm.
[RT #13620]
1831. [doc] Update named-checkzone documentation. [RT#13604]
1830. [bug] adb lame cache has sence of test reversed. [RT #13600]
1829. [bug] win32: "pid-file none;" broken. [RT #13563]
1828. [bug] isc_rwlock_init() failed to properly cleanup if it
encountered a error. [RT #13549]
1827. [bug] host: update usage message for '-a'. [RT #37116]
1826. [bug] Missing DESTROYLOCK() in isc_mem_createx() on out
of memory error. [RT #13537]
1825. [bug] Missing UNLOCK() on out of memory error from in
rbtdb.c:subtractrdataset(). [RT #13519]
1824. [bug] Memory leak on dns_zone_setdbtype() failure.
[RT #13510]
1823. [bug] Wrong macro used to check for point to point interface.
[RT#13418]
1822. [bug] check-names test for RT was reversed. [RT #13382]
1821. [doc] acls definitions are no longer required to be
in named.conf prior to reference. They can be
defined after being referenced.
1820. [bug] Gracefully handle acl loops. [RT #13659]
1819. [bug] The validator needed to check both the algorithm and
digest types of the DS to determine if it could be
used to introduce a secure zone. [RT #13593]
1816. [port] UnixWare: failed to compile lib/isc/unix/net.c.
[RT #13597]
1815. [bug] nsupdate triggered a REQUIRE if the server was set
without also setting the zone and it encountered
a CNAME and was using TSIG. [RT #13086]
1810. [bug] configure, lib/bind/configure make different default
decisions about whether to do a threaded build.
[RT #13212]
1809. [bug] "make distclean" failed for libbind if the platform
is not supported.
1807. [bug] When forwarding (forward only) set the active domain
from the forward zone name. [RT #13526]
1804. [bug] Ensure that if we are queried for glue that it fits
in the additional section or TC is set to tell the
client to retry using TCP. [RT #10114]
1803. [bug] dnssec-signzone sometimes failed to remove old
RRSIGs. [RT #13483]
1802. [bug] Handle connection resets better. [RT #11280]
1799. [bug] 'rndc flushname' failed to flush negative cache
entries. [RT #13438]
1795. [bug] "rndc dumpdb" was not fully documented. Minor
formating issues with "rndc dumpdb -all". [RT #13396]
1791. [bug] 'host -t a' still printed out AAAA and MX records.
[RT #13230]
--- 9.3.1 released ---
1818. [bug] 'named-checkconf -z' triggered an INSIST. [RT #13599]

731
contrib/bind9/FAQ
View file

@ -1,470 +1,525 @@
Frequently Asked Questions about BIND 9
-------------------------------------------------------------------------------
Q: Why doesn't -u work on Linux 2.2.x when I build with --enable-threads?
A: Linux threads do not fully implement the Posix threads (pthreads) standard.
In particular, setuid() operates only on the current thread, not the full
process. Because of this limitation, BIND 9 cannot use setuid() on Linux as it
can on all other supported platforms. setuid() cannot be called before
creating threads, since the server does not start listening on reserved ports
until after threads have started.
In particular, setuid() operates only on the current thread, not the full
process. Because of this limitation, BIND 9 cannot use setuid() on Linux as
it can on all other supported platforms. setuid() cannot be called before
creating threads, since the server does not start listening on reserved
ports until after threads have started.
In the 2.2.18 or 2.3.99-pre3 and newer kernels, the ability to preserve
capabilities across a setuid() call is present. This allows BIND 9 to call
setuid() early, while retaining the ability to bind reserved ports. This is
a Linux-specific hack.
In the 2.2.18 or 2.3.99-pre3 and newer kernels, the ability to preserve
capabilities across a setuid() call is present. This allows BIND 9 to call
setuid() early, while retaining the ability to bind reserved ports. This is
a Linux-specific hack.
On a 2.2 kernel, BIND 9 does drop many root privileges, so it should be less
of a security risk than a root process that has not dropped privileges.
On a 2.2 kernel, BIND 9 does drop many root privileges, so it should be less
of a security risk than a root process that has not dropped privileges.
If Linux threads ever work correctly, this restriction will go away.
If Linux threads ever work correctly, this restriction will go away.
Configuring BIND9 with the --disable-threads option (the default) causes a
non-threaded version to be built, which will allow -u to be used.
Configuring BIND9 with the --disable-threads option (the default) causes a
non-threaded version to be built, which will allow -u to be used.
Q: Why does named log the warning message "no TTL specified - using SOA MINTTL
instead"?
Q: Why does named log the warning message "no TTL specified - using SOA
MINTTL instead"?
A: Your zone file is illegal according to RFC1035. It must either
have a line like
A: Your zone file is illegal according to RFC1035. It must either have a line
like:
$TTL 86400
at the beginning, or the first record in it must have a TTL field,
like the "84600" in this example:
at the beginning, or the first record in it must have a TTL field, like the
"84600" in this example:
example.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 )
Q: Why do I see 5 (or more) copies of named on Linux?
A: Linux threads each show up as a process under ps. The approximate
number of threads running is n+4, where n is the number of CPUs. Note that
the amount of memory used is not cumulative; if each process is using 10M of
memory, only a total of 10M is used.
A: Linux threads each show up as a process under ps. The approximate number of
threads running is n+4, where n is the number of CPUs. Note that the amount
of memory used is not cumulative; if each process is using 10M of memory,
only a total of 10M is used.
Q: Why does BIND 9 log "permission denied" errors accessing its configuration
files or zones on my Linux system even though it is running as root?
Q: Why does BIND 9 log "permission denied" errors accessing its
configuration files or zones on my Linux system even though it is running
as root?
A: On Linux, BIND 9 drops most of its root privileges on startup.
This including the privilege to open files owned by other users.
Therefore, if the server is running as root, the configuration files
and zone files should also be owned by root.
A: On Linux, BIND 9 drops most of its root privileges on startup. This
including the privilege to open files owned by other users. Therefore, if
the server is running as root, the configuration files and zone files should
also be owned by root.
Q: Why do I get errors like "dns_zone_load: zone foo/IN: loading master file
bar: ran out of space"
A: This is often caused by TXT records with missing close quotes. Check that
all TXT records containing quoted strings have both open and close quotes.
bar: ran out of space"?
A: This is often caused by TXT records with missing close quotes. Check that
all TXT records containing quoted strings have both open and close quotes.
Q: How do I produce a usable core file from a multithreaded named on Linux?
A: If the Linux kernel is 2.4.7 or newer, multithreaded core dumps
are usable (that is, the correct thread is dumped). Otherwise, if using
a 2.2 kernel, apply the kernel patch found in contrib/linux/coredump-patch
and rebuild the kernel. This patch will cause multithreaded programs to dump
the correct thread.
A: If the Linux kernel is 2.4.7 or newer, multithreaded core dumps are usable
(that is, the correct thread is dumped). Otherwise, if using a 2.2 kernel,
apply the kernel patch found in contrib/linux/coredump-patch and rebuild the
kernel. This patch will cause multithreaded programs to dump the correct
thread.
Q: How do I restrict people from looking up the server version?
A: Put a "version" option containing something other than the real
version in the "options" section of named.conf. Note doing this will
not prevent attacks and may impede people trying to diagnose problems
with your server. Also it is possible to "fingerprint" nameservers to
determine their version.
A: Put a "version" option containing something other than the real version in
the "options" section of named.conf. Note doing this will not prevent
attacks and may impede people trying to diagnose problems with your server.
Also it is possible to "fingerprint" nameservers to determine their version.
Q: How do I restrict only remote users from looking up the server version?
Q: How do I restrict only remote users from looking up the server
version?
A: The following view statement will intercept lookups as the internal
view that holds the version information will be matched last. The
caveats of the previous answer still apply, of course.
view "chaos" chaos {
match-clients { <those to be refused>; };
allow-query { none; };
zone "." {
type hint;
file "/dev/null"; // or any empty file
};
};
A: The following view statement will intercept lookups as the internal view
that holds the version information will be matched last. The caveats of the
previous answer still apply, of course.
view "chaos" chaos {
match-clients { <those to be refused>; };
allow-query { none; };
zone "." {
type hint;
file "/dev/null"; // or any empty file
};
};
Q: What do "no source of entropy found" or "could not open entropy source foo"
mean?
mean?
A: The server requires a source of entropy to perform certain operations,
mostly DNSSEC related. These messages indicate that you have no source
of entropy. On systems with /dev/random or an equivalent, it is used by
default. A source of entropy can also be defined using the random-device
option in named.conf.
mostly DNSSEC related. These messages indicate that you have no source of
entropy. On systems with /dev/random or an equivalent, it is used by
default. A source of entropy can also be defined using the random-device
option in named.conf.
Q: I installed BIND 9 and restarted named, but it's still BIND 8. Why?
Q: I installed BIND 9 and restarted named, but it's still BIND 8. Why?
A: BIND 9 is installed under /usr/local by default. BIND 8 is often installed
under /usr. Check that the correct named is running.
A: BIND 9 is installed under /usr/local by default. BIND 8 is often
installed under /usr. Check that the correct named is running.
Q: I'm trying to use TSIG to authenticate dynamic updates or zone transfers.
I'm sure I have the keys set up correctly, but the server is rejecting the
TSIG. Why?
A: This may be a clock skew problem. Check that the the clocks on the client
and server are properly synchronised (e.g., using ntp).
Q: I'm trying to use TSIG to authenticate dynamic updates or zone
transfers. I'm sure I have the keys set up correctly, but the server
is rejecting the TSIG. Why?
Q: I'm trying to compile BIND 9, and "make" is failing due to files not being
found. Why?
A: This may be a clock skew problem. Check that the the clocks on
the client and server are properly synchronized (e.g., using ntp).
A: Using a parallel or distributed "make" to build BIND 9 is not supported, and
doesn't work. If you are using one of these, use normal make or gmake
instead.
Q: I have a BIND 9 master and a BIND 8.2.3 slave, and the master is logging
error messages like "notify to 10.0.0.1#53 failed: unexpected end of input".
What's wrong?
Q: I'm trying to compile BIND 9, and "make" is failing due to files not
being found. Why?
A: This error message is caused by a known bug in BIND 8.2.3 and is fixed in
BIND 8.2.4. It can be safely ignored - the notify has been acted on by the
slave despite the error message.
A: Using a parallel or distributed "make" to build BIND 9 is not
supported, and doesn't work. If you are using one of these, use
normal make or gmake instead.
Q: I keep getting log messages like the following. Why?
Dec 4 23:47:59 client 10.0.0.1#1355: updating zone 'example.com/IN': update
failed: 'RRset exists (value dependent)' prerequisite not satisfied
(NXRRSET)
Q: I have a BIND 9 master and a BIND 8.2.3 slave, and the master is
logging error messages like "notify to 10.0.0.1#53 failed: unexpected
end of input". What's wrong?
A: DNS updates allow the update request to test to see if certain conditions
are met prior to proceeding with the update. The message above is saying
that conditions were not met and the update is not proceeding. See doc/rfc/
rfc2136.txt for more details on prerequisites.
A: This error message is caused by a known bug in BIND 8.2.3 and is fixed
in BIND 8.2.4. It can be safely ignored - the notify has been acted on by
the slave despite the error message.
Q: I keep getting log messages like the following. Why?
Dec 4 23:47:59 client 10.0.0.1#1355: updating zone 'example.com/IN':
update failed: 'RRset exists (value dependent)' prerequisite not
satisfied (NXRRSET)
A: DNS updates allow the update request to test to see if certain
conditions are met prior to proceeding with the update. The message
above is saying that conditions were not met and the update is not
proceeding. See doc/rfc/rfc2136.txt for more details on prerequisites.
Q: I keep getting log messages like the following. Why?
Q: I keep getting log messages like the following. Why?
Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied
A: Someone is trying to update your DNS data using the RFC2136 Dynamic
Update protocol. Windows 2000 machines have a habit of sending dynamic
update requests to DNS servers without being specifically configured to
do so. If the update requests are coming from a Windows 2000 machine,
see <http://support.microsoft.com/support/kb/articles/q246/8/04.asp>
for information about how to turn them off.
A: Someone is trying to update your DNS data using the RFC2136 Dynamic Update
protocol. Windows 2000 machines have a habit of sending dynamic update
requests to DNS servers without being specifically configured to do so. If
the update requests are coming from a Windows 2000 machine, see http://
support.microsoft.com/support/kb/articles/q246/8/04.asp for information
about how to turn them off.
Q: I see a log message like the following. Why?
Q: I see a log message like the following. Why?
couldn't open pid file '/var/run/named.pid': Permission denied
A: You are most likely running named as a non-root user, and that user
does not have permission to write in /var/run. The common ways of
fixing this are to create a /var/run/named directory owned by the named
user and set pid-file to "/var/run/named/named.pid", or set
pid-file to "named.pid", which will put the file in the directory
specified by the directory option (which, in this case, must be writable
by the named user).
A: You are most likely running named as a non-root user, and that user does not
have permission to write in /var/run. The common ways of fixing this are to
create a /var/run/named directory owned by the named user and set pid-file
to "/var/run/named/named.pid", or set pid-file to "named.pid", which will
put the file in the directory specified by the directory option (which, in
this case, must be writable by the named user).
Q: When I do a "dig . ns", many of the A records for the root servers are
missing. Why?
Q: When I do a "dig . ns", many of the A records for the root
servers are missing. Why?
A: This is normal and harmless. It is a somewhat confusing side effect of the
way BIND 9 does RFC2181 trust ranking and of the efforts BIND 9 makes to
avoid promoting glue into answers.
A: This is normal and harmless. It is a somewhat confusing side effect
of the way BIND 9 does RFC2181 trust ranking and of the efforts BIND 9
makes to avoid promoting glue into answers.
When BIND 9 first starts up and primes its cache, it receives the root
server addresses as additional data in an authoritative response from a root
server, and these records are eligible for inclusion as additional data in
responses. Subsequently it receives a subset of the root server addresses as
additional data in a non-authoritative (referral) response from a root
server. This causes the addresses to now be considered non-authoritative
(glue) data, which is not eligible for inclusion in responses.
When BIND 9 first starts up and primes its cache, it receives the root
server addresses as additional data in an authoritative response from
a root server, and these records are eligible for inclusion as
additional data in responses. Subsequently it receives a subset of
the root server addresses as additional data in a non-authoritative
(referral) response from a root server. This causes the addresses to
now be considered non-authoritative (glue) data, which is not eligible
for inclusion in responses.
The server does have a complete set of root server addresses cached at all
times, it just may not include all of them as additional data, depending on
whether they were last received as answers or as glue. You can always look
up the addresses with explicit queries like "dig a.root-servers.net A".
The server does have a complete set of root server addresses cached
at all times, it just may not include all of them as additional data,
depending on whether they were last received as answers or as glue.
You can always look up the addresses with explicit queries like
"dig a.root-servers.net A".
Q: Zone transfers from my BIND 9 master to my Windows 2000 slave
fail. Why?
A: This may be caused by a bug in the Windows 2000 DNS server where
DNS messages larger than 16K are not handled properly. This can be
worked around by setting the option "transfer-format one-answer;".
Also check whether your zone contains domain names with embedded
spaces or other special characters, like "John\032Doe\213s\032Computer",
since such names have been known to cause Windows 2000 slaves to
incorrectly reject the zone.
Q: Zone transfers from my BIND 9 master to my Windows 2000 slave fail. Why?
A: This may be caused by a bug in the Windows 2000 DNS server where DNS
messages larger than 16K are not handled properly. This can be worked around
by setting the option "transfer-format one-answer;". Also check whether your
zone contains domain names with embedded spaces or other special characters,
like "John\032Doe\213s\032Computer", since such names have been known to
cause Windows 2000 slaves to incorrectly reject the zone.
Q: Why don't my zones reload when I do an "rndc reload" or SIGHUP?
A: A zone can be updated either by editing zone files and reloading
the server or by dynamic update, but not both. If you have enabled
dynamic update for a zone using the "allow-update" option, you are not
supposed to edit the zone file by hand, and the server will not
attempt to reload it.
A: A zone can be updated either by editing zone files and reloading the server
or by dynamic update, but not both. If you have enabled dynamic update for a
zone using the "allow-update" option, you are not supposed to edit the zone
file by hand, and the server will not attempt to reload it.
Q: I can query the nameserver from the nameserver but not from other machines.
Why?
Q: I can query the nameserver from the nameserver but not from other
machines. Why?
A: This is usually the result of the firewall configuration stopping the
queries and / or the replies.
A: This is usually the result of the firewall configuration stopping
the queries and / or the replies.
Q: How can I make a server a slave for both an internal and an external view at
the same time? When I tried, both views on the slave were transferred from
the same view on the master.
A: You will need to give the master and slave multiple IP addresses and use
those to make sure you reach the correct view on the other machine.
Q: How can I make a server a slave for both an internal and
an external view at the same time? When I tried, both views
on the slave were transferred from the same view on the master.
Master: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias)
internal:
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
notify-source 10.0.1.1;
transfer-source 10.0.1.1;
query-source address 10.0.1.1;
external:
match-clients { any; };
recursion no; // don't offer recursion to the world
notify-source 10.0.1.2;
transfer-source 10.0.1.2;
query-source address 10.0.1.2;
A: You will need to give the master and slave multiple IP addresses and
use those to make sure you reach the correct view on the other machine.
Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
internal:
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
notify-source 10.0.1.3;
transfer-source 10.0.1.3;
query-source address 10.0.1.3;
external:
match-clients { any; };
recursion no; // don't offer recursion to the world
notify-source 10.0.1.4;
transfer-source 10.0.1.4;
query-source address 10.0.1.4;
e.g.
Master: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias)
internal:
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
notify-source 10.0.1.1;
transfer-source 10.0.1.1;
query-source address 10.0.1.1;
external:
match-clients { any; };
recursion no; // don't offer recursion to the world
notify-source 10.0.1.2;
transfer-source 10.0.1.2;
query-source address 10.0.1.2;
You put the external address on the alias so that all the other dns clients
on these boxes see the internal view by default.
Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
internal:
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
notify-source 10.0.1.3;
transfer-source 10.0.1.3;
query-source address 10.0.1.3;
external:
match-clients { any; };
recursion no; // don't offer recursion to the world
notify-source 10.0.1.4;
transfer-source 10.0.1.4;
query-source address 10.0.1.4;
A: BIND 9.3 and later: Use TSIG to select the appropriate view.
You put the external address on the alias so that all the other
dns clients on these boxes see the internal view by default.
Master 10.0.1.1:
key "external" {
algorithm hmac-md5;
secret "xxxxxxxx";
};
view "internal" {
match-clients { !key external; 10.0.1/24; };
...
};
view "external" {
match-clients { key external; any; };
server 10.0.0.2 { keys external; };
recursion no;
...
};
A: (BIND 9.3 and later) Use TSIG to select the appropriate view.
Slave 10.0.1.2:
key "external" {
algorithm hmac-md5;
secret "xxxxxxxx";
};
view "internal" {
match-clients { !key external; 10.0.1/24; };
...
};
view "external" {
match-clients { key external; any; };
server 10.0.0.1 { keys external; };
recursion no;
...
};
Master 10.0.1.1:
key "external" {
algorithm hmac-md5;
secret "xxxxxxxx";
};
view "internal" {
match-clients { !key external; 10.0.1/24; };
...
};
view "external" {
match-clients { key external; any; };
server 10.0.0.2 { keys external; };
recursion no;
...
};
Q: I have FreeBSD 4.x and "rndc-confgen -a" just sits there.
Slave 10.0.1.2:
key "external" {
algorithm hmac-md5;
secret "xxxxxxxx";
};
view "internal" {
match-clients { !key external; 10.0.1/24; };
};
view "external" {
match-clients { key external; any; };
server 10.0.0.1 { keys external; };
recursion no;
...
};
A: /dev/random is not configured. Use rndcontrol(8) to tell the kernel to use
certain interrupts as a source of random events. You can make this permanent
by setting rand_irqs in /etc/rc.conf.
/etc/rc.conf
rand_irqs="3 14 15"
Q: I have Freebsd 4.x and "rndc-confgen -a" just sits there.
A: /dev/random is not configured. Use rndcontrol(8) to tell the kernel
to use certain interrupts as a source of random events. You can make this
permanent by setting rand_irqs in /etc/rc.conf.
e.g.
/etc/rc.conf
rand_irqs="3 14 15"
See also http://people.freebsd.org/~dougb/randomness.html
See also http://people.freebsd.org/~dougb/randomness.html
Q: Why is named listening on UDP port other than 53?
A: Named uses a system selected port to make queries of other nameservers.
This behaviour can be overridden by using query-source to lock down the
port and/or address. See also notify-source and transfer-source.
A: Named uses a system selected port to make queries of other nameservers. This
behaviour can be overridden by using query-source to lock down the port and/
or address. See also notify-source and transfer-source.
Q: I get error messages like "multiple RRs of singleton type" and "CNAME and
other data" when transferring a zone. What does this mean?
Q: I get error messages like "multiple RRs of singleton type" and
"CNAME and other data" when transferring a zone. What does this mean?
A: These indicate a malformed master zone. You can identify the exact records
involved by transferring the zone using dig then running named-checkzone on
it.
A: These indicate a malformed master zone. You can identify the
exact records involved by transferring the zone using dig then
running named-checkzone on it.
dig axfr example.com @master-server > tmp
named-checkzone example.com tmp
e.g.
dig axfr example.com @master-server > tmp
named-checkzone example.com tmp
A CNAME record cannot exist with the same name as another record except for
the DNSSEC records which prove its existance (NSEC).
RFC 1034, Section 3.6.2: "If a CNAME RR is present at a node, no other data
should be present; this ensures that the data for a canonical name and its
aliases cannot be different. This rule also insures that a cached CNAME can
be used without checking with an authoritative server for other RR types."
Q: I get error messages like "named.conf:99: unexpected end of input" where
99 is the last line of named.conf.
Q: I get error messages like "named.conf:99: unexpected end of input" where 99
is the last line of named.conf.
A: Some text editors (notepad and wordpad) fail to put a line termination
indication (e.g. CR/LF) on the last line of a text file. This can be fixed
by "adding" a blank line to the end of the file. Named expects to see EOF
immediately after EOL and treats text files where this is not met as truncated.
A: Some text editors (notepad and wordpad) fail to put a line title indication
(e.g. CR/LF) on the last line of a text file. This can be fixed by "adding"
a blank line to the end of the file. Named expects to see EOF immediately
after EOL and treats text files where this is not met as truncated.
Q: I get warning messages like "zone example.com/IN: refresh: failure trying master
1.2.3.4#53: timed out".
Q: I get warning messages like "zone example.com/IN: refresh: failure trying
master 1.2.3.4#53: timed out".
A: Check that you can make UDP queries from the slave to the master
dig +norec example.com soa @1.2.3.4
dig +norec example.com soa @1.2.3.4
A: You could be generating queries faster than the slave can cope with. Lower
the serial query rate.
You could be generating queries faster than the slave can cope with. Lower
the serial query rate.
serial-query-rate 5; // default 20
serial-query-rate 5; // default 20
Q: How do I share a dynamic zone between multiple views?
A: You choose one view to be master and the second a slave and transfer
the zone between views.
A: You choose one view to be master and the second a slave and transfer the
zone between views.
Master 10.0.1.1:
key "external" {
algorithm hmac-md5;
secret "xxxxxxxx";
};
Master 10.0.1.1:
key "external" {
algorithm hmac-md5;
secret "xxxxxxxx";
};
key "mykey" {
algorithm hmac-md5;
secret "yyyyyyyy";
};
key "mykey" {
algorithm hmac-md5;
secret "yyyyyyyy";
};
view "internal" {
match-clients { !external; 10.0.1/24; };
server 10.0.1.1 {
/* Deliver notify messages to external view. */
keys { external; };
};
zone "example.com" {
type master;
file "internal/example.db";
allow-update { key mykey; };
notify-also { 10.0.1.1; };
};
};
view "internal" {
match-clients { !external; 10.0.1/24; };
server 10.0.1.1 {
/* Deliver notify messages to external view. */
keys { external; };
};
zone "example.com" {
type master;
file "internal/example.db";
allow-update { key mykey; };
notify-also { 10.0.1.1; };
};
};
view "external" {
match-clients { external; any; };
zone "example.com" {
type slave;
file "external/example.db";
masters { 10.0.1.1; };
transfer-source { 10.0.1.1; };
// allow-update-forwarding { any; };
// allow-notify { ... };
};
};
view "external" {
match-clients { external; any; };
zone "example.com" {
type slave;
file "external/example.db";
masters { 10.0.1.1; };
transfer-source { 10.0.1.1; };
// allow-update-forwarding { any; };
// allow-notify { ... };
};
};
Q: I get a error message like "zone wireless.ietf56.ietf.org/IN: loading master
file primaries/wireless.ietf56.ietf.org: no owner".
A: This error is produced when a line in the master file contains leading
white space (tab/space) but the is no current record owner name to inherit
the name from. Usually this is the result of putting white space before
a comment. Forgeting the "@" for the SOA record or indenting the master
file.
file primaries/wireless.ietf56.ietf.org: no owner".
A: This error is produced when a line in the master file contains leading white
space (tab/space) but the is no current record owner name to inherit the
name from. Usually this is the result of putting white space before a
comment. Forgeting the "@" for the SOA record or indenting the master file.
Q: Why are my logs in GMT (UTC).
A: You are running chrooted (-t) and have not supplied local timzone
information in the chroot area.
information in the chroot area.
FreeBSD: /etc/localtime
Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo
OSF: /etc/zoneinfo/localtime
FreeBSD: /etc/localtime
Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo
OSF: /etc/zoneinfo/localtime
See also tzset(3) and zic(8).
See also tzset(3) and zic(8).
Q: I get the error message "named: capset failed: Operation not permitted" when
starting named.
Q: I get the error message "named: capset failed: Operation not permitted"
when starting named.
A: The capability module, part of "Linux Security Modules/LSM", has not been
loaded into the kernel. See insmod(8).
A: The capset module has not been loaded into the kernel. See insmod(8).
Q: I get "rndc: connect failed: connection refused" when I try to run
rndc.
Q: I get "rndc: connect failed: connection refused" when I try to run rndc.
A: This is usually a configuration error.
First ensure that named is running and no errors are being
reported at startup (/var/log/messages or equivalent). Running
"named -g <usual arguements>" from a terminal can help at this
point.
First ensure that named is running and no errors are being reported at
startup (/var/log/messages or equivalent). Running "named -g <usual
arguments>" from a title can help at this point.
Secondly ensure that named is configured to use rndc either by
"rndc-confgen -a", rndc-confgen or manually. The Administators
Reference manual has details on how to do this.
Secondly ensure that named is configured to use rndc either by "rndc-confgen
-a", rndc-confgen or manually. The Administrators Reference manual has
details on how to do this.
Old versions of rndc-confgen used localhost rather than 127.0.0.1
in /etc/rndc.conf for the default server. Update /etc/rndc.conf
if necessary so that the default server listed in /etc/rndc.conf
matches the addresses used in named.conf. "localhost" has two
address (127.0.0.1 and ::1).
If you use "rndc-confgen -a" and named is running with -t or -u
ensure that /etc/rndc.conf has the correct ownership and that
a copy is in the chroot area. You can do this by re-running
"rndc-confgen -a" with appropriate -t and -u arguements.
Old versions of rndc-confgen used localhost rather than 127.0.0.1 in /etc/
rndc.conf for the default server. Update /etc/rndc.conf if necessary so that
the default server listed in /etc/rndc.conf matches the addresses used in
named.conf. "localhost" has two address (127.0.0.1 and ::1).
If you use "rndc-confgen -a" and named is running with -t or -u ensure that
/etc/rndc.conf has the correct ownership and that a copy is in the chroot
area. You can do this by re-running "rndc-confgen -a" with appropriate -t
and -u arguments.
Q: I don't get RRSIG's returned when I use "dig +dnssec".
A: You need to ensure DNSSEC is enabled (dnssec-enable yes;).
Q: I get "Error 1067" when starting named under Windows.
A: This is the service manager saying that named exited. You need to
examine the Application log in the EventViewer to find out why.
A: This is the service manager saying that named exited. You need to examine
the Application log in the EventViewer to find out why.
Common causes are that you failed to create "named.conf" (usually
"C:\windows\dns\etc\named.conf") or failed to specify the directory
in named.conf.
Common causes are that you failed to create "named.conf" (usually "C:\
windows\dns\etc\named.conf") or failed to specify the directory in
named.conf.
options {
Directory "C:\windows\dns\etc";
};
options {
Directory "C:\windows\dns\etc";
};
Q: I get "transfer of 'example.net/IN' from 192.168.4.12#53: failed while
receiving responses: permission denied" error messages.
A: These indicate a filesystem permission error preventing named creating /
renaming the temporary file. These will usually also have other associated
error messages like
"dumping master file: sl/tmp-XXXX5il3sQ: open: permission denied"
Named needs write permission on the directory containing the file. Named
writes the new cache file to a temporary file then renames it to the name
specified in named.conf to ensure that the contents are always complete.
This is to prevent named loading a partial zone in the event of power
failure or similar interrupting the write of the master file.
Note file names are relative to the directory specified in options and any
chroot directory ([<chroot dir>/][<options dir>]).
If named is invoked as "named -t /chroot/DNS" with the following named.conf
then "/chroot/DNS/var/named/sl" needs to be writable by the user named is
running as.
options {
directory "/var/named";
};
zone "example.net" {
type slave;
file "sl/example.net";
masters { 192.168.4.12; };
};
Q: How do I intergrate BIND 9 and Solaris SMF
A: Sun has a blog entry describing how to do this.
http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris
Q: Can a NS record refer to a CNAME.
A: No. The rules for glue (copies of the *address* records in the parent zones)
and additional section processing do not allow it to work.
You would have to add both the CNAME and address records (A/AAAA) as glue to
the parent zone and have CNAMEs be followed when doing additional section
processing to make it work. No namesever implementation supports either of
these requirements.
Q: What does "RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA" mean?
A: If the IN-ADDR.ARPA name covered refers to a internal address space you are
using then you have failed to follow RFC 1918 usage rules and are leaking
queries to the Internet. You should establish your own zones for these
addresses to prevent you quering the Internet's name servers for these
addresses. Please see http://as112.net/ for details of the problems you are
causing and the counter measures that have had to be deployed.
If you are not using these private addresses then a client has queried for
them. You can just ignore the messages, get the offending client to stop
sending you these messages as they are most probably leaking them or setup
your own zones empty zones to serve answers to these queries.
zone "10.IN-ADDR.ARPA" {
type master;
file "empty";
};
zone "16.172.IN-ADDR.ARPA" {
type master;
file "empty";
};
...
zone "31.172.IN-ADDR.ARPA" {
type master;
file "empty";
};
zone "168.192.IN-ADDR.ARPA" {
type master;
file "empty";
};
empty:
@ 10800 IN SOA <name-of-server>. <contact-email>. (
1 3600 1200 604800 10800 )
@ 10800 IN NS <name-of-server>.
Note
Future versions of named are likely to do this automatically.

1007
contrib/bind9/FAQ.xml Normal file
View file

File diff suppressed because it is too large Load diff

24
contrib/bind9/README
View file

@ -43,6 +43,26 @@ BIND 9
Nominum, Inc.
BIND 9.3.2
BIND 9.3.2 is a maintenance release, containing fixes for
a number of bugs in 9.3.1.
libbind: corresponds to that from BIND 8.4.7-REL.
Known Issues:
The following INSIST can be triggered with DNSSEC enabled.
resolver.c:762: INSIST(result != 0 || dns_rdataset_isassociated(event->rdataset) || fctx->type == ((dns_rdatatype_t)dns_rdatatype_any) || fctx->type == ((dns_rdatatype_t)dns_rdatatype_rrsig)) failed
We are still trying to isolate the cause. If you have core
dump please send a bug report to bind9-bugs@isc.org with
the location of the core, named executable and OS details.
Note: contrib/nanny contains a perl script to restart named
in the event of a INSIST/REQUIRE/ENSURE failure.
BIND 9.3.1
BIND 9.3.1 is a maintenance release, containing fixes for
@ -210,7 +230,7 @@ Building
UnixWare 7.1.1
HP-UX 10.20
BSD/OS 4.2
Mac OS X 10.1
Mac OS X 10.1, 10.3.8
To build, just
@ -300,9 +320,11 @@ Building
Building with gcc is not supported, unless gcc is the vendor's usual
compiler (e.g. the various BSD systems, Linux).
Known compiler issues:
* gcc-3.2.1 and gcc-3.1.1 is known to cause problems with solaris-x86.
* gcc prior to gcc-3.2.3 ultrasparc generates incorrect code at -02.
* gcc-3.3.5 powerpc generates incorrect code at -02.
* Irix, MipsPRO 7.4.1m is known to cause problems.
A limited test suite can be run with "make test". Many of
the tests require you to configure a set of virtual IP addresses

67
contrib/bind9/bin/check/named-checkconf.8
View file

@ -1,59 +1,70 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2002 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2002 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: named-checkconf.8,v 1.11.12.4 2004/06/03 05:35:41 marka Exp $
.\" $Id: named-checkconf.8,v 1.11.12.7 2005/10/13 02:33:41 marka Exp $
.\"
.TH "NAMED-CHECKCONF" "8" "June 14, 2000" "BIND9" ""
.SH NAME
named-checkconf \- named configuration file syntax checking tool
.SH SYNOPSIS
.sp
\fBnamed-checkconf\fR [ \fB-v\fR ] [ \fB-j\fR ] [ \fB-t \fIdirectory\fB\fR ] \fBfilename\fR [ \fB-z\fR ]
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "NAMED\-CHECKCONF" "8" "June 14, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
named\-checkconf \- named configuration file syntax checking tool
.SH "SYNOPSIS"
.HP 16
\fBnamed\-checkconf\fR [\fB\-v\fR] [\fB\-j\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] {filename} [\fB\-z\fR]
.SH "DESCRIPTION"
.PP
\fBnamed-checkconf\fR checks the syntax, but not
the semantics, of a named configuration file.
\fBnamed\-checkconf\fR
checks the syntax, but not the semantics, of a named configuration file.
.SH "OPTIONS"
.TP
\fB-t \fIdirectory\fB\fR
chroot to \fIdirectory\fR so that include
directives in the configuration file are processed as if
run by a similarly chrooted named.
\-t \fIdirectory\fR
chroot to
\fIdirectory\fR
so that include directives in the configuration file are processed as if run by a similarly chrooted named.
.TP
\fB-v\fR
Print the version of the \fBnamed-checkconf\fR
\-v
Print the version of the
\fBnamed\-checkconf\fR
program and exit.
.TP
\fB-z\fR
\-z
Perform a check load the master zonefiles found in
\fInamed.conf\fR.
.TP
\fB-j\fR
\-j
When loading a zonefile read the journal if it exists.
.TP
\fBfilename\fR
The name of the configuration file to be checked. If not
specified, it defaults to \fI/etc/named.conf\fR.
filename
The name of the configuration file to be checked. If not specified, it defaults to
\fI/etc/named.conf\fR.
.SH "RETURN VALUES"
.PP
\fBnamed-checkconf\fR returns an exit status of 1 if
errors were detected and 0 otherwise.
\fBnamed\-checkconf\fR
returns an exit status of 1 if errors were detected and 0 otherwise.
.SH "SEE ALSO"
.PP
\fBnamed\fR(8),
\fIBIND 9 Administrator Reference Manual\fR.
BIND 9 Administrator Reference Manual.
.SH "AUTHOR"
.PP
Internet Systems Consortium

25
contrib/bind9/bin/check/named-checkconf.docbook
View file

@ -1,7 +1,9 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001, 2002 Internet Software Consortium.
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2002 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: named-checkconf.docbook,v 1.3.2.1.8.5 2004/06/03 02:24:59 marka Exp $ -->
<!-- $Id: named-checkconf.docbook,v 1.3.2.1.8.7 2005/05/12 21:35:56 sra Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,20 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><application>named-checkconf</application></refname>
<refpurpose>named configuration file syntax checking tool</refpurpose>
@ -116,6 +132,7 @@
<para>
<command>named-checkconf</command> returns an exit status of 1 if
errors were detected and 0 otherwise.
</para>
</refsect1>
<refsect1>

276
contrib/bind9/bin/check/named-checkconf.html
View file

@ -1,216 +1,92 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001, 2002 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2002 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: named-checkconf.html,v 1.5.2.1.4.5 2004/08/22 23:38:57 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>named-checkconf</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><SPAN
CLASS="APPLICATION"
>named-checkconf</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><SPAN
CLASS="APPLICATION"
>named-checkconf</SPAN
>&nbsp;--&nbsp;named configuration file syntax checking tool</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>named-checkconf</B
> [<VAR
CLASS="OPTION"
>-v</VAR
>] [<VAR
CLASS="OPTION"
>-j</VAR
>] [<VAR
CLASS="OPTION"
>-t <VAR
CLASS="REPLACEABLE"
>directory</VAR
></VAR
>] {filename} [<VAR
CLASS="OPTION"
>-z</VAR
>]</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN26"
></A
><H2
>DESCRIPTION</H2
><P
> <B
CLASS="COMMAND"
>named-checkconf</B
> checks the syntax, but not
<!-- $Id: named-checkconf.html,v 1.5.2.1.4.12 2005/10/13 02:33:42 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>named-checkconf</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><span class="application">named-checkconf</span> &#8212; named configuration file syntax checking tool</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">named-checkconf</code> [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-z</code>]</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525865"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">named-checkconf</strong></span> checks the syntax, but not
the semantics, of a named configuration file.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN30"
></A
><H2
>OPTIONS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>-t <VAR
CLASS="REPLACEABLE"
>directory</VAR
></DT
><DD
><P
> chroot to <TT
CLASS="FILENAME"
>directory</TT
> so that include
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525878"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
<dd><p>
chroot to <code class="filename">directory</code> so that include
directives in the configuration file are processed as if
run by a similarly chrooted named.
</P
></DD
><DT
>-v</DT
><DD
><P
> Print the version of the <B
CLASS="COMMAND"
>named-checkconf</B
>
</p></dd>
<dt><span class="term">-v</span></dt>
<dd><p>
Print the version of the <span><strong class="command">named-checkconf</strong></span>
program and exit.
</P
></DD
><DT
>-z</DT
><DD
><P
> Perform a check load the master zonefiles found in
<TT
CLASS="FILENAME"
>named.conf</TT
>.
</P
></DD
><DT
>-j</DT
><DD
><P
> When loading a zonefile read the journal if it exists.
</P
></DD
><DT
>filename</DT
><DD
><P
> The name of the configuration file to be checked. If not
specified, it defaults to <TT
CLASS="FILENAME"
>/etc/named.conf</TT
>.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN58"
></A
><H2
>RETURN VALUES</H2
><P
> <B
CLASS="COMMAND"
>named-checkconf</B
> returns an exit status of 1 if
</p></dd>
<dt><span class="term">-z</span></dt>
<dd><p>
Perform a check load the master zonefiles found in
<code class="filename">named.conf</code>.
</p></dd>
<dt><span class="term">-j</span></dt>
<dd><p>
When loading a zonefile read the journal if it exists.
</p></dd>
<dt><span class="term">filename</span></dt>
<dd><p>
The name of the configuration file to be checked. If not
specified, it defaults to <code class="filename">/etc/named.conf</code>.
</p></dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525970"></a><h2>RETURN VALUES</h2>
<p>
<span><strong class="command">named-checkconf</strong></span> returns an exit status of 1 if
errors were detected and 0 otherwise.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN62"
></A
><H2
>SEE ALSO</H2
><P
> <SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>named</SPAN
>(8)</SPAN
>,
<I
CLASS="CITETITLE"
>BIND 9 Administrator Reference Manual</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN69"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525982"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526006"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

113
contrib/bind9/bin/check/named-checkzone.8
View file

@ -1,94 +1,111 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2002 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2002 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: named-checkzone.8,v 1.11.2.1.8.4 2004/06/03 05:35:42 marka Exp $
.\" $Id: named-checkzone.8,v 1.11.2.1.8.8 2005/10/13 02:33:41 marka Exp $
.\"
.TH "NAMED-CHECKZONE" "8" "June 13, 2000" "BIND9" ""
.SH NAME
named-checkzone \- zone file validity checking tool
.SH SYNOPSIS
.sp
\fBnamed-checkzone\fR [ \fB-d\fR ] [ \fB-j\fR ] [ \fB-q\fR ] [ \fB-v\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-k \fImode\fB\fR ] [ \fB-n \fImode\fB\fR ] [ \fB-o \fIfilename\fB\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-w \fIdirectory\fB\fR ] [ \fB-D\fR ] \fBzonename\fR \fBfilename\fR
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "NAMED\-CHECKZONE" "8" "June 13, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
named\-checkzone \- zone file validity checking tool
.SH "SYNOPSIS"
.HP 16
\fBnamed\-checkzone\fR [\fB\-d\fR] [\fB\-j\fR] [\fB\-q\fR] [\fB\-v\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-k\ \fR\fB\fImode\fR\fR] [\fB\-n\ \fR\fB\fImode\fR\fR] [\fB\-o\ \fR\fB\fIfilename\fR\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-w\ \fR\fB\fIdirectory\fR\fR] [\fB\-D\fR] {zonename} {filename}
.SH "DESCRIPTION"
.PP
\fBnamed-checkzone\fR checks the syntax and integrity of
a zone file. It performs the same checks as \fBnamed\fR
\fBnamed\-checkzone\fR
checks the syntax and integrity of a zone file. It performs the same checks as
\fBnamed\fR
does when loading a zone. This makes
\fBnamed-checkzone\fR useful for checking zone
files before configuring them into a name server.
\fBnamed\-checkzone\fR
useful for checking zone files before configuring them into a name server.
.SH "OPTIONS"
.TP
\fB-d\fR
\-d
Enable debugging.
.TP
\fB-q\fR
Quiet mode - exit code only.
\-q
Quiet mode \- exit code only.
.TP
\fB-v\fR
Print the version of the \fBnamed-checkzone\fR
\-v
Print the version of the
\fBnamed\-checkzone\fR
program and exit.
.TP
\fB-j\fR
\-j
When loading the zone file read the journal if it exists.
.TP
\fB-c \fIclass\fB\fR
\-c \fIclass\fR
Specify the class of the zone. If not specified "IN" is assumed.
.TP
\fB-k \fImode\fB\fR
Perform \fB"check-name"\fR checks with the specified failure mode.
Possible modes are \fB"fail"\fR,
\fB"warn"\fR (default) and
\-k \fImode\fR
Perform
\fB"check\-name"\fR
checks with the specified failure mode. Possible modes are
\fB"fail"\fR,
\fB"warn"\fR
(default) and
\fB"ignore"\fR.
.TP
\fB-n \fImode\fB\fR
Specify whether NS records should be checked to see if they
are addresses. Possible modes are \fB"fail"\fR,
\fB"warn"\fR (default) and
\-n \fImode\fR
Specify whether NS records should be checked to see if they are addresses. Possible modes are
\fB"fail"\fR,
\fB"warn"\fR
(default) and
\fB"ignore"\fR.
.TP
\fB-o \fIfilename\fB\fR
Write zone output to \fIdirectory\fR.
\-o \fIfilename\fR
Write zone output to
\fIfilename\fR.
.TP
\fB-t \fIdirectory\fB\fR
chroot to \fIdirectory\fR so that include
directives in the configuration file are processed as if
run by a similarly chrooted named.
\-t \fIdirectory\fR
chroot to
\fIdirectory\fR
so that include directives in the configuration file are processed as if run by a similarly chrooted named.
.TP
\fB-w \fIdirectory\fB\fR
chdir to \fIdirectory\fR so that relative
filenames in master file $INCLUDE directives work. This
is similar to the directory clause in
\-w \fIdirectory\fR
chdir to
\fIdirectory\fR
so that relative filenames in master file $INCLUDE directives work. This is similar to the directory clause in
\fInamed.conf\fR.
.TP
\fB-D\fR
\-D
Dump zone file in canonical format.
.TP
\fBzonename\fR
zonename
The domain name of the zone being checked.
.TP
\fBfilename\fR
filename
The name of the zone file.
.SH "RETURN VALUES"
.PP
\fBnamed-checkzone\fR returns an exit status of 1 if
errors were detected and 0 otherwise.
\fBnamed\-checkzone\fR
returns an exit status of 1 if errors were detected and 0 otherwise.
.SH "SEE ALSO"
.PP
\fBnamed\fR(8),
\fIRFC 1035\fR,
\fIBIND 9 Administrator Reference Manual\fR.
RFC 1035,
BIND 9 Administrator Reference Manual.
.SH "AUTHOR"
.PP
Internet Systems Consortium

28
contrib/bind9/bin/check/named-checkzone.docbook
View file

@ -1,7 +1,9 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001, 2002 Internet Software Consortium.
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2002 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: named-checkzone.docbook,v 1.3.2.2.8.7 2004/06/03 02:25:00 marka Exp $ -->
<!-- $Id: named-checkzone.docbook,v 1.3.2.2.8.11 2005/05/12 21:35:57 sra Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,20 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><application>named-checkzone</application></refname>
<refpurpose>zone file validity checking tool</refpurpose>
@ -103,6 +119,7 @@
When loading the zone file read the journal if it exists.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-c <replaceable class="parameter">class</replaceable></term>
@ -141,7 +158,7 @@
<term>-o <replaceable class="parameter">filename</replaceable></term>
<listitem>
<para>
Write zone output to <filename>directory</filename>.
Write zone output to <filename>filename</filename>.
</para>
</listitem>
</varlistentry>
@ -205,6 +222,7 @@
<para>
<command>named-checkzone</command> returns an exit status of 1 if
errors were detected and 0 otherwise.
</para>
</refsect1>
<refsect1>

464
contrib/bind9/bin/check/named-checkzone.html
View file

@ -1,367 +1,135 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001, 2002 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2002 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: named-checkzone.html,v 1.5.2.2.4.5 2004/08/22 23:38:57 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>named-checkzone</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><SPAN
CLASS="APPLICATION"
>named-checkzone</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><SPAN
CLASS="APPLICATION"
>named-checkzone</SPAN
>&nbsp;--&nbsp;zone file validity checking tool</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>named-checkzone</B
> [<VAR
CLASS="OPTION"
>-d</VAR
>] [<VAR
CLASS="OPTION"
>-j</VAR
>] [<VAR
CLASS="OPTION"
>-q</VAR
>] [<VAR
CLASS="OPTION"
>-v</VAR
>] [<VAR
CLASS="OPTION"
>-c <VAR
CLASS="REPLACEABLE"
>class</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-k <VAR
CLASS="REPLACEABLE"
>mode</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-n <VAR
CLASS="REPLACEABLE"
>mode</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-o <VAR
CLASS="REPLACEABLE"
>filename</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-t <VAR
CLASS="REPLACEABLE"
>directory</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-w <VAR
CLASS="REPLACEABLE"
>directory</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-D</VAR
>] {zonename} {filename}</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN46"
></A
><H2
>DESCRIPTION</H2
><P
> <B
CLASS="COMMAND"
>named-checkzone</B
> checks the syntax and integrity of
a zone file. It performs the same checks as <B
CLASS="COMMAND"
>named</B
>
<!-- $Id: named-checkzone.html,v 1.5.2.2.4.13 2005/10/13 02:33:42 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>named-checkzone</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><span class="application">named-checkzone</span> &#8212; zone file validity checking tool</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">named-checkzone</code> [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] {zonename} {filename}</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525922"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">named-checkzone</strong></span> checks the syntax and integrity of
a zone file. It performs the same checks as <span><strong class="command">named</strong></span>
does when loading a zone. This makes
<B
CLASS="COMMAND"
>named-checkzone</B
> useful for checking zone
<span><strong class="command">named-checkzone</strong></span> useful for checking zone
files before configuring them into a name server.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN52"
></A
><H2
>OPTIONS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>-d</DT
><DD
><P
> Enable debugging.
</P
></DD
><DT
>-q</DT
><DD
><P
> Quiet mode - exit code only.
</P
></DD
><DT
>-v</DT
><DD
><P
> Print the version of the <B
CLASS="COMMAND"
>named-checkzone</B
>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525942"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-d</span></dt>
<dd><p>
Enable debugging.
</p></dd>
<dt><span class="term">-q</span></dt>
<dd><p>
Quiet mode - exit code only.
</p></dd>
<dt><span class="term">-v</span></dt>
<dd><p>
Print the version of the <span><strong class="command">named-checkzone</strong></span>
program and exit.
</P
></DD
><DT
>-j</DT
><DD
><P
> When loading the zone file read the journal if it exists.
</P
></DD
><DT
>-c <VAR
CLASS="REPLACEABLE"
>class</VAR
></DT
><DD
><P
> Specify the class of the zone. If not specified "IN" is assumed.
</P
></DD
><DT
>-k <VAR
CLASS="REPLACEABLE"
>mode</VAR
></DT
><DD
><P
> Perform <B
CLASS="COMMAND"
>"check-name"</B
> checks with the specified failure mode.
Possible modes are <B
CLASS="COMMAND"
>"fail"</B
>,
<B
CLASS="COMMAND"
>"warn"</B
> (default) and
<B
CLASS="COMMAND"
>"ignore"</B
>.
</P
></DD
><DT
>-n <VAR
CLASS="REPLACEABLE"
>mode</VAR
></DT
><DD
><P
> Specify whether NS records should be checked to see if they
are addresses. Possible modes are <B
CLASS="COMMAND"
>"fail"</B
>,
<B
CLASS="COMMAND"
>"warn"</B
> (default) and
<B
CLASS="COMMAND"
>"ignore"</B
>.
</P
></DD
><DT
>-o <VAR
CLASS="REPLACEABLE"
>filename</VAR
></DT
><DD
><P
> Write zone output to <TT
CLASS="FILENAME"
>directory</TT
>.
</P
></DD
><DT
>-t <VAR
CLASS="REPLACEABLE"
>directory</VAR
></DT
><DD
><P
> chroot to <TT
CLASS="FILENAME"
>directory</TT
> so that include
</p></dd>
<dt><span class="term">-j</span></dt>
<dd><p>
When loading the zone file read the journal if it exists.
</p></dd>
<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
<dd><p>
Specify the class of the zone. If not specified "IN" is assumed.
</p></dd>
<dt><span class="term">-k <em class="replaceable"><code>mode</code></em></span></dt>
<dd><p>
Perform <span><strong class="command">"check-name"</strong></span> checks with the specified failure mode.
Possible modes are <span><strong class="command">"fail"</strong></span>,
<span><strong class="command">"warn"</strong></span> (default) and
<span><strong class="command">"ignore"</strong></span>.
</p></dd>
<dt><span class="term">-n <em class="replaceable"><code>mode</code></em></span></dt>
<dd><p>
Specify whether NS records should be checked to see if they
are addresses. Possible modes are <span><strong class="command">"fail"</strong></span>,
<span><strong class="command">"warn"</strong></span> (default) and
<span><strong class="command">"ignore"</strong></span>.
</p></dd>
<dt><span class="term">-o <em class="replaceable"><code>filename</code></em></span></dt>
<dd><p>
Write zone output to <code class="filename">filename</code>.
</p></dd>
<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
<dd><p>
chroot to <code class="filename">directory</code> so that include
directives in the configuration file are processed as if
run by a similarly chrooted named.
</P
></DD
><DT
>-w <VAR
CLASS="REPLACEABLE"
>directory</VAR
></DT
><DD
><P
> chdir to <TT
CLASS="FILENAME"
>directory</TT
> so that relative
</p></dd>
<dt><span class="term">-w <em class="replaceable"><code>directory</code></em></span></dt>
<dd><p>
chdir to <code class="filename">directory</code> so that relative
filenames in master file $INCLUDE directives work. This
is similar to the directory clause in
<TT
CLASS="FILENAME"
>named.conf</TT
>.
</P
></DD
><DT
>-D</DT
><DD
><P
> Dump zone file in canonical format.
</P
></DD
><DT
>zonename</DT
><DD
><P
> The domain name of the zone being checked.
</P
></DD
><DT
>filename</DT
><DD
><P
> The name of the zone file.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN125"
></A
><H2
>RETURN VALUES</H2
><P
> <B
CLASS="COMMAND"
>named-checkzone</B
> returns an exit status of 1 if
<code class="filename">named.conf</code>.
</p></dd>
<dt><span class="term">-D</span></dt>
<dd><p>
Dump zone file in canonical format.
</p></dd>
<dt><span class="term">zonename</span></dt>
<dd><p>
The domain name of the zone being checked.
</p></dd>
<dt><span class="term">filename</span></dt>
<dd><p>
The name of the zone file.
</p></dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526187"></a><h2>RETURN VALUES</h2>
<p>
<span><strong class="command">named-checkzone</strong></span> returns an exit status of 1 if
errors were detected and 0 otherwise.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN129"
></A
><H2
>SEE ALSO</H2
><P
> <SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>named</SPAN
>(8)</SPAN
>,
<I
CLASS="CITETITLE"
>RFC 1035</I
>,
<I
CLASS="CITETITLE"
>BIND 9 Administrator Reference Manual</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN137"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526200"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
<em class="citetitle">RFC 1035</em>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526227"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

512
contrib/bind9/bin/dig/dig.1
View file

@ -1,216 +1,244 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2003 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2003 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: dig.1,v 1.14.2.4.2.6 2004/06/23 09:11:01 marka Exp $
.\" $Id: dig.1,v 1.14.2.4.2.10 2005/10/13 02:33:42 marka Exp $
.\"
.TH "DIG" "1" "Jun 30, 2000" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "DIG" "1" "Jun 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
dig \- DNS lookup utility
.SH SYNOPSIS
.sp
\fBdig\fR [ \fB@server\fR ] [ \fB-b \fIaddress\fB\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-f \fIfilename\fB\fR ] [ \fB-k \fIfilename\fB\fR ] [ \fB-p \fIport#\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-x \fIaddr\fB\fR ] [ \fB-y \fIname:key\fB\fR ] [ \fB-4\fR ] [ \fB-6\fR ] [ \fBname\fR ] [ \fBtype\fR ] [ \fBclass\fR ] [ \fBqueryopt\fR\fI...\fR ]
.sp
\fBdig\fR [ \fB-h\fR ]
.sp
\fBdig\fR [ \fBglobal-queryopt\fR\fI...\fR ] [ \fBquery\fR\fI...\fR ]
.SH "SYNOPSIS"
.HP 4
\fBdig\fR [@server] [\fB\-b\ \fR\fB\fIaddress\fR\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-f\ \fR\fB\fIfilename\fR\fR] [\fB\-k\ \fR\fB\fIfilename\fR\fR] [\fB\-p\ \fR\fB\fIport#\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-x\ \fR\fB\fIaddr\fR\fR] [\fB\-y\ \fR\fB\fIname:key\fR\fR] [\fB\-4\fR] [\fB\-6\fR] [name] [type] [class] [queryopt...]
.HP 4
\fBdig\fR [\fB\-h\fR]
.HP 4
\fBdig\fR [global\-queryopt...] [query...]
.SH "DESCRIPTION"
.PP
\fBdig\fR (domain information groper) is a flexible tool
for interrogating DNS name servers. It performs DNS lookups and
displays the answers that are returned from the name server(s) that
were queried. Most DNS administrators use \fBdig\fR to
troubleshoot DNS problems because of its flexibility, ease of use and
clarity of output. Other lookup tools tend to have less functionality
than \fBdig\fR.
\fBdig\fR
(domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most DNS administrators use
\fBdig\fR
to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than
\fBdig\fR.
.PP
Although \fBdig\fR is normally used with command-line
arguments, it also has a batch mode of operation for reading lookup
requests from a file. A brief summary of its command-line arguments
and options is printed when the \fB-h\fR option is given.
Unlike earlier versions, the BIND9 implementation of
\fBdig\fR allows multiple lookups to be issued from the
command line.
Although
\fBdig\fR
is normally used with command\-line arguments, it also has a batch mode of operation for reading lookup requests from a file. A brief summary of its command\-line arguments and options is printed when the
\fB\-h\fR
option is given. Unlike earlier versions, the BIND9 implementation of
\fBdig\fR
allows multiple lookups to be issued from the command line.
.PP
Unless it is told to query a specific name server,
\fBdig\fR will try each of the servers listed in
\fBdig\fR
will try each of the servers listed in
\fI/etc/resolv.conf\fR.
.PP
When no command line arguments or options are given, will perform an
NS query for "." (the root).
When no command line arguments or options are given, will perform an NS query for "." (the root).
.PP
It is possible to set per-user defaults for \fBdig\fR via
\fI${HOME}/.digrc\fR. This file is read and any options in it
are applied before the command line arguments.
It is possible to set per\-user defaults for
\fBdig\fR
via
\fI${HOME}/.digrc\fR. This file is read and any options in it are applied before the command line arguments.
.SH "SIMPLE USAGE"
.PP
A typical invocation of \fBdig\fR looks like:
A typical invocation of
\fBdig\fR
looks like:
.sp
.nf
dig @server name type
.sp
.fi
.sp
where:
.TP
\fBserver\fR
is the name or IP address of the name server to query. This can be an IPv4
address in dotted-decimal notation or an IPv6
address in colon-delimited notation. When the supplied
\fIserver\fR argument is a hostname,
\fBdig\fR resolves that name before querying that name
server. If no \fIserver\fR argument is provided,
\fBdig\fR consults \fI/etc/resolv.conf\fR
and queries the name servers listed there. The reply from the name
server that responds is displayed.
is the name or IP address of the name server to query. This can be an IPv4 address in dotted\-decimal notation or an IPv6 address in colon\-delimited notation. When the supplied
\fIserver\fR
argument is a hostname,
\fBdig\fR
resolves that name before querying that name server. If no
\fIserver\fR
argument is provided,
\fBdig\fR
consults
\fI/etc/resolv.conf\fR
and queries the name servers listed there. The reply from the name server that responds is displayed.
.TP
\fBname\fR
is the name of the resource record that is to be looked up.
.TP
\fBtype\fR
indicates what type of query is required \(em
ANY, A, MX, SIG, etc.
\fItype\fR can be any valid query type. If no
\fItype\fR argument is supplied,
\fBdig\fR will perform a lookup for an A record.
indicates what type of query is required \(em ANY, A, MX, SIG, etc.
\fItype\fR
can be any valid query type. If no
\fItype\fR
argument is supplied,
\fBdig\fR
will perform a lookup for an A record.
.SH "OPTIONS"
.PP
The \fB-b\fR option sets the source IP address of the query
to \fIaddress\fR. This must be a valid address on
one of the host's network interfaces or "0.0.0.0" or "::". An optional port
may be specified by appending "#<port>"
The
\fB\-b\fR
option sets the source IP address of the query to
\fIaddress\fR. This must be a valid address on one of the host's network interfaces or "0.0.0.0" or "::". An optional port may be specified by appending "#<port>"
.PP
The default query class (IN for internet) is overridden by the
\fB-c\fR option. \fIclass\fR is any valid
class, such as HS for Hesiod records or CH for CHAOSNET records.
\fB\-c\fR
option.
\fIclass\fR
is any valid class, such as HS for Hesiod records or CH for CHAOSNET records.
.PP
The \fB-f\fR option makes \fBdig \fR operate
in batch mode by reading a list of lookup requests to process from the
file \fIfilename\fR. The file contains a number of
queries, one per line. Each entry in the file should be organised in
the same way they would be presented as queries to
\fBdig\fR using the command-line interface.
The
\fB\-f\fR
option makes
\fBdig \fR
operate in batch mode by reading a list of lookup requests to process from the file
\fIfilename\fR. The file contains a number of queries, one per line. Each entry in the file should be organised in the same way they would be presented as queries to
\fBdig\fR
using the command\-line interface.
.PP
If a non-standard port number is to be queried, the
\fB-p\fR option is used. \fIport#\fR is
the port number that \fBdig\fR will send its queries
instead of the standard DNS port number 53. This option would be used
to test a name server that has been configured to listen for queries
on a non-standard port number.
If a non\-standard port number is to be queried, the
\fB\-p\fR
option is used.
\fIport#\fR
is the port number that
\fBdig\fR
will send its queries instead of the standard DNS port number 53. This option would be used to test a name server that has been configured to listen for queries on a non\-standard port number.
.PP
The \fB-4\fR option forces \fBdig\fR to only
use IPv4 query transport. The \fB-6\fR option forces
\fBdig\fR to only use IPv6 query transport.
The
\fB\-4\fR
option forces
\fBdig\fR
to only use IPv4 query transport. The
\fB\-6\fR
option forces
\fBdig\fR
to only use IPv6 query transport.
.PP
The \fB-t\fR option sets the query type to
\fItype\fR. It can be any valid query type which is
supported in BIND9. The default query type "A", unless the
\fB-x\fR option is supplied to indicate a reverse lookup.
A zone transfer can be requested by specifying a type of AXFR. When
an incremental zone transfer (IXFR) is required,
\fItype\fR is set to ixfr=N.
The incremental zone transfer will contain the changes made to the zone
since the serial number in the zone's SOA record was
The
\fB\-t\fR
option sets the query type to
\fItype\fR. It can be any valid query type which is supported in BIND9. The default query type "A", unless the
\fB\-x\fR
option is supplied to indicate a reverse lookup. A zone transfer can be requested by specifying a type of AXFR. When an incremental zone transfer (IXFR) is required,
\fItype\fR
is set to
ixfr=N. The incremental zone transfer will contain the changes made to the zone since the serial number in the zone's SOA record was
\fIN\fR.
.PP
Reverse lookups - mapping addresses to names - are simplified by the
\fB-x\fR option. \fIaddr\fR is an IPv4
address in dotted-decimal notation, or a colon-delimited IPv6 address.
When this option is used, there is no need to provide the
\fIname\fR, \fIclass\fR and
\fItype\fR arguments. \fBdig\fR
Reverse lookups \- mapping addresses to names \- are simplified by the
\fB\-x\fR
option.
\fIaddr\fR
is an IPv4 address in dotted\-decimal notation, or a colon\-delimited IPv6 address. When this option is used, there is no need to provide the
\fIname\fR,
\fIclass\fR
and
\fItype\fR
arguments.
\fBdig\fR
automatically performs a lookup for a name like
11.12.13.10.in-addr.arpa and sets the query type and
class to PTR and IN respectively. By default, IPv6 addresses are
looked up using nibble format under the IP6.ARPA domain.
To use the older RFC1886 method using the IP6.INT domain
specify the \fB-i\fR option. Bit string labels (RFC2874)
are now experimental and are not attempted.
11.12.13.10.in\-addr.arpa
and sets the query type and class to PTR and IN respectively. By default, IPv6 addresses are looked up using nibble format under the IP6.ARPA domain. To use the older RFC1886 method using the IP6.INT domain specify the
\fB\-i\fR
option. Bit string labels (RFC2874) are now experimental and are not attempted.
.PP
To sign the DNS queries sent by \fBdig\fR and their
responses using transaction signatures (TSIG), specify a TSIG key file
using the \fB-k\fR option. You can also specify the TSIG
key itself on the command line using the \fB-y\fR option;
\fIname\fR is the name of the TSIG key and
\fIkey\fR is the actual key. The key is a base-64
encoded string, typically generated by \fBdnssec-keygen\fR(8).
Caution should be taken when using the \fB-y\fR option on
multi-user systems as the key can be visible in the output from
\fBps\fR(1) or in the shell's history file. When
using TSIG authentication with \fBdig\fR, the name
server that is queried needs to know the key and algorithm that is
being used. In BIND, this is done by providing appropriate
\fBkey\fR and \fBserver\fR statements in
To sign the DNS queries sent by
\fBdig\fR
and their responses using transaction signatures (TSIG), specify a TSIG key file using the
\fB\-k\fR
option. You can also specify the TSIG key itself on the command line using the
\fB\-y\fR
option;
\fIname\fR
is the name of the TSIG key and
\fIkey\fR
is the actual key. The key is a base\-64 encoded string, typically generated by
\fBdnssec\-keygen\fR(8). Caution should be taken when using the
\fB\-y\fR
option on multi\-user systems as the key can be visible in the output from
\fBps\fR(1 )
or in the shell's history file. When using TSIG authentication with
\fBdig\fR, the name server that is queried needs to know the key and algorithm that is being used. In BIND, this is done by providing appropriate
\fBkey\fR
and
\fBserver\fR
statements in
\fInamed.conf\fR.
.SH "QUERY OPTIONS"
.PP
\fBdig\fR provides a number of query options which affect
the way in which lookups are made and the results displayed. Some of
these set or reset flag bits in the query header, some determine which
sections of the answer get printed, and others determine the timeout
and retry strategies.
\fBdig\fR
provides a number of query options which affect the way in which lookups are made and the results displayed. Some of these set or reset flag bits in the query header, some determine which sections of the answer get printed, and others determine the timeout and retry strategies.
.PP
Each query option is identified by a keyword preceded by a plus sign
(+). Some keywords set or reset an option. These may be preceded
by the string no to negate the meaning of that keyword. Other
keywords assign values to options like the timeout interval. They
have the form \fB+keyword=value\fR.
The query options are:
Each query option is identified by a keyword preceded by a plus sign (+). Some keywords set or reset an option. These may be preceded by the string
no
to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They have the form
\fB+keyword=value\fR. The query options are:
.TP
\fB+[no]tcp\fR
Use [do not use] TCP when querying name servers. The default
behaviour is to use UDP unless an AXFR or IXFR query is requested, in
which case a TCP connection is used.
Use [do not use] TCP when querying name servers. The default behaviour is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP connection is used.
.TP
\fB+[no]vc\fR
Use [do not use] TCP when querying name servers. This alternate
syntax to \fI+[no]tcp\fR is provided for backwards
compatibility. The "vc" stands for "virtual circuit".
Use [do not use] TCP when querying name servers. This alternate syntax to
\fI+[no]tcp\fR
is provided for backwards compatibility. The "vc" stands for "virtual circuit".
.TP
\fB+[no]ignore\fR
Ignore truncation in UDP responses instead of retrying with TCP. By
default, TCP retries are performed.
Ignore truncation in UDP responses instead of retrying with TCP. By default, TCP retries are performed.
.TP
\fB+domain=somename\fR
Set the search list to contain the single domain
\fIsomename\fR, as if specified in a
\fBdomain\fR directive in
\fI/etc/resolv.conf\fR, and enable search list
processing as if the \fI+search\fR option were given.
\fBdomain\fR
directive in
\fI/etc/resolv.conf\fR, and enable search list processing as if the
\fI+search\fR
option were given.
.TP
\fB+[no]search\fR
Use [do not use] the search list defined by the searchlist or domain
directive in \fIresolv.conf\fR (if any).
The search list is not used by default.
Use [do not use] the search list defined by the searchlist or domain directive in
\fIresolv.conf\fR
(if any). The search list is not used by default.
.TP
\fB+[no]defname\fR
Deprecated, treated as a synonym for \fI+[no]search\fR
Deprecated, treated as a synonym for
\fI+[no]search\fR
.TP
\fB+[no]aaonly\fR
Sets the "aa" flag in the query.
.TP
\fB+[no]aaflag\fR
A synonym for \fI+[no]aaonly\fR.
A synonym for
\fI+[no]aaonly\fR.
.TP
\fB+[no]adflag\fR
Set [do not set] the AD (authentic data) bit in the query. The AD bit
currently has a standard meaning only in responses, not in queries,
but the ability to set the bit in the query is provided for
completeness.
Set [do not set] the AD (authentic data) bit in the query. The AD bit currently has a standard meaning only in responses, not in queries, but the ability to set the bit in the query is provided for completeness.
.TP
\fB+[no]cdflag\fR
Set [do not set] the CD (checking disabled) bit in the query. This
requests the server to not perform DNSSEC validation of responses.
Set [do not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.
.TP
\fB+[no]cl\fR
Display [do not display] the CLASS when printing the record.
@ -219,170 +247,164 @@ Display [do not display] the CLASS when printing the record.
Display [do not display] the TTL when printing the record.
.TP
\fB+[no]recurse\fR
Toggle the setting of the RD (recursion desired) bit in the query.
This bit is set by default, which means \fBdig\fR
normally sends recursive queries. Recursion is automatically disabled
when the \fI+nssearch\fR or
\fI+trace\fR query options are used.
Toggle the setting of the RD (recursion desired) bit in the query. This bit is set by default, which means
\fBdig\fR
normally sends recursive queries. Recursion is automatically disabled when the
\fI+nssearch\fR
or
\fI+trace\fR
query options are used.
.TP
\fB+[no]nssearch\fR
When this option is set, \fBdig\fR attempts to find the
authoritative name servers for the zone containing the name being
looked up and display the SOA record that each name server has for the
zone.
When this option is set,
\fBdig\fR
attempts to find the authoritative name servers for the zone containing the name being looked up and display the SOA record that each name server has for the zone.
.TP
\fB+[no]trace\fR
Toggle tracing of the delegation path from the root name servers for
the name being looked up. Tracing is disabled by default. When
tracing is enabled, \fBdig\fR makes iterative queries to
resolve the name being looked up. It will follow referrals from the
root servers, showing the answer from each server that was used to
resolve the lookup.
Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled,
\fBdig\fR
makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup.
.TP
\fB+[no]cmd\fR
toggles the printing of the initial comment in the output identifying
the version of \fBdig\fR and the query options that have
been applied. This comment is printed by default.
toggles the printing of the initial comment in the output identifying the version of
\fBdig\fR
and the query options that have been applied. This comment is printed by default.
.TP
\fB+[no]short\fR
Provide a terse answer. The default is to print the answer in a
verbose form.
Provide a terse answer. The default is to print the answer in a verbose form.
.TP
\fB+[no]identify\fR
Show [or do not show] the IP address and port number that supplied the
answer when the \fI+short\fR option is enabled. If
short form answers are requested, the default is not to show the
source address and port number of the server that provided the answer.
Show [or do not show] the IP address and port number that supplied the answer when the
\fI+short\fR
option is enabled. If short form answers are requested, the default is not to show the source address and port number of the server that provided the answer.
.TP
\fB+[no]comments\fR
Toggle the display of comment lines in the output. The default is to
print comments.
Toggle the display of comment lines in the output. The default is to print comments.
.TP
\fB+[no]stats\fR
This query option toggles the printing of statistics: when the query
was made, the size of the reply and so on. The default behaviour is
to print the query statistics.
This query option toggles the printing of statistics: when the query was made, the size of the reply and so on. The default behaviour is to print the query statistics.
.TP
\fB+[no]qr\fR
Print [do not print] the query as it is sent.
By default, the query is not printed.
Print [do not print] the query as it is sent. By default, the query is not printed.
.TP
\fB+[no]question\fR
Print [do not print] the question section of a query when an answer is
returned. The default is to print the question section as a comment.
Print [do not print] the question section of a query when an answer is returned. The default is to print the question section as a comment.
.TP
\fB+[no]answer\fR
Display [do not display] the answer section of a reply. The default
is to display it.
Display [do not display] the answer section of a reply. The default is to display it.
.TP
\fB+[no]authority\fR
Display [do not display] the authority section of a reply. The
default is to display it.
Display [do not display] the authority section of a reply. The default is to display it.
.TP
\fB+[no]additional\fR
Display [do not display] the additional section of a reply.
The default is to display it.
Display [do not display] the additional section of a reply. The default is to display it.
.TP
\fB+[no]all\fR
Set or clear all display flags.
.TP
\fB+time=T\fR
Sets the timeout for a query to
\fIT\fR seconds. The default time out is 5 seconds.
An attempt to set \fIT\fR to less than 1 will result
in a query timeout of 1 second being applied.
\fIT\fR
seconds. The default time out is 5 seconds. An attempt to set
\fIT\fR
to less than 1 will result in a query timeout of 1 second being applied.
.TP
\fB+tries=T\fR
Sets the number of times to try UDP queries to server to
\fIT\fR instead of the default, 3. If
\fIT\fR is less than or equal to zero, the number of
tries is silently rounded up to 1.
\fIT\fR
instead of the default, 3. If
\fIT\fR
is less than or equal to zero, the number of tries is silently rounded up to 1.
.TP
\fB+retry=T\fR
Sets the number of times to retry UDP queries to server to
\fIT\fR instead of the default, 2. Unlike
\fI+tries\fR, this does not include the initial
query.
\fIT\fR
instead of the default, 2. Unlike
\fI+tries\fR, this does not include the initial query.
.TP
\fB+ndots=D\fR
Set the number of dots that have to appear in
\fIname\fR to \fID\fR for it to be
considered absolute. The default value is that defined using the
ndots statement in \fI/etc/resolv.conf\fR, or 1 if no
ndots statement is present. Names with fewer dots are interpreted as
relative names and will be searched for in the domains listed in the
\fBsearch\fR or \fBdomain\fR directive in
\fIname\fR
to
\fID\fR
for it to be considered absolute. The default value is that defined using the ndots statement in
\fI/etc/resolv.conf\fR, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the
\fBsearch\fR
or
\fBdomain\fR
directive in
\fI/etc/resolv.conf\fR.
.TP
\fB+bufsize=B\fR
Set the UDP message buffer size advertised using EDNS0 to
\fIB\fR bytes. The maximum and minimum sizes of this
buffer are 65535 and 0 respectively. Values outside this range are
rounded up or down appropriately.
\fIB\fR
bytes. The maximum and minimum sizes of this buffer are 65535 and 0 respectively. Values outside this range are rounded up or down appropriately.
.TP
\fB+[no]multiline\fR
Print records like the SOA records in a verbose multi-line
format with human-readable comments. The default is to print
each record on a single line, to facilitate machine parsing
of the \fBdig\fR output.
Print records like the SOA records in a verbose multi\-line format with human\-readable comments. The default is to print each record on a single line, to facilitate machine parsing of the
\fBdig\fR
output.
.TP
\fB+[no]fail\fR
Do not try the next server if you receive a SERVFAIL. The default is
to not try the next server which is the reverse of normal stub resolver
behaviour.
Do not try the next server if you receive a SERVFAIL. The default is to not try the next server which is the reverse of normal stub resolver behaviour.
.TP
\fB+[no]besteffort\fR
Attempt to display the contents of messages which are malformed.
The default is to not display malformed answers.
Attempt to display the contents of messages which are malformed. The default is to not display malformed answers.
.TP
\fB+[no]dnssec\fR
Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO)
in the OPT record in the additional section of the query.
Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional section of the query.
.TP
\fB+[no]sigchase\fR
Chase DNSSEC signature chains. Requires dig be compiled with
-DDIG_SIGCHASE.
Chase DNSSEC signature chains. Requires dig be compiled with \-DDIG_SIGCHASE.
.TP
\fB+trusted-key=####\fR
Specify a trusted key to be used with \fB+sigchase\fR.
Requires dig be compiled with -DDIG_SIGCHASE.
\fB+trusted\-key=####\fR
Specifies a file containing trusted keys to be used with
\fB+sigchase\fR. Each DNSKEY record must be on its own line.
.sp
If not specified
\fBdig\fR
will look for
\fI/etc/trusted\-key.key\fR
then
\fItrusted\-key.key\fR
in the current directory.
.sp
Requires dig be compiled with \-DDIG_SIGCHASE.
.TP
\fB+[no]topdown\fR
When chasing DNSSEC signature chains perform a top down validation.
Requires dig be compiled with -DDIG_SIGCHASE.
When chasing DNSSEC signature chains perform a top down validation. Requires dig be compiled with \-DDIG_SIGCHASE.
.SH "MULTIPLE QUERIES"
.PP
The BIND 9 implementation of \fBdig \fR supports
specifying multiple queries on the command line (in addition to
supporting the \fB-f\fR batch file option). Each of those
queries can be supplied with its own set of flags, options and query
options.
The BIND 9 implementation of
\fBdig \fR
supports specifying multiple queries on the command line (in addition to supporting the
\fB\-f\fR
batch file option). Each of those queries can be supplied with its own set of flags, options and query options.
.PP
In this case, each \fIquery\fR argument represent an
individual query in the command-line syntax described above. Each
consists of any of the standard options and flags, the name to be
looked up, an optional query type and class and any query options that
should be applied to that query.
In this case, each
\fIquery\fR
argument represent an individual query in the command\-line syntax described above. Each consists of any of the standard options and flags, the name to be looked up, an optional query type and class and any query options that should be applied to that query.
.PP
A global set of query options, which should be applied to all queries,
can also be supplied. These global query options must precede the
first tuple of name, class, type, options, flags, and query options
supplied on the command line. Any global query options (except
the \fB+[no]cmd\fR option) can be
overridden by a query-specific set of query options. For example:
A global set of query options, which should be applied to all queries, can also be supplied. These global query options must precede the first tuple of name, class, type, options, flags, and query options supplied on the command line. Any global query options (except the
\fB+[no]cmd\fR
option) can be overridden by a query\-specific set of query options. For example:
.sp
.nf
dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
.sp
dig +qr www.isc.org any \-x 127.0.0.1 isc.org ns +noqr
.fi
shows how \fBdig\fR could be used from the command line
to make three lookups: an ANY query for www.isc.org, a
reverse lookup of 127.0.0.1 and a query for the NS records of
isc.org.
A global query option of \fI+qr\fR is applied, so
that \fBdig\fR shows the initial query it made for each
lookup. The final query has a local query option of
\fI+noqr\fR which means that \fBdig\fR
.sp
shows how
\fBdig\fR
could be used from the command line to make three lookups: an ANY query for
www.isc.org, a reverse lookup of 127.0.0.1 and a query for the NS records of
isc.org. A global query option of
\fI+qr\fR
is applied, so that
\fBdig\fR
shows the initial query it made for each lookup. The final query has a local query option of
\fI+noqr\fR
which means that
\fBdig\fR
will not print the initial query when it looks up the NS records for
isc.org.
.SH "FILES"
@ -394,8 +416,8 @@ isc.org.
.PP
\fBhost\fR(1),
\fBnamed\fR(8),
\fBdnssec-keygen\fR(8),
\fIRFC1035\fR.
.SH "BUGS"
\fBdnssec\-keygen\fR(8),
RFC1035.
.SH "BUGS "
.PP
There are probably too many query options.
There are probably too many query options.

40
contrib/bind9/bin/dig/dig.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: dig.c,v 1.157.2.13.2.25 2004/09/16 02:14:14 marka Exp $ */
/* $Id: dig.c,v 1.157.2.13.2.29 2005/10/14 01:38:40 marka Exp $ */
#include <config.h>
#include <stdlib.h>
@ -45,10 +45,6 @@
#include <dig/dig.h>
extern ISC_LIST(dig_lookup_t) lookup_list;
extern dig_serverlist_t server_list;
extern ISC_LIST(dig_searchlist_t) search_list;
#define ADD_STRING(b, s) { \
if (strlen(s) >= isc_buffer_availablelength(b)) \
return (ISC_R_NOSPACE); \
@ -58,31 +54,8 @@ extern ISC_LIST(dig_searchlist_t) search_list;
#define DIG_MAX_ADDRESSES 20
extern isc_boolean_t have_ipv4, have_ipv6, specified_source,
usesearch, qr;
extern in_port_t port;
extern unsigned int timeout;
extern isc_mem_t *mctx;
extern dns_messageid_t id;
extern int sendcount;
extern int ndots;
extern int lookup_counter;
extern int exitcode;
extern isc_sockaddr_t bind_address;
extern char keynametext[MXNAME];
extern char keyfile[MXNAME];
extern char keysecret[MXNAME];
#ifdef DIG_SIGCHASE
extern char trustedkey[MXNAME];
#endif
extern dns_tsigkey_t *key;
extern isc_boolean_t validated;
extern isc_taskmgr_t *taskmgr;
extern isc_task_t *global_task;
extern isc_boolean_t free_now;
dig_lookup_t *default_lookup = NULL;
extern isc_boolean_t debugging, memdebugging;
static char *batchname = NULL;
static FILE *batchfp = NULL;
static char *argv0;
@ -133,8 +106,6 @@ static const char *rcodetext[] = {
"BADVERS"
};
extern char *progname;
static void
print_usage(FILE *fp) {
fputs(
@ -593,6 +564,7 @@ buftoosmall:
}
}
}
if (headers && query->lookup->comments && !short_form)
printf("\n");
@ -818,7 +790,7 @@ plus_option(char *option, isc_boolean_t is_batchfile,
break;
case 'l': /* cl */
FULLCHECK("cl");
noclass = !state;
noclass = ISC_TF(!state);
break;
case 'm': /* cmd */
FULLCHECK("cmd");
@ -892,7 +864,7 @@ plus_option(char *option, isc_boolean_t is_batchfile,
lookup->ns_search_only = state;
if (state) {
lookup->trace_root = ISC_TRUE;
lookup->recurse = ISC_FALSE;
lookup->recurse = ISC_TRUE;
lookup->identify = ISC_TRUE;
lookup->stats = ISC_FALSE;
lookup->comments = ISC_FALSE;
@ -1054,7 +1026,7 @@ plus_option(char *option, isc_boolean_t is_batchfile,
break;
case 't': /* ttlid */
FULLCHECK("ttlid");
nottl = !state;
nottl = ISC_TF(!state);
break;
default:
goto invalid_option;

60
contrib/bind9/bin/dig/dig.docbook
View file

@ -1,6 +1,8 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: dig.docbook,v 1.4.2.7.4.9 2004/06/23 04:19:41 marka Exp $ -->
<!-- $Id: dig.docbook,v 1.4.2.7.4.12 2005/08/30 00:50:29 marka Exp $ -->
<refentry>
@ -30,6 +32,21 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname>dig</refname>
<refpurpose>DNS lookup utility</refpurpose>
@ -38,7 +55,7 @@
<refsynopsisdiv>
<cmdsynopsis>
<command>dig</command>
<arg choice=opt>@server</arg>
<arg choice="opt">@server</arg>
<arg><option>-b <replaceable class="parameter">address</replaceable></option></arg>
<arg><option>-c <replaceable class="parameter">class</replaceable></option></arg>
<arg><option>-f <replaceable class="parameter">filename</replaceable></option></arg>
@ -49,10 +66,10 @@
<arg><option>-y <replaceable class="parameter">name:key</replaceable></option></arg>
<arg><option>-4</option></arg>
<arg><option>-6</option></arg>
<arg choice=opt>name</arg>
<arg choice=opt>type</arg>
<arg choice=opt>class</arg>
<arg choice=opt rep=repeat>queryopt</arg>
<arg choice="opt">name</arg>
<arg choice="opt">type</arg>
<arg choice="opt">class</arg>
<arg choice="opt" rep="repeat">queryopt</arg>
</cmdsynopsis>
<cmdsynopsis>
@ -62,8 +79,8 @@
<cmdsynopsis>
<command>dig</command>
<arg choice=opt rep=repeat>global-queryopt</arg>
<arg choice=opt rep=repeat>query</arg>
<arg choice="opt" rep="repeat">global-queryopt</arg>
<arg choice="opt" rep="repeat">query</arg>
</cmdsynopsis>
</refsynopsisdiv>
@ -513,11 +530,24 @@ Chase DNSSEC signature chains. Requires dig be compiled with
-DDIG_SIGCHASE.
</para></listitem></varlistentry>
<varlistentry><term><option>+trusted-key=####</option></term>
<listitem><para>
Specify a trusted key to be used with <option>+sigchase</option>.
Requires dig be compiled with -DDIG_SIGCHASE.
</para></listitem></varlistentry>
<varlistentry>
<term><option>+trusted-key=####</option></term>
<listitem>
<para>
Specifies a file containing trusted keys to be used with
<option>+sigchase</option>. Each DNSKEY record must be
on its own line.
</para>
<para>
If not specified <command>dig</command> will look for
<filename>/etc/trusted-key.key</filename> then
<filename>trusted-key.key</filename> in the current directory.
</para>
<para>
Requires dig be compiled with -DDIG_SIGCHASE.
</para>
</listitem>
</varlistentry>
<varlistentry><term><option>+[no]topdown</option></term>
<listitem><para>

1524
contrib/bind9/bin/dig/dig.html
View file

File diff suppressed because it is too large Load diff

911
contrib/bind9/bin/dig/dighost.c
View file

File diff suppressed because it is too large Load diff

231
contrib/bind9/bin/dig/host.1
View file

@ -1,132 +1,181 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2002 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2002 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: host.1,v 1.11.2.1.4.4 2004/04/13 04:11:03 marka Exp $
.\" $Id: host.1,v 1.11.2.1.4.7 2005/10/13 02:33:43 marka Exp $
.\"
.TH "HOST" "1" "Jun 30, 2000" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "HOST" "1" "Jun 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
host \- DNS lookup utility
.SH SYNOPSIS
.sp
\fBhost\fR [ \fB-aCdlnrTwv\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-N \fIndots\fB\fR ] [ \fB-R \fInumber\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-W \fIwait\fB\fR ] [ \fB-4\fR ] [ \fB-6\fR ] \fBname\fR [ \fBserver\fR ]
.SH "SYNOPSIS"
.HP 5
\fBhost\fR [\fB\-aCdlnrTwv\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-N\ \fR\fB\fIndots\fR\fR] [\fB\-R\ \fR\fB\fInumber\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-W\ \fR\fB\fIwait\fR\fR] [\fB\-4\fR] [\fB\-6\fR] {name} [server]
.SH "DESCRIPTION"
.PP
\fBhost\fR
is a simple utility for performing DNS lookups.
It is normally used to convert names to IP addresses and vice versa.
When no arguments or options are given,
is a simple utility for performing DNS lookups. It is normally used to convert names to IP addresses and vice versa. When no arguments or options are given,
\fBhost\fR
prints a short summary of its command line arguments and options.
.PP
\fIname\fR is the domain name that is to be looked
up. It can also be a dotted-decimal IPv4 address or a colon-delimited
IPv6 address, in which case \fBhost\fR will by default
perform a reverse lookup for that address.
\fIserver\fR is an optional argument which is either
the name or IP address of the name server that \fBhost\fR
\fIname\fR
is the domain name that is to be looked up. It can also be a dotted\-decimal IPv4 address or a colon\-delimited IPv6 address, in which case
\fBhost\fR
will by default perform a reverse lookup for that address.
\fIserver\fR
is an optional argument which is either the name or IP address of the name server that
\fBhost\fR
should query instead of the server or servers listed in
\fI/etc/resolv.conf\fR.
.PP
The \fB-a\fR (all) option is equivalent to setting the
\fB-v\fR option and asking \fBhost\fR to make
a query of type ANY.
The
\fB\-a\fR
(all) option is equivalent to setting the
\fB\-v\fR
option and asking
\fBhost\fR
to make a query of type ANY.
.PP
When the \fB-C\fR option is used, \fBhost\fR
When the
\fB\-C\fR
option is used,
\fBhost\fR
will attempt to display the SOA records for zone
\fIname\fR from all the listed authoritative name
servers for that zone. The list of name servers is defined by the NS
records that are found for the zone.
\fIname\fR
from all the listed authoritative name servers for that zone. The list of name servers is defined by the NS records that are found for the zone.
.PP
The \fB-c\fR option instructs to make a DNS query of class
\fIclass\fR. This can be used to lookup Hesiod or
Chaosnet class resource records. The default class is IN (Internet).
The
\fB\-c\fR
option instructs to make a DNS query of class
\fIclass\fR. This can be used to lookup Hesiod or Chaosnet class resource records. The default class is IN (Internet).
.PP
Verbose output is generated by \fBhost\fR when the
\fB-d\fR or \fB-v\fR option is used. The two
options are equivalent. They have been provided for backwards
compatibility. In previous versions, the \fB-d\fR option
switched on debugging traces and \fB-v\fR enabled verbose
output.
Verbose output is generated by
\fBhost\fR
when the
\fB\-d\fR
or
\fB\-v\fR
option is used. The two options are equivalent. They have been provided for backwards compatibility. In previous versions, the
\fB\-d\fR
option switched on debugging traces and
\fB\-v\fR
enabled verbose output.
.PP
List mode is selected by the \fB-l\fR option. This makes
\fBhost\fR perform a zone transfer for zone
\fIname\fR. Transfer the zone printing out the NS, PTR
and address records (A/AAAA). If combined with \fB-a\fR
all records will be printed.
List mode is selected by the
\fB\-l\fR
option. This makes
\fBhost\fR
perform a zone transfer for zone
\fIname\fR. Transfer the zone printing out the NS, PTR and address records (A/AAAA). If combined with
\fB\-a\fR
all records will be printed.
.PP
The \fB-i\fR
option specifies that reverse lookups of IPv6 addresses should
use the IP6.INT domain as defined in RFC1886.
The default is to use IP6.ARPA.
The
\fB\-i\fR
option specifies that reverse lookups of IPv6 addresses should use the IP6.INT domain as defined in RFC1886. The default is to use IP6.ARPA.
.PP
The \fB-N\fR option sets the number of dots that have to be
in \fIname\fR for it to be considered absolute. The
default value is that defined using the ndots statement in
\fI/etc/resolv.conf\fR, or 1 if no ndots statement is
present. Names with fewer dots are interpreted as relative names and
will be searched for in the domains listed in the \fBsearch\fR
or \fBdomain\fR directive in
The
\fB\-N\fR
option sets the number of dots that have to be in
\fIname\fR
for it to be considered absolute. The default value is that defined using the ndots statement in
\fI/etc/resolv.conf\fR, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the
\fBsearch\fR
or
\fBdomain\fR
directive in
\fI/etc/resolv.conf\fR.
.PP
The number of UDP retries for a lookup can be changed with the
\fB-R\fR option. \fInumber\fR indicates
how many times \fBhost\fR will repeat a query that does
not get answered. The default number of retries is 1. If
\fInumber\fR is negative or zero, the number of
retries will default to 1.
\fB\-R\fR
option.
\fInumber\fR
indicates how many times
\fBhost\fR
will repeat a query that does not get answered. The default number of retries is 1. If
\fInumber\fR
is negative or zero, the number of retries will default to 1.
.PP
Non-recursive queries can be made via the \fB-r\fR option.
Setting this option clears the \fBRD\fR \(em recursion
desired \(em bit in the query which \fBhost\fR makes.
This should mean that the name server receiving the query will not
attempt to resolve \fIname\fR. The
\fB-r\fR option enables \fBhost\fR to mimic
the behaviour of a name server by making non-recursive queries and
expecting to receive answers to those queries that are usually
referrals to other name servers.
Non\-recursive queries can be made via the
\fB\-r\fR
option. Setting this option clears the
\fBRD\fR
\(em recursion desired \(em bit in the query which
\fBhost\fR
makes. This should mean that the name server receiving the query will not attempt to resolve
\fIname\fR. The
\fB\-r\fR
option enables
\fBhost\fR
to mimic the behaviour of a name server by making non\-recursive queries and expecting to receive answers to those queries that are usually referrals to other name servers.
.PP
By default \fBhost\fR uses UDP when making queries. The
\fB-T\fR option makes it use a TCP connection when querying
the name server. TCP will be automatically selected for queries that
require it, such as zone transfer (AXFR) requests.
By default
\fBhost\fR
uses UDP when making queries. The
\fB\-T\fR
option makes it use a TCP connection when querying the name server. TCP will be automatically selected for queries that require it, such as zone transfer (AXFR) requests.
.PP
The \fB-4\fR option forces \fBhost\fR to only
use IPv4 query transport. The \fB-6\fR option forces
\fBhost\fR to only use IPv6 query transport.
The
\fB\-4\fR
option forces
\fBhost\fR
to only use IPv4 query transport. The
\fB\-6\fR
option forces
\fBhost\fR
to only use IPv6 query transport.
.PP
The \fB-t\fR option is used to select the query type.
\fItype\fR can be any recognised query type: CNAME,
NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified,
\fBhost\fR automatically selects an appropriate query
type. By default it looks for A records, but if the
\fB-C\fR option was given, queries will be made for SOA
records, and if \fIname\fR is a dotted-decimal IPv4
address or colon-delimited IPv6 address, \fBhost\fR will
query for PTR records. If a query type of IXFR is chosen the starting
serial number can be specified by appending an equal followed by the
starting serial number (e.g. -t IXFR=12345678).
The
\fB\-t\fR
option is used to select the query type.
\fItype\fR
can be any recognised query type: CNAME, NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified,
\fBhost\fR
automatically selects an appropriate query type. By default it looks for A records, but if the
\fB\-C\fR
option was given, queries will be made for SOA records, and if
\fIname\fR
is a dotted\-decimal IPv4 address or colon\-delimited IPv6 address,
\fBhost\fR
will query for PTR records. If a query type of IXFR is chosen the starting serial number can be specified by appending an equal followed by the starting serial number (e.g. \-t IXFR=12345678).
.PP
The time to wait for a reply can be controlled through the
\fB-W\fR and \fB-w\fR options. The
\fB-W\fR option makes \fBhost\fR wait for
\fIwait\fR seconds. If \fIwait\fR
\fB\-W\fR
and
\fB\-w\fR
options. The
\fB\-W\fR
option makes
\fBhost\fR
wait for
\fIwait\fR
seconds. If
\fIwait\fR
is less than one, the wait interval is set to one second. When the
\fB-w\fR option is used, \fBhost\fR will
effectively wait forever for a reply. The time to wait for a response
will be set to the number of seconds given by the hardware's maximum
value for an integer quantity.
\fB\-w\fR
option is used,
\fBhost\fR
will effectively wait forever for a reply. The time to wait for a response will be set to the number of seconds given by the hardware's maximum value for an integer quantity.
.SH "FILES"
.PP
\fI/etc/resolv.conf\fR

20
contrib/bind9/bin/dig/host.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: host.c,v 1.76.2.5.2.10 2004/09/06 01:33:05 marka Exp $ */
/* $Id: host.c,v 1.76.2.5.2.13 2005/07/04 03:29:45 marka Exp $ */
#include <config.h>
#include <limits.h>
@ -40,21 +40,6 @@
#include <dig/dig.h>
extern ISC_LIST(dig_lookup_t) lookup_list;
extern dig_serverlist_t server_list;
extern ISC_LIST(dig_searchlist_t) search_list;
extern isc_boolean_t have_ipv4, have_ipv6;
extern isc_boolean_t usesearch;
extern isc_boolean_t debugging;
extern unsigned int timeout;
extern isc_mem_t *mctx;
extern int ndots;
extern int tries;
extern char *progname;
extern isc_task_t *global_task;
extern int fatalexit;
static isc_boolean_t short_form = ISC_TRUE, listed_server = ISC_FALSE;
static isc_boolean_t default_lookups = ISC_TRUE;
static int seen_error = -1;
@ -604,6 +589,7 @@ parse_args(isc_boolean_t is_batchfile, int argc, char **argv) {
} else
list_type = rdtype;
list_addresses = ISC_FALSE;
default_lookups = ISC_FALSE;
break;
case 'c':
tr.base = isc_commandline_argument;

26
contrib/bind9/bin/dig/host.docbook
View file

@ -1,6 +1,8 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2002 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: host.docbook,v 1.2.2.2.4.5 2004/04/13 01:26:26 marka Exp $ -->
<!-- $Id: host.docbook,v 1.2.2.2.4.7 2005/05/13 01:22:32 marka Exp $ -->
<refentry>
@ -30,6 +32,20 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname>host</refname>
<refpurpose>DNS lookup utility</refpurpose>
@ -46,8 +62,8 @@
<arg><option>-W <replaceable class="parameter">wait</replaceable></option></arg>
<arg><option>-4</option></arg>
<arg><option>-6</option></arg>
<arg choice=req>name</arg>
<arg choice=opt>server</arg>
<arg choice="req">name</arg>
<arg choice="opt">server</arg>
</cmdsynopsis>
</refsynopsisdiv>

533
contrib/bind9/bin/dig/host.html
View file

@ -1,434 +1,171 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2002 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2002 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: host.html,v 1.4.2.1.4.6 2004/08/22 23:38:58 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>host</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
>host</H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN8"
></A
><H2
>Name</H2
>host&nbsp;--&nbsp;DNS lookup utility</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN11"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>host</B
> [<VAR
CLASS="OPTION"
>-aCdlnrTwv</VAR
>] [<VAR
CLASS="OPTION"
>-c <VAR
CLASS="REPLACEABLE"
>class</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-N <VAR
CLASS="REPLACEABLE"
>ndots</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-R <VAR
CLASS="REPLACEABLE"
>number</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-t <VAR
CLASS="REPLACEABLE"
>type</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-W <VAR
CLASS="REPLACEABLE"
>wait</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-4</VAR
>] [<VAR
CLASS="OPTION"
>-6</VAR
>] {name} [server]</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN37"
></A
><H2
>DESCRIPTION</H2
><P
><B
CLASS="COMMAND"
>host</B
>
<!-- $Id: host.html,v 1.4.2.1.4.12 2005/10/13 02:33:44 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>host</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p>host &#8212; DNS lookup utility</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">host</code> [<code class="option">-aCdlnrTwv</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-N <em class="replaceable"><code>ndots</code></em></code>] [<code class="option">-R <em class="replaceable"><code>number</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-W <em class="replaceable"><code>wait</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] {name} [server]</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525901"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">host</strong></span>
is a simple utility for performing DNS lookups.
It is normally used to convert names to IP addresses and vice versa.
When no arguments or options are given,
<B
CLASS="COMMAND"
>host</B
>
prints a short summary of its command line arguments and options.</P
><P
><VAR
CLASS="PARAMETER"
>name</VAR
> is the domain name that is to be looked
<span><strong class="command">host</strong></span>
prints a short summary of its command line arguments and options.
</p>
<p>
<em class="parameter"><code>name</code></em> is the domain name that is to be looked
up. It can also be a dotted-decimal IPv4 address or a colon-delimited
IPv6 address, in which case <B
CLASS="COMMAND"
>host</B
> will by default
IPv6 address, in which case <span><strong class="command">host</strong></span> will by default
perform a reverse lookup for that address.
<VAR
CLASS="PARAMETER"
>server</VAR
> is an optional argument which is either
the name or IP address of the name server that <B
CLASS="COMMAND"
>host</B
>
<em class="parameter"><code>server</code></em> is an optional argument which is either
the name or IP address of the name server that <span><strong class="command">host</strong></span>
should query instead of the server or servers listed in
<TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
>.</P
><P
>The <VAR
CLASS="OPTION"
>-a</VAR
> (all) option is equivalent to setting the
<VAR
CLASS="OPTION"
>-v</VAR
> option and asking <B
CLASS="COMMAND"
>host</B
> to make
a query of type ANY.</P
><P
>When the <VAR
CLASS="OPTION"
>-C</VAR
> option is used, <B
CLASS="COMMAND"
>host</B
>
<code class="filename">/etc/resolv.conf</code>.
</p>
<p>
The <code class="option">-a</code> (all) option is equivalent to setting the
<code class="option">-v</code> option and asking <span><strong class="command">host</strong></span> to make
a query of type ANY.
</p>
<p>
When the <code class="option">-C</code> option is used, <span><strong class="command">host</strong></span>
will attempt to display the SOA records for zone
<VAR
CLASS="PARAMETER"
>name</VAR
> from all the listed authoritative name
<em class="parameter"><code>name</code></em> from all the listed authoritative name
servers for that zone. The list of name servers is defined by the NS
records that are found for the zone.</P
><P
>The <VAR
CLASS="OPTION"
>-c</VAR
> option instructs to make a DNS query of class
<VAR
CLASS="PARAMETER"
>class</VAR
>. This can be used to lookup Hesiod or
Chaosnet class resource records. The default class is IN (Internet).</P
><P
>Verbose output is generated by <B
CLASS="COMMAND"
>host</B
> when the
<VAR
CLASS="OPTION"
>-d</VAR
> or <VAR
CLASS="OPTION"
>-v</VAR
> option is used. The two
records that are found for the zone.
</p>
<p>
The <code class="option">-c</code> option instructs to make a DNS query of class
<em class="parameter"><code>class</code></em>. This can be used to lookup Hesiod or
Chaosnet class resource records. The default class is IN (Internet).
</p>
<p>
Verbose output is generated by <span><strong class="command">host</strong></span> when the
<code class="option">-d</code> or <code class="option">-v</code> option is used. The two
options are equivalent. They have been provided for backwards
compatibility. In previous versions, the <VAR
CLASS="OPTION"
>-d</VAR
> option
switched on debugging traces and <VAR
CLASS="OPTION"
>-v</VAR
> enabled verbose
output.</P
><P
>List mode is selected by the <VAR
CLASS="OPTION"
>-l</VAR
> option. This makes
<B
CLASS="COMMAND"
>host</B
> perform a zone transfer for zone
<VAR
CLASS="PARAMETER"
>name</VAR
>. Transfer the zone printing out the NS, PTR
and address records (A/AAAA). If combined with <VAR
CLASS="OPTION"
>-a</VAR
>
all records will be printed. </P
><P
>The <VAR
CLASS="OPTION"
>-i</VAR
>
compatibility. In previous versions, the <code class="option">-d</code> option
switched on debugging traces and <code class="option">-v</code> enabled verbose
output.
</p>
<p>
List mode is selected by the <code class="option">-l</code> option. This makes
<span><strong class="command">host</strong></span> perform a zone transfer for zone
<em class="parameter"><code>name</code></em>. Transfer the zone printing out the NS, PTR
and address records (A/AAAA). If combined with <code class="option">-a</code>
all records will be printed.
</p>
<p>
The <code class="option">-i</code>
option specifies that reverse lookups of IPv6 addresses should
use the IP6.INT domain as defined in RFC1886.
The default is to use IP6.ARPA.</P
><P
>The <VAR
CLASS="OPTION"
>-N</VAR
> option sets the number of dots that have to be
in <VAR
CLASS="PARAMETER"
>name</VAR
> for it to be considered absolute. The
The default is to use IP6.ARPA.
</p>
<p>
The <code class="option">-N</code> option sets the number of dots that have to be
in <em class="parameter"><code>name</code></em> for it to be considered absolute. The
default value is that defined using the ndots statement in
<TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
>, or 1 if no ndots statement is
<code class="filename">/etc/resolv.conf</code>, or 1 if no ndots statement is
present. Names with fewer dots are interpreted as relative names and
will be searched for in the domains listed in the <SPAN
CLASS="TYPE"
>search</SPAN
>
or <SPAN
CLASS="TYPE"
>domain</SPAN
> directive in
<TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
>.</P
><P
>The number of UDP retries for a lookup can be changed with the
<VAR
CLASS="OPTION"
>-R</VAR
> option. <VAR
CLASS="PARAMETER"
>number</VAR
> indicates
how many times <B
CLASS="COMMAND"
>host</B
> will repeat a query that does
will be searched for in the domains listed in the <span class="type">search</span>
or <span class="type">domain</span> directive in
<code class="filename">/etc/resolv.conf</code>.
</p>
<p>
The number of UDP retries for a lookup can be changed with the
<code class="option">-R</code> option. <em class="parameter"><code>number</code></em> indicates
how many times <span><strong class="command">host</strong></span> will repeat a query that does
not get answered. The default number of retries is 1. If
<VAR
CLASS="PARAMETER"
>number</VAR
> is negative or zero, the number of
retries will default to 1.</P
><P
>Non-recursive queries can be made via the <VAR
CLASS="OPTION"
>-r</VAR
> option.
Setting this option clears the <SPAN
CLASS="TYPE"
>RD</SPAN
> &mdash; recursion
desired &mdash; bit in the query which <B
CLASS="COMMAND"
>host</B
> makes.
<em class="parameter"><code>number</code></em> is negative or zero, the number of
retries will default to 1.
</p>
<p>
Non-recursive queries can be made via the <code class="option">-r</code> option.
Setting this option clears the <span class="type">RD</span> &#8212; recursion
desired &#8212; bit in the query which <span><strong class="command">host</strong></span> makes.
This should mean that the name server receiving the query will not
attempt to resolve <VAR
CLASS="PARAMETER"
>name</VAR
>. The
<VAR
CLASS="OPTION"
>-r</VAR
> option enables <B
CLASS="COMMAND"
>host</B
> to mimic
attempt to resolve <em class="parameter"><code>name</code></em>. The
<code class="option">-r</code> option enables <span><strong class="command">host</strong></span> to mimic
the behaviour of a name server by making non-recursive queries and
expecting to receive answers to those queries that are usually
referrals to other name servers.</P
><P
>By default <B
CLASS="COMMAND"
>host</B
> uses UDP when making queries. The
<VAR
CLASS="OPTION"
>-T</VAR
> option makes it use a TCP connection when querying
referrals to other name servers.
</p>
<p>
By default <span><strong class="command">host</strong></span> uses UDP when making queries. The
<code class="option">-T</code> option makes it use a TCP connection when querying
the name server. TCP will be automatically selected for queries that
require it, such as zone transfer (AXFR) requests.</P
><P
>The <VAR
CLASS="OPTION"
>-4</VAR
> option forces <B
CLASS="COMMAND"
>host</B
> to only
use IPv4 query transport. The <VAR
CLASS="OPTION"
>-6</VAR
> option forces
<B
CLASS="COMMAND"
>host</B
> to only use IPv6 query transport.</P
><P
>The <VAR
CLASS="OPTION"
>-t</VAR
> option is used to select the query type.
<VAR
CLASS="PARAMETER"
>type</VAR
> can be any recognised query type: CNAME,
require it, such as zone transfer (AXFR) requests.
</p>
<p>
The <code class="option">-4</code> option forces <span><strong class="command">host</strong></span> to only
use IPv4 query transport. The <code class="option">-6</code> option forces
<span><strong class="command">host</strong></span> to only use IPv6 query transport.
</p>
<p>
The <code class="option">-t</code> option is used to select the query type.
<em class="parameter"><code>type</code></em> can be any recognised query type: CNAME,
NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified,
<B
CLASS="COMMAND"
>host</B
> automatically selects an appropriate query
<span><strong class="command">host</strong></span> automatically selects an appropriate query
type. By default it looks for A records, but if the
<VAR
CLASS="OPTION"
>-C</VAR
> option was given, queries will be made for SOA
records, and if <VAR
CLASS="PARAMETER"
>name</VAR
> is a dotted-decimal IPv4
address or colon-delimited IPv6 address, <B
CLASS="COMMAND"
>host</B
> will
<code class="option">-C</code> option was given, queries will be made for SOA
records, and if <em class="parameter"><code>name</code></em> is a dotted-decimal IPv4
address or colon-delimited IPv6 address, <span><strong class="command">host</strong></span> will
query for PTR records. If a query type of IXFR is chosen the starting
serial number can be specified by appending an equal followed by the
starting serial number (e.g. -t IXFR=12345678).</P
><P
>The time to wait for a reply can be controlled through the
<VAR
CLASS="OPTION"
>-W</VAR
> and <VAR
CLASS="OPTION"
>-w</VAR
> options. The
<VAR
CLASS="OPTION"
>-W</VAR
> option makes <B
CLASS="COMMAND"
>host</B
> wait for
<VAR
CLASS="PARAMETER"
>wait</VAR
> seconds. If <VAR
CLASS="PARAMETER"
>wait</VAR
>
starting serial number (e.g. -t IXFR=12345678).
</p>
<p>
The time to wait for a reply can be controlled through the
<code class="option">-W</code> and <code class="option">-w</code> options. The
<code class="option">-W</code> option makes <span><strong class="command">host</strong></span> wait for
<em class="parameter"><code>wait</code></em> seconds. If <em class="parameter"><code>wait</code></em>
is less than one, the wait interval is set to one second. When the
<VAR
CLASS="OPTION"
>-w</VAR
> option is used, <B
CLASS="COMMAND"
>host</B
> will
<code class="option">-w</code> option is used, <span><strong class="command">host</strong></span> will
effectively wait forever for a reply. The time to wait for a response
will be set to the number of seconds given by the hardware's maximum
value for an integer quantity.</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN115"
></A
><H2
>FILES</H2
><P
><TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
></P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN119"
></A
><H2
>SEE ALSO</H2
><P
><SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>dig</SPAN
>(1)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>named</SPAN
>(8)</SPAN
>.</P
></DIV
></BODY
></HTML
>
value for an integer quantity.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526241"></a><h2>FILES</h2>
<p>
<code class="filename">/etc/resolv.conf</code>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526253"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
</p>
</div>
</div></body>
</html>

54
contrib/bind9/bin/dig/include/dig/dig.h
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: dig.h,v 1.71.2.6.2.7 2004/09/06 01:33:06 marka Exp $ */
/* $Id: dig.h,v 1.71.2.6.2.11 2005/07/04 03:29:45 marka Exp $ */
#ifndef DIG_H
#define DIG_H
@ -35,7 +35,7 @@
#include <isc/sockaddr.h>
#include <isc/socket.h>
#define MXSERV 6
#define MXSERV 20
#define MXNAME (DNS_NAME_MAXTEXT+1)
#define MXRD 32
#define BUFSIZE 512
@ -66,14 +66,6 @@
* in a tight loop of constant lookups. It's value is arbitrary.
*/
#define ROOTNS 1
/*
* Set the number of root servers to ask for information when running in
* trace mode.
* XXXMWS -- trace mode is currently semi-broken, and this number *MUST*
* be 1.
*/
/*
* Defaults for the sigchase suboptions. Consolidated here because
* these control the layout of dig_lookup_t (among other things).
@ -224,6 +216,46 @@ struct dig_message {
ISC_LINK(dig_message_t) link;
};
#endif
typedef ISC_LIST(dig_searchlist_t) dig_searchlistlist_t;
typedef ISC_LIST(dig_lookup_t) dig_lookuplist_t;
/*
* Externals from dighost.c
*/
extern dig_lookuplist_t lookup_list;
extern dig_serverlist_t server_list;
extern dig_searchlistlist_t search_list;
extern isc_boolean_t have_ipv4, have_ipv6, specified_source,
usesearch, qr;
extern in_port_t port;
extern unsigned int timeout;
extern isc_mem_t *mctx;
extern dns_messageid_t id;
extern int sendcount;
extern int ndots;
extern int lookup_counter;
extern int exitcode;
extern isc_sockaddr_t bind_address;
extern char keynametext[MXNAME];
extern char keyfile[MXNAME];
extern char keysecret[MXNAME];
#ifdef DIG_SIGCHASE
extern char trustedkey[MXNAME];
#endif
extern dns_tsigkey_t *key;
extern isc_boolean_t validated;
extern isc_taskmgr_t *taskmgr;
extern isc_task_t *global_task;
extern isc_boolean_t free_now;
extern isc_boolean_t debugging, memdebugging;
extern char *progname;
extern int tries;
extern int fatalexit;
/*
* Routines in dighost.c.
*/

173
contrib/bind9/bin/dig/nslookup.1
View file

@ -1,76 +1,72 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: nslookup.1,v 1.1.6.2 2004/08/20 02:29:39 marka Exp $
.\" $Id: nslookup.1,v 1.1.6.5 2005/10/13 02:33:43 marka Exp $
.\"
.TH "NSLOOKUP" "1" "Jun 30, 2000" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "NSLOOKUP" "1" "Jun 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
nslookup \- query Internet name servers interactively
.SH SYNOPSIS
.sp
\fBnslookup\fR [ \fB-option\fR ] [ \fBname | -\fR ] [ \fBserver\fR ]
.SH "SYNOPSIS"
.HP 9
\fBnslookup\fR [\fB\-option\fR] [name\ |\ \-] [server]
.SH "DESCRIPTION"
.PP
\fBNslookup\fR
is a program to query Internet domain name servers. \fBNslookup\fR
has two modes: interactive and non-interactive. Interactive mode allows
the user to query name servers for information about various hosts and
domains or to print a list of hosts in a domain. Non-interactive mode is
used to print just the name and requested information for a host or
domain.
is a program to query Internet domain name servers.
\fBNslookup\fR
has two modes: interactive and non\-interactive. Interactive mode allows the user to query name servers for information about various hosts and domains or to print a list of hosts in a domain. Non\-interactive mode is used to print just the name and requested information for a host or domain.
.SH "ARGUMENTS"
.PP
Interactive mode is entered in the following cases:
.IP 1.
.TP 3
1.
when no arguments are given (the default name server will be used)
.IP 2.
when the first argument is a hyphen (-) and the second argument is
the host name or Internet address of a name server.
.TP
2.
when the first argument is a hyphen (\-) and the second argument is the host name or Internet address of a name server.
.PP
Non-interactive mode is used when the name or Internet address of the
host to be looked up is given as the first argument. The optional second
argument specifies the host name or address of a name server.
Non\-interactive mode is used when the name or Internet address of the host to be looked up is given as the first argument. The optional second argument specifies the host name or address of a name server.
.PP
Options can also be specified on the command line if they precede the
arguments and are prefixed with a hyphen. For example, to
change the default query type to host information, and the initial timeout to 10 seconds, type:
.PP
.sp
.nf
nslookup -query=hinfo -timeout=10
.sp
.fi
Options can also be specified on the command line if they precede the arguments and are prefixed with a hyphen. For example, to change the default query type to host information, and the initial timeout to 10 seconds, type:
.IP .sp .nf nslookup \-query=hinfo \-timeout=10 .fi
.SH "INTERACTIVE COMMANDS"
.TP
\fBhost [server]\fR
Look up information for host using the current default server or
using server, if specified. If host is an Internet address and
the query type is A or PTR, the name of the host is returned.
If host is a name and does not have a trailing period, the
search list is used to qualify the name.
To look up a host not in the current domain, append a period to
the name.
host [server]
Look up information for host using the current default server or using server, if specified. If host is an Internet address and the query type is A or PTR, the name of the host is returned. If host is a name and does not have a trailing period, the search list is used to qualify the name.
.sp
To look up a host not in the current domain, append a period to the name.
.TP
\fBserver \fIdomain\fB\fR
\fBserver\fR \fIdomain\fR
.TP
\fBlserver \fIdomain\fB\fR
Change the default server to \fIdomain\fR; lserver uses the initial
server to look up information about \fIdomain\fR, while server uses
the current default server. If an authoritative answer can't be
found, the names of servers that might have the answer are
returned.
\fBlserver\fR \fIdomain\fR
Change the default server to
\fIdomain\fR;
\fBlserver\fR
uses the initial server to look up information about
\fIdomain\fR, while
\fBserver\fR
uses the current default server. If an authoritative answer can't be found, the names of servers that might have the answer are returned.
.TP
\fBroot\fR
not implemented
@ -93,17 +89,15 @@ not implemented
\fBexit\fR
Exits the program.
.TP
\fBset \fIkeyword[=value]\fB\fR
This command is used to change state information that affects
the lookups. Valid keywords are:
\fBset\fR \fIkeyword\fR\fI[=value]\fR
This command is used to change state information that affects the lookups. Valid keywords are:
.RS
.TP
\fBall\fR
Prints the current values of the frequently used
options to \fBset\fR. Information about the current default
server and host is also printed.
Prints the current values of the frequently used options to
\fBset\fR. Information about the current default server and host is also printed.
.TP
\fBclass=\fIvalue\fB\fR
\fBclass=\fR\fIvalue\fR
Change the query class to one of:
.RS
.TP
@ -119,66 +113,61 @@ the Hesiod class
\fBANY\fR
wildcard
.RE
.PP
.IP
The class specifies the protocol group of the information.
.sp
(Default = IN; abbreviation = cl)
.TP
\fB\fI[no]\fBdebug\fR
Turn debugging mode on. A lot more information is
printed about the packet sent to the server and the
resulting answer.
(Default = nodebug; abbreviation = [no]deb)
\fB\fI[no]\fR\fR\fBdebug\fR
Turn debugging mode on. A lot more information is printed about the packet sent to the server and the resulting answer.
.sp
(Default = nodebug; abbreviation =
[no]deb)
.TP
\fB\fI[no]\fBd2\fR
Turn debugging mode on. A lot more information is
printed about the packet sent to the server and the
resulting answer.
\fB\fI[no]\fR\fR\fBd2\fR
Turn debugging mode on. A lot more information is printed about the packet sent to the server and the resulting answer.
.sp
(Default = nod2)
.TP
\fBdomain=\fIname\fB\fR
Sets the search list to \fIname\fR.
\fBdomain=\fR\fIname\fR
Sets the search list to
\fIname\fR.
.TP
\fB\fI[no]\fBsearch\fR
If the lookup request contains at least one period but
doesn't end with a trailing period, append the domain
names in the domain search list to the request until an
answer is received.
\fB\fI[no]\fR\fR\fBsearch\fR
If the lookup request contains at least one period but doesn't end with a trailing period, append the domain names in the domain search list to the request until an answer is received.
.sp
(Default = search)
.TP
\fBport=\fIvalue\fB\fR
Change the default TCP/UDP name server port to \fIvalue\fR.
\fBport=\fR\fIvalue\fR
Change the default TCP/UDP name server port to
\fIvalue\fR.
.sp
(Default = 53; abbreviation = po)
.TP
\fBquerytype=\fIvalue\fB\fR
\fBquerytype=\fR\fIvalue\fR
.TP
\fBtype=\fIvalue\fB\fR
\fBtype=\fR\fIvalue\fR
Change the top of the information query.
.sp
(Default = A; abbreviations = q, ty)
.TP
\fB\fI[no]\fBrecurse\fR
Tell the name server to query other servers if it does not have the
information.
\fB\fI[no]\fR\fR\fBrecurse\fR
Tell the name server to query other servers if it does not have the information.
.sp
(Default = recurse; abbreviation = [no]rec)
.TP
\fBretry=\fInumber\fB\fR
\fBretry=\fR\fInumber\fR
Set the number of retries to number.
.TP
\fBtimeout=\fInumber\fB\fR
Change the initial timeout interval for waiting for a
reply to number seconds.
\fBtimeout=\fR\fInumber\fR
Change the initial timeout interval for waiting for a reply to number seconds.
.TP
\fB\fI[no]\fBvc\fR
\fB\fI[no]\fR\fR\fBvc\fR
Always use a virtual circuit when sending requests to the server.
.sp
(Default = novc)
.RE
.IP
.SH "FILES"
.PP
\fI/etc/resolv.conf\fR

17
contrib/bind9/bin/dig/nslookup.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: nslookup.c,v 1.90.2.4.2.8 2004/09/06 01:33:05 marka Exp $ */
/* $Id: nslookup.c,v 1.90.2.4.2.10 2005/07/12 05:47:42 marka Exp $ */
#include <config.h>
@ -44,19 +44,6 @@
#include <dig/dig.h>
extern ISC_LIST(dig_lookup_t) lookup_list;
extern dig_serverlist_t server_list;
extern ISC_LIST(dig_searchlist_t) search_list;
extern isc_boolean_t usesearch, debugging;
extern in_port_t port;
extern unsigned int timeout;
extern isc_mem_t *mctx;
extern int tries;
extern int lookup_counter;
extern isc_task_t *global_task;
extern char *progname;
static isc_boolean_t short_form = ISC_TRUE,
tcpmode = ISC_FALSE,
identify = ISC_FALSE, stats = ISC_TRUE,

40
contrib/bind9/bin/dig/nslookup.docbook
View file

@ -1,6 +1,8 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -15,7 +17,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: nslookup.docbook,v 1.3.6.3 2004/08/30 00:50:11 marka Exp $ -->
<!-- $Id: nslookup.docbook,v 1.3.6.5 2005/05/13 01:22:33 marka Exp $ -->
<!--
- Copyright (c) 1985, 1989
@ -62,6 +64,14 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
</docinfo>
<refnamediv>
<refname>nslookup</refname>
<refpurpose>query Internet name servers interactively</refpurpose>
@ -71,8 +81,8 @@
<cmdsynopsis>
<command>nslookup</command>
<arg><option>-option</option></arg>
<arg choice=opt>name | -</arg>
<arg choice=opt>server</arg>
<arg choice="opt">name | -</arg>
<arg choice="opt">server</arg>
</cmdsynopsis>
</refsynopsisdiv>
@ -93,19 +103,19 @@ domain.
<title>ARGUMENTS</title>
<para>
Interactive mode is entered in the following cases:
<OrderedList Numeration=Loweralpha>
<Listitem>
<orderedlist numeration="loweralpha">
<listitem>
<para>
when no arguments are given (the default name server will be used)
</para>
</Listitem>
<Listitem>
</listitem>
<listitem>
<para>
when the first argument is a hyphen (-) and the second argument is
the host name or Internet address of a name server.
</para>
</Listitem>
</OrderedList>
</listitem>
</orderedlist>
</para>
<para>
@ -118,11 +128,11 @@ argument specifies the host name or address of a name server.
Options can also be specified on the command line if they precede the
arguments and are prefixed with a hyphen. For example, to
change the default query type to host information, and the initial timeout to 10 seconds, type:
<InformalExample>
<PROGRAMLISTING>
<informalexample>
<programlisting>
nslookup -query=hinfo -timeout=10
</PROGRAMLISTING>
</InformalExample>
</programlisting>
</informalexample>
</para>
</refsect1>

811
contrib/bind9/bin/dig/nslookup.html
View file

@ -1,617 +1,264 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: nslookup.html,v 1.1.6.3 2004/08/22 23:38:58 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>nslookup</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
>nslookup</H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN8"
></A
><H2
>Name</H2
>nslookup&nbsp;--&nbsp;query Internet name servers interactively</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN11"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>nslookup</B
> [<VAR
CLASS="OPTION"
>-option</VAR
>] [name | -] [server]</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN18"
></A
><H2
>DESCRIPTION</H2
><P
><B
CLASS="COMMAND"
>Nslookup</B
>
is a program to query Internet domain name servers. <B
CLASS="COMMAND"
>Nslookup</B
>
<!-- $Id: nslookup.html,v 1.1.6.9 2005/10/13 02:33:44 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>nslookup</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463728"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p>nslookup &#8212; query Internet name servers interactively</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">nslookup</code> [<code class="option">-option</code>] [name | -] [server]</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525973"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">Nslookup</strong></span>
is a program to query Internet domain name servers. <span><strong class="command">Nslookup</strong></span>
has two modes: interactive and non-interactive. Interactive mode allows
the user to query name servers for information about various hosts and
domains or to print a list of hosts in a domain. Non-interactive mode is
used to print just the name and requested information for a host or
domain.</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN23"
></A
><H2
>ARGUMENTS</H2
><P
>Interactive mode is entered in the following cases:
<P
></P
><OL
TYPE="a"
><LI
><P
>when no arguments are given (the default name server will be used)</P
></LI
><LI
><P
>when the first argument is a hyphen (-) and the second argument is
the host name or Internet address of a name server.</P
></LI
></OL
></P
><P
>Non-interactive mode is used when the name or Internet address of the
domain.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525990"></a><h2>ARGUMENTS</h2>
<p>
Interactive mode is entered in the following cases:
</p>
<div class="orderedlist"><ol type="a">
<li><p>
when no arguments are given (the default name server will be used)
</p></li>
<li><p>
when the first argument is a hyphen (-) and the second argument is
the host name or Internet address of a name server.
</p></li>
</ol></div>
<p>
</p>
<p>
Non-interactive mode is used when the name or Internet address of the
host to be looked up is given as the first argument. The optional second
argument specifies the host name or address of a name server.</P
><P
>Options can also be specified on the command line if they precede the
argument specifies the host name or address of a name server.
</p>
<p>
Options can also be specified on the command line if they precede the
arguments and are prefixed with a hyphen. For example, to
change the default query type to host information, and the initial timeout to 10 seconds, type:
<DIV
CLASS="INFORMALEXAMPLE"
><P
></P
><A
NAME="AEN33"
></A
><PRE
CLASS="PROGRAMLISTING"
>nslookup -query=hinfo -timeout=10</PRE
><P
></P
></DIV
></P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN35"
></A
><H2
>INTERACTIVE COMMANDS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>host [<SPAN
CLASS="OPTIONAL"
>server</SPAN
>]</DT
><DD
><P
>Look up information for host using the current default server or
</p>
<div class="informalexample"><pre class="programlisting">
nslookup -query=hinfo -timeout=10
</pre></div>
<p>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526033"></a><h2>INTERACTIVE COMMANDS</h2>
<div class="variablelist"><dl>
<dt><span class="term">host [<span class="optional">server</span>]</span></dt>
<dd>
<p>
Look up information for host using the current default server or
using server, if specified. If host is an Internet address and
the query type is A or PTR, the name of the host is returned.
If host is a name and does not have a trailing period, the
search list is used to qualify the name.</P
><P
>To look up a host not in the current domain, append a period to
the name.</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>server</CODE
> <VAR
CLASS="REPLACEABLE"
>domain</VAR
></DT
><DD
><P
></P
></DD
><DT
><CODE
CLASS="CONSTANT"
>lserver</CODE
> <VAR
CLASS="REPLACEABLE"
>domain</VAR
></DT
><DD
><P
>Change the default server to <VAR
CLASS="REPLACEABLE"
>domain</VAR
>; <CODE
CLASS="CONSTANT"
>lserver</CODE
> uses the initial
server to look up information about <VAR
CLASS="REPLACEABLE"
>domain</VAR
>, while <CODE
CLASS="CONSTANT"
>server</CODE
> uses
search list is used to qualify the name.
</p>
<p>
To look up a host not in the current domain, append a period to
the name.
</p>
</dd>
<dt><span class="term"><code class="constant">server</code> <em class="replaceable"><code>domain</code></em></span></dt>
<dd><p></p></dd>
<dt><span class="term"><code class="constant">lserver</code> <em class="replaceable"><code>domain</code></em></span></dt>
<dd><p>
Change the default server to <em class="replaceable"><code>domain</code></em>; <code class="constant">lserver</code> uses the initial
server to look up information about <em class="replaceable"><code>domain</code></em>, while <code class="constant">server</code> uses
the current default server. If an authoritative answer can't be
found, the names of servers that might have the answer are
returned.</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>root</CODE
></DT
><DD
><P
>not implemented</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>finger</CODE
></DT
><DD
><P
>not implemented</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>ls</CODE
></DT
><DD
><P
>not implemented</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>view</CODE
></DT
><DD
><P
>not implemented</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>help</CODE
></DT
><DD
><P
>not implemented</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>?</CODE
></DT
><DD
><P
>not implemented</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>exit</CODE
></DT
><DD
><P
>Exits the program.</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>set</CODE
> <VAR
CLASS="REPLACEABLE"
>keyword[<SPAN
CLASS="OPTIONAL"
>=value</SPAN
>]</VAR
></DT
><DD
><P
>This command is used to change state information that affects
returned.
</p></dd>
<dt><span class="term"><code class="constant">root</code></span></dt>
<dd><p>not implemented</p></dd>
<dt><span class="term"><code class="constant">finger</code></span></dt>
<dd><p>not implemented</p></dd>
<dt><span class="term"><code class="constant">ls</code></span></dt>
<dd><p>not implemented</p></dd>
<dt><span class="term"><code class="constant">view</code></span></dt>
<dd><p>not implemented</p></dd>
<dt><span class="term"><code class="constant">help</code></span></dt>
<dd><p>not implemented</p></dd>
<dt><span class="term"><code class="constant">?</code></span></dt>
<dd><p>not implemented</p></dd>
<dt><span class="term"><code class="constant">exit</code></span></dt>
<dd><p>Exits the program.</p></dd>
<dt><span class="term"><code class="constant">set</code> <em class="replaceable"><code>keyword[<span class="optional">=value</span>]</code></em></span></dt>
<dd>
<p>This command is used to change state information that affects
the lookups. Valid keywords are:
<P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><CODE
CLASS="CONSTANT"
>all</CODE
></DT
><DD
><P
>Prints the current values of the frequently used
options to <B
CLASS="COMMAND"
>set</B
>. Information about the current default
</p>
<div class="variablelist"><dl>
<dt><span class="term"><code class="constant">all</code></span></dt>
<dd><p>Prints the current values of the frequently used
options to <span><strong class="command">set</strong></span>. Information about the current default
server and host is also printed.
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>class=</CODE
><VAR
CLASS="REPLACEABLE"
>value</VAR
></DT
><DD
><P
> Change the query class to one of:
<P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><CODE
CLASS="CONSTANT"
>IN</CODE
></DT
><DD
><P
>the Internet class</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>CH</CODE
></DT
><DD
><P
>the Chaos class</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>HS</CODE
></DT
><DD
><P
>the Hesiod class</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>ANY</CODE
></DT
><DD
><P
>wildcard</P
></DD
></DL
></DIV
>
</p></dd>
<dt><span class="term"><code class="constant">class=</code><em class="replaceable"><code>value</code></em></span></dt>
<dd>
<p>
Change the query class to one of:
</p>
<div class="variablelist"><dl>
<dt><span class="term"><code class="constant">IN</code></span></dt>
<dd><p>the Internet class</p></dd>
<dt><span class="term"><code class="constant">CH</code></span></dt>
<dd><p>the Chaos class</p></dd>
<dt><span class="term"><code class="constant">HS</code></span></dt>
<dd><p>the Hesiod class</p></dd>
<dt><span class="term"><code class="constant">ANY</code></span></dt>
<dd><p>wildcard</p></dd>
</dl></div>
<p>
The class specifies the protocol group of the information.
</P
><P
> (Default = IN; abbreviation = cl)
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
><VAR
CLASS="REPLACEABLE"
>[<SPAN
CLASS="OPTIONAL"
>no</SPAN
>]</VAR
>debug</CODE
></DT
><DD
><P
> Turn debugging mode on. A lot more information is
</p>
<p>
(Default = IN; abbreviation = cl)
</p>
</dd>
<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>debug</code></span></dt>
<dd>
<p>
Turn debugging mode on. A lot more information is
printed about the packet sent to the server and the
resulting answer.
</P
><P
> (Default = nodebug; abbreviation = [<SPAN
CLASS="OPTIONAL"
>no</SPAN
>]deb)
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
><VAR
CLASS="REPLACEABLE"
>[<SPAN
CLASS="OPTIONAL"
>no</SPAN
>]</VAR
>d2</CODE
></DT
><DD
><P
> Turn debugging mode on. A lot more information is
</p>
<p>
(Default = nodebug; abbreviation = [<span class="optional">no</span>]deb)
</p>
</dd>
<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>d2</code></span></dt>
<dd>
<p>
Turn debugging mode on. A lot more information is
printed about the packet sent to the server and the
resulting answer.
</P
><P
> (Default = nod2)
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>domain=</CODE
><VAR
CLASS="REPLACEABLE"
>name</VAR
></DT
><DD
><P
> Sets the search list to <VAR
CLASS="REPLACEABLE"
>name</VAR
>.
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
><VAR
CLASS="REPLACEABLE"
>[<SPAN
CLASS="OPTIONAL"
>no</SPAN
>]</VAR
>search</CODE
></DT
><DD
><P
> If the lookup request contains at least one period but
</p>
<p>
(Default = nod2)
</p>
</dd>
<dt><span class="term"><code class="constant">domain=</code><em class="replaceable"><code>name</code></em></span></dt>
<dd><p>
Sets the search list to <em class="replaceable"><code>name</code></em>.
</p></dd>
<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>search</code></span></dt>
<dd>
<p>
If the lookup request contains at least one period but
doesn't end with a trailing period, append the domain
names in the domain search list to the request until an
answer is received.
</P
><P
> (Default = search)
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>port=</CODE
><VAR
CLASS="REPLACEABLE"
>value</VAR
></DT
><DD
><P
> Change the default TCP/UDP name server port to <VAR
CLASS="REPLACEABLE"
>value</VAR
>.
</P
><P
> (Default = 53; abbreviation = po)
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>querytype=</CODE
><VAR
CLASS="REPLACEABLE"
>value</VAR
></DT
><DD
><P
></P
></DD
><DT
><CODE
CLASS="CONSTANT"
>type=</CODE
><VAR
CLASS="REPLACEABLE"
>value</VAR
></DT
><DD
><P
> Change the top of the information query.
</P
><P
> (Default = A; abbreviations = q, ty)
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
><VAR
CLASS="REPLACEABLE"
>[<SPAN
CLASS="OPTIONAL"
>no</SPAN
>]</VAR
>recurse</CODE
></DT
><DD
><P
> Tell the name server to query other servers if it does not have the
</p>
<p>
(Default = search)
</p>
</dd>
<dt><span class="term"><code class="constant">port=</code><em class="replaceable"><code>value</code></em></span></dt>
<dd>
<p>
Change the default TCP/UDP name server port to <em class="replaceable"><code>value</code></em>.
</p>
<p>
(Default = 53; abbreviation = po)
</p>
</dd>
<dt><span class="term"><code class="constant">querytype=</code><em class="replaceable"><code>value</code></em></span></dt>
<dd><p></p></dd>
<dt><span class="term"><code class="constant">type=</code><em class="replaceable"><code>value</code></em></span></dt>
<dd>
<p>
Change the top of the information query.
</p>
<p>
(Default = A; abbreviations = q, ty)
</p>
</dd>
<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>recurse</code></span></dt>
<dd>
<p>
Tell the name server to query other servers if it does not have the
information.
</P
><P
> (Default = recurse; abbreviation = [no]rec)
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>retry=</CODE
><VAR
CLASS="REPLACEABLE"
>number</VAR
></DT
><DD
><P
> Set the number of retries to number.
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
>timeout=</CODE
><VAR
CLASS="REPLACEABLE"
>number</VAR
></DT
><DD
><P
> Change the initial timeout interval for waiting for a
</p>
<p>
(Default = recurse; abbreviation = [no]rec)
</p>
</dd>
<dt><span class="term"><code class="constant">retry=</code><em class="replaceable"><code>number</code></em></span></dt>
<dd><p>
Set the number of retries to number.
</p></dd>
<dt><span class="term"><code class="constant">timeout=</code><em class="replaceable"><code>number</code></em></span></dt>
<dd><p>
Change the initial timeout interval for waiting for a
reply to number seconds.
</P
></DD
><DT
><CODE
CLASS="CONSTANT"
><VAR
CLASS="REPLACEABLE"
>[<SPAN
CLASS="OPTIONAL"
>no</SPAN
>]</VAR
>vc</CODE
></DT
><DD
><P
> Always use a virtual circuit when sending requests to the server.
</P
><P
> (Default = novc)
</P
></DD
></DL
></DIV
></P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN218"
></A
><H2
>FILES</H2
><P
><TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
></P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN222"
></A
><H2
>SEE ALSO</H2
><P
><SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>dig</SPAN
>(1)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>host</SPAN
>(1)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>named</SPAN
>(8)</SPAN
>.</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN234"
></A
><H2
>Author</H2
><P
>Andrew Cherenson</P
></DIV
></BODY
></HTML
>
</p></dd>
<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>vc</code></span></dt>
<dd>
<p>
Always use a virtual circuit when sending requests to the server.
</p>
<p>
(Default = novc)
</p>
</dd>
</dl></div>
<p>
</p>
</dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526490"></a><h2>FILES</h2>
<p>
<code class="filename">/etc/resolv.conf</code>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526503"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526538"></a><h2>Author</h2>
<p>
Andrew Cherenson
</p>
</div>
</div></body>
</html>

7
contrib/bind9/bin/dnssec/Makefile.in
View file

@ -1,4 +1,4 @@
# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2000-2002 Internet Software Consortium.
#
# Permission to use, copy, modify, and distribute this software for any
@ -13,7 +13,7 @@
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.
# $Id: Makefile.in,v 1.19.12.9 2004/07/20 07:01:48 marka Exp $
# $Id: Makefile.in,v 1.19.12.12 2005/05/02 00:25:54 marka Exp $
srcdir = @srcdir@
VPATH = @srcdir@
@ -58,7 +58,8 @@ dnssec-keygen@EXEEXT@: dnssec-keygen.@O@ ${OBJS} ${DEPLIBS}
dnssec-keygen.@O@ ${OBJS} ${LIBS}
dnssec-signzone.@O@: dnssec-signzone.c
${LIBTOOL_MODE_COMPILE} ${PURIFY} ${CC} ${ALL_CFLAGS} -c $<
${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} -DVERSION=\"${VERSION}\" \
-c ${srcdir}/dnssec-signzone.c
dnssec-signzone@EXEEXT@: dnssec-signzone.@O@ ${OBJS} ${DEPLIBS}
${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \

222
contrib/bind9/bin/dnssec/dnssec-keygen.8
View file

@ -1,174 +1,164 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2003 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2003 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: dnssec-keygen.8,v 1.19.12.5 2004/06/11 02:32:45 marka Exp $
.\" $Id: dnssec-keygen.8,v 1.19.12.9 2005/10/13 02:33:45 marka Exp $
.\"
.TH "DNSSEC-KEYGEN" "8" "June 30, 2000" "BIND9" ""
.SH NAME
dnssec-keygen \- DNSSEC key generation tool
.SH SYNOPSIS
.sp
\fBdnssec-keygen\fR \fB-a \fIalgorithm\fB\fR \fB-b \fIkeysize\fB\fR \fB-n \fInametype\fB\fR [ \fB-c \fIclass\fB\fR ] [ \fB-e\fR ] [ \fB-f \fIflag\fB\fR ] [ \fB-g \fIgenerator\fB\fR ] [ \fB-h\fR ] [ \fB-k\fR ] [ \fB-p \fIprotocol\fB\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstrength\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-v \fIlevel\fB\fR ] \fBname\fR
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "DNSSEC\-KEYGEN" "8" "June 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
dnssec\-keygen \- DNSSEC key generation tool
.SH "SYNOPSIS"
.HP 14
\fBdnssec\-keygen\fR {\-a\ \fIalgorithm\fR} {\-b\ \fIkeysize\fR} {\-n\ \fInametype\fR} [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-e\fR] [\fB\-f\ \fR\fB\fIflag\fR\fR] [\fB\-g\ \fR\fB\fIgenerator\fR\fR] [\fB\-h\fR] [\fB\-k\fR] [\fB\-p\ \fR\fB\fIprotocol\fR\fR] [\fB\-r\ \fR\fB\fIrandomdev\fR\fR] [\fB\-s\ \fR\fB\fIstrength\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-v\ \fR\fB\fIlevel\fR\fR] {name}
.SH "DESCRIPTION"
.PP
\fBdnssec-keygen\fR generates keys for DNSSEC
(Secure DNS), as defined in RFC 2535 and RFC <TBA\\>. It can also generate
keys for use with TSIG (Transaction Signatures), as
defined in RFC 2845.
\fBdnssec\-keygen\fR
generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 and RFC <TBA\\>. It can also generate keys for use with TSIG (Transaction Signatures), as defined in RFC 2845.
.SH "OPTIONS"
.TP
\fB-a \fIalgorithm\fB\fR
\-a \fIalgorithm\fR
Selects the cryptographic algorithm. The value of
\fBalgorithm\fR must be one of RSAMD5 (RSA) or RSASHA1,
DSA, DH (Diffie Hellman), or HMAC-MD5. These values
are case insensitive.
Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm,
and DSA is recommended. For TSIG, HMAC-MD5 is mandatory.
Note 2: HMAC-MD5 and DH automatically set the -k flag.
\fBalgorithm\fR
must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC\-MD5. These values are case insensitive.
.sp
Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, and DSA is recommended. For TSIG, HMAC\-MD5 is mandatory.
.sp
Note 2: HMAC\-MD5 and DH automatically set the \-k flag.
.TP
\fB-b \fIkeysize\fB\fR
Specifies the number of bits in the key. The choice of key
size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between
512 and 2048 bits. Diffie Hellman keys must be between
128 and 4096 bits. DSA keys must be between 512 and 1024
bits and an exact multiple of 64. HMAC-MD5 keys must be
between 1 and 512 bits.
\-b \fIkeysize\fR
Specifies the number of bits in the key. The choice of key size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between 512 and 2048 bits. Diffie Hellman keys must be between 128 and 4096 bits. DSA keys must be between 512 and 1024 bits and an exact multiple of 64. HMAC\-MD5 keys must be between 1 and 512 bits.
.TP
\fB-n \fInametype\fB\fR
\-n \fInametype\fR
Specifies the owner type of the key. The value of
\fBnametype\fR must either be ZONE (for a DNSSEC
zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)),
USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are
case insensitive.
\fBnametype\fR
must either be ZONE (for a DNSSEC zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are case insensitive.
.TP
\fB-c \fIclass\fB\fR
Indicates that the DNS record containing the key should have
the specified class. If not specified, class IN is used.
\-c \fIclass\fR
Indicates that the DNS record containing the key should have the specified class. If not specified, class IN is used.
.TP
\fB-e\fR
\-e
If generating an RSAMD5/RSASHA1 key, use a large exponent.
.TP
\fB-f \fIflag\fB\fR
Set the specified flag in the flag field of the KEY/DNSKEY record.
The only recognized flag is KSK (Key Signing Key) DNSKEY.
\-f \fIflag\fR
Set the specified flag in the flag field of the KEY/DNSKEY record. The only recognized flag is KSK (Key Signing Key) DNSKEY.
.TP
\fB-g \fIgenerator\fB\fR
If generating a Diffie Hellman key, use this generator.
Allowed values are 2 and 5. If no generator
is specified, a known prime from RFC 2539 will be used
if possible; otherwise the default is 2.
\-g \fIgenerator\fR
If generating a Diffie Hellman key, use this generator. Allowed values are 2 and 5. If no generator is specified, a known prime from RFC 2539 will be used if possible; otherwise the default is 2.
.TP
\fB-h\fR
\-h
Prints a short summary of the options and arguments to
\fBdnssec-keygen\fR.
\fBdnssec\-keygen\fR.
.TP
\fB-k\fR
\-k
Generate KEY records rather than DNSKEY records.
.TP
\fB-p \fIprotocol\fB\fR
Sets the protocol value for the generated key. The protocol
is a number between 0 and 255. The default is 3 (DNSSEC).
Other possible values for this argument are listed in
RFC 2535 and its successors.
\-p \fIprotocol\fR
Sets the protocol value for the generated key. The protocol is a number between 0 and 255. The default is 3 (DNSSEC). Other possible values for this argument are listed in RFC 2535 and its successors.
.TP
\fB-r \fIrandomdev\fB\fR
Specifies the source of randomness. If the operating
system does not provide a \fI/dev/random\fR
or equivalent device, the default source of randomness
is keyboard input. \fIrandomdev\fR specifies
the name of a character device or file containing random
data to be used instead of the default. The special value
\fIkeyboard\fR indicates that keyboard
input should be used.
\-r \fIrandomdev\fR
Specifies the source of randomness. If the operating system does not provide a
\fI/dev/random\fR
or equivalent device, the default source of randomness is keyboard input.
\fIrandomdev\fR
specifies the name of a character device or file containing random data to be used instead of the default. The special value
\fIkeyboard\fR
indicates that keyboard input should be used.
.TP
\fB-s \fIstrength\fB\fR
Specifies the strength value of the key. The strength is
a number between 0 and 15, and currently has no defined
purpose in DNSSEC.
\-s \fIstrength\fR
Specifies the strength value of the key. The strength is a number between 0 and 15, and currently has no defined purpose in DNSSEC.
.TP
\fB-t \fItype\fB\fR
Indicates the use of the key. \fBtype\fR must be
one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default
is AUTHCONF. AUTH refers to the ability to authenticate
data, and CONF the ability to encrypt data.
\-t \fItype\fR
Indicates the use of the key.
\fBtype\fR
must be one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default is AUTHCONF. AUTH refers to the ability to authenticate data, and CONF the ability to encrypt data.
.TP
\fB-v \fIlevel\fB\fR
\-v \fIlevel\fR
Sets the debugging level.
.SH "GENERATED KEYS"
.PP
When \fBdnssec-keygen\fR completes successfully,
it prints a string of the form \fIKnnnn.+aaa+iiiii\fR
to the standard output. This is an identification string for
the key it has generated. These strings can be used as arguments
to \fBdnssec-makekeyset\fR.
.TP 0.2i
When
\fBdnssec\-keygen\fR
completes successfully, it prints a string of the form
\fIKnnnn.+aaa+iiiii\fR
to the standard output. This is an identification string for the key it has generated.
.TP 3
\(bu
\fInnnn\fR is the key name.
.TP 0.2i
\fInnnn\fR
is the key name.
.TP
\(bu
\fIaaa\fR is the numeric representation of the
algorithm.
.TP 0.2i
\fIaaa\fR
is the numeric representation of the algorithm.
.TP
\(bu
\fIiiiii\fR is the key identifier (or footprint).
\fIiiiii\fR
is the key identifier (or footprint).
.PP
\fBdnssec-keygen\fR creates two file, with names based
on the printed string. \fIKnnnn.+aaa+iiiii.key\fR
\fBdnssec\-keygen\fR
creates two file, with names based on the printed string.
\fIKnnnn.+aaa+iiiii.key\fR
contains the public key, and
\fIKnnnn.+aaa+iiiii.private\fR contains the private
key.
\fIKnnnn.+aaa+iiiii.private\fR
contains the private key.
.PP
The
\fI.key\fR
file contains a DNS KEY record that can be inserted into a zone file (directly or with a $INCLUDE statement).
.PP
The \fI.key\fR file contains a DNS KEY record that
can be inserted into a zone file (directly or with a $INCLUDE
statement).
.PP
.PP
The \fI.private\fR file contains algorithm specific
fields. For obvious security reasons, this file does not have
general read permission.
.PP
.PP
Both \fI.key\fR and \fI.private\fR
files are generated for symmetric encryption algorithm such as
HMAC-MD5, even though the public and private key are equivalent.
The
\fI.private\fR
file contains algorithm specific fields. For obvious security reasons, this file does not have general read permission.
.PP
Both
\fI.key\fR
and
\fI.private\fR
files are generated for symmetric encryption algorithm such as HMAC\-MD5, even though the public and private key are equivalent.
.SH "EXAMPLE"
.PP
To generate a 768-bit DSA key for the domain
\fBexample.com\fR, the following command would be
issued:
To generate a 768\-bit DSA key for the domain
\fBexample.com\fR, the following command would be issued:
.PP
\fBdnssec-keygen -a DSA -b 768 -n ZONE example.com\fR
\fBdnssec\-keygen \-a DSA \-b 768 \-n ZONE example.com\fR
.PP
The command would print a string of the form:
.PP
\fBKexample.com.+003+26160\fR
.PP
In this example, \fBdnssec-keygen\fR creates
the files \fIKexample.com.+003+26160.key\fR and
In this example,
\fBdnssec\-keygen\fR
creates the files
\fIKexample.com.+003+26160.key\fR
and
\fIKexample.com.+003+26160.private\fR
.SH "SEE ALSO"
.PP
\fBdnssec-signzone\fR(8),
\fIBIND 9 Administrator Reference Manual\fR,
\fIRFC 2535\fR,
\fIRFC 2845\fR,
\fIRFC 2539\fR.
\fBdnssec\-signzone\fR(8),
BIND 9 Administrator Reference Manual,
RFC 2535,
RFC 2845,
RFC 2539.
.SH "AUTHOR"
.PP
Internet Systems Consortium

28
contrib/bind9/bin/dnssec/dnssec-keygen.docbook
View file

@ -1,7 +1,9 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001-2003 Internet Software Consortium.
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: dnssec-keygen.docbook,v 1.3.12.6 2004/06/11 01:17:34 marka Exp $ -->
<!-- $Id: dnssec-keygen.docbook,v 1.3.12.9 2005/08/30 01:41:41 marka Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,21 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><application>dnssec-keygen</application></refname>
<refpurpose>DNSSEC key generation tool</refpurpose>
@ -244,8 +261,7 @@
When <command>dnssec-keygen</command> completes successfully,
it prints a string of the form <filename>Knnnn.+aaa+iiiii</filename>
to the standard output. This is an identification string for
the key it has generated. These strings can be used as arguments
to <command>dnssec-makekeyset</command>.
the key it has generated.
</para>
<itemizedlist>
<listitem>

666
contrib/bind9/bin/dnssec/dnssec-keygen.html
View file

@ -1,544 +1,228 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001-2003 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: dnssec-keygen.html,v 1.5.2.1.4.6 2004/08/22 23:38:58 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>dnssec-keygen</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><SPAN
CLASS="APPLICATION"
>dnssec-keygen</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><SPAN
CLASS="APPLICATION"
>dnssec-keygen</SPAN
>&nbsp;--&nbsp;DNSSEC key generation tool</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>dnssec-keygen</B
> {-a <VAR
CLASS="REPLACEABLE"
>algorithm</VAR
>} {-b <VAR
CLASS="REPLACEABLE"
>keysize</VAR
>} {-n <VAR
CLASS="REPLACEABLE"
>nametype</VAR
>} [<VAR
CLASS="OPTION"
>-c <VAR
CLASS="REPLACEABLE"
>class</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-e</VAR
>] [<VAR
CLASS="OPTION"
>-f <VAR
CLASS="REPLACEABLE"
>flag</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-g <VAR
CLASS="REPLACEABLE"
>generator</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-h</VAR
>] [<VAR
CLASS="OPTION"
>-k</VAR
>] [<VAR
CLASS="OPTION"
>-p <VAR
CLASS="REPLACEABLE"
>protocol</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-r <VAR
CLASS="REPLACEABLE"
>randomdev</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-s <VAR
CLASS="REPLACEABLE"
>strength</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-t <VAR
CLASS="REPLACEABLE"
>type</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-v <VAR
CLASS="REPLACEABLE"
>level</VAR
></VAR
>] {name}</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN53"
></A
><H2
>DESCRIPTION</H2
><P
> <B
CLASS="COMMAND"
>dnssec-keygen</B
> generates keys for DNSSEC
<!-- $Id: dnssec-keygen.html,v 1.5.2.1.4.13 2005/10/13 02:33:45 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>dnssec-keygen</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><span class="application">dnssec-keygen</span> &#8212; DNSSEC key generation tool</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code> {-a <em class="replaceable"><code>algorithm</code></em>} {-b <em class="replaceable"><code>keysize</code></em>} {-n <em class="replaceable"><code>nametype</code></em>} [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k</code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {name}</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525956"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">dnssec-keygen</strong></span> generates keys for DNSSEC
(Secure DNS), as defined in RFC 2535 and RFC &lt;TBA\&gt;. It can also generate
keys for use with TSIG (Transaction Signatures), as
defined in RFC 2845.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN57"
></A
><H2
>OPTIONS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>-a <VAR
CLASS="REPLACEABLE"
>algorithm</VAR
></DT
><DD
><P
> Selects the cryptographic algorithm. The value of
<VAR
CLASS="OPTION"
>algorithm</VAR
> must be one of RSAMD5 (RSA) or RSASHA1,
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525969"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
<dd>
<p>
Selects the cryptographic algorithm. The value of
<code class="option">algorithm</code> must be one of RSAMD5 (RSA) or RSASHA1,
DSA, DH (Diffie Hellman), or HMAC-MD5. These values
are case insensitive.
</P
><P
> Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm,
</p>
<p>
Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm,
and DSA is recommended. For TSIG, HMAC-MD5 is mandatory.
</P
><P
> Note 2: HMAC-MD5 and DH automatically set the -k flag.
</P
></DD
><DT
>-b <VAR
CLASS="REPLACEABLE"
>keysize</VAR
></DT
><DD
><P
> Specifies the number of bits in the key. The choice of key
</p>
<p>
Note 2: HMAC-MD5 and DH automatically set the -k flag.
</p>
</dd>
<dt><span class="term">-b <em class="replaceable"><code>keysize</code></em></span></dt>
<dd><p>
Specifies the number of bits in the key. The choice of key
size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between
512 and 2048 bits. Diffie Hellman keys must be between
128 and 4096 bits. DSA keys must be between 512 and 1024
bits and an exact multiple of 64. HMAC-MD5 keys must be
between 1 and 512 bits.
</P
></DD
><DT
>-n <VAR
CLASS="REPLACEABLE"
>nametype</VAR
></DT
><DD
><P
> Specifies the owner type of the key. The value of
<VAR
CLASS="OPTION"
>nametype</VAR
> must either be ZONE (for a DNSSEC
</p></dd>
<dt><span class="term">-n <em class="replaceable"><code>nametype</code></em></span></dt>
<dd><p>
Specifies the owner type of the key. The value of
<code class="option">nametype</code> must either be ZONE (for a DNSSEC
zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)),
USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are
case insensitive.
</P
></DD
><DT
>-c <VAR
CLASS="REPLACEABLE"
>class</VAR
></DT
><DD
><P
> Indicates that the DNS record containing the key should have
</p></dd>
<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
<dd><p>
Indicates that the DNS record containing the key should have
the specified class. If not specified, class IN is used.
</P
></DD
><DT
>-e</DT
><DD
><P
> If generating an RSAMD5/RSASHA1 key, use a large exponent.
</P
></DD
><DT
>-f <VAR
CLASS="REPLACEABLE"
>flag</VAR
></DT
><DD
><P
> Set the specified flag in the flag field of the KEY/DNSKEY record.
</p></dd>
<dt><span class="term">-e</span></dt>
<dd><p>
If generating an RSAMD5/RSASHA1 key, use a large exponent.
</p></dd>
<dt><span class="term">-f <em class="replaceable"><code>flag</code></em></span></dt>
<dd><p>
Set the specified flag in the flag field of the KEY/DNSKEY record.
The only recognized flag is KSK (Key Signing Key) DNSKEY.
</P
></DD
><DT
>-g <VAR
CLASS="REPLACEABLE"
>generator</VAR
></DT
><DD
><P
> If generating a Diffie Hellman key, use this generator.
</p></dd>
<dt><span class="term">-g <em class="replaceable"><code>generator</code></em></span></dt>
<dd><p>
If generating a Diffie Hellman key, use this generator.
Allowed values are 2 and 5. If no generator
is specified, a known prime from RFC 2539 will be used
if possible; otherwise the default is 2.
</P
></DD
><DT
>-h</DT
><DD
><P
> Prints a short summary of the options and arguments to
<B
CLASS="COMMAND"
>dnssec-keygen</B
>.
</P
></DD
><DT
>-k</DT
><DD
><P
> Generate KEY records rather than DNSKEY records.
</P
></DD
><DT
>-p <VAR
CLASS="REPLACEABLE"
>protocol</VAR
></DT
><DD
><P
> Sets the protocol value for the generated key. The protocol
</p></dd>
<dt><span class="term">-h</span></dt>
<dd><p>
Prints a short summary of the options and arguments to
<span><strong class="command">dnssec-keygen</strong></span>.
</p></dd>
<dt><span class="term">-k</span></dt>
<dd><p>
Generate KEY records rather than DNSKEY records.
</p></dd>
<dt><span class="term">-p <em class="replaceable"><code>protocol</code></em></span></dt>
<dd><p>
Sets the protocol value for the generated key. The protocol
is a number between 0 and 255. The default is 3 (DNSSEC).
Other possible values for this argument are listed in
RFC 2535 and its successors.
</P
></DD
><DT
>-r <VAR
CLASS="REPLACEABLE"
>randomdev</VAR
></DT
><DD
><P
> Specifies the source of randomness. If the operating
system does not provide a <TT
CLASS="FILENAME"
>/dev/random</TT
>
</p></dd>
<dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt>
<dd><p>
Specifies the source of randomness. If the operating
system does not provide a <code class="filename">/dev/random</code>
or equivalent device, the default source of randomness
is keyboard input. <TT
CLASS="FILENAME"
>randomdev</TT
> specifies
is keyboard input. <code class="filename">randomdev</code> specifies
the name of a character device or file containing random
data to be used instead of the default. The special value
<TT
CLASS="FILENAME"
>keyboard</TT
> indicates that keyboard
<code class="filename">keyboard</code> indicates that keyboard
input should be used.
</P
></DD
><DT
>-s <VAR
CLASS="REPLACEABLE"
>strength</VAR
></DT
><DD
><P
> Specifies the strength value of the key. The strength is
</p></dd>
<dt><span class="term">-s <em class="replaceable"><code>strength</code></em></span></dt>
<dd><p>
Specifies the strength value of the key. The strength is
a number between 0 and 15, and currently has no defined
purpose in DNSSEC.
</P
></DD
><DT
>-t <VAR
CLASS="REPLACEABLE"
>type</VAR
></DT
><DD
><P
> Indicates the use of the key. <VAR
CLASS="OPTION"
>type</VAR
> must be
</p></dd>
<dt><span class="term">-t <em class="replaceable"><code>type</code></em></span></dt>
<dd><p>
Indicates the use of the key. <code class="option">type</code> must be
one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default
is AUTHCONF. AUTH refers to the ability to authenticate
data, and CONF the ability to encrypt data.
</P
></DD
><DT
>-v <VAR
CLASS="REPLACEABLE"
>level</VAR
></DT
><DD
><P
> Sets the debugging level.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN136"
></A
><H2
>GENERATED KEYS</H2
><P
> When <B
CLASS="COMMAND"
>dnssec-keygen</B
> completes successfully,
it prints a string of the form <TT
CLASS="FILENAME"
>Knnnn.+aaa+iiiii</TT
>
</p></dd>
<dt><span class="term">-v <em class="replaceable"><code>level</code></em></span></dt>
<dd><p>
Sets the debugging level.
</p></dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526306"></a><h2>GENERATED KEYS</h2>
<p>
When <span><strong class="command">dnssec-keygen</strong></span> completes successfully,
it prints a string of the form <code class="filename">Knnnn.+aaa+iiiii</code>
to the standard output. This is an identification string for
the key it has generated. These strings can be used as arguments
to <B
CLASS="COMMAND"
>dnssec-makekeyset</B
>.
</P
><P
></P
><UL
><LI
><P
> <TT
CLASS="FILENAME"
>nnnn</TT
> is the key name.
</P
></LI
><LI
><P
> <TT
CLASS="FILENAME"
>aaa</TT
> is the numeric representation of the
the key it has generated.
</p>
<div class="itemizedlist"><ul type="disc">
<li><p>
<code class="filename">nnnn</code> is the key name.
</p></li>
<li><p>
<code class="filename">aaa</code> is the numeric representation of the
algorithm.
</P
></LI
><LI
><P
> <TT
CLASS="FILENAME"
>iiiii</TT
> is the key identifier (or footprint).
</P
></LI
></UL
><P
> <B
CLASS="COMMAND"
>dnssec-keygen</B
> creates two file, with names based
on the printed string. <TT
CLASS="FILENAME"
>Knnnn.+aaa+iiiii.key</TT
>
</p></li>
<li><p>
<code class="filename">iiiii</code> is the key identifier (or footprint).
</p></li>
</ul></div>
<p>
<span><strong class="command">dnssec-keygen</strong></span> creates two file, with names based
on the printed string. <code class="filename">Knnnn.+aaa+iiiii.key</code>
contains the public key, and
<TT
CLASS="FILENAME"
>Knnnn.+aaa+iiiii.private</TT
> contains the private
<code class="filename">Knnnn.+aaa+iiiii.private</code> contains the private
key.
</P
><P
> The <TT
CLASS="FILENAME"
>.key</TT
> file contains a DNS KEY record that
</p>
<p>
The <code class="filename">.key</code> file contains a DNS KEY record that
can be inserted into a zone file (directly or with a $INCLUDE
statement).
</P
><P
> The <TT
CLASS="FILENAME"
>.private</TT
> file contains algorithm specific
</p>
<p>
The <code class="filename">.private</code> file contains algorithm specific
fields. For obvious security reasons, this file does not have
general read permission.
</P
><P
> Both <TT
CLASS="FILENAME"
>.key</TT
> and <TT
CLASS="FILENAME"
>.private</TT
>
</p>
<p>
Both <code class="filename">.key</code> and <code class="filename">.private</code>
files are generated for symmetric encryption algorithm such as
HMAC-MD5, even though the public and private key are equivalent.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN163"
></A
><H2
>EXAMPLE</H2
><P
> To generate a 768-bit DSA key for the domain
<KBD
CLASS="USERINPUT"
>example.com</KBD
>, the following command would be
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526394"></a><h2>EXAMPLE</h2>
<p>
To generate a 768-bit DSA key for the domain
<strong class="userinput"><code>example.com</code></strong>, the following command would be
issued:
</P
><P
> <KBD
CLASS="USERINPUT"
>dnssec-keygen -a DSA -b 768 -n ZONE example.com</KBD
>
</P
><P
> The command would print a string of the form:
</P
><P
> <KBD
CLASS="USERINPUT"
>Kexample.com.+003+26160</KBD
>
</P
><P
> In this example, <B
CLASS="COMMAND"
>dnssec-keygen</B
> creates
the files <TT
CLASS="FILENAME"
>Kexample.com.+003+26160.key</TT
> and
<TT
CLASS="FILENAME"
>Kexample.com.+003+26160.private</TT
>
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN176"
></A
><H2
>SEE ALSO</H2
><P
> <SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>dnssec-signzone</SPAN
>(8)</SPAN
>,
<I
CLASS="CITETITLE"
>BIND 9 Administrator Reference Manual</I
>,
<I
CLASS="CITETITLE"
>RFC 2535</I
>,
<I
CLASS="CITETITLE"
>RFC 2845</I
>,
<I
CLASS="CITETITLE"
>RFC 2539</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN186"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
</p>
<p>
<strong class="userinput"><code>dnssec-keygen -a DSA -b 768 -n ZONE example.com</code></strong>
</p>
<p>
The command would print a string of the form:
</p>
<p>
<strong class="userinput"><code>Kexample.com.+003+26160</code></strong>
</p>
<p>
In this example, <span><strong class="command">dnssec-keygen</strong></span> creates
the files <code class="filename">Kexample.com.+003+26160.key</code> and
<code class="filename">Kexample.com.+003+26160.private</code>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526440"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>,
<em class="citetitle">RFC 2535</em>,
<em class="citetitle">RFC 2845</em>,
<em class="citetitle">RFC 2539</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526473"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

218
contrib/bind9/bin/dnssec/dnssec-signzone.8
View file

@ -1,167 +1,157 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2003 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2003 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: dnssec-signzone.8,v 1.23.2.1.4.6 2004/06/11 02:32:46 marka Exp $
.\" $Id: dnssec-signzone.8,v 1.23.2.1.4.10 2005/10/13 02:33:45 marka Exp $
.\"
.TH "DNSSEC-SIGNZONE" "8" "June 30, 2000" "BIND9" ""
.SH NAME
dnssec-signzone \- DNSSEC zone signing tool
.SH SYNOPSIS
.sp
\fBdnssec-signzone\fR [ \fB-a\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-d \fIdirectory\fB\fR ] [ \fB-e \fIend-time\fB\fR ] [ \fB-f \fIoutput-file\fB\fR ] [ \fB-g\fR ] [ \fB-h\fR ] [ \fB-k \fIkey\fB\fR ] [ \fB-l \fIdomain\fB\fR ] [ \fB-i \fIinterval\fB\fR ] [ \fB-n \fInthreads\fB\fR ] [ \fB-o \fIorigin\fB\fR ] [ \fB-p\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstart-time\fB\fR ] [ \fB-t\fR ] [ \fB-v \fIlevel\fB\fR ] [ \fB-z\fR ] \fBzonefile\fR [ \fBkey\fR\fI...\fR ]
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "DNSSEC\-SIGNZONE" "8" "June 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
dnssec\-signzone \- DNSSEC zone signing tool
.SH "SYNOPSIS"
.HP 16
\fBdnssec\-signzone\fR [\fB\-a\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-d\ \fR\fB\fIdirectory\fR\fR] [\fB\-e\ \fR\fB\fIend\-time\fR\fR] [\fB\-f\ \fR\fB\fIoutput\-file\fR\fR] [\fB\-g\fR] [\fB\-h\fR] [\fB\-k\ \fR\fB\fIkey\fR\fR] [\fB\-l\ \fR\fB\fIdomain\fR\fR] [\fB\-i\ \fR\fB\fIinterval\fR\fR] [\fB\-n\ \fR\fB\fInthreads\fR\fR] [\fB\-o\ \fR\fB\fIorigin\fR\fR] [\fB\-p\fR] [\fB\-r\ \fR\fB\fIrandomdev\fR\fR] [\fB\-s\ \fR\fB\fIstart\-time\fR\fR] [\fB\-t\fR] [\fB\-v\ \fR\fB\fIlevel\fR\fR] [\fB\-z\fR] {zonefile} [key...]
.SH "DESCRIPTION"
.PP
\fBdnssec-signzone\fR signs a zone. It generates
NSEC and RRSIG records and produces a signed version of the
zone. The security status of delegations from the signed zone
(that is, whether the child zones are secure or not) is
determined by the presence or absence of a
\fIkeyset\fR file for each child zone.
\fBdnssec\-signzone\fR
signs a zone. It generates NSEC and RRSIG records and produces a signed version of the zone. The security status of delegations from the signed zone (that is, whether the child zones are secure or not) is determined by the presence or absence of a
\fIkeyset\fR
file for each child zone.
.SH "OPTIONS"
.TP
\fB-a\fR
\-a
Verify all generated signatures.
.TP
\fB-c \fIclass\fB\fR
\-c \fIclass\fR
Specifies the DNS class of the zone.
.TP
\fB-k \fIkey\fB\fR
Treat specified key as a key signing key ignoring any
key flags. This option may be specified multiple times.
\-k \fIkey\fR
Treat specified key as a key signing key ignoring any key flags. This option may be specified multiple times.
.TP
\fB-l \fIdomain\fB\fR
Generate a DLV set in addition to the key (DNSKEY) and DS sets.
The domain is appended to the name of the records.
\-l \fIdomain\fR
Generate a DLV set in addition to the key (DNSKEY) and DS sets. The domain is appended to the name of the records.
.TP
\fB-d \fIdirectory\fB\fR
Look for \fIkeyset\fR files in
\fBdirectory\fR as the directory
\-d \fIdirectory\fR
Look for
\fIkeyset\fR
files in
\fBdirectory\fR
as the directory
.TP
\fB-g\fR
Generate DS records for child zones from keyset files.
Existing DS records will be removed.
\-g
Generate DS records for child zones from keyset files. Existing DS records will be removed.
.TP
\fB-s \fIstart-time\fB\fR
Specify the date and time when the generated RRSIG records
become valid. This can be either an absolute or relative
time. An absolute start time is indicated by a number
in YYYYMMDDHHMMSS notation; 20000530144500 denotes
14:45:00 UTC on May 30th, 2000. A relative start time is
indicated by +N, which is N seconds from the current time.
If no \fBstart-time\fR is specified, the current
time minus 1 hour (to allow for clock skew) is used.
\-s \fIstart\-time\fR
Specify the date and time when the generated RRSIG records become valid. This can be either an absolute or relative time. An absolute start time is indicated by a number in YYYYMMDDHHMMSS notation; 20000530144500 denotes 14:45:00 UTC on May 30th, 2000. A relative start time is indicated by +N, which is N seconds from the current time. If no
\fBstart\-time\fR
is specified, the current time minus 1 hour (to allow for clock skew) is used.
.TP
\fB-e \fIend-time\fB\fR
Specify the date and time when the generated RRSIG records
expire. As with \fBstart-time\fR, an absolute
time is indicated in YYYYMMDDHHMMSS notation. A time relative
to the start time is indicated with +N, which is N seconds from
the start time. A time relative to the current time is
indicated with now+N. If no \fBend-time\fR is
specified, 30 days from the start time is used as a default.
\-e \fIend\-time\fR
Specify the date and time when the generated RRSIG records expire. As with
\fBstart\-time\fR, an absolute time is indicated in YYYYMMDDHHMMSS notation. A time relative to the start time is indicated with +N, which is N seconds from the start time. A time relative to the current time is indicated with now+N. If no
\fBend\-time\fR
is specified, 30 days from the start time is used as a default.
.TP
\fB-f \fIoutput-file\fB\fR
The name of the output file containing the signed zone. The
default is to append \fI.signed\fR to the
input file.
\-f \fIoutput\-file\fR
The name of the output file containing the signed zone. The default is to append
\fI.signed\fR
to the input file.
.TP
\fB-h\fR
\-h
Prints a short summary of the options and arguments to
\fBdnssec-signzone\fR.
\fBdnssec\-signzone\fR.
.TP
\fB-i \fIinterval\fB\fR
When a previously signed zone is passed as input, records
may be resigned. The \fBinterval\fR option
specifies the cycle interval as an offset from the current
time (in seconds). If a RRSIG record expires after the
cycle interval, it is retained. Otherwise, it is considered
to be expiring soon, and it will be replaced.
The default cycle interval is one quarter of the difference
between the signature end and start times. So if neither
\fBend-time\fR or \fBstart-time\fR
are specified, \fBdnssec-signzone\fR generates
signatures that are valid for 30 days, with a cycle
interval of 7.5 days. Therefore, if any existing RRSIG records
are due to expire in less than 7.5 days, they would be
replaced.
\-i \fIinterval\fR
When a previously signed zone is passed as input, records may be resigned. The
\fBinterval\fR
option specifies the cycle interval as an offset from the current time (in seconds). If a RRSIG record expires after the cycle interval, it is retained. Otherwise, it is considered to be expiring soon, and it will be replaced.
.sp
The default cycle interval is one quarter of the difference between the signature end and start times. So if neither
\fBend\-time\fR
or
\fBstart\-time\fR
are specified,
\fBdnssec\-signzone\fR
generates signatures that are valid for 30 days, with a cycle interval of 7.5 days. Therefore, if any existing RRSIG records are due to expire in less than 7.5 days, they would be replaced.
.TP
\fB-n \fIncpus\fB\fR
Specifies the number of threads to use. By default, one
thread is started for each detected CPU.
\-n \fIncpus\fR
Specifies the number of threads to use. By default, one thread is started for each detected CPU.
.TP
\fB-o \fIorigin\fB\fR
The zone origin. If not specified, the name of the zone file
is assumed to be the origin.
\-o \fIorigin\fR
The zone origin. If not specified, the name of the zone file is assumed to be the origin.
.TP
\fB-p\fR
Use pseudo-random data when signing the zone. This is faster,
but less secure, than using real random data. This option
may be useful when signing large zones or when the entropy
source is limited.
\-p
Use pseudo\-random data when signing the zone. This is faster, but less secure, than using real random data. This option may be useful when signing large zones or when the entropy source is limited.
.TP
\fB-r \fIrandomdev\fB\fR
Specifies the source of randomness. If the operating
system does not provide a \fI/dev/random\fR
or equivalent device, the default source of randomness
is keyboard input. \fIrandomdev\fR specifies
the name of a character device or file containing random
data to be used instead of the default. The special value
\fIkeyboard\fR indicates that keyboard
input should be used.
\-r \fIrandomdev\fR
Specifies the source of randomness. If the operating system does not provide a
\fI/dev/random\fR
or equivalent device, the default source of randomness is keyboard input.
\fIrandomdev\fR
specifies the name of a character device or file containing random data to be used instead of the default. The special value
\fIkeyboard\fR
indicates that keyboard input should be used.
.TP
\fB-t\fR
\-t
Print statistics at completion.
.TP
\fB-v \fIlevel\fB\fR
\-v \fIlevel\fR
Sets the debugging level.
.TP
\fB-z\fR
\-z
Ignore KSK flag on key when determining what to sign.
.TP
\fBzonefile\fR
zonefile
The file containing the zone to be signed.
Sets the debugging level.
.TP
\fBkey\fR
The keys used to sign the zone. If no keys are specified, the
default all zone keys that have private key files in the
current directory.
key
The keys used to sign the zone. If no keys are specified, the default all zone keys that have private key files in the current directory.
.SH "EXAMPLE"
.PP
The following command signs the \fBexample.com\fR
zone with the DSA key generated in the \fBdnssec-keygen\fR
The following command signs the
\fBexample.com\fR
zone with the DSA key generated in the
\fBdnssec\-keygen\fR
man page. The zone's keys must be in the zone. If there are
\fIkeyset\fR files associated with child zones,
they must be in the current directory.
\fBexample.com\fR, the following command would be
issued:
\fIkeyset\fR
files associated with child zones, they must be in the current directory.
\fBexample.com\fR, the following command would be issued:
.PP
\fBdnssec-signzone -o example.com db.example.com Kexample.com.+003+26160\fR
\fBdnssec\-signzone \-o example.com db.example.com Kexample.com.+003+26160\fR
.PP
The command would print a string of the form:
.PP
In this example, \fBdnssec-signzone\fR creates
the file \fIdb.example.com.signed\fR. This file
should be referenced in a zone statement in a
\fInamed.conf\fR file.
In this example,
\fBdnssec\-signzone\fR
creates the file
\fIdb.example.com.signed\fR. This file should be referenced in a zone statement in a
\fInamed.conf\fR
file.
.SH "SEE ALSO"
.PP
\fBdnssec-keygen\fR(8),
\fIBIND 9 Administrator Reference Manual\fR,
\fIRFC 2535\fR.
\fBdnssec\-keygen\fR(8),
BIND 9 Administrator Reference Manual,
RFC 2535.
.SH "AUTHOR"
.PP
Internet Systems Consortium

87
contrib/bind9/bin/dnssec/dnssec-signzone.c
View file

@ -1,5 +1,5 @@
/*
* Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Portions Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Portions Copyright (C) 1999-2003 Internet Software Consortium.
* Portions Copyright (C) 1995-2000 by Network Associates, Inc.
*
@ -16,7 +16,7 @@
* IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: dnssec-signzone.c,v 1.139.2.2.4.17 2004/10/25 01:36:06 marka Exp $ */
/* $Id: dnssec-signzone.c,v 1.139.2.2.4.21 2005/10/14 01:38:41 marka Exp $ */
#include <config.h>
@ -787,7 +787,6 @@ signname(dns_dbnode_t *node, dns_name_t *name) {
dns_rdatasetiter_t *rdsiter;
isc_boolean_t isdelegation = ISC_FALSE;
isc_boolean_t hasds = ISC_FALSE;
isc_boolean_t atorigin;
isc_boolean_t changed = ISC_FALSE;
dns_diff_t del, add;
char namestr[DNS_NAME_FORMATSIZE];
@ -795,8 +794,6 @@ signname(dns_dbnode_t *node, dns_name_t *name) {
dns_name_format(name, namestr, sizeof(namestr));
atorigin = dns_name_equal(name, gorigin);
/*
* Determine if this is a delegation point.
*/
@ -931,13 +928,16 @@ signname(dns_dbnode_t *node, dns_name_t *name) {
static inline isc_boolean_t
active_node(dns_dbnode_t *node) {
dns_rdatasetiter_t *rdsiter;
dns_rdatasetiter_t *rdsiter = NULL;
dns_rdatasetiter_t *rdsiter2 = NULL;
isc_boolean_t active = ISC_FALSE;
isc_result_t result;
dns_rdataset_t rdataset;
dns_rdatatype_t type;
dns_rdatatype_t covers;
isc_boolean_t found;
dns_rdataset_init(&rdataset);
rdsiter = NULL;
result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter);
check_result(result, "dns_db_allrdatasets()");
result = dns_rdatasetiter_first(rdsiter);
@ -958,36 +958,63 @@ active_node(dns_dbnode_t *node) {
if (!active) {
/*
* Make sure there is no NSEC / RRSIG records for
* this node.
* The node is empty of everything but NSEC / RRSIG records.
*/
result = dns_db_deleterdataset(gdb, node, gversion,
dns_rdatatype_nsec, 0);
if (result == DNS_R_UNCHANGED)
result = ISC_R_SUCCESS;
check_result(result, "dns_db_deleterdataset(nsec)");
result = dns_rdatasetiter_first(rdsiter);
for (result = dns_rdatasetiter_first(rdsiter);
result == ISC_R_SUCCESS;
result = dns_rdatasetiter_next(rdsiter)) {
dns_rdatasetiter_current(rdsiter, &rdataset);
if (rdataset.type == dns_rdatatype_rrsig) {
dns_rdatatype_t type = rdataset.type;
dns_rdatatype_t covers = rdataset.covers;
result = dns_db_deleterdataset(gdb, node,
gversion, type,
covers);
if (result == DNS_R_UNCHANGED)
result = ISC_R_SUCCESS;
check_result(result,
"dns_db_deleterdataset(rrsig)");
}
result = dns_db_deleterdataset(gdb, node, gversion,
rdataset.type,
rdataset.covers);
check_result(result, "dns_db_deleterdataset()");
dns_rdataset_disassociate(&rdataset);
}
if (result != ISC_R_NOMORE)
fatal("rdataset iteration failed: %s",
isc_result_totext(result));
} else {
/*
* Delete RRSIGs for types that no longer exist.
*/
result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter2);
check_result(result, "dns_db_allrdatasets()");
for (result = dns_rdatasetiter_first(rdsiter);
result == ISC_R_SUCCESS;
result = dns_rdatasetiter_next(rdsiter)) {
dns_rdatasetiter_current(rdsiter, &rdataset);
type = rdataset.type;
covers = rdataset.covers;
dns_rdataset_disassociate(&rdataset);
if (type != dns_rdatatype_rrsig)
continue;
found = ISC_FALSE;
for (result = dns_rdatasetiter_first(rdsiter2);
!found && result == ISC_R_SUCCESS;
result = dns_rdatasetiter_next(rdsiter2)) {
dns_rdatasetiter_current(rdsiter2, &rdataset);
if (rdataset.type == covers)
found = ISC_TRUE;
dns_rdataset_disassociate(&rdataset);
}
if (!found) {
if (result != ISC_R_NOMORE)
fatal("rdataset iteration failed: %s",
isc_result_totext(result));
result = dns_db_deleterdataset(gdb, node,
gversion, type,
covers);
check_result(result,
"dns_db_deleterdataset(rrsig)");
} else if (result != ISC_R_NOMORE &&
result != ISC_R_SUCCESS)
fatal("rdataset iteration failed: %s",
isc_result_totext(result));
}
if (result != ISC_R_NOMORE)
fatal("rdataset iteration failed: %s",
isc_result_totext(result));
dns_rdatasetiter_destroy(&rdsiter2);
}
dns_rdatasetiter_destroy(&rdsiter);
@ -1423,7 +1450,6 @@ warnifallksk(dns_db_t *db) {
dns_dbnode_t *node = NULL;
dns_rdataset_t rdataset;
dns_rdata_t rdata = DNS_RDATA_INIT;
dst_key_t *pubkey;
isc_result_t result;
dns_rdata_key_t key;
isc_boolean_t have_non_ksk = ISC_FALSE;
@ -1444,7 +1470,6 @@ warnifallksk(dns_db_t *db) {
result = dns_rdataset_first(&rdataset);
check_result(result, "dns_rdataset_first");
while (result == ISC_R_SUCCESS) {
pubkey = NULL;
dns_rdata_reset(&rdata);
dns_rdataset_current(&rdataset, &rdata);
result = dns_rdata_tostruct(&rdata, &key, NULL);
@ -1615,9 +1640,9 @@ usage(void) {
fprintf(stderr, "\t\tdirectory to find keyset files (.)\n");
fprintf(stderr, "\t-g:\t");
fprintf(stderr, "generate DS records from keyset files\n");
fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n");
fprintf(stderr, "\t-s [YYYYMMDDHHMMSS|+offset]:\n");
fprintf(stderr, "\t\tRRSIG start time - absolute|offset (now - 1 hour)\n");
fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n");
fprintf(stderr, "\t-e [YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n");
fprintf(stderr, "\t\tRRSIG end time - absolute|from start|from now "
"(now + 30 days)\n");
fprintf(stderr, "\t-i interval:\n");

26
contrib/bind9/bin/dnssec/dnssec-signzone.docbook
View file

@ -1,7 +1,9 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001-2003 Internet Software Consortium.
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: dnssec-signzone.docbook,v 1.2.2.2.4.8 2004/06/11 01:17:35 marka Exp $ -->
<!-- $Id: dnssec-signzone.docbook,v 1.2.2.2.4.11 2005/06/24 00:18:15 marka Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,21 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><application>dnssec-signzone</application></refname>
<refpurpose>DNSSEC zone signing tool</refpurpose>
@ -290,7 +307,6 @@
<listitem>
<para>
The file containing the zone to be signed.
Sets the debugging level.
</para>
</listitem>
</varlistentry>

665
contrib/bind9/bin/dnssec/dnssec-signzone.html
View file

@ -1,553 +1,220 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001-2003 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: dnssec-signzone.html,v 1.4.2.1.4.7 2004/08/22 23:38:58 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>dnssec-signzone</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><SPAN
CLASS="APPLICATION"
>dnssec-signzone</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><SPAN
CLASS="APPLICATION"
>dnssec-signzone</SPAN
>&nbsp;--&nbsp;DNSSEC zone signing tool</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>dnssec-signzone</B
> [<VAR
CLASS="OPTION"
>-a</VAR
>] [<VAR
CLASS="OPTION"
>-c <VAR
CLASS="REPLACEABLE"
>class</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-d <VAR
CLASS="REPLACEABLE"
>directory</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-e <VAR
CLASS="REPLACEABLE"
>end-time</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-f <VAR
CLASS="REPLACEABLE"
>output-file</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-g</VAR
>] [<VAR
CLASS="OPTION"
>-h</VAR
>] [<VAR
CLASS="OPTION"
>-k <VAR
CLASS="REPLACEABLE"
>key</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-l <VAR
CLASS="REPLACEABLE"
>domain</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-i <VAR
CLASS="REPLACEABLE"
>interval</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-n <VAR
CLASS="REPLACEABLE"
>nthreads</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-o <VAR
CLASS="REPLACEABLE"
>origin</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-p</VAR
>] [<VAR
CLASS="OPTION"
>-r <VAR
CLASS="REPLACEABLE"
>randomdev</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-s <VAR
CLASS="REPLACEABLE"
>start-time</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-t</VAR
>] [<VAR
CLASS="OPTION"
>-v <VAR
CLASS="REPLACEABLE"
>level</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-z</VAR
>] {zonefile} [key...]</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN66"
></A
><H2
>DESCRIPTION</H2
><P
> <B
CLASS="COMMAND"
>dnssec-signzone</B
> signs a zone. It generates
<!-- $Id: dnssec-signzone.html,v 1.4.2.1.4.14 2005/10/13 02:33:46 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>dnssec-signzone</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><span class="application">dnssec-signzone</span> &#8212; DNSSEC zone signing tool</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">dnssec-signzone</code> [<code class="option">-a</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-e <em class="replaceable"><code>end-time</code></em></code>] [<code class="option">-f <em class="replaceable"><code>output-file</code></em></code>] [<code class="option">-g</code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>key</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-n <em class="replaceable"><code>nthreads</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-p</code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>start-time</code></em></code>] [<code class="option">-t</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {zonefile} [key...]</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525979"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">dnssec-signzone</strong></span> signs a zone. It generates
NSEC and RRSIG records and produces a signed version of the
zone. The security status of delegations from the signed zone
(that is, whether the child zones are secure or not) is
determined by the presence or absence of a
<TT
CLASS="FILENAME"
>keyset</TT
> file for each child zone.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN71"
></A
><H2
>OPTIONS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>-a</DT
><DD
><P
> Verify all generated signatures.
</P
></DD
><DT
>-c <VAR
CLASS="REPLACEABLE"
>class</VAR
></DT
><DD
><P
> Specifies the DNS class of the zone.
</P
></DD
><DT
>-k <VAR
CLASS="REPLACEABLE"
>key</VAR
></DT
><DD
><P
> Treat specified key as a key signing key ignoring any
<code class="filename">keyset</code> file for each child zone.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525995"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-a</span></dt>
<dd><p>
Verify all generated signatures.
</p></dd>
<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
<dd><p>
Specifies the DNS class of the zone.
</p></dd>
<dt><span class="term">-k <em class="replaceable"><code>key</code></em></span></dt>
<dd><p>
Treat specified key as a key signing key ignoring any
key flags. This option may be specified multiple times.
</P
></DD
><DT
>-l <VAR
CLASS="REPLACEABLE"
>domain</VAR
></DT
><DD
><P
> Generate a DLV set in addition to the key (DNSKEY) and DS sets.
</p></dd>
<dt><span class="term">-l <em class="replaceable"><code>domain</code></em></span></dt>
<dd><p>
Generate a DLV set in addition to the key (DNSKEY) and DS sets.
The domain is appended to the name of the records.
</P
></DD
><DT
>-d <VAR
CLASS="REPLACEABLE"
>directory</VAR
></DT
><DD
><P
> Look for <TT
CLASS="FILENAME"
>keyset</TT
> files in
<VAR
CLASS="OPTION"
>directory</VAR
> as the directory
</P
></DD
><DT
>-g</DT
><DD
><P
> Generate DS records for child zones from keyset files.
</p></dd>
<dt><span class="term">-d <em class="replaceable"><code>directory</code></em></span></dt>
<dd><p>
Look for <code class="filename">keyset</code> files in
<code class="option">directory</code> as the directory
</p></dd>
<dt><span class="term">-g</span></dt>
<dd><p>
Generate DS records for child zones from keyset files.
Existing DS records will be removed.
</P
></DD
><DT
>-s <VAR
CLASS="REPLACEABLE"
>start-time</VAR
></DT
><DD
><P
> Specify the date and time when the generated RRSIG records
</p></dd>
<dt><span class="term">-s <em class="replaceable"><code>start-time</code></em></span></dt>
<dd><p>
Specify the date and time when the generated RRSIG records
become valid. This can be either an absolute or relative
time. An absolute start time is indicated by a number
in YYYYMMDDHHMMSS notation; 20000530144500 denotes
14:45:00 UTC on May 30th, 2000. A relative start time is
indicated by +N, which is N seconds from the current time.
If no <VAR
CLASS="OPTION"
>start-time</VAR
> is specified, the current
If no <code class="option">start-time</code> is specified, the current
time minus 1 hour (to allow for clock skew) is used.
</P
></DD
><DT
>-e <VAR
CLASS="REPLACEABLE"
>end-time</VAR
></DT
><DD
><P
> Specify the date and time when the generated RRSIG records
expire. As with <VAR
CLASS="OPTION"
>start-time</VAR
>, an absolute
</p></dd>
<dt><span class="term">-e <em class="replaceable"><code>end-time</code></em></span></dt>
<dd><p>
Specify the date and time when the generated RRSIG records
expire. As with <code class="option">start-time</code>, an absolute
time is indicated in YYYYMMDDHHMMSS notation. A time relative
to the start time is indicated with +N, which is N seconds from
the start time. A time relative to the current time is
indicated with now+N. If no <VAR
CLASS="OPTION"
>end-time</VAR
> is
indicated with now+N. If no <code class="option">end-time</code> is
specified, 30 days from the start time is used as a default.
</P
></DD
><DT
>-f <VAR
CLASS="REPLACEABLE"
>output-file</VAR
></DT
><DD
><P
> The name of the output file containing the signed zone. The
default is to append <TT
CLASS="FILENAME"
>.signed</TT
> to the
</p></dd>
<dt><span class="term">-f <em class="replaceable"><code>output-file</code></em></span></dt>
<dd><p>
The name of the output file containing the signed zone. The
default is to append <code class="filename">.signed</code> to the
input file.
</P
></DD
><DT
>-h</DT
><DD
><P
> Prints a short summary of the options and arguments to
<B
CLASS="COMMAND"
>dnssec-signzone</B
>.
</P
></DD
><DT
>-i <VAR
CLASS="REPLACEABLE"
>interval</VAR
></DT
><DD
><P
> When a previously signed zone is passed as input, records
may be resigned. The <VAR
CLASS="OPTION"
>interval</VAR
> option
</p></dd>
<dt><span class="term">-h</span></dt>
<dd><p>
Prints a short summary of the options and arguments to
<span><strong class="command">dnssec-signzone</strong></span>.
</p></dd>
<dt><span class="term">-i <em class="replaceable"><code>interval</code></em></span></dt>
<dd>
<p>
When a previously signed zone is passed as input, records
may be resigned. The <code class="option">interval</code> option
specifies the cycle interval as an offset from the current
time (in seconds). If a RRSIG record expires after the
cycle interval, it is retained. Otherwise, it is considered
to be expiring soon, and it will be replaced.
</P
><P
> The default cycle interval is one quarter of the difference
</p>
<p>
The default cycle interval is one quarter of the difference
between the signature end and start times. So if neither
<VAR
CLASS="OPTION"
>end-time</VAR
> or <VAR
CLASS="OPTION"
>start-time</VAR
>
are specified, <B
CLASS="COMMAND"
>dnssec-signzone</B
> generates
<code class="option">end-time</code> or <code class="option">start-time</code>
are specified, <span><strong class="command">dnssec-signzone</strong></span> generates
signatures that are valid for 30 days, with a cycle
interval of 7.5 days. Therefore, if any existing RRSIG records
are due to expire in less than 7.5 days, they would be
replaced.
</P
></DD
><DT
>-n <VAR
CLASS="REPLACEABLE"
>ncpus</VAR
></DT
><DD
><P
> Specifies the number of threads to use. By default, one
</p>
</dd>
<dt><span class="term">-n <em class="replaceable"><code>ncpus</code></em></span></dt>
<dd><p>
Specifies the number of threads to use. By default, one
thread is started for each detected CPU.
</P
></DD
><DT
>-o <VAR
CLASS="REPLACEABLE"
>origin</VAR
></DT
><DD
><P
> The zone origin. If not specified, the name of the zone file
</p></dd>
<dt><span class="term">-o <em class="replaceable"><code>origin</code></em></span></dt>
<dd><p>
The zone origin. If not specified, the name of the zone file
is assumed to be the origin.
</P
></DD
><DT
>-p</DT
><DD
><P
> Use pseudo-random data when signing the zone. This is faster,
</p></dd>
<dt><span class="term">-p</span></dt>
<dd><p>
Use pseudo-random data when signing the zone. This is faster,
but less secure, than using real random data. This option
may be useful when signing large zones or when the entropy
source is limited.
</P
></DD
><DT
>-r <VAR
CLASS="REPLACEABLE"
>randomdev</VAR
></DT
><DD
><P
> Specifies the source of randomness. If the operating
system does not provide a <TT
CLASS="FILENAME"
>/dev/random</TT
>
</p></dd>
<dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt>
<dd><p>
Specifies the source of randomness. If the operating
system does not provide a <code class="filename">/dev/random</code>
or equivalent device, the default source of randomness
is keyboard input. <TT
CLASS="FILENAME"
>randomdev</TT
> specifies
is keyboard input. <code class="filename">randomdev</code> specifies
the name of a character device or file containing random
data to be used instead of the default. The special value
<TT
CLASS="FILENAME"
>keyboard</TT
> indicates that keyboard
<code class="filename">keyboard</code> indicates that keyboard
input should be used.
</P
></DD
><DT
>-t</DT
><DD
><P
> Print statistics at completion.
</P
></DD
><DT
>-v <VAR
CLASS="REPLACEABLE"
>level</VAR
></DT
><DD
><P
> Sets the debugging level.
</P
></DD
><DT
>-z</DT
><DD
><P
> Ignore KSK flag on key when determining what to sign.
</P
></DD
><DT
>zonefile</DT
><DD
><P
> The file containing the zone to be signed.
</p></dd>
<dt><span class="term">-t</span></dt>
<dd><p>
Print statistics at completion.
</p></dd>
<dt><span class="term">-v <em class="replaceable"><code>level</code></em></span></dt>
<dd><p>
Sets the debugging level.
</P
></DD
><DT
>key</DT
><DD
><P
> The keys used to sign the zone. If no keys are specified, the
</p></dd>
<dt><span class="term">-z</span></dt>
<dd><p>
Ignore KSK flag on key when determining what to sign.
</p></dd>
<dt><span class="term">zonefile</span></dt>
<dd><p>
The file containing the zone to be signed.
</p></dd>
<dt><span class="term">key</span></dt>
<dd><p>
The keys used to sign the zone. If no keys are specified, the
default all zone keys that have private key files in the
current directory.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN181"
></A
><H2
>EXAMPLE</H2
><P
> The following command signs the <KBD
CLASS="USERINPUT"
>example.com</KBD
>
zone with the DSA key generated in the <B
CLASS="COMMAND"
>dnssec-keygen</B
>
</p></dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526435"></a><h2>EXAMPLE</h2>
<p>
The following command signs the <strong class="userinput"><code>example.com</code></strong>
zone with the DSA key generated in the <span><strong class="command">dnssec-keygen</strong></span>
man page. The zone's keys must be in the zone. If there are
<TT
CLASS="FILENAME"
>keyset</TT
> files associated with child zones,
<code class="filename">keyset</code> files associated with child zones,
they must be in the current directory.
<KBD
CLASS="USERINPUT"
>example.com</KBD
>, the following command would be
<strong class="userinput"><code>example.com</code></strong>, the following command would be
issued:
</P
><P
> <KBD
CLASS="USERINPUT"
>dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160</KBD
>
</P
><P
> The command would print a string of the form:
</P
><P
> In this example, <B
CLASS="COMMAND"
>dnssec-signzone</B
> creates
the file <TT
CLASS="FILENAME"
>db.example.com.signed</TT
>. This file
</p>
<p>
<strong class="userinput"><code>dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160</code></strong>
</p>
<p>
The command would print a string of the form:
</p>
<p>
In this example, <span><strong class="command">dnssec-signzone</strong></span> creates
the file <code class="filename">db.example.com.signed</code>. This file
should be referenced in a zone statement in a
<TT
CLASS="FILENAME"
>named.conf</TT
> file.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN195"
></A
><H2
>SEE ALSO</H2
><P
> <SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>dnssec-keygen</SPAN
>(8)</SPAN
>,
<I
CLASS="CITETITLE"
>BIND 9 Administrator Reference Manual</I
>,
<I
CLASS="CITETITLE"
>RFC 2535</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN203"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
<code class="filename">named.conf</code> file.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526485"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>,
<em class="citetitle">RFC 2535</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526512"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

6
contrib/bind9/bin/dnssec/dnssectool.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: dnssectool.c,v 1.31.2.3.2.4 2004/03/08 02:07:38 marka Exp $ */
/* $Id: dnssectool.c,v 1.31.2.3.2.6 2005/07/02 02:42:43 marka Exp $ */
#include <config.h>
@ -145,6 +145,8 @@ setup_logging(int verbose, isc_mem_t *mctx, isc_log_t **logp) {
isc_log_t *log = NULL;
int level;
if (verbose < 0)
verbose = 0;
switch (verbose) {
case 0:
/*

23
contrib/bind9/bin/named/aclconf.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2002 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: aclconf.c,v 1.27.12.3 2004/03/08 04:04:18 marka Exp $ */
/* $Id: aclconf.c,v 1.27.12.5 2005/03/17 03:58:25 marka Exp $ */
#include <config.h>
@ -31,6 +31,8 @@
#include <named/aclconf.h>
#define LOOP_MAGIC ISC_MAGIC('L','O','O','P')
void
ns_aclconfctx_init(ns_aclconfctx_t *ctx) {
ISC_LIST_INIT(ctx->named_acl_cache);
@ -81,6 +83,7 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx,
isc_result_t result;
cfg_obj_t *cacl = NULL;
dns_acl_t *dacl;
dns_acl_t loop;
char *aclname = cfg_obj_asstring(nameobj);
/* Look for an already-converted version. */
@ -89,6 +92,11 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx,
dacl = ISC_LIST_NEXT(dacl, nextincache))
{
if (strcasecmp(aclname, dacl->name) == 0) {
if (ISC_MAGIC_VALID(dacl, LOOP_MAGIC)) {
cfg_obj_log(nameobj, dns_lctx, ISC_LOG_ERROR,
"acl loop detected: %s", aclname);
return (ISC_R_FAILURE);
}
dns_acl_attach(dacl, target);
return (ISC_R_SUCCESS);
}
@ -100,7 +108,18 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx,
"undefined ACL '%s'", aclname);
return (result);
}
/*
* Add a loop detection element.
*/
memset(&loop, 0, sizeof(loop));
ISC_LINK_INIT(&loop, nextincache);
loop.name = aclname;
loop.magic = LOOP_MAGIC;
ISC_LIST_APPEND(ctx->named_acl_cache, &loop, nextincache);
result = ns_acl_fromconfig(cacl, cctx, ctx, mctx, &dacl);
ISC_LIST_UNLINK(ctx->named_acl_cache, &loop, nextincache);
loop.magic = 0;
loop.name = NULL;
if (result != ISC_R_SUCCESS)
return (result);
dacl->name = isc_mem_strdup(dacl->mctx, aclname);

37
contrib/bind9/bin/named/client.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: client.c,v 1.176.2.13.4.23 2004/09/26 22:37:43 marka Exp $ */
/* $Id: client.c,v 1.176.2.13.4.26 2005/07/27 02:53:14 marka Exp $ */
#include <config.h>
@ -177,23 +177,29 @@ static void client_request(isc_task_t *task, isc_event_t *event);
static void ns_client_dumpmessage(ns_client_t *client, const char *reason);
void
ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest) {
ns_client_recursing(ns_client_t *client) {
REQUIRE(NS_CLIENT_VALID(client));
LOCK(&client->manager->lock);
ISC_LIST_UNLINK(*client->list, client, link);
ISC_LIST_APPEND(client->manager->recursing, client, link);
client->list = &client->manager->recursing;
UNLOCK(&client->manager->lock);
}
void
ns_client_killoldestquery(ns_client_t *client) {
ns_client_t *oldest;
REQUIRE(NS_CLIENT_VALID(client));
LOCK(&client->manager->lock);
if (killoldest) {
oldest = ISC_LIST_HEAD(client->manager->recursing);
if (oldest != NULL) {
ns_query_cancel(oldest);
ISC_LIST_UNLINK(*oldest->list, oldest, link);
ISC_LIST_APPEND(client->manager->active, oldest, link);
oldest->list = &client->manager->active;
}
oldest = ISC_LIST_HEAD(client->manager->recursing);
if (oldest != NULL) {
ns_query_cancel(oldest);
ISC_LIST_UNLINK(*oldest->list, oldest, link);
ISC_LIST_APPEND(client->manager->active, oldest, link);
oldest->list = &client->manager->active;
}
ISC_LIST_UNLINK(*client->list, client, link);
ISC_LIST_APPEND(client->manager->recursing, client, link);
client->list = &client->manager->recursing;
UNLOCK(&client->manager->lock);
}
@ -1603,8 +1609,7 @@ client_timeout(isc_task_t *task, isc_event_t *event) {
}
static isc_result_t
client_create(ns_clientmgr_t *manager, ns_client_t **clientp)
{
client_create(ns_clientmgr_t *manager, ns_client_t **clientp) {
ns_client_t *client;
isc_result_t result;

40
contrib/bind9/bin/named/control.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2001-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: control.c,v 1.7.2.2.2.11 2004/09/03 03:43:31 marka Exp $ */
/* $Id: control.c,v 1.7.2.2.2.14 2005/04/29 01:04:47 marka Exp $ */
#include <config.h>
@ -37,6 +37,9 @@
#include <named/log.h>
#include <named/os.h>
#include <named/server.h>
#ifdef HAVE_LIBSCF
#include <named/ns_smf_globals.h>
#endif
static isc_boolean_t
command_compare(const char *text, const char *command) {
@ -58,6 +61,9 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) {
isccc_sexpr_t *data;
char *command;
isc_result_t result;
#ifdef HAVE_LIBSCF
ns_smf_want_disable = 0;
#endif
data = isccc_alist_lookup(message, "_data");
if (data == NULL) {
@ -92,11 +98,41 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) {
} else if (command_compare(command, NS_COMMAND_RETRANSFER)) {
result = ns_server_retransfercommand(ns_g_server, command);
} else if (command_compare(command, NS_COMMAND_HALT)) {
#ifdef HAVE_LIBSCF
/*
* If we are managed by smf(5), AND in chroot, then
* we cannot connect to the smf repository, so just
* return with an appropriate message back to rndc.
*/
if (ns_smf_got_instance == 1 && ns_smf_chroot == 1) {
result = ns_smf_add_message(text);
return (result);
}
/*
* If we are managed by smf(5) but not in chroot,
* try to disable ourselves the smf way.
*/
if (ns_smf_got_instance == 1 && ns_smf_chroot == 0)
ns_smf_want_disable = 1;
/*
* If ns_smf_got_instance = 0, ns_smf_chroot
* is not relevant and we fall through to
* isc_app_shutdown below.
*/
#endif
ns_server_flushonshutdown(ns_g_server, ISC_FALSE);
ns_os_shutdownmsg(command, text);
isc_app_shutdown();
result = ISC_R_SUCCESS;
} else if (command_compare(command, NS_COMMAND_STOP)) {
#ifdef HAVE_LIBSCF
if (ns_smf_got_instance == 1 && ns_smf_chroot == 1) {
result = ns_smf_add_message(text);
return (result);
}
if (ns_smf_got_instance == 1 && ns_smf_chroot == 0)
ns_smf_want_disable = 1;
#endif
ns_server_flushonshutdown(ns_g_server, ISC_TRUE);
ns_os_shutdownmsg(command, text);
isc_app_shutdown();

14
contrib/bind9/bin/named/include/named/client.h
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: client.h,v 1.60.2.2.10.8 2004/07/23 02:56:52 marka Exp $ */
/* $Id: client.h,v 1.60.2.2.10.10 2005/07/29 00:13:08 marka Exp $ */
#ifndef NAMED_CLIENT_H
#define NAMED_CLIENT_H 1
@ -322,12 +322,18 @@ ns_client_aclmsg(const char *msg, dns_name_t *name, dns_rdatatype_t type,
DNS_RDATACLASS_FORMATSIZE + sizeof(x) + sizeof("'/'"))
void
ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest);
/*
ns_client_recursing(ns_client_t *client);
/*%
* Add client to end of recursing list. If 'killoldest' is true
* kill the oldest recursive client (list head).
*/
void
ns_client_killoldestquery(ns_client_t *client);
/*%
* Kill the oldest recursive query (recursing list head).
*/
void
ns_client_dumprecursing(FILE *f, ns_clientmgr_t *manager);
/*

44
contrib/bind9/bin/named/include/named/ns_smf_globals.h Normal file
View file

@ -0,0 +1,44 @@
/*
* Copyright (C) 2005 Internet Systems Consortium, Inc. ("ISC")
*
* 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.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
* REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS. IN NO EVENT SHALL ISC 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.
*/
/* $Id: ns_smf_globals.h,v 1.2.4.4 2005/05/13 01:22:33 marka Exp $ */
#ifndef NS_SMF_GLOBALS_H
#define NS_SMF_GLOBALS_H 1
#include <libscf.h>
#undef EXTERN
#undef INIT
#ifdef NS_MAIN
#define EXTERN
#define INIT(v) = (v)
#else
#define EXTERN extern
#define INIT(v)
#endif
EXTERN unsigned int ns_smf_got_instance INIT(0);
EXTERN unsigned int ns_smf_chroot INIT(0);
EXTERN unsigned int ns_smf_want_disable INIT(0);
isc_result_t ns_smf_add_message(isc_buffer_t *text);
isc_result_t ns_smf_get_instance(char **name, int debug, isc_mem_t *mctx);
#undef EXTERN
#undef INIT
#endif /* NS_SMF_GLOBALS_H */

16
contrib/bind9/bin/named/log.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2002 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: log.c,v 1.33.2.1.10.4 2004/03/08 09:04:14 marka Exp $ */
/* $Id: log.c,v 1.33.2.1.10.6 2005/05/24 23:58:17 marka Exp $ */
#include <config.h>
@ -154,6 +154,9 @@ ns_log_setdefaultchannels(isc_logconfig_t *lcfg) {
isc_result_t
ns_log_setsafechannels(isc_logconfig_t *lcfg) {
isc_result_t result;
#if ISC_FACILITY != LOG_DAEMON
isc_logdestination_t destination;
#endif
if (! ns_g_logstderr) {
result = isc_log_createchannel(lcfg, "default_debug",
@ -172,6 +175,15 @@ ns_log_setsafechannels(isc_logconfig_t *lcfg) {
isc_log_setdebuglevel(ns_g_lctx, ns_g_debuglevel);
}
#if ISC_FACILITY != LOG_DAEMON
destination.facility = ISC_FACILITY;
result = isc_log_createchannel(lcfg, "default_syslog",
ISC_LOG_TOSYSLOG, ISC_LOG_INFO,
&destination, 0);
if (result != ISC_R_SUCCESS)
goto cleanup;
#endif
result = ISC_R_SUCCESS;
cleanup:

174
contrib/bind9/bin/named/lwresd.8
View file

@ -1,135 +1,135 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000, 2001 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000, 2001 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: lwresd.8,v 1.13.208.2 2004/06/03 05:35:47 marka Exp $
.\" $Id: lwresd.8,v 1.13.208.5 2005/10/13 02:33:47 marka Exp $
.\"
.TH "LWRESD" "8" "June 30, 2000" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "LWRESD" "8" "June 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
lwresd \- lightweight resolver daemon
.SH SYNOPSIS
.sp
\fBlwresd\fR [ \fB-C \fIconfig-file\fB\fR ] [ \fB-d \fIdebug-level\fB\fR ] [ \fB-f\fR ] [ \fB-g\fR ] [ \fB-i \fIpid-file\fB\fR ] [ \fB-n \fI#cpus\fB\fR ] [ \fB-P \fIport\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-s\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-u \fIuser\fB\fR ] [ \fB-v\fR ]
.SH "SYNOPSIS"
.HP 7
\fBlwresd\fR [\fB\-C\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-d\ \fR\fB\fIdebug\-level\fR\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-i\ \fR\fB\fIpid\-file\fR\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-P\ \fR\fB\fIport\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR]
.SH "DESCRIPTION"
.PP
\fBlwresd\fR is the daemon providing name lookup
services to clients that use the BIND 9 lightweight resolver
library. It is essentially a stripped-down, caching-only name
server that answers queries using the BIND 9 lightweight
resolver protocol rather than the DNS protocol.
\fBlwresd\fR
is the daemon providing name lookup services to clients that use the BIND 9 lightweight resolver library. It is essentially a stripped\-down, caching\-only name server that answers queries using the BIND 9 lightweight resolver protocol rather than the DNS protocol.
.PP
\fBlwresd\fR listens for resolver queries on a
UDP port on the IPv4 loopback interface, 127.0.0.1. This
means that \fBlwresd\fR can only be used by
processes running on the local machine. By default UDP port
number 921 is used for lightweight resolver requests and
responses.
\fBlwresd\fR
listens for resolver queries on a UDP port on the IPv4 loopback interface, 127.0.0.1. This means that
\fBlwresd\fR
can only be used by processes running on the local machine. By default UDP port number 921 is used for lightweight resolver requests and responses.
.PP
Incoming lightweight resolver requests are decoded by the
server which then resolves them using the DNS protocol. When
the DNS lookup completes, \fBlwresd\fR encodes
the answers in the lightweight resolver format and returns
them to the client that made the request.
Incoming lightweight resolver requests are decoded by the server which then resolves them using the DNS protocol. When the DNS lookup completes,
\fBlwresd\fR
encodes the answers in the lightweight resolver format and returns them to the client that made the request.
.PP
If \fI/etc/resolv.conf\fR contains any
\fBnameserver\fR entries, \fBlwresd\fR
sends recursive DNS queries to those servers. This is similar
to the use of forwarders in a caching name server. If no
\fBnameserver\fR entries are present, or if
forwarding fails, \fBlwresd\fR resolves the
queries autonomously starting at the root name servers, using
a built-in list of root server hints.
If
\fI/etc/resolv.conf\fR
contains any
\fBnameserver\fR
entries,
\fBlwresd\fR
sends recursive DNS queries to those servers. This is similar to the use of forwarders in a caching name server. If no
\fBnameserver\fR
entries are present, or if forwarding fails,
\fBlwresd\fR
resolves the queries autonomously starting at the root name servers, using a built\-in list of root server hints.
.SH "OPTIONS"
.TP
\fB-C \fIconfig-file\fB\fR
Use \fIconfig-file\fR as the
configuration file instead of the default,
\-C \fIconfig\-file\fR
Use
\fIconfig\-file\fR
as the configuration file instead of the default,
\fI/etc/resolv.conf\fR.
.TP
\fB-d \fIdebug-level\fB\fR
Set the daemon's debug level to \fIdebug-level\fR.
Debugging traces from \fBlwresd\fR become
more verbose as the debug level increases.
\-d \fIdebug\-level\fR
Set the daemon's debug level to
\fIdebug\-level\fR. Debugging traces from
\fBlwresd\fR
become more verbose as the debug level increases.
.TP
\fB-f\fR
\-f
Run the server in the foreground (i.e. do not daemonize).
.TP
\fB-g\fR
Run the server in the foreground and force all logging
to \fIstderr\fR.
\-g
Run the server in the foreground and force all logging to
\fIstderr\fR.
.TP
\fB-n \fI#cpus\fB\fR
Create \fI#cpus\fR worker threads
to take advantage of multiple CPUs. If not specified,
\fBlwresd\fR will try to determine the
number of CPUs present and create one thread per CPU.
If it is unable to determine the number of CPUs, a
single worker thread will be created.
\-n \fI#cpus\fR
Create
\fI#cpus\fR
worker threads to take advantage of multiple CPUs. If not specified,
\fBlwresd\fR
will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created.
.TP
\fB-P \fIport\fB\fR
\-P \fIport\fR
Listen for lightweight resolver queries on port
\fIport\fR. If
not specified, the default is port 921.
\fIport\fR. If not specified, the default is port 921.
.TP
\fB-p \fIport\fB\fR
Send DNS lookups to port \fIport\fR. If not
specified, the default is port 53. This provides a
way of testing the lightweight resolver daemon with a
name server that listens for queries on a non-standard
port number.
\-p \fIport\fR
Send DNS lookups to port
\fIport\fR. If not specified, the default is port 53. This provides a way of testing the lightweight resolver daemon with a name server that listens for queries on a non\-standard port number.
.TP
\fB-s\fR
Write memory usage statistics to \fIstdout\fR
\-s
Write memory usage statistics to
\fIstdout\fR
on exit.
.sp
.RS
.B "Note:"
This option is mainly of interest to BIND 9 developers
and may be removed or changed in a future release.
This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release.
.RE
.sp
.TP
\fB-t \fIdirectory\fB\fR
\fBchroot()\fR to \fIdirectory\fR after
processing the command line arguments, but before
reading the configuration file.
.sp
\-t \fIdirectory\fR
\fBchroot()\fR
to
\fIdirectory\fR
after processing the command line arguments, but before reading the configuration file.
.RS
.B "Warning:"
This option should be used in conjunction with the
\fB-u\fR option, as chrooting a process
running as root doesn't enhance security on most
systems; the way \fBchroot()\fR is
defined allows a process with root privileges to
escape a chroot jail.
\fB\-u\fR
option, as chrooting a process running as root doesn't enhance security on most systems; the way
\fBchroot()\fR
is defined allows a process with root privileges to escape a chroot jail.
.RE
.sp
.TP
\fB-u \fIuser\fB\fR
\fBsetuid()\fR to \fIuser\fR after completing
privileged operations, such as creating sockets that
listen on privileged ports.
\-u \fIuser\fR
\fBsetuid()\fR
to
\fIuser\fR
after completing privileged operations, such as creating sockets that listen on privileged ports.
.TP
\fB-v\fR
\-v
Report the version number and exit.
.SH "FILES"
.TP
\fB\fI/etc/resolv.conf\fB\fR
\fI/etc/resolv.conf\fR
The default configuration file.
.TP
\fB\fI/var/run/lwresd.pid\fB\fR
The default process-id file.
\fI/var/run/lwresd.pid\fR
The default process\-id file.
.SH "SEE ALSO"
.PP
\fBnamed\fR(8),

21
contrib/bind9/bin/named/lwresd.docbook
View file

@ -1,6 +1,8 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: lwresd.docbook,v 1.6.208.2 2004/06/03 02:24:57 marka Exp $ -->
<!-- $Id: lwresd.docbook,v 1.6.208.4 2005/05/13 01:22:33 marka Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,19 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><application>lwresd</application></refname>
<refpurpose>lightweight resolver daemon</refpurpose>

594
contrib/bind9/bin/named/lwresd.html
View file

@ -1,497 +1,189 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: lwresd.html,v 1.4.2.1.4.3 2004/08/22 23:38:59 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>lwresd</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><SPAN
CLASS="APPLICATION"
>lwresd</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><SPAN
CLASS="APPLICATION"
>lwresd</SPAN
>&nbsp;--&nbsp;lightweight resolver daemon</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>lwresd</B
> [<VAR
CLASS="OPTION"
>-C <VAR
CLASS="REPLACEABLE"
>config-file</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-d <VAR
CLASS="REPLACEABLE"
>debug-level</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-f</VAR
>] [<VAR
CLASS="OPTION"
>-g</VAR
>] [<VAR
CLASS="OPTION"
>-i <VAR
CLASS="REPLACEABLE"
>pid-file</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-n <VAR
CLASS="REPLACEABLE"
>#cpus</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-P <VAR
CLASS="REPLACEABLE"
>port</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-p <VAR
CLASS="REPLACEABLE"
>port</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-s</VAR
>] [<VAR
CLASS="OPTION"
>-t <VAR
CLASS="REPLACEABLE"
>directory</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-u <VAR
CLASS="REPLACEABLE"
>user</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-v</VAR
>]</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN48"
></A
><H2
>DESCRIPTION</H2
><P
> <B
CLASS="COMMAND"
>lwresd</B
> is the daemon providing name lookup
<!-- $Id: lwresd.html,v 1.4.2.1.4.8 2005/10/13 02:33:47 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>lwresd</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><span class="application">lwresd</span> &#8212; lightweight resolver daemon</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">lwresd</code> [<code class="option">-C <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-i <em class="replaceable"><code>pid-file</code></em></code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-P <em class="replaceable"><code>port</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>]</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525920"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">lwresd</strong></span> is the daemon providing name lookup
services to clients that use the BIND 9 lightweight resolver
library. It is essentially a stripped-down, caching-only name
server that answers queries using the BIND 9 lightweight
resolver protocol rather than the DNS protocol.
</P
><P
> <B
CLASS="COMMAND"
>lwresd</B
> listens for resolver queries on a
</p>
<p>
<span><strong class="command">lwresd</strong></span> listens for resolver queries on a
UDP port on the IPv4 loopback interface, 127.0.0.1. This
means that <B
CLASS="COMMAND"
>lwresd</B
> can only be used by
means that <span><strong class="command">lwresd</strong></span> can only be used by
processes running on the local machine. By default UDP port
number 921 is used for lightweight resolver requests and
responses.
</P
><P
> Incoming lightweight resolver requests are decoded by the
</p>
<p>
Incoming lightweight resolver requests are decoded by the
server which then resolves them using the DNS protocol. When
the DNS lookup completes, <B
CLASS="COMMAND"
>lwresd</B
> encodes
the DNS lookup completes, <span><strong class="command">lwresd</strong></span> encodes
the answers in the lightweight resolver format and returns
them to the client that made the request.
</P
><P
> If <TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
> contains any
<VAR
CLASS="OPTION"
>nameserver</VAR
> entries, <B
CLASS="COMMAND"
>lwresd</B
>
</p>
<p>
If <code class="filename">/etc/resolv.conf</code> contains any
<code class="option">nameserver</code> entries, <span><strong class="command">lwresd</strong></span>
sends recursive DNS queries to those servers. This is similar
to the use of forwarders in a caching name server. If no
<VAR
CLASS="OPTION"
>nameserver</VAR
> entries are present, or if
forwarding fails, <B
CLASS="COMMAND"
>lwresd</B
> resolves the
<code class="option">nameserver</code> entries are present, or if
forwarding fails, <span><strong class="command">lwresd</strong></span> resolves the
queries autonomously starting at the root name servers, using
a built-in list of root server hints.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN63"
></A
><H2
>OPTIONS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>-C <VAR
CLASS="REPLACEABLE"
>config-file</VAR
></DT
><DD
><P
> Use <VAR
CLASS="REPLACEABLE"
>config-file</VAR
> as the
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525969"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-C <em class="replaceable"><code>config-file</code></em></span></dt>
<dd><p>
Use <em class="replaceable"><code>config-file</code></em> as the
configuration file instead of the default,
<TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
>.
</P
></DD
><DT
>-d <VAR
CLASS="REPLACEABLE"
>debug-level</VAR
></DT
><DD
><P
> Set the daemon's debug level to <VAR
CLASS="REPLACEABLE"
>debug-level</VAR
>.
Debugging traces from <B
CLASS="COMMAND"
>lwresd</B
> become
<code class="filename">/etc/resolv.conf</code>.
</p></dd>
<dt><span class="term">-d <em class="replaceable"><code>debug-level</code></em></span></dt>
<dd><p>
Set the daemon's debug level to <em class="replaceable"><code>debug-level</code></em>.
Debugging traces from <span><strong class="command">lwresd</strong></span> become
more verbose as the debug level increases.
</P
></DD
><DT
>-f</DT
><DD
><P
> Run the server in the foreground (i.e. do not daemonize).
</P
></DD
><DT
>-g</DT
><DD
><P
> Run the server in the foreground and force all logging
to <TT
CLASS="FILENAME"
>stderr</TT
>.
</P
></DD
><DT
>-n <VAR
CLASS="REPLACEABLE"
>#cpus</VAR
></DT
><DD
><P
> Create <VAR
CLASS="REPLACEABLE"
>#cpus</VAR
> worker threads
</p></dd>
<dt><span class="term">-f</span></dt>
<dd><p>
Run the server in the foreground (i.e. do not daemonize).
</p></dd>
<dt><span class="term">-g</span></dt>
<dd><p>
Run the server in the foreground and force all logging
to <code class="filename">stderr</code>.
</p></dd>
<dt><span class="term">-n <em class="replaceable"><code>#cpus</code></em></span></dt>
<dd><p>
Create <em class="replaceable"><code>#cpus</code></em> worker threads
to take advantage of multiple CPUs. If not specified,
<B
CLASS="COMMAND"
>lwresd</B
> will try to determine the
<span><strong class="command">lwresd</strong></span> will try to determine the
number of CPUs present and create one thread per CPU.
If it is unable to determine the number of CPUs, a
single worker thread will be created.
</P
></DD
><DT
>-P <VAR
CLASS="REPLACEABLE"
>port</VAR
></DT
><DD
><P
> Listen for lightweight resolver queries on port
<VAR
CLASS="REPLACEABLE"
>port</VAR
>. If
</p></dd>
<dt><span class="term">-P <em class="replaceable"><code>port</code></em></span></dt>
<dd><p>
Listen for lightweight resolver queries on port
<em class="replaceable"><code>port</code></em>. If
not specified, the default is port 921.
</P
></DD
><DT
>-p <VAR
CLASS="REPLACEABLE"
>port</VAR
></DT
><DD
><P
> Send DNS lookups to port <VAR
CLASS="REPLACEABLE"
>port</VAR
>. If not
</p></dd>
<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
<dd><p>
Send DNS lookups to port <em class="replaceable"><code>port</code></em>. If not
specified, the default is port 53. This provides a
way of testing the lightweight resolver daemon with a
name server that listens for queries on a non-standard
port number.
</P
></DD
><DT
>-s</DT
><DD
><P
> Write memory usage statistics to <TT
CLASS="FILENAME"
>stdout</TT
>
</p></dd>
<dt><span class="term">-s</span></dt>
<dd>
<p>
Write memory usage statistics to <code class="filename">stdout</code>
on exit.
</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
> This option is mainly of interest to BIND 9 developers
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>
This option is mainly of interest to BIND 9 developers
and may be removed or changed in a future release.
</P
></BLOCKQUOTE
></DIV
></DD
><DT
>-t <VAR
CLASS="REPLACEABLE"
>directory</VAR
></DT
><DD
><P
> <CODE
CLASS="FUNCTION"
>chroot()</CODE
> to <VAR
CLASS="REPLACEABLE"
>directory</VAR
> after
</p>
</div>
</dd>
<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
<dd>
<p>
<code class="function">chroot()</code> to <em class="replaceable"><code>directory</code></em> after
processing the command line arguments, but before
reading the configuration file.
</P
><DIV
CLASS="WARNING"
><P
></P
><TABLE
CLASS="WARNING"
BORDER="1"
WIDTH="90%"
><TR
><TD
ALIGN="CENTER"
><B
>Warning</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
> This option should be used in conjunction with the
<VAR
CLASS="OPTION"
>-u</VAR
> option, as chrooting a process
</p>
<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Warning</h3>
<p>
This option should be used in conjunction with the
<code class="option">-u</code> option, as chrooting a process
running as root doesn't enhance security on most
systems; the way <CODE
CLASS="FUNCTION"
>chroot()</CODE
> is
systems; the way <code class="function">chroot()</code> is
defined allows a process with root privileges to
escape a chroot jail.
</P
></TD
></TR
></TABLE
></DIV
></DD
><DT
>-u <VAR
CLASS="REPLACEABLE"
>user</VAR
></DT
><DD
><P
> <CODE
CLASS="FUNCTION"
>setuid()</CODE
> to <VAR
CLASS="REPLACEABLE"
>user</VAR
> after completing
</p>
</div>
</dd>
<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
<dd><p>
<code class="function">setuid()</code> to <em class="replaceable"><code>user</code></em> after completing
privileged operations, such as creating sockets that
listen on privileged ports.
</P
></DD
><DT
>-v</DT
><DD
><P
> Report the version number and exit.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN137"
></A
><H2
>FILES</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="FILENAME"
>/etc/resolv.conf</TT
></DT
><DD
><P
> The default configuration file.
</P
></DD
><DT
><TT
CLASS="FILENAME"
>/var/run/lwresd.pid</TT
></DT
><DD
><P
> The default process-id file.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN150"
></A
><H2
>SEE ALSO</H2
><P
> <SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>named</SPAN
>(8)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>lwres</SPAN
>(3)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>resolver</SPAN
>(5)</SPAN
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN162"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
</p></dd>
<dt><span class="term">-v</span></dt>
<dd><p>
Report the version number and exit.
</p></dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526237"></a><h2>FILES</h2>
<div class="variablelist"><dl>
<dt><span class="term"><code class="filename">/etc/resolv.conf</code></span></dt>
<dd><p>
The default configuration file.
</p></dd>
<dt><span class="term"><code class="filename">/var/run/lwresd.pid</code></span></dt>
<dd><p>
The default process-id file.
</p></dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526277"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">lwres</span>(3)</span>,
<span class="citerefentry"><span class="refentrytitle">resolver</span>(5)</span>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526315"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

135
contrib/bind9/bin/named/main.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: main.c,v 1.119.2.3.2.17 2004/10/25 00:42:54 marka Exp $ */
/* $Id: main.c,v 1.119.2.3.2.22 2005/04/29 01:04:47 marka Exp $ */
#include <config.h>
@ -47,10 +47,6 @@
#include <dst/result.h>
#ifdef HAVE_LIBSCF
#include <libscf.h>
#endif
/*
* Defining NS_MAIN provides storage declarations (rather than extern)
* for variables in named/globals.h.
@ -66,6 +62,9 @@
#include <named/server.h>
#include <named/lwresd.h>
#include <named/main.h>
#ifdef HAVE_LIBSCF
#include <named/ns_smf_globals.h>
#endif
/*
* Include header files for database drivers here.
@ -540,6 +539,9 @@ destroy_managers(void) {
static void
setup(void) {
isc_result_t result;
#ifdef HAVE_LIBSCF
char *instance = NULL;
#endif
/*
* Get the user and group information before changing the root
@ -555,6 +557,18 @@ setup(void) {
ns_os_opendevnull();
#ifdef HAVE_LIBSCF
/* Check if named is under smf control, before chroot. */
result = ns_smf_get_instance(&instance, 0, ns_g_mctx);
/* We don't care about instance, just check if we got one. */
if (result == ISC_R_SUCCESS)
ns_smf_got_instance = 1;
else
ns_smf_got_instance = 0;
if (instance != NULL)
isc_mem_free(ns_g_mctx, instance);
#endif /* HAVE_LIBSCF */
#ifdef PATH_RANDOMDEV
/*
* Initialize system's random device as fallback entropy source
@ -699,92 +713,73 @@ ns_main_setmemstats(const char *filename) {
#ifdef HAVE_LIBSCF
/*
* Get FMRI for the current named process
* Get FMRI for the named process.
*/
static char *
scf_get_ins_name(void) {
isc_result_t
ns_smf_get_instance(char **ins_name, int debug, isc_mem_t *mctx) {
scf_handle_t *h = NULL;
int namelen;
char *ins_name;
char *instance;
REQUIRE(ins_name != NULL && *ins_name == NULL);
if ((h = scf_handle_create(SCF_VERSION)) == NULL) {
UNEXPECTED_ERROR(__FILE__, __LINE__,
"scf_handle_create() failed: %s",
scf_strerror(scf_error()));
return (NULL);
if (debug)
UNEXPECTED_ERROR(__FILE__, __LINE__,
"scf_handle_create() failed: %s",
scf_strerror(scf_error()));
return (ISC_R_FAILURE);
}
if (scf_handle_bind(h) == -1) {
UNEXPECTED_ERROR(__FILE__, __LINE__,
"scf_handle_bind() failed: %s",
scf_strerror(scf_error()));
if (debug)
UNEXPECTED_ERROR(__FILE__, __LINE__,
"scf_handle_bind() failed: %s",
scf_strerror(scf_error()));
scf_handle_destroy(h);
return (NULL);
return (ISC_R_FAILURE);
}
if ((namelen = scf_myname(h, NULL, 0)) == -1) {
isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
NS_LOGMODULE_MAIN, ISC_LOG_INFO,
"scf_myname() failed: %s",
scf_strerror(scf_error()));
if (debug)
UNEXPECTED_ERROR(__FILE__, __LINE__,
"scf_myname() failed: %s",
scf_strerror(scf_error()));
scf_handle_destroy(h);
return (NULL);
return (ISC_R_FAILURE);
}
if ((ins_name = malloc(namelen + 1)) == NULL) {
if ((instance = isc_mem_allocate(mctx, namelen + 1)) == NULL) {
UNEXPECTED_ERROR(__FILE__, __LINE__,
"scf_get_ins_named() memory "
"ns_smf_get_instance memory "
"allocation failed: %s",
isc_result_totext(ISC_R_NOMEMORY));
scf_handle_destroy(h);
return (NULL);
return (ISC_R_FAILURE);
}
if (scf_myname(h, ins_name, namelen + 1) == -1) {
UNEXPECTED_ERROR(__FILE__, __LINE__,
"scf_myname() failed: %s",
scf_strerror(scf_error()));
if (scf_myname(h, instance, namelen + 1) == -1) {
if (debug)
UNEXPECTED_ERROR(__FILE__, __LINE__,
"scf_myname() failed: %s",
scf_strerror(scf_error()));
scf_handle_destroy(h);
free(ins_name);
return (NULL);
isc_mem_free(mctx, instance);
return (ISC_R_FAILURE);
}
scf_handle_destroy(h);
isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_MAIN,
ISC_LOG_INFO, "instance name:%s", ins_name);
return (ins_name);
*ins_name = instance;
return (ISC_R_SUCCESS);
}
static void
scf_cleanup(void) {
char *s;
char *ins_name;
if ((ins_name = scf_get_ins_name()) != NULL) {
if ((s = smf_get_state(ins_name)) != NULL) {
if ((strcmp(SCF_STATE_STRING_ONLINE, s) == 0) ||
(strcmp(SCF_STATE_STRING_DEGRADED, s) == 0)) {
if (smf_disable_instance(ins_name, 0) != 0) {
UNEXPECTED_ERROR(__FILE__, __LINE__,
"smf_disable_instance() failed: %s",
scf_strerror(scf_error()));
}
}
free(s);
} else {
UNEXPECTED_ERROR(__FILE__, __LINE__,
"smf_get_state() failed: %s",
scf_strerror(scf_error()));
}
free(ins_name);
}
}
#endif
#endif /* HAVE_LIBSCF */
int
main(int argc, char *argv[]) {
isc_result_t result;
#ifdef HAVE_LIBSCF
char *instance = NULL;
#endif
/*
* Record version in core image.
@ -856,8 +851,20 @@ main(int argc, char *argv[]) {
} while (result != ISC_R_SUCCESS);
#ifdef HAVE_LIBSCF
scf_cleanup();
#endif
if (ns_smf_want_disable == 1) {
result = ns_smf_get_instance(&instance, 1, ns_g_mctx);
if (result == ISC_R_SUCCESS && instance != NULL) {
if (smf_disable_instance(instance, 0) != 0)
UNEXPECTED_ERROR(__FILE__, __LINE__,
"smf_disable_instance() ",
"failed for %s : %s",
instance,
scf_strerror(scf_error()));
}
if (instance != NULL)
isc_mem_free(ns_g_mctx, instance);
}
#endif /* HAVE_LIBSCF */
cleanup();

225
contrib/bind9/bin/named/named.8
View file

@ -1,177 +1,182 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: named.8,v 1.17.208.3 2004/06/03 05:35:47 marka Exp $
.\" $Id: named.8,v 1.17.208.6 2005/10/13 02:33:46 marka Exp $
.\"
.TH "NAMED" "8" "June 30, 2000" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "NAMED" "8" "June 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
named \- Internet domain name server
.SH SYNOPSIS
.sp
\fBnamed\fR [ \fB-4\fR ] [ \fB-6\fR ] [ \fB-c \fIconfig-file\fB\fR ] [ \fB-d \fIdebug-level\fB\fR ] [ \fB-f\fR ] [ \fB-g\fR ] [ \fB-n \fI#cpus\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-s\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-u \fIuser\fB\fR ] [ \fB-v\fR ] [ \fB-x \fIcache-file\fB\fR ]
.SH "SYNOPSIS"
.HP 6
\fBnamed\fR [\fB\-4\fR] [\fB\-6\fR] [\fB\-c\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-d\ \fR\fB\fIdebug\-level\fR\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR] [\fB\-x\ \fR\fB\fIcache\-file\fR\fR]
.SH "DESCRIPTION"
.PP
\fBnamed\fR is a Domain Name System (DNS) server,
part of the BIND 9 distribution from ISC. For more
information on the DNS, see RFCs 1033, 1034, and 1035.
\fBnamed\fR
is a Domain Name System (DNS) server, part of the BIND 9 distribution from ISC. For more information on the DNS, see RFCs 1033, 1034, and 1035.
.PP
When invoked without arguments, \fBnamed\fR will
read the default configuration file
\fI/etc/named.conf\fR, read any initial
data, and listen for queries.
When invoked without arguments,
\fBnamed\fR
will read the default configuration file
\fI/etc/named.conf\fR, read any initial data, and listen for queries.
.SH "OPTIONS"
.TP
\fB-4\fR
\-4
Use IPv4 only even if the host machine is capable of IPv6.
\fB-4\fR and \fB-6\fR are mutually
exclusive.
\fB\-4\fR
and
\fB\-6\fR
are mutually exclusive.
.TP
\fB-6\fR
\-6
Use IPv6 only even if the host machine is capable of IPv4.
\fB-4\fR and \fB-6\fR are mutually
exclusive.
\fB\-4\fR
and
\fB\-6\fR
are mutually exclusive.
.TP
\fB-c \fIconfig-file\fB\fR
Use \fIconfig-file\fR as the
configuration file instead of the default,
\fI/etc/named.conf\fR. To
ensure that reloading the configuration file continues
to work after the server has changed its working
directory due to to a possible
\fBdirectory\fR option in the configuration
file, \fIconfig-file\fR should be
an absolute pathname.
\-c \fIconfig\-file\fR
Use
\fIconfig\-file\fR
as the configuration file instead of the default,
\fI/etc/named.conf\fR. To ensure that reloading the configuration file continues to work after the server has changed its working directory due to to a possible
\fBdirectory\fR
option in the configuration file,
\fIconfig\-file\fR
should be an absolute pathname.
.TP
\fB-d \fIdebug-level\fB\fR
Set the daemon's debug level to \fIdebug-level\fR.
Debugging traces from \fBnamed\fR become
more verbose as the debug level increases.
\-d \fIdebug\-level\fR
Set the daemon's debug level to
\fIdebug\-level\fR. Debugging traces from
\fBnamed\fR
become more verbose as the debug level increases.
.TP
\fB-f\fR
\-f
Run the server in the foreground (i.e. do not daemonize).
.TP
\fB-g\fR
Run the server in the foreground and force all logging
to \fIstderr\fR.
\-g
Run the server in the foreground and force all logging to
\fIstderr\fR.
.TP
\fB-n \fI#cpus\fB\fR
Create \fI#cpus\fR worker threads
to take advantage of multiple CPUs. If not specified,
\fBnamed\fR will try to determine the
number of CPUs present and create one thread per CPU.
If it is unable to determine the number of CPUs, a
single worker thread will be created.
\-n \fI#cpus\fR
Create
\fI#cpus\fR
worker threads to take advantage of multiple CPUs. If not specified,
\fBnamed\fR
will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created.
.TP
\fB-p \fIport\fB\fR
Listen for queries on port \fIport\fR. If not
specified, the default is port 53.
\-p \fIport\fR
Listen for queries on port
\fIport\fR. If not specified, the default is port 53.
.TP
\fB-s\fR
Write memory usage statistics to \fIstdout\fR on exit.
.sp
\-s
Write memory usage statistics to
\fIstdout\fR
on exit.
.RS
.B "Note:"
This option is mainly of interest to BIND 9 developers
and may be removed or changed in a future release.
This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release.
.RE
.sp
.TP
\fB-t \fIdirectory\fB\fR
\fBchroot()\fR to \fIdirectory\fR after
processing the command line arguments, but before
reading the configuration file.
.sp
\-t \fIdirectory\fR
\fBchroot()\fR
to
\fIdirectory\fR
after processing the command line arguments, but before reading the configuration file.
.RS
.B "Warning:"
This option should be used in conjunction with the
\fB-u\fR option, as chrooting a process
running as root doesn't enhance security on most
systems; the way \fBchroot()\fR is
defined allows a process with root privileges to
escape a chroot jail.
\fB\-u\fR
option, as chrooting a process running as root doesn't enhance security on most systems; the way
\fBchroot()\fR
is defined allows a process with root privileges to escape a chroot jail.
.RE
.sp
.TP
\fB-u \fIuser\fB\fR
\fBsetuid()\fR to \fIuser\fR after completing
privileged operations, such as creating sockets that
listen on privileged ports.
.sp
\-u \fIuser\fR
\fBsetuid()\fR
to
\fIuser\fR
after completing privileged operations, such as creating sockets that listen on privileged ports.
.RS
.B "Note:"
On Linux, \fBnamed\fR uses the kernel's
capability mechanism to drop all root privileges
except the ability to \fBbind()\fR to a
privileged port and set process resource limits.
Unfortunately, this means that the \fB-u\fR
option only works when \fBnamed\fR is run
on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or
later, since previous kernels did not allow privileges
to be retained after \fBsetuid()\fR.
On Linux,
\fBnamed\fR
uses the kernel's capability mechanism to drop all root privileges except the ability to
\fBbind()\fR
to a privileged port and set process resource limits. Unfortunately, this means that the
\fB\-u\fR
option only works when
\fBnamed\fR
is run on kernel 2.2.18 or later, or kernel 2.3.99\-pre3 or later, since previous kernels did not allow privileges to be retained after
\fBsetuid()\fR.
.RE
.sp
.TP
\fB-v\fR
\-v
Report the version number and exit.
.TP
\fB-x \fIcache-file\fB\fR
Load data from \fIcache-file\fR into the
cache of the default view.
.sp
\-x \fIcache\-file\fR
Load data from
\fIcache\-file\fR
into the cache of the default view.
.RS
.B "Warning:"
This option must not be used. It is only of interest
to BIND 9 developers and may be removed or changed in a
future release.
This option must not be used. It is only of interest to BIND 9 developers and may be removed or changed in a future release.
.RE
.sp
.SH "SIGNALS"
.PP
In routine operation, signals should not be used to control
the nameserver; \fBrndc\fR should be used
instead.
In routine operation, signals should not be used to control the nameserver;
\fBrndc\fR
should be used instead.
.TP
\fBSIGHUP\fR
SIGHUP
Force a reload of the server.
.TP
\fBSIGINT, SIGTERM\fR
SIGINT, SIGTERM
Shut down the server.
.PP
The result of sending any other signals to the server is undefined.
.PP
.SH "CONFIGURATION"
.PP
The \fBnamed\fR configuration file is too complex
to describe in detail here. A complete description is
provided in the \fIBIND 9 Administrator Reference
Manual\fR.
The
\fBnamed\fR
configuration file is too complex to describe in detail here. A complete description is provided in the
BIND 9 Administrator Reference Manual.
.SH "FILES"
.TP
\fB\fI/etc/named.conf\fB\fR
\fI/etc/named.conf\fR
The default configuration file.
.TP
\fB\fI/var/run/named.pid\fB\fR
The default process-id file.
\fI/var/run/named.pid\fR
The default process\-id file.
.SH "SEE ALSO"
.PP
\fIRFC 1033\fR,
\fIRFC 1034\fR,
\fIRFC 1035\fR,
RFC 1033,
RFC 1034,
RFC 1035,
\fBrndc\fR(8),
\fBlwresd\fR(8),
\fIBIND 9 Administrator Reference Manual\fR.
BIND 9 Administrator Reference Manual.
.SH "AUTHOR"
.PP
Internet Systems Consortium

493
contrib/bind9/bin/named/named.conf.5
View file

@ -1,32 +1,40 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: named.conf.5,v 1.1.4.3 2004/10/18 02:33:06 marka Exp $
.\" $Id: named.conf.5,v 1.1.4.6 2005/10/13 02:33:47 marka Exp $
.\"
.TH "NAMED.CONF" "5" "Aug 13, 2004" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "\\FINAMED.CONF\\FR" "5" "Aug 13, 2004" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
named.conf \- configuration file for named
.SH SYNOPSIS
.sp
.SH "SYNOPSIS"
.HP 11
\fBnamed.conf\fR
.SH "DESCRIPTION"
.PP
\fInamed.conf\fR is the configuration file for
\fBnamed\fR. Statements are enclosed
in braces and terminated with a semi-colon. Clauses in
the statements are also semi-colon terminated. The usual
comment styles are supported:
\fInamed.conf\fR
is the configuration file for
\fBnamed\fR. Statements are enclosed in braces and terminated with a semi\-colon. Clauses in the statements are also semi\-colon terminated. The usual comment styles are supported:
.PP
C style: /* */
.PP
@ -37,7 +45,6 @@ Unix style: # to end of line
.sp
.nf
acl \fIstring\fR { \fIaddress_match_element\fR; ... };
.sp
.fi
.SH "KEY"
.sp
@ -46,7 +53,6 @@ key \fIdomain_name\fR {
algorithm \fIstring\fR;
secret \fIstring\fR;
};
.sp
.fi
.SH "MASTERS"
.sp
@ -55,7 +61,6 @@ masters \fIstring\fR [ port \fIinteger\fR ] {
( \fImasters\fR | \fIipv4_address\fR [port \fIinteger\fR] |
\fIipv6_address\fR [port \fIinteger\fR] ) [ key \fIstring\fR ]; ...
};
.sp
.fi
.SH "SERVER"
.sp
@ -63,27 +68,24 @@ masters \fIstring\fR [ port \fIinteger\fR ] {
server ( \fIipv4_address\fR | \fIipv6_address\fR ) {
bogus \fIboolean\fR;
edns \fIboolean\fR;
provide-ixfr \fIboolean\fR;
request-ixfr \fIboolean\fR;
provide\-ixfr \fIboolean\fR;
request\-ixfr \fIboolean\fR;
keys \fIserver_key\fR;
transfers \fIinteger\fR;
transfer-format ( many-answers | one-answer );
transfer-source ( \fIipv4_address\fR | * )
transfer\-format ( many\-answers | one\-answer );
transfer\-source ( \fIipv4_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
transfer-source-v6 ( \fIipv6_address\fR | * )
transfer\-source\-v6 ( \fIipv6_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
support-ixfr \fIboolean\fR; // obsolete
support\-ixfr \fIboolean\fR; // obsolete
};
.sp
.fi
.SH "TRUSTED-KEYS"
.SH "TRUSTED\-KEYS"
.sp
.nf
trusted-keys {
trusted\-keys {
\fIdomain_name\fR \fIflags\fR \fIprotocol\fR \fIalgorithm\fR \fIkey\fR; ...
};
.sp
.fi
.SH "CONTROLS"
.sp
@ -95,7 +97,6 @@ controls {
[ keys { \fIstring\fR; ... } ];
unix \fIunsupported\fR; // not implemented
};
.sp
.fi
.SH "LOGGING"
.sp
@ -107,363 +108,325 @@ logging {
null;
stderr;
severity \fIlog_severity\fR;
print-time \fIboolean\fR;
print-severity \fIboolean\fR;
print-category \fIboolean\fR;
print\-time \fIboolean\fR;
print\-severity \fIboolean\fR;
print\-category \fIboolean\fR;
};
category \fIstring\fR { \fIstring\fR; ... };
};
.sp
.fi
.SH "LWRES"
.sp
.nf
lwres {
listen-on [ port \fIinteger\fR ] {
listen\-on [ port \fIinteger\fR ] {
( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ...
};
view \fIstring\fR \fIoptional_class\fR;
search { \fIstring\fR; ... };
ndots \fIinteger\fR;
};
.sp
.fi
.SH "OPTIONS"
.sp
.nf
options {
avoid-v4-udp-ports { \fIport\fR; ... };
avoid-v6-udp-ports { \fIport\fR; ... };
avoid\-v4\-udp\-ports { \fIport\fR; ... };
avoid\-v6\-udp\-ports { \fIport\fR; ... };
blackhole { \fIaddress_match_element\fR; ... };
coresize \fIsize\fR;
datasize \fIsize\fR;
directory \fIquoted_string\fR;
dump-file \fIquoted_string\fR;
dump\-file \fIquoted_string\fR;
files \fIsize\fR;
heartbeat-interval \fIinteger\fR;
host-statistics \fIboolean\fR; // not implemented
host-statistics-max \fInumber\fR; // not implemented
heartbeat\-interval \fIinteger\fR;
host\-statistics \fIboolean\fR; // not implemented
host\-statistics\-max \fInumber\fR; // not implemented
hostname ( \fIquoted_string\fR | none );
interface-interval \fIinteger\fR;
listen-on [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... };
listen-on-v6 [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... };
match-mapped-addresses \fIboolean\fR;
memstatistics-file \fIquoted_string\fR;
pid-file ( \fIquoted_string\fR | none );
interface\-interval \fIinteger\fR;
listen\-on [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... };
listen\-on\-v6 [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... };
match\-mapped\-addresses \fIboolean\fR;
memstatistics\-file \fIquoted_string\fR;
pid\-file ( \fIquoted_string\fR | none );
port \fIinteger\fR;
querylog \fIboolean\fR;
recursing-file \fIquoted_string\fR;
random-device \fIquoted_string\fR;
recursive-clients \fIinteger\fR;
serial-query-rate \fIinteger\fR;
server-id ( \fIquoted_string\fR | none |;
recursing\-file \fIquoted_string\fR;
random\-device \fIquoted_string\fR;
recursive\-clients \fIinteger\fR;
serial\-query\-rate \fIinteger\fR;
server\-id ( \fIquoted_string\fR | none |;
stacksize \fIsize\fR;
statistics-file \fIquoted_string\fR;
statistics-interval \fIinteger\fR; // not yet implemented
tcp-clients \fIinteger\fR;
tcp-listen-queue \fIinteger\fR;
tkey-dhkey \fIquoted_string\fR \fIinteger\fR;
tkey-gssapi-credential \fIquoted_string\fR;
tkey-domain \fIquoted_string\fR;
transfers-per-ns \fIinteger\fR;
transfers-in \fIinteger\fR;
transfers-out \fIinteger\fR;
use-ixfr \fIboolean\fR;
statistics\-file \fIquoted_string\fR;
statistics\-interval \fIinteger\fR; // not yet implemented
tcp\-clients \fIinteger\fR;
tcp\-listen\-queue \fIinteger\fR;
tkey\-dhkey \fIquoted_string\fR \fIinteger\fR;
tkey\-gssapi\-credential \fIquoted_string\fR;
tkey\-domain \fIquoted_string\fR;
transfers\-per\-ns \fIinteger\fR;
transfers\-in \fIinteger\fR;
transfers\-out \fIinteger\fR;
use\-ixfr \fIboolean\fR;
version ( \fIquoted_string\fR | none );
allow-recursion { \fIaddress_match_element\fR; ... };
allow\-recursion { \fIaddress_match_element\fR; ... };
sortlist { \fIaddress_match_element\fR; ... };
topology { \fIaddress_match_element\fR; ... }; // not implemented
auth-nxdomain \fIboolean\fR; // default changed
minimal-responses \fIboolean\fR;
auth\-nxdomain \fIboolean\fR; // default changed
minimal\-responses \fIboolean\fR;
recursion \fIboolean\fR;
rrset-order {
rrset\-order {
[ class \fIstring\fR ] [ type \fIstring\fR ]
[ name \fIquoted_string\fR ] \fIstring\fR \fIstring\fR; ...
};
provide-ixfr \fIboolean\fR;
request-ixfr \fIboolean\fR;
rfc2308-type1 \fIboolean\fR; // not yet implemented
additional-from-auth \fIboolean\fR;
additional-from-cache \fIboolean\fR;
query-source \fIquerysource4\fR;
query-source-v6 \fIquerysource6\fR;
cleaning-interval \fIinteger\fR;
min-roots \fIinteger\fR; // not implemented
lame-ttl \fIinteger\fR;
max-ncache-ttl \fIinteger\fR;
max-cache-ttl \fIinteger\fR;
transfer-format ( many-answers | one-answer );
max-cache-size \fIsize_no_default\fR;
check-names ( master | slave | response )
provide\-ixfr \fIboolean\fR;
request\-ixfr \fIboolean\fR;
rfc2308\-type1 \fIboolean\fR; // not yet implemented
additional\-from\-auth \fIboolean\fR;
additional\-from\-cache \fIboolean\fR;
query\-source \fIquerysource4\fR;
query\-source\-v6 \fIquerysource6\fR;
cleaning\-interval \fIinteger\fR;
min\-roots \fIinteger\fR; // not implemented
lame\-ttl \fIinteger\fR;
max\-ncache\-ttl \fIinteger\fR;
max\-cache\-ttl \fIinteger\fR;
transfer\-format ( many\-answers | one\-answer );
max\-cache\-size \fIsize_no_default\fR;
check\-names ( master | slave | response )
( fail | warn | ignore );
cache-file \fIquoted_string\fR;
suppress-initial-notify \fIboolean\fR; // not yet implemented
preferred-glue \fIstring\fR;
dual-stack-servers [ port \fIinteger\fR ] {
cache\-file \fIquoted_string\fR;
suppress\-initial\-notify \fIboolean\fR; // not yet implemented
preferred\-glue \fIstring\fR;
dual\-stack\-servers [ port \fIinteger\fR ] {
( \fIquoted_string\fR [port \fIinteger\fR] |
\fIipv4_address\fR [port \fIinteger\fR] |
\fIipv6_address\fR [port \fIinteger\fR] ); ...
}
edns-udp-size \fIinteger\fR;
root-delegation-only [ exclude { \fIquoted_string\fR; ... } ];
disable-algorithms \fIstring\fR { \fIstring\fR; ... };
dnssec-enable \fIboolean\fR;
dnssec-lookaside \fIstring\fR trust-anchor \fIstring\fR;
dnssec-must-be-secure \fIstring\fR \fIboolean\fR;
edns\-udp\-size \fIinteger\fR;
root\-delegation\-only [ exclude { \fIquoted_string\fR; ... } ];
disable\-algorithms \fIstring\fR { \fIstring\fR; ... };
dnssec\-enable \fIboolean\fR;
dnssec\-lookaside \fIstring\fR trust\-anchor \fIstring\fR;
dnssec\-must\-be\-secure \fIstring\fR \fIboolean\fR;
dialup \fIdialuptype\fR;
ixfr-from-differences \fIixfrdiff\fR;
allow-query { \fIaddress_match_element\fR; ... };
allow-transfer { \fIaddress_match_element\fR; ... };
allow-update-forwarding { \fIaddress_match_element\fR; ... };
ixfr\-from\-differences \fIixfrdiff\fR;
allow\-query { \fIaddress_match_element\fR; ... };
allow\-transfer { \fIaddress_match_element\fR; ... };
allow\-update\-forwarding { \fIaddress_match_element\fR; ... };
notify \fInotifytype\fR;
notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
[ port \fIinteger\fR ]; ... };
allow-notify { \fIaddress_match_element\fR; ... };
allow\-notify { \fIaddress_match_element\fR; ... };
forward ( first | only );
forwarders [ port \fIinteger\fR ] {
( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ...
};
max-journal-size \fIsize_no_default\fR;
max-transfer-time-in \fIinteger\fR;
max-transfer-time-out \fIinteger\fR;
max-transfer-idle-in \fIinteger\fR;
max-transfer-idle-out \fIinteger\fR;
max-retry-time \fIinteger\fR;
min-retry-time \fIinteger\fR;
max-refresh-time \fIinteger\fR;
min-refresh-time \fIinteger\fR;
multi-master \fIboolean\fR;
sig-validity-interval \fIinteger\fR;
transfer-source ( \fIipv4_address\fR | * )
max\-journal\-size \fIsize_no_default\fR;
max\-transfer\-time\-in \fIinteger\fR;
max\-transfer\-time\-out \fIinteger\fR;
max\-transfer\-idle\-in \fIinteger\fR;
max\-transfer\-idle\-out \fIinteger\fR;
max\-retry\-time \fIinteger\fR;
min\-retry\-time \fIinteger\fR;
max\-refresh\-time \fIinteger\fR;
min\-refresh\-time \fIinteger\fR;
multi\-master \fIboolean\fR;
sig\-validity\-interval \fIinteger\fR;
transfer\-source ( \fIipv4_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
transfer-source-v6 ( \fIipv6_address\fR | * )
transfer\-source\-v6 ( \fIipv6_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
alt-transfer-source ( \fIipv4_address\fR | * )
alt\-transfer\-source ( \fIipv4_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
alt-transfer-source-v6 ( \fIipv6_address\fR | * )
alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
use-alt-transfer-source \fIboolean\fR;
zone-statistics \fIboolean\fR;
key-directory \fIquoted_string\fR;
allow-v6-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
deallocate-on-exit \fIboolean\fR; // obsolete
fake-iquery \fIboolean\fR; // obsolete
fetch-glue \fIboolean\fR; // obsolete
has-old-clients \fIboolean\fR; // obsolete
maintain-ixfr-base \fIboolean\fR; // obsolete
max-ixfr-log-size \fIsize\fR; // obsolete
multiple-cnames \fIboolean\fR; // obsolete
named-xfer \fIquoted_string\fR; // obsolete
serial-queries \fIinteger\fR; // obsolete
treat-cr-as-space \fIboolean\fR; // obsolete
use-id-pool \fIboolean\fR; // obsolete
use\-alt\-transfer\-source \fIboolean\fR;
zone\-statistics \fIboolean\fR;
key\-directory \fIquoted_string\fR;
allow\-v6\-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
deallocate\-on\-exit \fIboolean\fR; // obsolete
fake\-iquery \fIboolean\fR; // obsolete
fetch\-glue \fIboolean\fR; // obsolete
has\-old\-clients \fIboolean\fR; // obsolete
maintain\-ixfr\-base \fIboolean\fR; // obsolete
max\-ixfr\-log\-size \fIsize\fR; // obsolete
multiple\-cnames \fIboolean\fR; // obsolete
named\-xfer \fIquoted_string\fR; // obsolete
serial\-queries \fIinteger\fR; // obsolete
treat\-cr\-as\-space \fIboolean\fR; // obsolete
use\-id\-pool \fIboolean\fR; // obsolete
};
.sp
.fi
.SH "VIEW"
.sp
.nf
view \fIstring\fR \fIoptional_class\fR {
match-clients { \fIaddress_match_element\fR; ... };
match-destinations { \fIaddress_match_element\fR; ... };
match-recursive-only \fIboolean\fR;
match\-clients { \fIaddress_match_element\fR; ... };
match\-destinations { \fIaddress_match_element\fR; ... };
match\-recursive\-only \fIboolean\fR;
key \fIstring\fR {
algorithm \fIstring\fR;
secret \fIstring\fR;
};
zone \fIstring\fR \fIoptional_class\fR {
...
};
server ( \fIipv4_address\fR | \fIipv6_address\fR ) {
...
};
trusted-keys {
trusted\-keys {
\fIstring\fR \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; ...
};
allow-recursion { \fIaddress_match_element\fR; ... };
allow\-recursion { \fIaddress_match_element\fR; ... };
sortlist { \fIaddress_match_element\fR; ... };
topology { \fIaddress_match_element\fR; ... }; // not implemented
auth-nxdomain \fIboolean\fR; // default changed
minimal-responses \fIboolean\fR;
auth\-nxdomain \fIboolean\fR; // default changed
minimal\-responses \fIboolean\fR;
recursion \fIboolean\fR;
rrset-order {
rrset\-order {
[ class \fIstring\fR ] [ type \fIstring\fR ]
[ name \fIquoted_string\fR ] \fIstring\fR \fIstring\fR; ...
};
provide-ixfr \fIboolean\fR;
request-ixfr \fIboolean\fR;
rfc2308-type1 \fIboolean\fR; // not yet implemented
additional-from-auth \fIboolean\fR;
additional-from-cache \fIboolean\fR;
query-source \fIquerysource4\fR;
query-source-v6 \fIquerysource6\fR;
cleaning-interval \fIinteger\fR;
min-roots \fIinteger\fR; // not implemented
lame-ttl \fIinteger\fR;
max-ncache-ttl \fIinteger\fR;
max-cache-ttl \fIinteger\fR;
transfer-format ( many-answers | one-answer );
max-cache-size \fIsize_no_default\fR;
check-names ( master | slave | response )
provide\-ixfr \fIboolean\fR;
request\-ixfr \fIboolean\fR;
rfc2308\-type1 \fIboolean\fR; // not yet implemented
additional\-from\-auth \fIboolean\fR;
additional\-from\-cache \fIboolean\fR;
query\-source \fIquerysource4\fR;
query\-source\-v6 \fIquerysource6\fR;
cleaning\-interval \fIinteger\fR;
min\-roots \fIinteger\fR; // not implemented
lame\-ttl \fIinteger\fR;
max\-ncache\-ttl \fIinteger\fR;
max\-cache\-ttl \fIinteger\fR;
transfer\-format ( many\-answers | one\-answer );
max\-cache\-size \fIsize_no_default\fR;
check\-names ( master | slave | response )
( fail | warn | ignore );
cache-file \fIquoted_string\fR;
suppress-initial-notify \fIboolean\fR; // not yet implemented
preferred-glue \fIstring\fR;
dual-stack-servers [ port \fIinteger\fR ] {
cache\-file \fIquoted_string\fR;
suppress\-initial\-notify \fIboolean\fR; // not yet implemented
preferred\-glue \fIstring\fR;
dual\-stack\-servers [ port \fIinteger\fR ] {
( \fIquoted_string\fR [port \fIinteger\fR] |
\fIipv4_address\fR [port \fIinteger\fR] |
\fIipv6_address\fR [port \fIinteger\fR] ); ...
};
edns-udp-size \fIinteger\fR;
root-delegation-only [ exclude { \fIquoted_string\fR; ... } ];
disable-algorithms \fIstring\fR { \fIstring\fR; ... };
dnssec-enable \fIboolean\fR;
dnssec-lookaside \fIstring\fR trust-anchor \fIstring\fR;
dnssec-must-be-secure \fIstring\fR \fIboolean\fR;
edns\-udp\-size \fIinteger\fR;
root\-delegation\-only [ exclude { \fIquoted_string\fR; ... } ];
disable\-algorithms \fIstring\fR { \fIstring\fR; ... };
dnssec\-enable \fIboolean\fR;
dnssec\-lookaside \fIstring\fR trust\-anchor \fIstring\fR;
dnssec\-must\-be\-secure \fIstring\fR \fIboolean\fR;
dialup \fIdialuptype\fR;
ixfr-from-differences \fIixfrdiff\fR;
allow-query { \fIaddress_match_element\fR; ... };
allow-transfer { \fIaddress_match_element\fR; ... };
allow-update-forwarding { \fIaddress_match_element\fR; ... };
ixfr\-from\-differences \fIixfrdiff\fR;
allow\-query { \fIaddress_match_element\fR; ... };
allow\-transfer { \fIaddress_match_element\fR; ... };
allow\-update\-forwarding { \fIaddress_match_element\fR; ... };
notify \fInotifytype\fR;
notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
[ port \fIinteger\fR ]; ... };
allow-notify { \fIaddress_match_element\fR; ... };
allow\-notify { \fIaddress_match_element\fR; ... };
forward ( first | only );
forwarders [ port \fIinteger\fR ] {
( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ...
};
max-journal-size \fIsize_no_default\fR;
max-transfer-time-in \fIinteger\fR;
max-transfer-time-out \fIinteger\fR;
max-transfer-idle-in \fIinteger\fR;
max-transfer-idle-out \fIinteger\fR;
max-retry-time \fIinteger\fR;
min-retry-time \fIinteger\fR;
max-refresh-time \fIinteger\fR;
min-refresh-time \fIinteger\fR;
multi-master \fIboolean\fR;
sig-validity-interval \fIinteger\fR;
transfer-source ( \fIipv4_address\fR | * )
max\-journal\-size \fIsize_no_default\fR;
max\-transfer\-time\-in \fIinteger\fR;
max\-transfer\-time\-out \fIinteger\fR;
max\-transfer\-idle\-in \fIinteger\fR;
max\-transfer\-idle\-out \fIinteger\fR;
max\-retry\-time \fIinteger\fR;
min\-retry\-time \fIinteger\fR;
max\-refresh\-time \fIinteger\fR;
min\-refresh\-time \fIinteger\fR;
multi\-master \fIboolean\fR;
sig\-validity\-interval \fIinteger\fR;
transfer\-source ( \fIipv4_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
transfer-source-v6 ( \fIipv6_address\fR | * )
transfer\-source\-v6 ( \fIipv6_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
alt-transfer-source ( \fIipv4_address\fR | * )
alt\-transfer\-source ( \fIipv4_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
alt-transfer-source-v6 ( \fIipv6_address\fR | * )
alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
use-alt-transfer-source \fIboolean\fR;
zone-statistics \fIboolean\fR;
key-directory \fIquoted_string\fR;
allow-v6-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
fetch-glue \fIboolean\fR; // obsolete
maintain-ixfr-base \fIboolean\fR; // obsolete
max-ixfr-log-size \fIsize\fR; // obsolete
use\-alt\-transfer\-source \fIboolean\fR;
zone\-statistics \fIboolean\fR;
key\-directory \fIquoted_string\fR;
allow\-v6\-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
fetch\-glue \fIboolean\fR; // obsolete
maintain\-ixfr\-base \fIboolean\fR; // obsolete
max\-ixfr\-log\-size \fIsize\fR; // obsolete
};
.sp
.fi
.SH "ZONE"
.sp
.nf
zone \fIstring\fR \fIoptional_class\fR {
type ( master | slave | stub | hint |
forward | delegation-only );
forward | delegation\-only );
file \fIquoted_string\fR;
masters [ port \fIinteger\fR ] {
( \fImasters\fR |
\fIipv4_address\fR [port \fIinteger\fR] |
\fIipv6_address\fR [ port \fIinteger\fR ] ) [ key \fIstring\fR ]; ...
};
database \fIstring\fR;
delegation-only \fIboolean\fR;
check-names ( fail | warn | ignore );
delegation\-only \fIboolean\fR;
check\-names ( fail | warn | ignore );
dialup \fIdialuptype\fR;
ixfr-from-differences \fIboolean\fR;
allow-query { \fIaddress_match_element\fR; ... };
allow-transfer { \fIaddress_match_element\fR; ... };
allow-update { \fIaddress_match_element\fR; ... };
allow-update-forwarding { \fIaddress_match_element\fR; ... };
update-policy {
ixfr\-from\-differences \fIboolean\fR;
allow\-query { \fIaddress_match_element\fR; ... };
allow\-transfer { \fIaddress_match_element\fR; ... };
allow\-update { \fIaddress_match_element\fR; ... };
allow\-update\-forwarding { \fIaddress_match_element\fR; ... };
update\-policy {
( grant | deny ) \fIstring\fR
( name | subdomain | wildcard | self ) \fIstring\fR
\fIrrtypelist\fR; ...
};
notify \fInotifytype\fR;
notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
[ port \fIinteger\fR ]; ... };
allow-notify { \fIaddress_match_element\fR; ... };
allow\-notify { \fIaddress_match_element\fR; ... };
forward ( first | only );
forwarders [ port \fIinteger\fR ] {
( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ...
};
max-journal-size \fIsize_no_default\fR;
max-transfer-time-in \fIinteger\fR;
max-transfer-time-out \fIinteger\fR;
max-transfer-idle-in \fIinteger\fR;
max-transfer-idle-out \fIinteger\fR;
max-retry-time \fIinteger\fR;
min-retry-time \fIinteger\fR;
max-refresh-time \fIinteger\fR;
min-refresh-time \fIinteger\fR;
multi-master \fIboolean\fR;
sig-validity-interval \fIinteger\fR;
transfer-source ( \fIipv4_address\fR | * )
max\-journal\-size \fIsize_no_default\fR;
max\-transfer\-time\-in \fIinteger\fR;
max\-transfer\-time\-out \fIinteger\fR;
max\-transfer\-idle\-in \fIinteger\fR;
max\-transfer\-idle\-out \fIinteger\fR;
max\-retry\-time \fIinteger\fR;
min\-retry\-time \fIinteger\fR;
max\-refresh\-time \fIinteger\fR;
min\-refresh\-time \fIinteger\fR;
multi\-master \fIboolean\fR;
sig\-validity\-interval \fIinteger\fR;
transfer\-source ( \fIipv4_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
transfer-source-v6 ( \fIipv6_address\fR | * )
transfer\-source\-v6 ( \fIipv6_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
alt-transfer-source ( \fIipv4_address\fR | * )
alt\-transfer\-source ( \fIipv4_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
alt-transfer-source-v6 ( \fIipv6_address\fR | * )
alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * )
[ port ( \fIinteger\fR | * ) ];
use-alt-transfer-source \fIboolean\fR;
zone-statistics \fIboolean\fR;
key-directory \fIquoted_string\fR;
ixfr-base \fIquoted_string\fR; // obsolete
ixfr-tmp-file \fIquoted_string\fR; // obsolete
maintain-ixfr-base \fIboolean\fR; // obsolete
max-ixfr-log-size \fIsize\fR; // obsolete
use\-alt\-transfer\-source \fIboolean\fR;
zone\-statistics \fIboolean\fR;
key\-directory \fIquoted_string\fR;
ixfr\-base \fIquoted_string\fR; // obsolete
ixfr\-tmp\-file \fIquoted_string\fR; // obsolete
maintain\-ixfr\-base \fIboolean\fR; // obsolete
max\-ixfr\-log\-size \fIsize\fR; // obsolete
pubkey \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; // obsolete
};
.sp
.fi
.SH "FILES"
.PP
@ -472,4 +435,4 @@ zone \fIstring\fR \fIoptional_class\fR {
.PP
\fBnamed\fR(8),
\fBrndc\fR(8),
\fBBIND 9 Adminstrators Reference Manual\fR.
\fBBIND 9 Adminstrators Reference Manual\fR().

60
contrib/bind9/bin/named/named.conf.docbook
View file

@ -1,6 +1,8 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -15,7 +17,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: named.conf.docbook,v 1.1.4.2 2004/10/17 23:19:49 marka Exp $ -->
<!-- $Id: named.conf.docbook,v 1.1.4.4 2005/05/13 01:22:33 marka Exp $ -->
<refentry>
<refentryinfo>
@ -28,6 +30,14 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><filename>named.conf</filename></refname>
<refpurpose>configuration file for named</refpurpose>
@ -61,35 +71,35 @@
<refsect1>
<title>ACL</title>
<LITERALLAYOUT>
<literallayout>
acl <replaceable>string</replaceable> { <replaceable>address_match_element</replaceable>; ... };
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>KEY</title>
<LITERALLAYOUT>
<literallayout>
key <replaceable>domain_name</replaceable> {
algorithm <replaceable>string</replaceable>;
secret <replaceable>string</replaceable>;
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>MASTERS</title>
<LITERALLAYOUT>
<literallayout>
masters <replaceable>string</replaceable> <optional> port <replaceable>integer</replaceable> </optional> {
( <replaceable>masters</replaceable> | <replaceable>ipv4_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> |
<replaceable>ipv6_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> ) <optional> key <replaceable>string</replaceable> </optional>; ...
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>SERVER</title>
<LITERALLAYOUT>
<literallayout>
server ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) {
bogus <replaceable>boolean</replaceable>;
edns <replaceable>boolean</replaceable>;
@ -105,21 +115,21 @@ server ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</re
support-ixfr <replaceable>boolean</replaceable>; // obsolete
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>TRUSTED-KEYS</title>
<LITERALLAYOUT>
<literallayout>
trusted-keys {
<replaceable>domain_name</replaceable> <replaceable>flags</replaceable> <replaceable>protocol</replaceable> <replaceable>algorithm</replaceable> <replaceable>key</replaceable>; ...
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>CONTROLS</title>
<LITERALLAYOUT>
<literallayout>
controls {
inet ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> | * )
<optional> port ( <replaceable>integer</replaceable> | * ) </optional>
@ -127,12 +137,12 @@ controls {
<optional> keys { <replaceable>string</replaceable>; ... } </optional>;
unix <replaceable>unsupported</replaceable>; // not implemented
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>LOGGING</title>
<LITERALLAYOUT>
<literallayout>
logging {
channel <replaceable>string</replaceable> {
file <replaceable>log_file</replaceable>;
@ -146,12 +156,12 @@ logging {
};
category <replaceable>string</replaceable> { <replaceable>string</replaceable>; ... };
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>LWRES</title>
<LITERALLAYOUT>
<literallayout>
lwres {
listen-on <optional> port <replaceable>integer</replaceable> </optional> {
( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) <optional> port <replaceable>integer</replaceable> </optional>; ...
@ -160,12 +170,12 @@ lwres {
search { <replaceable>string</replaceable>; ... };
ndots <replaceable>integer</replaceable>;
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>OPTIONS</title>
<LITERALLAYOUT>
<literallayout>
options {
avoid-v4-udp-ports { <replaceable>port</replaceable>; ... };
avoid-v6-udp-ports { <replaceable>port</replaceable>; ... };
@ -304,12 +314,12 @@ options {
treat-cr-as-space <replaceable>boolean</replaceable>; // obsolete
use-id-pool <replaceable>boolean</replaceable>; // obsolete
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>VIEW</title>
<LITERALLAYOUT>
<literallayout>
view <replaceable>string</replaceable> <replaceable>optional_class</replaceable> {
match-clients { <replaceable>address_match_element</replaceable>; ... };
match-destinations { <replaceable>address_match_element</replaceable>; ... };
@ -423,12 +433,12 @@ view <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
maintain-ixfr-base <replaceable>boolean</replaceable>; // obsolete
max-ixfr-log-size <replaceable>size</replaceable>; // obsolete
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>
<title>ZONE</title>
<LITERALLAYOUT>
<literallayout>
zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable> {
type ( master | slave | stub | hint |
forward | delegation-only );
@ -500,7 +510,7 @@ zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
max-ixfr-log-size <replaceable>size</replaceable>; // obsolete
pubkey <replaceable>integer</replaceable> <replaceable>integer</replaceable> <replaceable>integer</replaceable> <replaceable>quoted_string</replaceable>; // obsolete
};
</LITERALLAYOUT>
</literallayout>
</refsect1>
<refsect1>

2263
contrib/bind9/bin/named/named.conf.html
View file

File diff suppressed because it is too large Load diff

22
contrib/bind9/bin/named/named.docbook
View file

@ -1,6 +1,8 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: named.docbook,v 1.5.98.3 2004/06/03 02:24:57 marka Exp $ -->
<!-- $Id: named.docbook,v 1.5.98.5 2005/05/13 01:22:33 marka Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,20 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2003</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><application>named</application></refname>
<refpurpose>Internet domain name server</refpurpose>

775
contrib/bind9/bin/named/named.html
View file

@ -1,625 +1,240 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: named.html,v 1.4.2.1.4.4 2004/08/22 23:38:59 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>named</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><SPAN
CLASS="APPLICATION"
>named</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><SPAN
CLASS="APPLICATION"
>named</SPAN
>&nbsp;--&nbsp;Internet domain name server</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>named</B
> [<VAR
CLASS="OPTION"
>-4</VAR
>] [<VAR
CLASS="OPTION"
>-6</VAR
>] [<VAR
CLASS="OPTION"
>-c <VAR
CLASS="REPLACEABLE"
>config-file</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-d <VAR
CLASS="REPLACEABLE"
>debug-level</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-f</VAR
>] [<VAR
CLASS="OPTION"
>-g</VAR
>] [<VAR
CLASS="OPTION"
>-n <VAR
CLASS="REPLACEABLE"
>#cpus</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-p <VAR
CLASS="REPLACEABLE"
>port</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-s</VAR
>] [<VAR
CLASS="OPTION"
>-t <VAR
CLASS="REPLACEABLE"
>directory</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-u <VAR
CLASS="REPLACEABLE"
>user</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-v</VAR
>] [<VAR
CLASS="OPTION"
>-x <VAR
CLASS="REPLACEABLE"
>cache-file</VAR
></VAR
>]</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN49"
></A
><H2
>DESCRIPTION</H2
><P
> <B
CLASS="COMMAND"
>named</B
> is a Domain Name System (DNS) server,
<!-- $Id: named.html,v 1.4.2.1.4.9 2005/10/13 02:33:47 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>named</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><span class="application">named</span> &#8212; Internet domain name server</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">named</code> [<code class="option">-4</code>] [<code class="option">-6</code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>] [<code class="option">-x <em class="replaceable"><code>cache-file</code></em></code>]</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525923"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">named</strong></span> is a Domain Name System (DNS) server,
part of the BIND 9 distribution from ISC. For more
information on the DNS, see RFCs 1033, 1034, and 1035.
</P
><P
> When invoked without arguments, <B
CLASS="COMMAND"
>named</B
> will
</p>
<p>
When invoked without arguments, <span><strong class="command">named</strong></span> will
read the default configuration file
<TT
CLASS="FILENAME"
>/etc/named.conf</TT
>, read any initial
<code class="filename">/etc/named.conf</code>, read any initial
data, and listen for queries.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN56"
></A
><H2
>OPTIONS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>-4</DT
><DD
><P
> Use IPv4 only even if the host machine is capable of IPv6.
<VAR
CLASS="OPTION"
>-4</VAR
> and <VAR
CLASS="OPTION"
>-6</VAR
> are mutually
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525948"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-4</span></dt>
<dd><p>
Use IPv4 only even if the host machine is capable of IPv6.
<code class="option">-4</code> and <code class="option">-6</code> are mutually
exclusive.
</P
></DD
><DT
>-6</DT
><DD
><P
> Use IPv6 only even if the host machine is capable of IPv4.
<VAR
CLASS="OPTION"
>-4</VAR
> and <VAR
CLASS="OPTION"
>-6</VAR
> are mutually
</p></dd>
<dt><span class="term">-6</span></dt>
<dd><p>
Use IPv6 only even if the host machine is capable of IPv4.
<code class="option">-4</code> and <code class="option">-6</code> are mutually
exclusive.
</P
></DD
><DT
>-c <VAR
CLASS="REPLACEABLE"
>config-file</VAR
></DT
><DD
><P
> Use <VAR
CLASS="REPLACEABLE"
>config-file</VAR
> as the
</p></dd>
<dt><span class="term">-c <em class="replaceable"><code>config-file</code></em></span></dt>
<dd><p>
Use <em class="replaceable"><code>config-file</code></em> as the
configuration file instead of the default,
<TT
CLASS="FILENAME"
>/etc/named.conf</TT
>. To
<code class="filename">/etc/named.conf</code>. To
ensure that reloading the configuration file continues
to work after the server has changed its working
directory due to to a possible
<VAR
CLASS="OPTION"
>directory</VAR
> option in the configuration
file, <VAR
CLASS="REPLACEABLE"
>config-file</VAR
> should be
<code class="option">directory</code> option in the configuration
file, <em class="replaceable"><code>config-file</code></em> should be
an absolute pathname.
</P
></DD
><DT
>-d <VAR
CLASS="REPLACEABLE"
>debug-level</VAR
></DT
><DD
><P
> Set the daemon's debug level to <VAR
CLASS="REPLACEABLE"
>debug-level</VAR
>.
Debugging traces from <B
CLASS="COMMAND"
>named</B
> become
</p></dd>
<dt><span class="term">-d <em class="replaceable"><code>debug-level</code></em></span></dt>
<dd><p>
Set the daemon's debug level to <em class="replaceable"><code>debug-level</code></em>.
Debugging traces from <span><strong class="command">named</strong></span> become
more verbose as the debug level increases.
</P
></DD
><DT
>-f</DT
><DD
><P
> Run the server in the foreground (i.e. do not daemonize).
</P
></DD
><DT
>-g</DT
><DD
><P
> Run the server in the foreground and force all logging
to <TT
CLASS="FILENAME"
>stderr</TT
>.
</P
></DD
><DT
>-n <VAR
CLASS="REPLACEABLE"
>#cpus</VAR
></DT
><DD
><P
> Create <VAR
CLASS="REPLACEABLE"
>#cpus</VAR
> worker threads
</p></dd>
<dt><span class="term">-f</span></dt>
<dd><p>
Run the server in the foreground (i.e. do not daemonize).
</p></dd>
<dt><span class="term">-g</span></dt>
<dd><p>
Run the server in the foreground and force all logging
to <code class="filename">stderr</code>.
</p></dd>
<dt><span class="term">-n <em class="replaceable"><code>#cpus</code></em></span></dt>
<dd><p>
Create <em class="replaceable"><code>#cpus</code></em> worker threads
to take advantage of multiple CPUs. If not specified,
<B
CLASS="COMMAND"
>named</B
> will try to determine the
<span><strong class="command">named</strong></span> will try to determine the
number of CPUs present and create one thread per CPU.
If it is unable to determine the number of CPUs, a
single worker thread will be created.
</P
></DD
><DT
>-p <VAR
CLASS="REPLACEABLE"
>port</VAR
></DT
><DD
><P
> Listen for queries on port <VAR
CLASS="REPLACEABLE"
>port</VAR
>. If not
</p></dd>
<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
<dd><p>
Listen for queries on port <em class="replaceable"><code>port</code></em>. If not
specified, the default is port 53.
</P
></DD
><DT
>-s</DT
><DD
><P
> Write memory usage statistics to <TT
CLASS="FILENAME"
>stdout</TT
> on exit.
</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
> This option is mainly of interest to BIND 9 developers
</p></dd>
<dt><span class="term">-s</span></dt>
<dd>
<p>
Write memory usage statistics to <code class="filename">stdout</code> on exit.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>
This option is mainly of interest to BIND 9 developers
and may be removed or changed in a future release.
</P
></BLOCKQUOTE
></DIV
></DD
><DT
>-t <VAR
CLASS="REPLACEABLE"
>directory</VAR
></DT
><DD
><P
> <CODE
CLASS="FUNCTION"
>chroot()</CODE
> to <VAR
CLASS="REPLACEABLE"
>directory</VAR
> after
</p>
</div>
</dd>
<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
<dd>
<p>
<code class="function">chroot()</code> to <em class="replaceable"><code>directory</code></em> after
processing the command line arguments, but before
reading the configuration file.
</P
><DIV
CLASS="WARNING"
><P
></P
><TABLE
CLASS="WARNING"
BORDER="1"
WIDTH="90%"
><TR
><TD
ALIGN="CENTER"
><B
>Warning</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
> This option should be used in conjunction with the
<VAR
CLASS="OPTION"
>-u</VAR
> option, as chrooting a process
</p>
<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Warning</h3>
<p>
This option should be used in conjunction with the
<code class="option">-u</code> option, as chrooting a process
running as root doesn't enhance security on most
systems; the way <CODE
CLASS="FUNCTION"
>chroot()</CODE
> is
systems; the way <code class="function">chroot()</code> is
defined allows a process with root privileges to
escape a chroot jail.
</P
></TD
></TR
></TABLE
></DIV
></DD
><DT
>-u <VAR
CLASS="REPLACEABLE"
>user</VAR
></DT
><DD
><P
> <CODE
CLASS="FUNCTION"
>setuid()</CODE
> to <VAR
CLASS="REPLACEABLE"
>user</VAR
> after completing
</p>
</div>
</dd>
<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
<dd>
<p>
<code class="function">setuid()</code> to <em class="replaceable"><code>user</code></em> after completing
privileged operations, such as creating sockets that
listen on privileged ports.
</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
> On Linux, <B
CLASS="COMMAND"
>named</B
> uses the kernel's
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>
On Linux, <span><strong class="command">named</strong></span> uses the kernel's
capability mechanism to drop all root privileges
except the ability to <CODE
CLASS="FUNCTION"
>bind()</CODE
> to a
except the ability to <code class="function">bind()</code> to a
privileged port and set process resource limits.
Unfortunately, this means that the <VAR
CLASS="OPTION"
>-u</VAR
>
option only works when <B
CLASS="COMMAND"
>named</B
> is run
Unfortunately, this means that the <code class="option">-u</code>
option only works when <span><strong class="command">named</strong></span> is run
on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or
later, since previous kernels did not allow privileges
to be retained after <CODE
CLASS="FUNCTION"
>setuid()</CODE
>.
</P
></BLOCKQUOTE
></DIV
></DD
><DT
>-v</DT
><DD
><P
> Report the version number and exit.
</P
></DD
><DT
>-x <VAR
CLASS="REPLACEABLE"
>cache-file</VAR
></DT
><DD
><P
> Load data from <VAR
CLASS="REPLACEABLE"
>cache-file</VAR
> into the
to be retained after <code class="function">setuid()</code>.
</p>
</div>
</dd>
<dt><span class="term">-v</span></dt>
<dd><p>
Report the version number and exit.
</p></dd>
<dt><span class="term">-x <em class="replaceable"><code>cache-file</code></em></span></dt>
<dd>
<p>
Load data from <em class="replaceable"><code>cache-file</code></em> into the
cache of the default view.
</P
><DIV
CLASS="WARNING"
><P
></P
><TABLE
CLASS="WARNING"
BORDER="1"
WIDTH="90%"
><TR
><TD
ALIGN="CENTER"
><B
>Warning</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
> This option must not be used. It is only of interest
</p>
<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Warning</h3>
<p>
This option must not be used. It is only of interest
to BIND 9 developers and may be removed or changed in a
future release.
</P
></TD
></TR
></TABLE
></DIV
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN153"
></A
><H2
>SIGNALS</H2
><P
> In routine operation, signals should not be used to control
the nameserver; <B
CLASS="COMMAND"
>rndc</B
> should be used
</p>
</div>
</dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526297"></a><h2>SIGNALS</h2>
<p>
In routine operation, signals should not be used to control
the nameserver; <span><strong class="command">rndc</strong></span> should be used
instead.
</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>SIGHUP</DT
><DD
><P
> Force a reload of the server.
</P
></DD
><DT
>SIGINT, SIGTERM</DT
><DD
><P
> Shut down the server.
</P
></DD
></DL
></DIV
><P
> The result of sending any other signals to the server is undefined.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN167"
></A
><H2
>CONFIGURATION</H2
><P
> The <B
CLASS="COMMAND"
>named</B
> configuration file is too complex
</p>
<div class="variablelist"><dl>
<dt><span class="term">SIGHUP</span></dt>
<dd><p>
Force a reload of the server.
</p></dd>
<dt><span class="term">SIGINT, SIGTERM</span></dt>
<dd><p>
Shut down the server.
</p></dd>
</dl></div>
<p>
The result of sending any other signals to the server is undefined.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526412"></a><h2>CONFIGURATION</h2>
<p>
The <span><strong class="command">named</strong></span> configuration file is too complex
to describe in detail here. A complete description is
provided in the <I
CLASS="CITETITLE"
>BIND 9 Administrator Reference
Manual</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN172"
></A
><H2
>FILES</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="FILENAME"
>/etc/named.conf</TT
></DT
><DD
><P
> The default configuration file.
</P
></DD
><DT
><TT
CLASS="FILENAME"
>/var/run/named.pid</TT
></DT
><DD
><P
> The default process-id file.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN185"
></A
><H2
>SEE ALSO</H2
><P
> <I
CLASS="CITETITLE"
>RFC 1033</I
>,
<I
CLASS="CITETITLE"
>RFC 1034</I
>,
<I
CLASS="CITETITLE"
>RFC 1035</I
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>rndc</SPAN
>(8)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>lwresd</SPAN
>(8)</SPAN
>,
<I
CLASS="CITETITLE"
>BIND 9 Administrator Reference Manual</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN198"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
provided in the <em class="citetitle">BIND 9 Administrator Reference
Manual</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526429"></a><h2>FILES</h2>
<div class="variablelist"><dl>
<dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt>
<dd><p>
The default configuration file.
</p></dd>
<dt><span class="term"><code class="filename">/var/run/named.pid</code></span></dt>
<dd><p>
The default process-id file.
</p></dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526469"></a><h2>SEE ALSO</h2>
<p>
<em class="citetitle">RFC 1033</em>,
<em class="citetitle">RFC 1034</em>,
<em class="citetitle">RFC 1035</em>,
<span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">lwresd</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526512"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

110
contrib/bind9/bin/named/query.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: query.c,v 1.198.2.13.4.30 2004/06/30 14:13:05 marka Exp $ */
/* $Id: query.c,v 1.198.2.13.4.36 2005/08/11 05:25:20 marka Exp $ */
#include <config.h>
@ -1198,17 +1198,7 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
* recursing to add address records, which in turn can cause
* recursion to add KEYs.
*/
if (type == dns_rdatatype_a || type == dns_rdatatype_aaaa) {
/*
* RFC 2535 section 3.5 says that when A or AAAA records are
* retrieved as additional data, any KEY RRs for the owner name
* should be added to the additional data section.
*
* XXXRTH We should lower the priority here. Alternatively,
* we could raise the priority of glue records.
*/
eresult = query_addadditional(client, name, dns_rdatatype_dnskey);
} else if (type == dns_rdatatype_srv && trdataset != NULL) {
if (type == dns_rdatatype_srv && trdataset != NULL) {
/*
* If we're adding SRV records to the additional data
* section, it's helpful if we add the SRV additional data
@ -1241,8 +1231,6 @@ static inline void
query_addrdataset(ns_client_t *client, dns_name_t *fname,
dns_rdataset_t *rdataset)
{
dns_rdatatype_t type = rdataset->type;
/*
* Add 'rdataset' and any pertinent additional data to
* 'fname', a name in the response message for 'client'.
@ -1266,22 +1254,6 @@ query_addrdataset(ns_client_t *client, dns_name_t *fname,
*/
(void)dns_rdataset_additionaldata(rdataset,
query_addadditional, client);
/*
* RFC 2535 section 3.5 says that when NS, SOA, A, or AAAA records
* are retrieved, any KEY RRs for the owner name should be added
* to the additional data section. We treat A6 records the same way.
*
* We don't care if query_addadditional() fails.
*/
if (type == dns_rdatatype_ns || type == dns_rdatatype_soa ||
type == dns_rdatatype_a || type == dns_rdatatype_aaaa ||
type == dns_rdatatype_a6) {
/*
* XXXRTH We should lower the priority here. Alternatively,
* we could raise the priority of glue records.
*/
(void)query_addadditional(client, fname, dns_rdatatype_dnskey);
}
CTRACE("query_addrdataset: done");
}
@ -2116,33 +2088,37 @@ query_recurse(ns_client_t *client, dns_rdatatype_t qtype, dns_name_t *qdomain,
* connection was accepted (if allowed by the TCP quota).
*/
if (client->recursionquota == NULL) {
isc_boolean_t killoldest = ISC_FALSE;
result = isc_quota_attach(&ns_g_server->recursionquota,
&client->recursionquota);
if (result == ISC_R_SOFTQUOTA) {
if (result == ISC_R_SOFTQUOTA) {
ns_client_log(client, NS_LOGCATEGORY_CLIENT,
NS_LOGMODULE_QUERY, ISC_LOG_WARNING,
"recursive-clients limit exceeded, "
"recursive-clients soft limit exceeded, "
"aborting oldest query");
killoldest = ISC_TRUE;
ns_client_killoldestquery(client);
result = ISC_R_SUCCESS;
}
if (dns_resolver_nrunning(client->view->resolver) >
(unsigned int)ns_g_server->recursionquota.max)
result = ISC_R_QUOTA;
if (result == ISC_R_SUCCESS && !client->mortal &&
(client->attributes & NS_CLIENTATTR_TCP) == 0)
result = ns_client_replace(client);
if (result != ISC_R_SUCCESS) {
} else if (result == ISC_R_QUOTA) {
ns_client_log(client, NS_LOGCATEGORY_CLIENT,
NS_LOGMODULE_QUERY, ISC_LOG_WARNING,
"no more recursive clients: %s",
isc_result_totext(result));
if (client->recursionquota != NULL)
isc_quota_detach(&client->recursionquota);
return (result);
ns_client_killoldestquery(client);
}
ns_client_recursing(client, killoldest);
if (result == ISC_R_SUCCESS && !client->mortal &&
(client->attributes & NS_CLIENTATTR_TCP) == 0) {
result = ns_client_replace(client);
if (result != ISC_R_SUCCESS) {
ns_client_log(client, NS_LOGCATEGORY_CLIENT,
NS_LOGMODULE_QUERY,
ISC_LOG_WARNING,
"ns_client_replace() failed: %s",
isc_result_totext(result));
isc_quota_detach(&client->recursionquota);
}
}
if (result != ISC_R_SUCCESS)
return (result);
ns_client_recursing(client);
}
/*
@ -2319,6 +2295,34 @@ query_addnoqnameproof(ns_client_t *client, dns_rdataset_t *rdataset) {
query_releasename(client, &fname);
}
static inline void
answer_in_glue(ns_client_t *client, dns_rdatatype_t qtype) {
dns_name_t *name;
dns_message_t *msg;
dns_section_t section = DNS_SECTION_ADDITIONAL;
dns_rdataset_t *rdataset = NULL;
msg = client->message;
for (name = ISC_LIST_HEAD(msg->sections[section]);
name != NULL;
name = ISC_LIST_NEXT(name, link))
if (dns_name_equal(name, client->query.qname)) {
for (rdataset = ISC_LIST_HEAD(name->list);
rdataset != NULL;
rdataset = ISC_LIST_NEXT(rdataset, link))
if (rdataset->type == qtype)
break;
break;
}
if (rdataset != NULL) {
ISC_LIST_UNLINK(msg->sections[section], name, link);
ISC_LIST_PREPEND(msg->sections[section], name, link);
ISC_LIST_UNLINK(name->list, rdataset, link);
ISC_LIST_PREPEND(name->list, rdataset, link);
rdataset->attributes |= DNS_RDATASETATTR_REQUIREDGLUE;
}
}
/*
* Do the bulk of query processing for the current query of 'client'.
* If 'event' is non-NULL, we are returning from recursion and 'qtype'
@ -2875,7 +2879,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
/*
* Add SOA. If the query was for a SOA record force the
* ttl to zero so that it is possible for clients to find
* the containing zone of a arbitary name with a stub
* the containing zone of an arbitrary name with a stub
* resolver and not have it cached.
*/
if (qtype == dns_rdatatype_soa)
@ -3338,6 +3342,16 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
*/
setup_query_sortlist(client);
/*
* If this is a referral and the answer to the question
* is in the glue sort it to the start of the additional
* section.
*/
if (client->message->counts[DNS_SECTION_ANSWER] == 0 &&
client->message->rcode == dns_rcode_noerror &&
(qtype == dns_rdatatype_a || qtype == dns_rdatatype_aaaa))
answer_in_glue(client, qtype);
if (client->message->rcode == dns_rcode_nxdomain &&
client->view->auth_nxdomain == ISC_TRUE)
client->message->flags |= DNS_MESSAGEFLAG_AA;

66
contrib/bind9/bin/named/server.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: server.c,v 1.339.2.15.2.59 2004/11/10 22:13:56 marka Exp $ */
/* $Id: server.c,v 1.339.2.15.2.65 2005/07/27 02:53:15 marka Exp $ */
#include <config.h>
@ -81,6 +81,10 @@
#include <named/tkeyconf.h>
#include <named/tsigconf.h>
#include <named/zoneconf.h>
#ifdef HAVE_LIBSCF
#include <named/ns_smf_globals.h>
#include <stdlib.h>
#endif
/*
* Check an operation for failure. Assumes that the function
@ -1798,7 +1802,7 @@ configure_server_quota(cfg_obj_t **maps, const char *name, isc_quota_t *quota)
result = ns_config_get(maps, name, &obj);
INSIST(result == ISC_R_SUCCESS);
quota->max = cfg_obj_asuint32(obj);
isc_quota_max(quota, cfg_obj_asuint32(obj));
}
/*
@ -1937,9 +1941,13 @@ adjust_interfaces(ns_server_t *server, isc_mem_t *mctx) {
* At this point the zone list may contain a stale zone
* just removed from the configuration. To see the validity,
* check if the corresponding view is in our current view list.
* There may also be old zones that are still in the process
* of shutting down and have detached from their old view
* (zoneview == NULL).
*/
zoneview = dns_zone_getview(zone);
INSIST(zoneview != NULL);
if (zoneview == NULL)
continue;
for (view = ISC_LIST_HEAD(server->viewlist);
view != NULL && view != zoneview;
view = ISC_LIST_NEXT(view, link))
@ -2221,6 +2229,11 @@ load_configuration(const char *filename, ns_server_t *server,
configure_server_quota(maps, "tcp-clients", &server->tcpquota);
configure_server_quota(maps, "recursive-clients",
&server->recursionquota);
if (server->recursionquota.max > 1000)
isc_quota_soft(&server->recursionquota,
server->recursionquota.max - 100);
else
isc_quota_soft(&server->recursionquota, 0);
CHECK(configure_view_acl(NULL, config, "blackhole", &aclconfctx,
ns_g_mctx, &server->blackholeacl));
@ -2948,7 +2961,6 @@ ns_server_create(isc_mem_t *mctx, ns_server_t **serverp) {
RUNTIME_CHECK(result == ISC_R_SUCCESS);
result = isc_quota_init(&server->recursionquota, 100);
RUNTIME_CHECK(result == ISC_R_SUCCESS);
isc_quota_soft(&server->recursionquota, ISC_FALSE);
result = dns_aclenv_init(mctx, &server->aclenv);
RUNTIME_CHECK(result == ISC_R_SUCCESS);
@ -3637,6 +3649,15 @@ add_view_tolist(struct dumpcontext *dctx, dns_view_t *view) {
struct viewlistentry *vle;
isc_result_t result = ISC_R_SUCCESS;
/*
* Prevent duplicate views.
*/
for (vle = ISC_LIST_HEAD(dctx->viewlist);
vle != NULL;
vle = ISC_LIST_NEXT(vle, link))
if (vle->view == view)
return (ISC_R_SUCCESS);
vle = isc_mem_get(dctx->mctx, sizeof *vle);
if (vle == NULL)
return (ISC_R_NOMEMORY);
@ -3700,9 +3721,11 @@ dumpdone(void *arg, isc_result_t result) {
if (dctx->view == NULL)
goto done;
INSIST(dctx->zone == NULL);
}
} else
goto resume;
nextview:
fprintf(dctx->fp, ";\n; Start view %s\n;\n", dctx->view->view->name);
resume:
if (dctx->zone == NULL && dctx->cache == NULL && dctx->dumpcache) {
style = &dns_master_style_cache;
/* start cache dump */
@ -3763,9 +3786,12 @@ dumpdone(void *arg, isc_result_t result) {
&dctx->mdctx);
if (result == DNS_R_CONTINUE)
return;
if (result == ISC_R_NOTIMPLEMENTED)
if (result == ISC_R_NOTIMPLEMENTED) {
fprintf(dctx->fp, "; %s\n",
dns_result_totext(result));
result = ISC_R_SUCCESS;
goto nextzone;
}
if (result != ISC_R_SUCCESS)
goto cleanup;
}
@ -3789,7 +3815,6 @@ dumpdone(void *arg, isc_result_t result) {
dumpcontext_destroy(dctx);
}
isc_result_t
ns_server_dumpdb(ns_server_t *server, char *args) {
struct dumpcontext *dctx = NULL;
@ -3845,6 +3870,7 @@ ns_server_dumpdb(ns_server_t *server, char *args) {
ptr = next_token(&args, " \t");
}
nextview:
for (view = ISC_LIST_HEAD(server->viewlist);
view != NULL;
view = ISC_LIST_NEXT(view, link))
@ -3853,6 +3879,11 @@ ns_server_dumpdb(ns_server_t *server, char *args) {
continue;
CHECK(add_view_tolist(dctx, view));
}
if (ptr != NULL) {
ptr = next_token(&args, " \t");
if (ptr != NULL)
goto nextview;
}
dumpdone(dctx, ISC_R_SUCCESS);
return (ISC_R_SUCCESS);
@ -4101,3 +4132,22 @@ ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) {
dns_zone_detach(&zone);
return (result);
}
#ifdef HAVE_LIBSCF
/*
* This function adds a message for rndc to echo if named
* is managed by smf and is also running chroot.
*/
isc_result_t
ns_smf_add_message(isc_buffer_t *text) {
unsigned int n;
n = snprintf((char *)isc_buffer_used(text),
isc_buffer_availablelength(text),
"use svcadm(1M) to manage named");
if (n >= isc_buffer_availablelength(text))
return (ISC_R_NOSPACE);
isc_buffer_add(text, n);
return (ISC_R_SUCCESS);
}
#endif /* HAVE_LIBSCF */

16
contrib/bind9/bin/named/unix/os.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2002 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: os.c,v 1.46.2.4.8.19 2004/10/07 02:34:20 marka Exp $ */
/* $Id: os.c,v 1.46.2.4.8.22 2005/05/20 01:37:19 marka Exp $ */
#include <config.h>
#include <stdarg.h>
@ -46,6 +46,9 @@
#include <named/main.h>
#include <named/os.h>
#ifdef HAVE_LIBSCF
#include <named/ns_smf_globals.h>
#endif
static char *pidfile = NULL;
static int devnullfd = -1;
@ -159,7 +162,7 @@ linux_setcaps(unsigned int caps) {
memset(&cap, 0, sizeof(cap));
cap.effective = caps;
cap.permitted = caps;
cap.inheritable = caps;
cap.inheritable = 0;
if (syscall(SYS_capset, &caphead, &cap) < 0) {
isc__strerror(errno, strbuf, sizeof(strbuf));
ns_main_earlyfatal("capset failed: %s:"
@ -417,6 +420,9 @@ all_digits(const char *s) {
void
ns_os_chroot(const char *root) {
char strbuf[ISC_STRERRORSIZE];
#ifdef HAVE_LIBSCF
ns_smf_chroot = 0;
#endif
if (root != NULL) {
if (chroot(root) < 0) {
isc__strerror(errno, strbuf, sizeof(strbuf));
@ -426,6 +432,10 @@ ns_os_chroot(const char *root) {
isc__strerror(errno, strbuf, sizeof(strbuf));
ns_main_earlyfatal("chdir(/): %s", strbuf);
}
#ifdef HAVE_LIBSCF
/* Set ns_smf_chroot flag on successful chroot. */
ns_smf_chroot = 1;
#endif
}
}

8
contrib/bind9/bin/named/update.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: update.c,v 1.88.2.5.2.25 2004/10/21 01:40:22 marka Exp $ */
/* $Id: update.c,v 1.88.2.5.2.27 2005/10/08 00:21:06 marka Exp $ */
#include <config.h>
@ -2723,8 +2723,8 @@ updatedone_action(isc_task_t *task, isc_event_t *event) {
INSIST(client->nupdates > 0);
client->nupdates--;
respond(client, uev->result);
ns_client_detach(&client);
isc_event_free(&event);
ns_client_detach(&client);
}
/*
@ -2740,8 +2740,8 @@ forward_fail(isc_task_t *task, isc_event_t *event) {
INSIST(client->nupdates > 0);
client->nupdates--;
respond(client, DNS_R_SERVFAIL);
ns_client_detach(&client);
isc_event_free(&event);
ns_client_detach(&client);
}

8
contrib/bind9/bin/named/xfrout.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: xfrout.c,v 1.101.2.5.2.10 2004/04/02 06:08:17 marka Exp $ */
/* $Id: xfrout.c,v 1.101.2.5.2.12 2005/10/14 02:13:05 marka Exp $ */
#include <config.h>
@ -868,7 +868,7 @@ xfrout_log1(ns_client_t *client, dns_name_t *zonename,
const char *fmt, ...) ISC_FORMAT_PRINTF(5, 6);
static void
xfrout_log(xfrout_ctx_t *xfr, unsigned int level, const char *fmt, ...)
xfrout_log(xfrout_ctx_t *xfr, int level, const char *fmt, ...)
ISC_FORMAT_PRINTF(3, 4);
/**************************************************************************/
@ -1710,7 +1710,7 @@ xfrout_log1(ns_client_t *client, dns_name_t *zonename,
* Logging function for use when there is a xfrout_ctx_t.
*/
static void
xfrout_log(xfrout_ctx_t *xfr, unsigned int level, const char *fmt, ...) {
xfrout_log(xfrout_ctx_t *xfr, int level, const char *fmt, ...) {
va_list ap;
va_start(ap, fmt);
xfrout_logv(xfr->client, xfr->qname, xfr->qclass, level, fmt, ap);

23
contrib/bind9/bin/named/zoneconf.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: zoneconf.c,v 1.87.2.4.10.13 2004/04/20 14:12:09 marka Exp $ */
/* $Id: zoneconf.c,v 1.87.2.4.10.15 2005/09/06 02:12:39 marka Exp $ */
#include <config.h>
@ -375,17 +375,30 @@ ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig,
obj = NULL;
result = cfg_map_get(zoptions, "database", &obj);
if (result == ISC_R_SUCCESS)
cpval = cfg_obj_asstring(obj);
cpval = isc_mem_strdup(mctx, cfg_obj_asstring(obj));
else
cpval = default_dbtype;
RETERR(strtoargv(mctx, cpval, &dbargc, &dbargv));
if (cpval == NULL)
return(ISC_R_NOMEMORY);
result = strtoargv(mctx, cpval, &dbargc, &dbargv);
if (result != ISC_R_SUCCESS && cpval != default_dbtype) {
isc_mem_free(mctx, cpval);
return (result);
}
/*
* ANSI C is strange here. There is no logical reason why (char **)
* cannot be promoted automatically to (const char * const *) by the
* compiler w/o generating a warning.
*/
RETERR(dns_zone_setdbtype(zone, dbargc, (const char * const *)dbargv));
result = dns_zone_setdbtype(zone, dbargc, (const char * const *)dbargv);
isc_mem_put(mctx, dbargv, dbargc * sizeof(*dbargv));
if (cpval != default_dbtype)
isc_mem_free(mctx, cpval);
if (result != ISC_R_SUCCESS)
return (result);
obj = NULL;
result = cfg_map_get(zoptions, "file", &obj);

327
contrib/bind9/bin/nsupdate/nsupdate.8
View file

@ -1,294 +1,239 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2003 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000-2003 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: nsupdate.8,v 1.24.2.2.2.5 2004/03/08 09:04:15 marka Exp $
.\" $Id: nsupdate.8,v 1.24.2.2.2.8 2005/10/13 02:33:48 marka Exp $
.\"
.TH "NSUPDATE" "8" "Jun 30, 2000" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "NSUPDATE" "8" "Jun 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
nsupdate \- Dynamic DNS update utility
.SH SYNOPSIS
.sp
\fBnsupdate\fR [ \fB-d\fR ] [ \fB [ -y \fIkeyname:secret\fB ] [ -k \fIkeyfile\fB ] \fR ] [ \fB-t \fItimeout\fB\fR ] [ \fB-u \fIudptimeout\fB\fR ] [ \fB-r \fIudpretries\fB\fR ] [ \fB-v\fR ] [ \fBfilename\fR ]
.SH "SYNOPSIS"
.HP 9
\fBnsupdate\fR [\fB\-d\fR] [[\fB\-y\ \fR\fB\fIkeyname:secret\fR\fR] [\fB\-k\ \fR\fB\fIkeyfile\fR\fR]] [\fB\-t\ \fR\fB\fItimeout\fR\fR] [\fB\-u\ \fR\fB\fIudptimeout\fR\fR] [\fB\-r\ \fR\fB\fIudpretries\fR\fR] [\fB\-v\fR] [filename]
.SH "DESCRIPTION"
.PP
\fBnsupdate\fR
is used to submit Dynamic DNS Update requests as defined in RFC2136
to a name server.
This allows resource records to be added or removed from a zone
without manually editing the zone file.
A single update request can contain requests to add or remove more than one
resource record.
is used to submit Dynamic DNS Update requests as defined in RFC2136 to a name server. This allows resource records to be added or removed from a zone without manually editing the zone file. A single update request can contain requests to add or remove more than one resource record.
.PP
Zones that are under dynamic control via
\fBnsupdate\fR
or a DHCP server should not be edited by hand.
Manual edits could
conflict with dynamic updates and cause data to be lost.
or a DHCP server should not be edited by hand. Manual edits could conflict with dynamic updates and cause data to be lost.
.PP
The resource records that are dynamically added or removed with
\fBnsupdate\fR
have to be in the same zone.
Requests are sent to the zone's master server.
This is identified by the MNAME field of the zone's SOA record.
have to be in the same zone. Requests are sent to the zone's master server. This is identified by the MNAME field of the zone's SOA record.
.PP
The
\fB-d\fR
\fB\-d\fR
option makes
\fBnsupdate\fR
operate in debug mode.
This provides tracing information about the update requests that are
made and the replies received from the name server.
operate in debug mode. This provides tracing information about the update requests that are made and the replies received from the name server.
.PP
Transaction signatures can be used to authenticate the Dynamic DNS
updates.
These use the TSIG resource record type described in RFC2845 or the
SIG(0) record described in RFC3535 and RFC2931.
TSIG relies on a shared secret that should only be known to
\fBnsupdate\fR and the name server.
Currently, the only supported encryption algorithm for TSIG is
HMAC-MD5, which is defined in RFC 2104.
Once other algorithms are defined for TSIG, applications will need to
ensure they select the appropriate algorithm as well as the key when
authenticating each other.
For instance suitable
Transaction signatures can be used to authenticate the Dynamic DNS updates. These use the TSIG resource record type described in RFC2845 or the SIG(0) record described in RFC3535 and RFC2931. TSIG relies on a shared secret that should only be known to
\fBnsupdate\fR
and the name server. Currently, the only supported encryption algorithm for TSIG is HMAC\-MD5, which is defined in RFC 2104. Once other algorithms are defined for TSIG, applications will need to ensure they select the appropriate algorithm as well as the key when authenticating each other. For instance suitable
\fBkey\fR
and
\fBserver\fR
statements would be added to
\fI/etc/named.conf\fR
so that the name server can associate the appropriate secret key
and algorithm with the IP address of the
client application that will be using TSIG authentication.
SIG(0) uses public key cryptography. To use a SIG(0) key, the public
key must be stored in a KEY record in a zone served by the name server.
so that the name server can associate the appropriate secret key and algorithm with the IP address of the client application that will be using TSIG authentication. SIG(0) uses public key cryptography. To use a SIG(0) key, the public key must be stored in a KEY record in a zone served by the name server.
\fBnsupdate\fR
does not read
\fI/etc/named.conf\fR.
.PP
\fBnsupdate\fR
uses the
\fB-y\fR
\fB\-y\fR
or
\fB-k\fR
option (with an HMAC-MD5 key) to provide the shared secret needed to generate
a TSIG record for authenticating Dynamic DNS update requests.
These options are mutually exclusive.
With the
\fB-k\fR
\fB\-k\fR
option (with an HMAC\-MD5 key) to provide the shared secret needed to generate a TSIG record for authenticating Dynamic DNS update requests. These options are mutually exclusive. With the
\fB\-k\fR
option,
\fBnsupdate\fR
reads the shared secret from the file
\fIkeyfile\fR,
whose name is of the form
\fIK{name}.+157.+{random}.private\fR.
For historical
reasons, the file
\fIkeyfile\fR, whose name is of the form
\fIK{name}.+157.+{random}.private\fR. For historical reasons, the file
\fIK{name}.+157.+{random}.key\fR
must also be present. When the
\fB-y\fR
\fB\-y\fR
option is used, a signature is generated from
\fIkeyname:secret.\fR
\fIkeyname\fR
is the name of the key,
and
\fIkeyname:secret.\fR\fIkeyname\fR
is the name of the key, and
\fIsecret\fR
is the base64 encoded shared secret.
Use of the
\fB-y\fR
option is discouraged because the shared secret is supplied as a command
line argument in clear text.
This may be visible in the output from
\fBps\fR(1)
is the base64 encoded shared secret. Use of the
\fB\-y\fR
option is discouraged because the shared secret is supplied as a command line argument in clear text. This may be visible in the output from
\fBps\fR(1 )
or in a history file maintained by the user's shell.
.PP
The \fB-k\fR may also be used to specify a SIG(0) key used
to authenticate Dynamic DNS update requests. In this case, the key
specified is not an HMAC-MD5 key.
The
\fB\-k\fR
may also be used to specify a SIG(0) key used to authenticate Dynamic DNS update requests. In this case, the key specified is not an HMAC\-MD5 key.
.PP
By default
\fBnsupdate\fR
uses UDP to send update requests to the name server unless they are too
large to fit in a UDP request in which case TCP will be used.
The
\fB-v\fR
uses UDP to send update requests to the name server unless they are too large to fit in a UDP request in which case TCP will be used. The
\fB\-v\fR
option makes
\fBnsupdate\fR
use a TCP connection.
This may be preferable when a batch of update requests is made.
use a TCP connection. This may be preferable when a batch of update requests is made.
.PP
The \fB-t\fR option sets the maximum time a update request can
take before it is aborted. The default is 300 seconds. Zero can be used
to disable the timeout.
The
\fB\-t\fR
option sets the maximum time a update request can take before it is aborted. The default is 300 seconds. Zero can be used to disable the timeout.
.PP
The \fB-u\fR option sets the UDP retry interval. The default is
3 seconds. If zero the interval will be computed from the timeout interval
and number of UDP retries.
The
\fB\-u\fR
option sets the UDP retry interval. The default is 3 seconds. If zero the interval will be computed from the timeout interval and number of UDP retries.
.PP
The \fB-r\fR option sets the number of UDP retries. The default is
3. If zero only one update request will be made.
The
\fB\-r\fR
option sets the number of UDP retries. The default is 3. If zero only one update request will be made.
.SH "INPUT FORMAT"
.PP
\fBnsupdate\fR
reads input from
\fIfilename\fR
or standard input.
Each command is supplied on exactly one line of input.
Some commands are for administrative purposes.
The others are either update instructions or prerequisite checks on the
contents of the zone.
These checks set conditions that some name or set of
resource records (RRset) either exists or is absent from the zone.
These conditions must be met if the entire update request is to succeed.
Updates will be rejected if the tests for the prerequisite conditions fail.
or standard input. Each command is supplied on exactly one line of input. Some commands are for administrative purposes. The others are either update instructions or prerequisite checks on the contents of the zone. These checks set conditions that some name or set of resource records (RRset) either exists or is absent from the zone. These conditions must be met if the entire update request is to succeed. Updates will be rejected if the tests for the prerequisite conditions fail.
.PP
Every update request consists of zero or more prerequisites
and zero or more updates.
This allows a suitably authenticated update request to proceed if some
specified resource records are present or missing from the zone.
A blank input line (or the \fBsend\fR command) causes the
accumulated commands to be sent as one Dynamic DNS update request to the
name server.
Every update request consists of zero or more prerequisites and zero or more updates. This allows a suitably authenticated update request to proceed if some specified resource records are present or missing from the zone. A blank input line (or the
\fBsend\fR
command) causes the accumulated commands to be sent as one Dynamic DNS update request to the name server.
.PP
The command formats and their meaning are as follows:
.TP
\fBserver servername [ port ]\fR
.HP 7 \fBserver\fR {servername} [port]
Sends all dynamic update requests to the name server
\fIservername\fR.
When no server statement is provided,
\fIservername\fR. When no server statement is provided,
\fBnsupdate\fR
will send updates to the master server of the correct zone.
The MNAME field of that zone's SOA record will identify the master
server for that zone.
will send updates to the master server of the correct zone. The MNAME field of that zone's SOA record will identify the master server for that zone.
\fIport\fR
is the port number on
\fIservername\fR
where the dynamic update requests get sent.
If no port number is specified, the default DNS port number of 53 is
used.
where the dynamic update requests get sent. If no port number is specified, the default DNS port number of 53 is used.
.TP
\fBlocal address [ port ]\fR
.HP 6 \fBlocal\fR {address} [port]
Sends all dynamic update requests using the local
\fIaddress\fR.
When no local statement is provided,
\fIaddress\fR. When no local statement is provided,
\fBnsupdate\fR
will send updates using an address and port chosen by the system.
\fIport\fR
can additionally be used to make requests come from a specific port.
If no port number is specified, the system will assign one.
can additionally be used to make requests come from a specific port. If no port number is specified, the system will assign one.
.TP
\fBzone zonename\fR
.HP 5 \fBzone\fR {zonename}
Specifies that all updates are to be made to the zone
\fIzonename\fR.
If no
\fIzonename\fR. If no
\fIzone\fR
statement is provided,
\fBnsupdate\fR
will attempt determine the correct zone to update based on the rest of the input.
.TP
\fBclass classname\fR
Specify the default class.
If no \fIclass\fR is specified the default class is
.HP 6 \fBclass\fR {classname}
Specify the default class. If no
\fIclass\fR
is specified the default class is
\fIIN\fR.
.TP
\fBkey name secret\fR
.HP 4 \fBkey\fR {name} {secret}
Specifies that all updates are to be TSIG signed using the
\fIkeyname\fR \fIkeysecret\fR pair.
The \fBkey\fR command
overrides any key specified on the command line via
\fB-y\fR or \fB-k\fR.
\fIkeyname\fR\fIkeysecret\fR
pair. The
\fBkey\fR
command overrides any key specified on the command line via
\fB\-y\fR
or
\fB\-k\fR.
.TP
\fBprereq nxdomain domain-name\fR
.HP 16 \fBprereq nxdomain\fR {domain\-name}
Requires that no resource record of any type exists with name
\fIdomain-name\fR.
\fIdomain\-name\fR.
.TP
\fBprereq yxdomain domain-name\fR
.HP 16 \fBprereq yxdomain\fR {domain\-name}
Requires that
\fIdomain-name\fR
\fIdomain\-name\fR
exists (has as at least one resource record, of any type).
.TP
\fBprereq nxrrset domain-name [ class ] type\fR
.HP 15 \fBprereq nxrrset\fR {domain\-name} [class] {type}
Requires that no resource record exists of the specified
\fItype\fR,
\fIclass\fR
and
\fIdomain-name\fR.
If
\fIdomain\-name\fR. If
\fIclass\fR
is omitted, IN (internet) is assumed.
.TP
\fBprereq yxrrset domain-name [ class ] type\fR
.HP 15 \fBprereq yxrrset\fR {domain\-name} [class] {type}
This requires that a resource record of the specified
\fItype\fR,
\fIclass\fR
and
\fIdomain-name\fR
must exist.
If
\fIdomain\-name\fR
must exist. If
\fIclass\fR
is omitted, IN (internet) is assumed.
.TP
\fBprereq yxrrset domain-name [ class ] type data\fI...\fB\fR
.HP 15 \fBprereq yxrrset\fR {domain\-name} [class] {type} {data...}
The
\fIdata\fR
from each set of prerequisites of this form
sharing a common
from each set of prerequisites of this form sharing a common
\fItype\fR,
\fIclass\fR,
and
\fIdomain-name\fR
are combined to form a set of RRs. This set of RRs must
exactly match the set of RRs existing in the zone at the
given
\fIclass\fR, and
\fIdomain\-name\fR
are combined to form a set of RRs. This set of RRs must exactly match the set of RRs existing in the zone at the given
\fItype\fR,
\fIclass\fR,
and
\fIdomain-name\fR.
The
\fIclass\fR, and
\fIdomain\-name\fR. The
\fIdata\fR
are written in the standard text representation of the resource record's
RDATA.
are written in the standard text representation of the resource record's RDATA.
.TP
\fBupdate delete domain-name [ ttl ] [ class ] [ type [ data\fI...\fB ] ]\fR
.HP 14 \fBupdate delete\fR {domain\-name} [ttl] [class] [type\ [data...]]
Deletes any resource records named
\fIdomain-name\fR.
If
\fIdomain\-name\fR. If
\fItype\fR
and
\fIdata\fR
is provided, only matching resource records will be removed.
The internet class is assumed if
is provided, only matching resource records will be removed. The internet class is assumed if
\fIclass\fR
is not supplied. The
\fIttl\fR
is ignored, and is only allowed for compatibility.
.TP
\fBupdate add domain-name ttl [ class ] type data\fI...\fB\fR
.HP 11 \fBupdate add\fR {domain\-name} {ttl} [class] {type} {data...}
Adds a new resource record with the specified
\fIttl\fR,
\fIclass\fR
and
\fIdata\fR.
.TP
\fBshow\fR
Displays the current message, containing all of the prerequisites and
updates specified since the last send.
.HP 5 \fBshow\fR
Displays the current message, containing all of the prerequisites and updates specified since the last send.
.TP
\fBsend\fR
.HP 5 \fBsend\fR
Sends the current message. This is equivalent to entering a blank line.
.TP
\fBanswer\fR
.HP 7 \fBanswer\fR
Displays the answer.
.PP
Lines beginning with a semicolon are comments and are ignored.
@ -298,10 +243,7 @@ The examples below show how
\fBnsupdate\fR
could be used to insert and delete resource records from the
\fBexample.com\fR
zone.
Notice that the input in each example contains a trailing blank line so that
a group of commands are sent as one dynamic update request to the
master name server for
zone. Notice that the input in each example contains a trailing blank line so that a group of commands are sent as one dynamic update request to the master name server for
\fBexample.com\fR.
.sp
.nf
@ -309,61 +251,48 @@ master name server for
> update delete oldhost.example.com A
> update add newhost.example.com 86400 A 172.16.1.1
> send
.sp
.fi
.sp
.PP
Any A records for
\fBoldhost.example.com\fR
are deleted.
and an A record for
are deleted. and an A record for
\fBnewhost.example.com\fR
it IP address 172.16.1.1 is added.
The newly-added record has a 1 day TTL (86400 seconds)
it IP address 172.16.1.1 is added. The newly\-added record has a 1 day TTL (86400 seconds)
.sp
.nf
# nsupdate
> prereq nxdomain nickname.example.com
> update add nickname.example.com 86400 CNAME somehost.example.com
> send
.sp
.fi
.sp
.PP
The prerequisite condition gets the name server to check that there
are no resource records of any type for
\fBnickname.example.com\fR.
If there are, the update request fails.
If this name does not exist, a CNAME for it is added.
This ensures that when the CNAME is added, it cannot conflict with the
long-standing rule in RFC1034 that a name must not exist as any other
record type if it exists as a CNAME.
(The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have
RRSIG, DNSKEY and NSEC records.)
The prerequisite condition gets the name server to check that there are no resource records of any type for
\fBnickname.example.com\fR. If there are, the update request fails. If this name does not exist, a CNAME for it is added. This ensures that when the CNAME is added, it cannot conflict with the long\-standing rule in RFC1034 that a name must not exist as any other record type if it exists as a CNAME. (The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have RRSIG, DNSKEY and NSEC records.)
.SH "FILES"
.TP
\fB/etc/resolv.conf\fR
used to identify default name server
.TP
\fBK{name}.+157.+{random}.key\fR
base-64 encoding of HMAC-MD5 key created by
\fBdnssec-keygen\fR(8).
base\-64 encoding of HMAC\-MD5 key created by
\fBdnssec\-keygen\fR(8).
.TP
\fBK{name}.+157.+{random}.private\fR
base-64 encoding of HMAC-MD5 key created by
\fBdnssec-keygen\fR(8).
base\-64 encoding of HMAC\-MD5 key created by
\fBdnssec\-keygen\fR(8).
.SH "SEE ALSO"
.PP
\fBRFC2136\fR,
\fBRFC3007\fR,
\fBRFC2104\fR,
\fBRFC2845\fR,
\fBRFC1034\fR,
\fBRFC2535\fR,
\fBRFC2931\fR,
\fBRFC2136\fR(),
\fBRFC3007\fR(),
\fBRFC2104\fR(),
\fBRFC2845\fR(),
\fBRFC1034\fR(),
\fBRFC2535\fR(),
\fBRFC2931\fR(),
\fBnamed\fR(8),
\fBdnssec-keygen\fR(8).
\fBdnssec\-keygen\fR(8).
.SH "BUGS"
.PP
The TSIG key is redundantly stored in two separate files.
This is a consequence of nsupdate using the DST library
for its cryptographic operations, and may change in future
releases.
The TSIG key is redundantly stored in two separate files. This is a consequence of nsupdate using the DST library for its cryptographic operations, and may change in future releases.

6
contrib/bind9/bin/nsupdate/nsupdate.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: nsupdate.c,v 1.103.2.15.2.18 2004/09/16 02:12:18 marka Exp $ */
/* $Id: nsupdate.c,v 1.103.2.15.2.20 2005/03/17 03:58:26 marka Exp $ */
#include <config.h>
@ -1634,6 +1634,7 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
ddebug("Destroying request [%p]", request);
dns_request_destroy(&request);
dns_message_renderreset(soaquery);
dns_message_settsigkey(soaquery, NULL);
sendrequest(localaddr, &servers[ns_inuse], soaquery, &request);
isc_mem_put(mctx, reqinfo, sizeof(nsu_requestinfo_t));
isc_event_free(&event);
@ -1813,6 +1814,7 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
dns_name_clone(&tname, name);
dns_request_destroy(&request);
dns_message_renderreset(soaquery);
dns_message_settsigkey(soaquery, NULL);
if (userserver != NULL)
sendrequest(localaddr, userserver, soaquery, &request);
else

39
contrib/bind9/bin/nsupdate/nsupdate.docbook
View file

@ -1,7 +1,9 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001-2003 Internet Software Consortium.
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: nsupdate.docbook,v 1.8.2.3.2.8 2004/03/08 04:04:23 marka Exp $ -->
<!-- $Id: nsupdate.docbook,v 1.8.2.3.2.10 2005/05/12 21:36:03 sra Exp $ -->
<refentry>
<refentryinfo>
@ -27,6 +29,22 @@
<manvolnum>8</manvolnum>
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname>nsupdate</refname>
<refpurpose>Dynamic DNS update utility</refpurpose>
@ -229,6 +247,8 @@ where the dynamic update requests get sent.
If no port number is specified, the default DNS port number of 53 is
used.
</para>
</listitem>
</varlistentry>
<varlistentry><term>
<cmdsynopsis>
@ -248,6 +268,9 @@ will send updates using an address and port chosen by the system.
<parameter>port</parameter>
can additionally be used to make requests come from a specific port.
If no port number is specified, the system will assign one.
</para>
</listitem>
</varlistentry>
<varlistentry><term>
<cmdsynopsis>
@ -482,6 +505,7 @@ updates specified since the last send.
Sends the current message. This is equivalent to entering a blank line.
</para>
</listitem>
</varlistentry>
<varlistentry><term>
<cmdsynopsis>
@ -493,8 +517,10 @@ Sends the current message. This is equivalent to entering a blank line.
Displays the answer.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
Lines beginning with a semicolon are comments and are ignored.
@ -562,6 +588,7 @@ RRSIG, DNSKEY and NSEC records.)
used to identify default name server
</para>
</listitem>
</varlistentry>
<varlistentry><term><constant>K{name}.+157.+{random}.key</constant></term>
<listitem>
@ -572,6 +599,7 @@ base-64 encoding of HMAC-MD5 key created by
</citerefentry>.
</para>
</listitem>
</varlistentry>
<varlistentry><term><constant>K{name}.+157.+{random}.private</constant></term>
<listitem>
@ -582,6 +610,7 @@ base-64 encoding of HMAC-MD5 key created by
</citerefentry>.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
@ -615,7 +644,7 @@ base-64 encoding of HMAC-MD5 key created by
<citerefentry>
<refentrytitle>dnssec-keygen</refentrytitle><manvolnum>8</manvolnum>
</citerefentry>.
</para>
</refsect1>
<refsect1>
<title>BUGS</title>

1158
contrib/bind9/bin/nsupdate/nsupdate.html
View file

File diff suppressed because it is too large Load diff

241
contrib/bind9/bin/rndc/rndc-confgen.8
View file

@ -1,140 +1,183 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2001-2003 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2001, 2003 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: rndc-confgen.8,v 1.3.2.5.2.3 2004/06/03 05:35:48 marka Exp $
.\" $Id: rndc-confgen.8,v 1.3.2.5.2.7 2005/10/13 02:33:50 marka Exp $
.\"
.TH "RNDC-CONFGEN" "8" "Aug 27, 2001" "BIND9" ""
.SH NAME
rndc-confgen \- rndc key generation tool
.SH SYNOPSIS
.sp
\fBrndc-confgen\fR [ \fB-a\fR ] [ \fB-b \fIkeysize\fB\fR ] [ \fB-c \fIkeyfile\fB\fR ] [ \fB-h\fR ] [ \fB-k \fIkeyname\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-r \fIrandomfile\fB\fR ] [ \fB-s \fIaddress\fB\fR ] [ \fB-t \fIchrootdir\fB\fR ] [ \fB-u \fIuser\fB\fR ]
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "RNDC\-CONFGEN" "8" "Aug 27, 2001" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
rndc\-confgen \- rndc key generation tool
.SH "SYNOPSIS"
.HP 13
\fBrndc\-confgen\fR [\fB\-a\fR] [\fB\-b\ \fR\fB\fIkeysize\fR\fR] [\fB\-c\ \fR\fB\fIkeyfile\fR\fR] [\fB\-h\fR] [\fB\-k\ \fR\fB\fIkeyname\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-r\ \fR\fB\fIrandomfile\fR\fR] [\fB\-s\ \fR\fB\fIaddress\fR\fR] [\fB\-t\ \fR\fB\fIchrootdir\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR]
.SH "DESCRIPTION"
.PP
\fBrndc-confgen\fR generates configuration files
for \fBrndc\fR. It can be used as a
convenient alternative to writing the
\fIrndc.conf\fR file
and the corresponding \fBcontrols\fR
and \fBkey\fR
statements in \fInamed.conf\fR by hand.
Alternatively, it can be run with the \fB-a\fR
option to set up a \fIrndc.key\fR file and
avoid the need for a \fIrndc.conf\fR file
and a \fBcontrols\fR statement altogether.
\fBrndc\-confgen\fR
generates configuration files for
\fBrndc\fR. It can be used as a convenient alternative to writing the
\fIrndc.conf\fR
file and the corresponding
\fBcontrols\fR
and
\fBkey\fR
statements in
\fInamed.conf\fR
by hand. Alternatively, it can be run with the
\fB\-a\fR
option to set up a
\fIrndc.key\fR
file and avoid the need for a
\fIrndc.conf\fR
file and a
\fBcontrols\fR
statement altogether.
.SH "OPTIONS"
.TP
\fB-a\fR
Do automatic \fBrndc\fR configuration.
This creates a file \fIrndc.key\fR
in \fI/etc\fR (or whatever
sysconfdir
was specified as when BIND was built)
that is read by both \fBrndc\fR
and \fBnamed\fR on startup. The
\fIrndc.key\fR file defines a default
command channel and authentication key allowing
\fBrndc\fR to communicate with
\fBnamed\fR on the local host
with no further configuration.
Running \fBrndc-confgen -a\fR allows
BIND 9 and \fBrndc\fR to be used as drop-in
replacements for BIND 8 and \fBndc\fR,
with no changes to the existing BIND 8
\fInamed.conf\fR file.
If a more elaborate configuration than that
generated by \fBrndc-confgen -a\fR
is required, for example if rndc is to be used remotely,
you should run \fBrndc-confgen\fR without the
\fB-a\fR option and set up a
\fIrndc.conf\fR and
\-a
Do automatic
\fBrndc\fR
configuration. This creates a file
\fIrndc.key\fR
in
\fI/etc\fR
(or whatever
\fIsysconfdir\fR
was specified as when
BIND
was built) that is read by both
\fBrndc\fR
and
\fBnamed\fR
on startup. The
\fIrndc.key\fR
file defines a default command channel and authentication key allowing
\fBrndc\fR
to communicate with
\fBnamed\fR
on the local host with no further configuration.
.sp
Running
\fBrndc\-confgen \-a\fR
allows BIND 9 and
\fBrndc\fR
to be used as drop\-in replacements for BIND 8 and
\fBndc\fR, with no changes to the existing BIND 8
\fInamed.conf\fR
file.
.sp
If a more elaborate configuration than that generated by
\fBrndc\-confgen \-a\fR
is required, for example if rndc is to be used remotely, you should run
\fBrndc\-confgen\fR
without the
\fB\-a\fR
option and set up a
\fIrndc.conf\fR
and
\fInamed.conf\fR
as directed.
.TP
\fB-b \fIkeysize\fB\fR
Specifies the size of the authentication key in bits.
Must be between 1 and 512 bits; the default is 128.
\-b \fIkeysize\fR
Specifies the size of the authentication key in bits. Must be between 1 and 512 bits; the default is 128.
.TP
\fB-c \fIkeyfile\fB\fR
Used with the \fB-a\fR option to specify
an alternate location for \fIrndc.key\fR.
\-c \fIkeyfile\fR
Used with the
\fB\-a\fR
option to specify an alternate location for
\fIrndc.key\fR.
.TP
\fB-h\fR
\-h
Prints a short summary of the options and arguments to
\fBrndc-confgen\fR.
\fBrndc\-confgen\fR.
.TP
\fB-k \fIkeyname\fB\fR
Specifies the key name of the rndc authentication key.
This must be a valid domain name.
The default is rndc-key.
\-k \fIkeyname\fR
Specifies the key name of the rndc authentication key. This must be a valid domain name. The default is
\fBrndc\-key\fR.
.TP
\fB-p \fIport\fB\fR
Specifies the command channel port where \fBnamed\fR
listens for connections from \fBrndc\fR.
The default is 953.
\-p \fIport\fR
Specifies the command channel port where
\fBnamed\fR
listens for connections from
\fBrndc\fR. The default is 953.
.TP
\fB-r \fIrandomfile\fB\fR
Specifies a source of random data for generating the
authorization. If the operating
system does not provide a \fI/dev/random\fR
or equivalent device, the default source of randomness
is keyboard input. \fIrandomdev\fR specifies
the name of a character device or file containing random
data to be used instead of the default. The special value
\fIkeyboard\fR indicates that keyboard
input should be used.
\-r \fIrandomfile\fR
Specifies a source of random data for generating the authorization. If the operating system does not provide a
\fI/dev/random\fR
or equivalent device, the default source of randomness is keyboard input.
\fIrandomdev\fR
specifies the name of a character device or file containing random data to be used instead of the default. The special value
\fIkeyboard\fR
indicates that keyboard input should be used.
.TP
\fB-s \fIaddress\fB\fR
Specifies the IP address where \fBnamed\fR
\-s \fIaddress\fR
Specifies the IP address where
\fBnamed\fR
listens for command channel connections from
\fBrndc\fR. The default is the loopback
address 127.0.0.1.
\fBrndc\fR. The default is the loopback address 127.0.0.1.
.TP
\fB-t \fIchrootdir\fB\fR
Used with the \fB-a\fR option to specify
a directory where \fBnamed\fR will run
chrooted. An additional copy of the \fIrndc.key\fR
will be written relative to this directory so that
it will be found by the chrooted \fBnamed\fR.
\-t \fIchrootdir\fR
Used with the
\fB\-a\fR
option to specify a directory where
\fBnamed\fR
will run chrooted. An additional copy of the
\fIrndc.key\fR
will be written relative to this directory so that it will be found by the chrooted
\fBnamed\fR.
.TP
\fB-u \fIuser\fB\fR
Used with the \fB-a\fR option to set the owner
of the \fIrndc.key\fR file generated. If
\fB-t\fR is also specified only the file in
the chroot area has its owner changed.
\-u \fIuser\fR
Used with the
\fB\-a\fR
option to set the owner of the
\fIrndc.key\fR
file generated. If
\fB\-t\fR
is also specified only the file in the chroot area has its owner changed.
.SH "EXAMPLES"
.PP
To allow \fBrndc\fR to be used with
no manual configuration, run
To allow
\fBrndc\fR
to be used with no manual configuration, run
.PP
\fBrndc-confgen -a\fR
\fBrndc\-confgen \-a\fR
.PP
To print a sample \fIrndc.conf\fR file and
corresponding \fBcontrols\fR and \fBkey\fR
statements to be manually inserted into \fInamed.conf\fR,
run
To print a sample
\fIrndc.conf\fR
file and corresponding
\fBcontrols\fR
and
\fBkey\fR
statements to be manually inserted into
\fInamed.conf\fR, run
.PP
\fBrndc-confgen\fR
\fBrndc\-confgen\fR
.SH "SEE ALSO"
.PP
\fBrndc\fR(8),
\fBrndc.conf\fR(5),
\fBnamed\fR(8),
\fIBIND 9 Administrator Reference Manual\fR.
BIND 9 Administrator Reference Manual.
.SH "AUTHOR"
.PP
Internet Systems Consortium

21
contrib/bind9/bin/rndc/rndc-confgen.docbook
View file

@ -1,6 +1,8 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001, 2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: rndc-confgen.docbook,v 1.3.2.1.4.3 2004/06/03 02:24:58 marka Exp $ -->
<!-- $Id: rndc-confgen.docbook,v 1.3.2.1.4.5 2005/05/13 01:22:34 marka Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,19 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2001</year>
<year>2003</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><application>rndc-confgen</application></refname>
<refpurpose>rndc key generation tool</refpurpose>

661
contrib/bind9/bin/rndc/rndc-confgen.html
View file

@ -1,538 +1,185 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001-2003 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001, 2003 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: rndc-confgen.html,v 1.3.2.5.2.4 2004/08/22 23:39:00 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>rndc-confgen</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><SPAN
CLASS="APPLICATION"
>rndc-confgen</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><SPAN
CLASS="APPLICATION"
>rndc-confgen</SPAN
>&nbsp;--&nbsp;rndc key generation tool</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>rndc-confgen</B
> [<VAR
CLASS="OPTION"
>-a</VAR
>] [<VAR
CLASS="OPTION"
>-b <VAR
CLASS="REPLACEABLE"
>keysize</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-c <VAR
CLASS="REPLACEABLE"
>keyfile</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-h</VAR
>] [<VAR
CLASS="OPTION"
>-k <VAR
CLASS="REPLACEABLE"
>keyname</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-p <VAR
CLASS="REPLACEABLE"
>port</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-r <VAR
CLASS="REPLACEABLE"
>randomfile</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-s <VAR
CLASS="REPLACEABLE"
>address</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-t <VAR
CLASS="REPLACEABLE"
>chrootdir</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-u <VAR
CLASS="REPLACEABLE"
>user</VAR
></VAR
>]</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN44"
></A
><H2
>DESCRIPTION</H2
><P
> <B
CLASS="COMMAND"
>rndc-confgen</B
> generates configuration files
for <B
CLASS="COMMAND"
>rndc</B
>. It can be used as a
<!-- $Id: rndc-confgen.html,v 1.3.2.5.2.11 2005/10/13 02:33:51 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>rndc-confgen</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><span class="application">rndc-confgen</span> &#8212; rndc key generation tool</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">rndc-confgen</code> [<code class="option">-a</code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-c <em class="replaceable"><code>keyfile</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [<code class="option">-s <em class="replaceable"><code>address</code></em></code>] [<code class="option">-t <em class="replaceable"><code>chrootdir</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>]</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525911"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">rndc-confgen</strong></span> generates configuration files
for <span><strong class="command">rndc</strong></span>. It can be used as a
convenient alternative to writing the
<TT
CLASS="FILENAME"
>rndc.conf</TT
> file
and the corresponding <B
CLASS="COMMAND"
>controls</B
>
and <B
CLASS="COMMAND"
>key</B
>
statements in <TT
CLASS="FILENAME"
>named.conf</TT
> by hand.
Alternatively, it can be run with the <B
CLASS="COMMAND"
>-a</B
>
option to set up a <TT
CLASS="FILENAME"
>rndc.key</TT
> file and
avoid the need for a <TT
CLASS="FILENAME"
>rndc.conf</TT
> file
and a <B
CLASS="COMMAND"
>controls</B
> statement altogether.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN57"
></A
><H2
>OPTIONS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>-a</DT
><DD
><P
> Do automatic <B
CLASS="COMMAND"
>rndc</B
> configuration.
This creates a file <TT
CLASS="FILENAME"
>rndc.key</TT
>
in <TT
CLASS="FILENAME"
>/etc</TT
> (or whatever
<VAR
CLASS="VARNAME"
>sysconfdir</VAR
>
was specified as when <ACRONYM
CLASS="ACRONYM"
>BIND</ACRONYM
> was built)
that is read by both <B
CLASS="COMMAND"
>rndc</B
>
and <B
CLASS="COMMAND"
>named</B
> on startup. The
<TT
CLASS="FILENAME"
>rndc.key</TT
> file defines a default
<code class="filename">rndc.conf</code> file
and the corresponding <span><strong class="command">controls</strong></span>
and <span><strong class="command">key</strong></span>
statements in <code class="filename">named.conf</code> by hand.
Alternatively, it can be run with the <span><strong class="command">-a</strong></span>
option to set up a <code class="filename">rndc.key</code> file and
avoid the need for a <code class="filename">rndc.conf</code> file
and a <span><strong class="command">controls</strong></span> statement altogether.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525957"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-a</span></dt>
<dd>
<p>
Do automatic <span><strong class="command">rndc</strong></span> configuration.
This creates a file <code class="filename">rndc.key</code>
in <code class="filename">/etc</code> (or whatever
<code class="varname">sysconfdir</code>
was specified as when <span class="acronym">BIND</span> was built)
that is read by both <span><strong class="command">rndc</strong></span>
and <span><strong class="command">named</strong></span> on startup. The
<code class="filename">rndc.key</code> file defines a default
command channel and authentication key allowing
<B
CLASS="COMMAND"
>rndc</B
> to communicate with
<B
CLASS="COMMAND"
>named</B
> on the local host
<span><strong class="command">rndc</strong></span> to communicate with
<span><strong class="command">named</strong></span> on the local host
with no further configuration.
</P
><P
> Running <B
CLASS="COMMAND"
>rndc-confgen -a</B
> allows
BIND 9 and <B
CLASS="COMMAND"
>rndc</B
> to be used as drop-in
replacements for BIND 8 and <B
CLASS="COMMAND"
>ndc</B
>,
</p>
<p>
Running <span><strong class="command">rndc-confgen -a</strong></span> allows
BIND 9 and <span><strong class="command">rndc</strong></span> to be used as drop-in
replacements for BIND 8 and <span><strong class="command">ndc</strong></span>,
with no changes to the existing BIND 8
<TT
CLASS="FILENAME"
>named.conf</TT
> file.
</P
><P
> If a more elaborate configuration than that
generated by <B
CLASS="COMMAND"
>rndc-confgen -a</B
>
<code class="filename">named.conf</code> file.
</p>
<p>
If a more elaborate configuration than that
generated by <span><strong class="command">rndc-confgen -a</strong></span>
is required, for example if rndc is to be used remotely,
you should run <B
CLASS="COMMAND"
>rndc-confgen</B
> without the
<B
CLASS="COMMAND"
>-a</B
> option and set up a
<TT
CLASS="FILENAME"
>rndc.conf</TT
> and
<TT
CLASS="FILENAME"
>named.conf</TT
>
you should run <span><strong class="command">rndc-confgen</strong></span> without the
<span><strong class="command">-a</strong></span> option and set up a
<code class="filename">rndc.conf</code> and
<code class="filename">named.conf</code>
as directed.
</P
></DD
><DT
>-b <VAR
CLASS="REPLACEABLE"
>keysize</VAR
></DT
><DD
><P
> Specifies the size of the authentication key in bits.
</p>
</dd>
<dt><span class="term">-b <em class="replaceable"><code>keysize</code></em></span></dt>
<dd><p>
Specifies the size of the authentication key in bits.
Must be between 1 and 512 bits; the default is 128.
</P
></DD
><DT
>-c <VAR
CLASS="REPLACEABLE"
>keyfile</VAR
></DT
><DD
><P
> Used with the <B
CLASS="COMMAND"
>-a</B
> option to specify
an alternate location for <TT
CLASS="FILENAME"
>rndc.key</TT
>.
</P
></DD
><DT
>-h</DT
><DD
><P
> Prints a short summary of the options and arguments to
<B
CLASS="COMMAND"
>rndc-confgen</B
>.
</P
></DD
><DT
>-k <VAR
CLASS="REPLACEABLE"
>keyname</VAR
></DT
><DD
><P
> Specifies the key name of the rndc authentication key.
</p></dd>
<dt><span class="term">-c <em class="replaceable"><code>keyfile</code></em></span></dt>
<dd><p>
Used with the <span><strong class="command">-a</strong></span> option to specify
an alternate location for <code class="filename">rndc.key</code>.
</p></dd>
<dt><span class="term">-h</span></dt>
<dd><p>
Prints a short summary of the options and arguments to
<span><strong class="command">rndc-confgen</strong></span>.
</p></dd>
<dt><span class="term">-k <em class="replaceable"><code>keyname</code></em></span></dt>
<dd><p>
Specifies the key name of the rndc authentication key.
This must be a valid domain name.
The default is <CODE
CLASS="CONSTANT"
>rndc-key</CODE
>.
</P
></DD
><DT
>-p <VAR
CLASS="REPLACEABLE"
>port</VAR
></DT
><DD
><P
> Specifies the command channel port where <B
CLASS="COMMAND"
>named</B
>
listens for connections from <B
CLASS="COMMAND"
>rndc</B
>.
The default is <code class="constant">rndc-key</code>.
</p></dd>
<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
<dd><p>
Specifies the command channel port where <span><strong class="command">named</strong></span>
listens for connections from <span><strong class="command">rndc</strong></span>.
The default is 953.
</P
></DD
><DT
>-r <VAR
CLASS="REPLACEABLE"
>randomfile</VAR
></DT
><DD
><P
> Specifies a source of random data for generating the
</p></dd>
<dt><span class="term">-r <em class="replaceable"><code>randomfile</code></em></span></dt>
<dd><p>
Specifies a source of random data for generating the
authorization. If the operating
system does not provide a <TT
CLASS="FILENAME"
>/dev/random</TT
>
system does not provide a <code class="filename">/dev/random</code>
or equivalent device, the default source of randomness
is keyboard input. <TT
CLASS="FILENAME"
>randomdev</TT
> specifies
is keyboard input. <code class="filename">randomdev</code> specifies
the name of a character device or file containing random
data to be used instead of the default. The special value
<TT
CLASS="FILENAME"
>keyboard</TT
> indicates that keyboard
<code class="filename">keyboard</code> indicates that keyboard
input should be used.
</P
></DD
><DT
>-s <VAR
CLASS="REPLACEABLE"
>address</VAR
></DT
><DD
><P
> Specifies the IP address where <B
CLASS="COMMAND"
>named</B
>
</p></dd>
<dt><span class="term">-s <em class="replaceable"><code>address</code></em></span></dt>
<dd><p>
Specifies the IP address where <span><strong class="command">named</strong></span>
listens for command channel connections from
<B
CLASS="COMMAND"
>rndc</B
>. The default is the loopback
<span><strong class="command">rndc</strong></span>. The default is the loopback
address 127.0.0.1.
</P
></DD
><DT
>-t <VAR
CLASS="REPLACEABLE"
>chrootdir</VAR
></DT
><DD
><P
> Used with the <B
CLASS="COMMAND"
>-a</B
> option to specify
a directory where <B
CLASS="COMMAND"
>named</B
> will run
chrooted. An additional copy of the <TT
CLASS="FILENAME"
>rndc.key</TT
>
</p></dd>
<dt><span class="term">-t <em class="replaceable"><code>chrootdir</code></em></span></dt>
<dd><p>
Used with the <span><strong class="command">-a</strong></span> option to specify
a directory where <span><strong class="command">named</strong></span> will run
chrooted. An additional copy of the <code class="filename">rndc.key</code>
will be written relative to this directory so that
it will be found by the chrooted <B
CLASS="COMMAND"
>named</B
>.
</P
></DD
><DT
>-u <VAR
CLASS="REPLACEABLE"
>user</VAR
></DT
><DD
><P
> Used with the <B
CLASS="COMMAND"
>-a</B
> option to set the owner
of the <TT
CLASS="FILENAME"
>rndc.key</TT
> file generated. If
<B
CLASS="COMMAND"
>-t</B
> is also specified only the file in
it will be found by the chrooted <span><strong class="command">named</strong></span>.
</p></dd>
<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
<dd><p>
Used with the <span><strong class="command">-a</strong></span> option to set the owner
of the <code class="filename">rndc.key</code> file generated. If
<span><strong class="command">-t</strong></span> is also specified only the file in
the chroot area has its owner changed.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN147"
></A
><H2
>EXAMPLES</H2
><P
> To allow <B
CLASS="COMMAND"
>rndc</B
> to be used with
</p></dd>
</dl></div>
</div>
<div class="refsect1" lang="en">
<a name="id2526270"></a><h2>EXAMPLES</h2>
<p>
To allow <span><strong class="command">rndc</strong></span> to be used with
no manual configuration, run
</P
><P
> <KBD
CLASS="USERINPUT"
>rndc-confgen -a</KBD
>
</P
><P
> To print a sample <TT
CLASS="FILENAME"
>rndc.conf</TT
> file and
corresponding <B
CLASS="COMMAND"
>controls</B
> and <B
CLASS="COMMAND"
>key</B
>
statements to be manually inserted into <TT
CLASS="FILENAME"
>named.conf</TT
>,
</p>
<p>
<strong class="userinput"><code>rndc-confgen -a</code></strong>
</p>
<p>
To print a sample <code class="filename">rndc.conf</code> file and
corresponding <span><strong class="command">controls</strong></span> and <span><strong class="command">key</strong></span>
statements to be manually inserted into <code class="filename">named.conf</code>,
run
</P
><P
> <KBD
CLASS="USERINPUT"
>rndc-confgen</KBD
>
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN160"
></A
><H2
>SEE ALSO</H2
><P
> <SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>rndc</SPAN
>(8)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>rndc.conf</SPAN
>(5)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>named</SPAN
>(8)</SPAN
>,
<I
CLASS="CITETITLE"
>BIND 9 Administrator Reference Manual</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN173"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
</p>
<p>
<strong class="userinput"><code>rndc-confgen</code></strong>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526314"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526357"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

146
contrib/bind9/bin/rndc/rndc.8
View file

@ -1,118 +1,118 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000, 2001 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000, 2001 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: rndc.8,v 1.24.206.2 2004/06/03 05:35:49 marka Exp $
.\" $Id: rndc.8,v 1.24.206.5 2005/10/13 02:33:49 marka Exp $
.\"
.TH "RNDC" "8" "June 30, 2000" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "RNDC" "8" "June 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
rndc \- name server control utility
.SH SYNOPSIS
.sp
\fBrndc\fR [ \fB-c \fIconfig-file\fB\fR ] [ \fB-k \fIkey-file\fB\fR ] [ \fB-s \fIserver\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-V\fR ] [ \fB-y \fIkey_id\fB\fR ] \fBcommand\fR
.SH "SYNOPSIS"
.HP 5
\fBrndc\fR [\fB\-c\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-k\ \fR\fB\fIkey\-file\fR\fR] [\fB\-s\ \fR\fB\fIserver\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-V\fR] [\fB\-y\ \fR\fB\fIkey_id\fR\fR] {command}
.SH "DESCRIPTION"
.PP
\fBrndc\fR controls the operation of a name
server. It supersedes the \fBndc\fR utility
that was provided in old BIND releases. If
\fBrndc\fR is invoked with no command line
options or arguments, it prints a short summary of the
supported commands and the available options and their
arguments.
\fBrndc\fR
controls the operation of a name server. It supersedes the
\fBndc\fR
utility that was provided in old BIND releases. If
\fBrndc\fR
is invoked with no command line options or arguments, it prints a short summary of the supported commands and the available options and their arguments.
.PP
\fBrndc\fR communicates with the name server
over a TCP connection, sending commands authenticated with
digital signatures. In the current versions of
\fBrndc\fR and \fBnamed\fR named
the only supported authentication algorithm is HMAC-MD5,
which uses a shared secret on each end of the connection.
This provides TSIG-style authentication for the command
request and the name server's response. All commands sent
over the channel must be signed by a key_id known to the
server.
\fBrndc\fR
communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. In the current versions of
\fBrndc\fR
and
\fBnamed\fR
named the only supported authentication algorithm is HMAC\-MD5, which uses a shared secret on each end of the connection. This provides TSIG\-style authentication for the command request and the name server's response. All commands sent over the channel must be signed by a key_id known to the server.
.PP
\fBrndc\fR reads a configuration file to
determine how to contact the name server and decide what
algorithm and key it should use.
\fBrndc\fR
reads a configuration file to determine how to contact the name server and decide what algorithm and key it should use.
.SH "OPTIONS"
.TP
\fB-c \fIconfig-file\fB\fR
Use \fIconfig-file\fR
\-c \fIconfig\-file\fR
Use
\fIconfig\-file\fR
as the configuration file instead of the default,
\fI/etc/rndc.conf\fR.
.TP
\fB-k \fIkey-file\fB\fR
Use \fIkey-file\fR
\-k \fIkey\-file\fR
Use
\fIkey\-file\fR
as the key file instead of the default,
\fI/etc/rndc.key\fR. The key in
\fI/etc/rndc.key\fR will be used to authenticate
commands sent to the server if the \fIconfig-file\fR
\fI/etc/rndc.key\fR
will be used to authenticate commands sent to the server if the
\fIconfig\-file\fR
does not exist.
.TP
\fB-s \fIserver\fB\fR
\fIserver\fR is
the name or address of the server which matches a
server statement in the configuration file for
\fBrndc\fR. If no server is supplied on the
command line, the host named by the default-server clause
in the option statement of the configuration file will be
used.
\-s \fIserver\fR
\fIserver\fR
is the name or address of the server which matches a server statement in the configuration file for
\fBrndc\fR. If no server is supplied on the command line, the host named by the default\-server clause in the option statement of the configuration file will be used.
.TP
\fB-p \fIport\fB\fR
\-p \fIport\fR
Send commands to TCP port
\fIport\fR instead
of BIND 9's default control channel port, 953.
\fIport\fR
instead of BIND 9's default control channel port, 953.
.TP
\fB-V\fR
\-V
Enable verbose logging.
.TP
\fB-y \fIkeyid\fB\fR
Use the key \fIkeyid\fR
\-y \fIkeyid\fR
Use the key
\fIkeyid\fR
from the configuration file.
\fIkeyid\fR must be
known by named with the same algorithm and secret string
in order for control message validation to succeed.
If no \fIkeyid\fR
is specified, \fBrndc\fR will first look
for a key clause in the server statement of the server
being used, or if no server statement is present for that
host, then the default-key clause of the options statement.
Note that the configuration file contains shared secrets
which are used to send authenticated control commands
to name servers. It should therefore not have general read
or write access.
.PP
For the complete set of commands supported by \fBrndc\fR,
see the BIND 9 Administrator Reference Manual or run
\fBrndc\fR without arguments to see its help message.
\fIkeyid\fR
must be known by named with the same algorithm and secret string in order for control message validation to succeed. If no
\fIkeyid\fR
is specified,
\fBrndc\fR
will first look for a key clause in the server statement of the server being used, or if no server statement is present for that host, then the default\-key clause of the options statement. Note that the configuration file contains shared secrets which are used to send authenticated control commands to name servers. It should therefore not have general read or write access.
.PP
For the complete set of commands supported by
\fBrndc\fR, see the BIND 9 Administrator Reference Manual or run
\fBrndc\fR
without arguments to see its help message.
.SH "LIMITATIONS"
.PP
\fBrndc\fR does not yet support all the commands of
the BIND 8 \fBndc\fR utility.
\fBrndc\fR
does not yet support all the commands of the BIND 8
\fBndc\fR
utility.
.PP
There is currently no way to provide the shared secret for a
\fBkey_id\fR without using the configuration file.
\fBkey_id\fR
without using the configuration file.
.PP
Several error messages could be clearer.
.SH "SEE ALSO"
.PP
\fBrndc.conf\fR(5),
\fBnamed\fR(8),
\fBnamed.conf\fR(5)
\fBndc\fR(8),
\fIBIND 9 Administrator Reference Manual\fR.
\fBnamed.conf\fR(5)\fBndc\fR(8),
BIND 9 Administrator Reference Manual.
.SH "AUTHOR"
.PP
Internet Systems Consortium

7
contrib/bind9/bin/rndc/rndc.c
View file

@ -1,5 +1,5 @@
/*
* Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: rndc.c,v 1.77.2.5.2.13 2004/09/03 03:43:32 marka Exp $ */
/* $Id: rndc.c,v 1.77.2.5.2.15 2005/03/17 03:58:27 marka Exp $ */
/*
* Principal Author: DCL
@ -104,7 +104,8 @@ command is one of the following:\n\
reconfig Reload configuration file and new zones only.\n\
stats Write server statistics to the statistics file.\n\
querylog Toggle query logging.\n\
dumpdb Dump cache(s) to the dump file (named_dump.db).\n\
dumpdb [-all|-cache|-zones] [view ...]\n\
Dump cache(s) to the dump file (named_dump.db).\n\
stop Save pending updates to master files and stop the server.\n\
stop -p Save pending updates to master files and stop the server\n\
reporting process id.\n\

188
contrib/bind9/bin/rndc/rndc.conf.5
View file

@ -1,35 +1,42 @@
.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000, 2001 Internet Software Consortium.
.\"
.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (C) 2000, 2001 Internet Software Consortium.
.\"
.\" 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.
.\"
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
.\" AND FITNESS. IN NO EVENT SHALL ISC 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.
.\"
.\" $Id: rndc.conf.5,v 1.21.206.2 2004/06/03 05:35:50 marka Exp $
.\" $Id: rndc.conf.5,v 1.21.206.5 2005/10/13 02:33:50 marka Exp $
.\"
.TH "RNDC.CONF" "5" "June 30, 2000" "BIND9" ""
.SH NAME
.hy 0
.ad l
.\" ** You probably do not want to edit this file directly **
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
.TH "\\FIRNDC.CONF\\FR" "5" "June 30, 2000" "BIND9" "BIND9"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.SH "NAME"
rndc.conf \- rndc configuration file
.SH SYNOPSIS
.sp
.SH "SYNOPSIS"
.HP 10
\fBrndc.conf\fR
.SH "DESCRIPTION"
.PP
\fIrndc.conf\fR is the configuration file
for \fBrndc\fR, the BIND 9 name server control
utility. This file has a similar structure and syntax to
\fInamed.conf\fR. Statements are enclosed
in braces and terminated with a semi-colon. Clauses in
the statements are also semi-colon terminated. The usual
comment styles are supported:
\fIrndc.conf\fR
is the configuration file for
\fBrndc\fR, the BIND 9 name server control utility. This file has a similar structure and syntax to
\fInamed.conf\fR. Statements are enclosed in braces and terminated with a semi\-colon. Clauses in the statements are also semi\-colon terminated. The usual comment styles are supported:
.PP
C style: /* */
.PP
@ -37,106 +44,111 @@ C++ style: // to end of line
.PP
Unix style: # to end of line
.PP
\fIrndc.conf\fR is much simpler than
\fInamed.conf\fR. The file uses three
statements: an options statement, a server statement
and a key statement.
\fIrndc.conf\fR
is much simpler than
\fInamed.conf\fR. The file uses three statements: an options statement, a server statement and a key statement.
.PP
The \fBoptions\fR statement contains three clauses.
The \fBdefault-server\fR clause is followed by the
name or address of a name server. This host will be used when
no name server is given as an argument to
\fBrndc\fR. The \fBdefault-key\fR
clause is followed by the name of a key which is identified by
a \fBkey\fR statement. If no
\fBkeyid\fR is provided on the rndc command line,
and no \fBkey\fR clause is found in a matching
\fBserver\fR statement, this default key will be
used to authenticate the server's commands and responses. The
\fBdefault-port\fR clause is followed by the port
to connect to on the remote name server. If no
\fBport\fR option is provided on the rndc command
line, and no \fBport\fR clause is found in a
matching \fBserver\fR statement, this default port
will be used to connect.
The
\fBoptions\fR
statement contains three clauses. The
\fBdefault\-server\fR
clause is followed by the name or address of a name server. This host will be used when no name server is given as an argument to
\fBrndc\fR. The
\fBdefault\-key\fR
clause is followed by the name of a key which is identified by a
\fBkey\fR
statement. If no
\fBkeyid\fR
is provided on the rndc command line, and no
\fBkey\fR
clause is found in a matching
\fBserver\fR
statement, this default key will be used to authenticate the server's commands and responses. The
\fBdefault\-port\fR
clause is followed by the port to connect to on the remote name server. If no
\fBport\fR
option is provided on the rndc command line, and no
\fBport\fR
clause is found in a matching
\fBserver\fR
statement, this default port will be used to connect.
.PP
After the \fBserver\fR keyword, the server statement
includes a string which is the hostname or address for a name
server. The statement has two possible clauses:
\fBkey\fR and \fBport\fR. The key name must
match the name of a key statement in the file. The port number
specifies the port to connect to.
After the
\fBserver\fR
keyword, the server statement includes a string which is the hostname or address for a name server. The statement has two possible clauses:
\fBkey\fR
and
\fBport\fR. The key name must match the name of a key statement in the file. The port number specifies the port to connect to.
.PP
The \fBkey\fR statement begins with an identifying
string, the name of the key. The statement has two clauses.
\fBalgorithm\fR identifies the encryption algorithm
for \fBrndc\fR to use; currently only HMAC-MD5 is
supported. This is followed by a secret clause which contains
the base-64 encoding of the algorithm's encryption key. The
base-64 string is enclosed in double quotes.
The
\fBkey\fR
statement begins with an identifying string, the name of the key. The statement has two clauses.
\fBalgorithm\fR
identifies the encryption algorithm for
\fBrndc\fR
to use; currently only HMAC\-MD5 is supported. This is followed by a secret clause which contains the base\-64 encoding of the algorithm's encryption key. The base\-64 string is enclosed in double quotes.
.PP
There are two common ways to generate the base-64 string for the
secret. The BIND 9 program \fBrndc-confgen\fR can
be used to generate a random key, or the
\fBmmencode\fR program, also known as
\fBmimencode\fR, can be used to generate a base-64
string from known input. \fBmmencode\fR does not
ship with BIND 9 but is available on many systems. See the
EXAMPLE section for sample command lines for each.
There are two common ways to generate the base\-64 string for the secret. The BIND 9 program
\fBrndc\-confgen\fR
can be used to generate a random key, or the
\fBmmencode\fR
program, also known as
\fBmimencode\fR, can be used to generate a base\-64 string from known input.
\fBmmencode\fR
does not ship with BIND 9 but is available on many systems. See the EXAMPLE section for sample command lines for each.
.SH "EXAMPLE"
.sp
.nf
options {
default-server localhost;
default-key samplekey;
default\-server localhost;
default\-key samplekey;
};
server localhost {
key samplekey;
};
key samplekey {
algorithm hmac-md5;
algorithm hmac\-md5;
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
.sp
.fi
.PP
In the above example, \fBrndc\fR will by default use
the server at localhost (127.0.0.1) and the key called samplekey.
Commands to the localhost server will use the samplekey key, which
must also be defined in the server's configuration file with the
same name and secret. The key statement indicates that samplekey
uses the HMAC-MD5 algorithm and its secret clause contains the
base-64 encoding of the HMAC-MD5 secret enclosed in double quotes.
In the above example,
\fBrndc\fR
will by default use the server at localhost (127.0.0.1) and the key called samplekey. Commands to the localhost server will use the samplekey key, which must also be defined in the server's configuration file with the same name and secret. The key statement indicates that samplekey uses the HMAC\-MD5 algorithm and its secret clause contains the base\-64 encoding of the HMAC\-MD5 secret enclosed in double quotes.
.PP
To generate a random secret with \fBrndc-confgen\fR:
To generate a random secret with
\fBrndc\-confgen\fR:
.PP
\fBrndc-confgen\fR
\fBrndc\-confgen\fR
.PP
A complete \fIrndc.conf\fR file, including the
randomly generated key, will be written to the standard
output. Commented out \fBkey\fR and
\fBcontrols\fR statements for
\fInamed.conf\fR are also printed.
A complete
\fIrndc.conf\fR
file, including the randomly generated key, will be written to the standard output. Commented out
\fBkey\fR
and
\fBcontrols\fR
statements for
\fInamed.conf\fR
are also printed.
.PP
To generate a base-64 secret with \fBmmencode\fR:
To generate a base\-64 secret with
\fBmmencode\fR:
.PP
\fBecho "known plaintext for a secret" | mmencode\fR
.SH "NAME SERVER CONFIGURATION"
.PP
The name server must be configured to accept rndc connections and
to recognize the key specified in the \fIrndc.conf\fR
file, using the controls statement in \fInamed.conf\fR.
See the sections on the \fBcontrols\fR statement in the
BIND 9 Administrator Reference Manual for details.
The name server must be configured to accept rndc connections and to recognize the key specified in the
\fIrndc.conf\fR
file, using the controls statement in
\fInamed.conf\fR. See the sections on the
\fBcontrols\fR
statement in the BIND 9 Administrator Reference Manual for details.
.SH "SEE ALSO"
.PP
\fBrndc\fR(8),
\fBrndc-confgen\fR(8),
\fBrndc\-confgen\fR(8),
\fBmmencode\fR(1),
\fIBIND 9 Administrator Reference Manual\fR.
BIND 9 Administrator Reference Manual.
.SH "AUTHOR"
.PP
Internet Systems Consortium

23
contrib/bind9/bin/rndc/rndc.conf.docbook
View file

@ -1,7 +1,9 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001 Internet Software Consortium.
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: rndc.conf.docbook,v 1.4.206.2 2004/06/03 02:24:58 marka Exp $ -->
<!-- $Id: rndc.conf.docbook,v 1.4.206.4 2005/05/12 21:36:04 sra Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,19 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><filename>rndc.conf</filename></refname>
<refpurpose>rndc configuration file</refpurpose>

448
contrib/bind9/bin/rndc/rndc.conf.html
View file

@ -1,238 +1,113 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: rndc.conf.html,v 1.5.2.1.4.3 2004/08/22 23:39:00 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>rndc.conf</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><TT
CLASS="FILENAME"
>rndc.conf</TT
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><TT
CLASS="FILENAME"
>rndc.conf</TT
>&nbsp;--&nbsp;rndc configuration file</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>rndc.conf</B
> </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN16"
></A
><H2
>DESCRIPTION</H2
><P
> <TT
CLASS="FILENAME"
>rndc.conf</TT
> is the configuration file
for <B
CLASS="COMMAND"
>rndc</B
>, the BIND 9 name server control
<!-- $Id: rndc.conf.html,v 1.5.2.1.4.10 2005/10/13 02:33:51 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>rndc.conf</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><code class="filename">rndc.conf</code> &#8212; rndc configuration file</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525833"></a><h2>DESCRIPTION</h2>
<p>
<code class="filename">rndc.conf</code> is the configuration file
for <span><strong class="command">rndc</strong></span>, the BIND 9 name server control
utility. This file has a similar structure and syntax to
<TT
CLASS="FILENAME"
>named.conf</TT
>. Statements are enclosed
<code class="filename">named.conf</code>. Statements are enclosed
in braces and terminated with a semi-colon. Clauses in
the statements are also semi-colon terminated. The usual
comment styles are supported:
</P
><P
> C style: /* */
</P
><P
> C++ style: // to end of line
</P
><P
> Unix style: # to end of line
</P
><P
> <TT
CLASS="FILENAME"
>rndc.conf</TT
> is much simpler than
<TT
CLASS="FILENAME"
>named.conf</TT
>. The file uses three
</p>
<p>
C style: /* */
</p>
<p>
C++ style: // to end of line
</p>
<p>
Unix style: # to end of line
</p>
<p>
<code class="filename">rndc.conf</code> is much simpler than
<code class="filename">named.conf</code>. The file uses three
statements: an options statement, a server statement
and a key statement.
</P
><P
> The <VAR
CLASS="OPTION"
>options</VAR
> statement contains three clauses.
The <VAR
CLASS="OPTION"
>default-server</VAR
> clause is followed by the
</p>
<p>
The <code class="option">options</code> statement contains three clauses.
The <code class="option">default-server</code> clause is followed by the
name or address of a name server. This host will be used when
no name server is given as an argument to
<B
CLASS="COMMAND"
>rndc</B
>. The <VAR
CLASS="OPTION"
>default-key</VAR
>
<span><strong class="command">rndc</strong></span>. The <code class="option">default-key</code>
clause is followed by the name of a key which is identified by
a <VAR
CLASS="OPTION"
>key</VAR
> statement. If no
<VAR
CLASS="OPTION"
>keyid</VAR
> is provided on the rndc command line,
and no <VAR
CLASS="OPTION"
>key</VAR
> clause is found in a matching
<VAR
CLASS="OPTION"
>server</VAR
> statement, this default key will be
a <code class="option">key</code> statement. If no
<code class="option">keyid</code> is provided on the rndc command line,
and no <code class="option">key</code> clause is found in a matching
<code class="option">server</code> statement, this default key will be
used to authenticate the server's commands and responses. The
<VAR
CLASS="OPTION"
>default-port</VAR
> clause is followed by the port
<code class="option">default-port</code> clause is followed by the port
to connect to on the remote name server. If no
<VAR
CLASS="OPTION"
>port</VAR
> option is provided on the rndc command
line, and no <VAR
CLASS="OPTION"
>port</VAR
> clause is found in a
matching <VAR
CLASS="OPTION"
>server</VAR
> statement, this default port
<code class="option">port</code> option is provided on the rndc command
line, and no <code class="option">port</code> clause is found in a
matching <code class="option">server</code> statement, this default port
will be used to connect.
</P
><P
> After the <VAR
CLASS="OPTION"
>server</VAR
> keyword, the server statement
</p>
<p>
After the <code class="option">server</code> keyword, the server statement
includes a string which is the hostname or address for a name
server. The statement has two possible clauses:
<VAR
CLASS="OPTION"
>key</VAR
> and <VAR
CLASS="OPTION"
>port</VAR
>. The key name must
<code class="option">key</code> and <code class="option">port</code>. The key name must
match the name of a key statement in the file. The port number
specifies the port to connect to.
</P
><P
> The <VAR
CLASS="OPTION"
>key</VAR
> statement begins with an identifying
</p>
<p>
The <code class="option">key</code> statement begins with an identifying
string, the name of the key. The statement has two clauses.
<VAR
CLASS="OPTION"
>algorithm</VAR
> identifies the encryption algorithm
for <B
CLASS="COMMAND"
>rndc</B
> to use; currently only HMAC-MD5 is
<code class="option">algorithm</code> identifies the encryption algorithm
for <span><strong class="command">rndc</strong></span> to use; currently only HMAC-MD5 is
supported. This is followed by a secret clause which contains
the base-64 encoding of the algorithm's encryption key. The
base-64 string is enclosed in double quotes.
</P
><P
> There are two common ways to generate the base-64 string for the
secret. The BIND 9 program <B
CLASS="COMMAND"
>rndc-confgen</B
> can
</p>
<p>
There are two common ways to generate the base-64 string for the
secret. The BIND 9 program <span><strong class="command">rndc-confgen</strong></span> can
be used to generate a random key, or the
<B
CLASS="COMMAND"
>mmencode</B
> program, also known as
<B
CLASS="COMMAND"
>mimencode</B
>, can be used to generate a base-64
string from known input. <B
CLASS="COMMAND"
>mmencode</B
> does not
<span><strong class="command">mmencode</strong></span> program, also known as
<span><strong class="command">mimencode</strong></span>, can be used to generate a base-64
string from known input. <span><strong class="command">mmencode</strong></span> does not
ship with BIND 9 but is available on many systems. See the
EXAMPLE section for sample command lines for each.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN54"
></A
><H2
>EXAMPLE</H2
><PRE
CLASS="PROGRAMLISTING"
> options {
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525968"></a><h2>EXAMPLE</h2>
<pre class="programlisting">
options {
default-server localhost;
default-key samplekey;
};
@ -245,133 +120,60 @@ CLASS="PROGRAMLISTING"
algorithm hmac-md5;
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
</PRE
><P
> In the above example, <B
CLASS="COMMAND"
>rndc</B
> will by default use
</pre>
<p>
In the above example, <span><strong class="command">rndc</strong></span> will by default use
the server at localhost (127.0.0.1) and the key called samplekey.
Commands to the localhost server will use the samplekey key, which
must also be defined in the server's configuration file with the
same name and secret. The key statement indicates that samplekey
uses the HMAC-MD5 algorithm and its secret clause contains the
base-64 encoding of the HMAC-MD5 secret enclosed in double quotes.
</P
><P
> To generate a random secret with <B
CLASS="COMMAND"
>rndc-confgen</B
>:
</P
><P
> <KBD
CLASS="USERINPUT"
>rndc-confgen</KBD
>
</P
><P
> A complete <TT
CLASS="FILENAME"
>rndc.conf</TT
> file, including the
</p>
<p>
To generate a random secret with <span><strong class="command">rndc-confgen</strong></span>:
</p>
<p>
<strong class="userinput"><code>rndc-confgen</code></strong>
</p>
<p>
A complete <code class="filename">rndc.conf</code> file, including the
randomly generated key, will be written to the standard
output. Commented out <VAR
CLASS="OPTION"
>key</VAR
> and
<VAR
CLASS="OPTION"
>controls</VAR
> statements for
<TT
CLASS="FILENAME"
>named.conf</TT
> are also printed.
</P
><P
> To generate a base-64 secret with <B
CLASS="COMMAND"
>mmencode</B
>:
</P
><P
> <KBD
CLASS="USERINPUT"
>echo "known plaintext for a secret" | mmencode</KBD
>
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN72"
></A
><H2
>NAME SERVER CONFIGURATION</H2
><P
> The name server must be configured to accept rndc connections and
to recognize the key specified in the <TT
CLASS="FILENAME"
>rndc.conf</TT
>
file, using the controls statement in <TT
CLASS="FILENAME"
>named.conf</TT
>.
See the sections on the <VAR
CLASS="OPTION"
>controls</VAR
> statement in the
output. Commented out <code class="option">key</code> and
<code class="option">controls</code> statements for
<code class="filename">named.conf</code> are also printed.
</p>
<p>
To generate a base-64 secret with <span><strong class="command">mmencode</strong></span>:
</p>
<p>
<strong class="userinput"><code>echo "known plaintext for a secret" | mmencode</code></strong>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526028"></a><h2>NAME SERVER CONFIGURATION</h2>
<p>
The name server must be configured to accept rndc connections and
to recognize the key specified in the <code class="filename">rndc.conf</code>
file, using the controls statement in <code class="filename">named.conf</code>.
See the sections on the <code class="option">controls</code> statement in the
BIND 9 Administrator Reference Manual for details.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN78"
></A
><H2
>SEE ALSO</H2
><P
> <SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>rndc</SPAN
>(8)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>rndc-confgen</SPAN
>(8)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>mmencode</SPAN
>(1)</SPAN
>,
<I
CLASS="CITETITLE"
>BIND 9 Administrator Reference Manual</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN91"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526049"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">mmencode</span>(1)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526091"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

23
contrib/bind9/bin/rndc/rndc.docbook
View file

@ -1,7 +1,9 @@
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001 Internet Software Consortium.
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001 Internet Software Consortium.
-
- Permission to use, copy, modify, and distribute this software for any
- purpose with or without fee is hereby granted, provided that the above
@ -16,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: rndc.docbook,v 1.7.206.2 2004/06/03 02:24:58 marka Exp $ -->
<!-- $Id: rndc.docbook,v 1.7.206.4 2005/05/12 21:36:05 sra Exp $ -->
<refentry>
<refentryinfo>
@ -29,6 +31,19 @@
<refmiscinfo>BIND9</refmiscinfo>
</refmeta>
<docinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</docinfo>
<refnamediv>
<refname><application>rndc</application></refname>
<refpurpose>name server control utility</refpurpose>

454
contrib/bind9/bin/rndc/rndc.html
View file

@ -1,284 +1,112 @@
<!--
- Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2001 Internet Software Consortium.
-
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000, 2001 Internet Software Consortium.
-
- 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.
-
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: rndc.html,v 1.7.2.1.4.3 2004/08/22 23:39:00 marka Exp $ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>rndc</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><H1
><A
NAME="AEN1"
></A
><SPAN
CLASS="APPLICATION"
>rndc</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN9"
></A
><H2
>Name</H2
><SPAN
CLASS="APPLICATION"
>rndc</SPAN
>&nbsp;--&nbsp;name server control utility</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN13"
></A
><H2
>Synopsis</H2
><P
><B
CLASS="COMMAND"
>rndc</B
> [<VAR
CLASS="OPTION"
>-c <VAR
CLASS="REPLACEABLE"
>config-file</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-k <VAR
CLASS="REPLACEABLE"
>key-file</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-s <VAR
CLASS="REPLACEABLE"
>server</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-p <VAR
CLASS="REPLACEABLE"
>port</VAR
></VAR
>] [<VAR
CLASS="OPTION"
>-V</VAR
>] [<VAR
CLASS="OPTION"
>-y <VAR
CLASS="REPLACEABLE"
>key_id</VAR
></VAR
>] {command}</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN34"
></A
><H2
>DESCRIPTION</H2
><P
> <B
CLASS="COMMAND"
>rndc</B
> controls the operation of a name
server. It supersedes the <B
CLASS="COMMAND"
>ndc</B
> utility
<!-- $Id: rndc.html,v 1.7.2.1.4.10 2005/10/13 02:33:50 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>rndc</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="id2463721"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p><span class="application">rndc</span> &#8212; name server control utility</p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><code class="command">rndc</code> [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key-file</code></em></code>] [<code class="option">-s <em class="replaceable"><code>server</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-V</code>] [<code class="option">-y <em class="replaceable"><code>key_id</code></em></code>] {command}</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2525886"></a><h2>DESCRIPTION</h2>
<p>
<span><strong class="command">rndc</strong></span> controls the operation of a name
server. It supersedes the <span><strong class="command">ndc</strong></span> utility
that was provided in old BIND releases. If
<B
CLASS="COMMAND"
>rndc</B
> is invoked with no command line
<span><strong class="command">rndc</strong></span> is invoked with no command line
options or arguments, it prints a short summary of the
supported commands and the available options and their
arguments.
</P
><P
> <B
CLASS="COMMAND"
>rndc</B
> communicates with the name server
</p>
<p>
<span><strong class="command">rndc</strong></span> communicates with the name server
over a TCP connection, sending commands authenticated with
digital signatures. In the current versions of
<B
CLASS="COMMAND"
>rndc</B
> and <B
CLASS="COMMAND"
>named</B
> named
<span><strong class="command">rndc</strong></span> and <span><strong class="command">named</strong></span> named
the only supported authentication algorithm is HMAC-MD5,
which uses a shared secret on each end of the connection.
This provides TSIG-style authentication for the command
request and the name server's response. All commands sent
over the channel must be signed by a key_id known to the
server.
</P
><P
> <B
CLASS="COMMAND"
>rndc</B
> reads a configuration file to
</p>
<p>
<span><strong class="command">rndc</strong></span> reads a configuration file to
determine how to contact the name server and decide what
algorithm and key it should use.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN46"
></A
><H2
>OPTIONS</H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>-c <VAR
CLASS="REPLACEABLE"
>config-file</VAR
></DT
><DD
><P
> Use <VAR
CLASS="REPLACEABLE"
>config-file</VAR
>
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2525927"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-c <em class="replaceable"><code>config-file</code></em></span></dt>
<dd><p>
Use <em class="replaceable"><code>config-file</code></em>
as the configuration file instead of the default,
<TT
CLASS="FILENAME"
>/etc/rndc.conf</TT
>.
</P
></DD
><DT
>-k <VAR
CLASS="REPLACEABLE"
>key-file</VAR
></DT
><DD
><P
> Use <VAR
CLASS="REPLACEABLE"
>key-file</VAR
>
<code class="filename">/etc/rndc.conf</code>.
</p></dd>
<dt><span class="term">-k <em class="replaceable"><code>key-file</code></em></span></dt>
<dd><p>
Use <em class="replaceable"><code>key-file</code></em>
as the key file instead of the default,
<TT
CLASS="FILENAME"
>/etc/rndc.key</TT
>. The key in
<TT
CLASS="FILENAME"
>/etc/rndc.key</TT
> will be used to authenticate
commands sent to the server if the <VAR
CLASS="REPLACEABLE"
>config-file</VAR
>
<code class="filename">/etc/rndc.key</code>. The key in
<code class="filename">/etc/rndc.key</code> will be used to authenticate
commands sent to the server if the <em class="replaceable"><code>config-file</code></em>
does not exist.
</P
></DD
><DT
>-s <VAR
CLASS="REPLACEABLE"
>server</VAR
></DT
><DD
><P
> <VAR
CLASS="REPLACEABLE"
>server</VAR
> is
</p></dd>
<dt><span class="term">-s <em class="replaceable"><code>server</code></em></span></dt>
<dd><p>
<em class="replaceable"><code>server</code></em> is
the name or address of the server which matches a
server statement in the configuration file for
<B
CLASS="COMMAND"
>rndc</B
>. If no server is supplied on the
<span><strong class="command">rndc</strong></span>. If no server is supplied on the
command line, the host named by the default-server clause
in the option statement of the configuration file will be
used.
</P
></DD
><DT
>-p <VAR
CLASS="REPLACEABLE"
>port</VAR
></DT
><DD
><P
> Send commands to TCP port
<VAR
CLASS="REPLACEABLE"
>port</VAR
> instead
</p></dd>
<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
<dd><p>
Send commands to TCP port
<em class="replaceable"><code>port</code></em> instead
of BIND 9's default control channel port, 953.
</P
></DD
><DT
>-V</DT
><DD
><P
> Enable verbose logging.
</P
></DD
><DT
>-y <VAR
CLASS="REPLACEABLE"
>keyid</VAR
></DT
><DD
><P
> Use the key <VAR
CLASS="REPLACEABLE"
>keyid</VAR
>
</p></dd>
<dt><span class="term">-V</span></dt>
<dd><p>
Enable verbose logging.
</p></dd>
<dt><span class="term">-y <em class="replaceable"><code>keyid</code></em></span></dt>
<dd><p>
Use the key <em class="replaceable"><code>keyid</code></em>
from the configuration file.
<VAR
CLASS="REPLACEABLE"
>keyid</VAR
> must be
<em class="replaceable"><code>keyid</code></em> must be
known by named with the same algorithm and secret string
in order for control message validation to succeed.
If no <VAR
CLASS="REPLACEABLE"
>keyid</VAR
>
is specified, <B
CLASS="COMMAND"
>rndc</B
> will first look
If no <em class="replaceable"><code>keyid</code></em>
is specified, <span><strong class="command">rndc</strong></span> will first look
for a key clause in the server statement of the server
being used, or if no server statement is present for that
host, then the default-key clause of the options statement.
@ -286,103 +114,43 @@ CLASS="COMMAND"
which are used to send authenticated control commands
to name servers. It should therefore not have general read
or write access.
</P
></DD
></DL
></DIV
><P
> For the complete set of commands supported by <B
CLASS="COMMAND"
>rndc</B
>,
</p></dd>
</dl></div>
<p>
For the complete set of commands supported by <span><strong class="command">rndc</strong></span>,
see the BIND 9 Administrator Reference Manual or run
<B
CLASS="COMMAND"
>rndc</B
> without arguments to see its help message.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN94"
></A
><H2
>LIMITATIONS</H2
><P
> <B
CLASS="COMMAND"
>rndc</B
> does not yet support all the commands of
the BIND 8 <B
CLASS="COMMAND"
>ndc</B
> utility.
</P
><P
> There is currently no way to provide the shared secret for a
<VAR
CLASS="OPTION"
>key_id</VAR
> without using the configuration file.
</P
><P
> Several error messages could be clearer.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN102"
></A
><H2
>SEE ALSO</H2
><P
> <SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>rndc.conf</SPAN
>(5)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>named</SPAN
>(8)</SPAN
>,
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>named.conf</SPAN
>(5)</SPAN
>
<SPAN
CLASS="CITEREFENTRY"
><SPAN
CLASS="REFENTRYTITLE"
>ndc</SPAN
>(8)</SPAN
>,
<I
CLASS="CITETITLE"
>BIND 9 Administrator Reference Manual</I
>.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN118"
></A
><H2
>AUTHOR</H2
><P
> Internet Systems Consortium
</P
></DIV
></BODY
></HTML
>
<span><strong class="command">rndc</strong></span> without arguments to see its help message.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526109"></a><h2>LIMITATIONS</h2>
<p>
<span><strong class="command">rndc</strong></span> does not yet support all the commands of
the BIND 8 <span><strong class="command">ndc</strong></span> utility.
</p>
<p>
There is currently no way to provide the shared secret for a
<code class="option">key_id</code> without using the configuration file.
</p>
<p>
Several error messages could be clearer.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526138"></a><h2>SEE ALSO</h2>
<p>
<span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">named.conf</span>(5)</span>
<span class="citerefentry"><span class="refentrytitle">ndc</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2526190"></a><h2>AUTHOR</h2>
<p>
<span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
</div></body>
</html>

152
contrib/bind9/config.threads.in Normal file
View file

@ -0,0 +1,152 @@
#
# Begin pthreads checking.
#
# First, decide whether to use multithreading or not.
#
# Enable multithreading by default on systems where it is known
# to work well, and where debugging of multithreaded programs
# is supported.
#
AC_MSG_CHECKING(whether to build with thread support)
case $host in
*-dec-osf*)
use_threads=true ;;
[*-solaris2.[0-6]])
# Thread signals are broken on Solaris 2.6; they are sometimes
# delivered to the wrong thread.
use_threads=false ;;
*-solaris*)
use_threads=true ;;
*-ibm-aix*)
use_threads=true ;;
*-hp-hpux10*)
use_threads=false ;;
*-hp-hpux11*)
use_threads=true ;;
*-sgi-irix*)
use_threads=true ;;
*-sco-sysv*uw*|*-*-sysv*UnixWare*)
# UnixWare
use_threads=false ;;
*-*-sysv*OpenUNIX*)
# UnixWare
use_threads=true ;;
*-netbsd*)
if test -r /usr/lib/libpthread.so ; then
use_threads=true
else
# Socket I/O optimizations introduced in 9.2 expose a
# bug in unproven-pthreads; see PR #12650
use_threads=false
fi
;;
*-openbsd*)
# OpenBSD users have reported that named dumps core on
# startup when built with threads.
use_threads=false ;;
*-freebsd*)
use_threads=false ;;
*-bsdi[234]*)
# Thread signals do not work reliably on some versions of BSD/OS.
use_threads=false ;;
*-bsdi5*)
use_threads=true ;;
*-linux*)
# Threads are disabled on Linux by default because most
# Linux kernels produce unusable core dumps from multithreaded
# programs, and because of limitations in setuid().
use_threads=false ;;
*)
use_threads=false ;;
esac
AC_ARG_ENABLE(threads,
[ --enable-threads enable multithreading])
case "$enable_threads" in
yes)
use_threads=true
;;
no)
use_threads=false
;;
'')
# Use system-dependent default
;;
*)
AC_MSG_ERROR([--enable-threads takes yes or no])
;;
esac
if $use_threads
then
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT(no)
fi
if $use_threads
then
#
# Search for / configure pthreads in a system-dependent fashion.
#
case "$host" in
*-netbsd*)
# NetBSD has multiple pthreads implementations. The
# recommended one to use is "unproven-pthreads". The
# older "mit-pthreads" may also work on some NetBSD
# versions. The PTL2 thread library does not
# currently work with bind9, but can be chosen with
# the --with-ptl2 option for those who wish to
# experiment with it.
CC="gcc"
AC_MSG_CHECKING(which NetBSD thread library to use)
AC_ARG_WITH(ptl2,
[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)],
use_ptl2="$withval", use_ptl2="no")
: ${LOCALBASE:=/usr/pkg}
if test "X$use_ptl2" = "Xyes"
then
AC_MSG_RESULT(PTL2)
AC_MSG_WARN(
[linking with PTL2 is highly experimental and not expected to work])
CC=ptlgcc
else
if test -r /usr/lib/libpthread.so
then
AC_MSG_RESULT(native)
LIBS="-lpthread $LIBS"
else
if test ! -d $LOCALBASE/pthreads
then
AC_MSG_RESULT(none)
AC_MSG_ERROR("could not find thread libraries")
fi
if $use_threads
then
AC_MSG_RESULT(mit-pthreads/unproven-pthreads)
pkg="$LOCALBASE/pthreads"
lib1="-L$pkg/lib -Wl,-R$pkg/lib"
lib2="-lpthread -lm -lgcc -lpthread"
LIBS="$lib1 $lib2 $LIBS"
CPPFLAGS="$CPPFLAGS -I$pkg/include"
STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include"
fi
fi
fi
;;
*)
AC_CHECK_LIB(pthread, pthread_create,,
AC_CHECK_LIB(pthread, __pthread_create,,
AC_CHECK_LIB(pthread, __pthread_create_system,,
AC_CHECK_LIB(c_r, pthread_create,,
AC_CHECK_LIB(c, pthread_create,,
AC_MSG_ERROR("could not find thread libraries"))))))
;;
esac
fi

390
contrib/bind9/configure.in
View file

@ -1,4 +1,4 @@
# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 1998-2003 Internet Software Consortium.
#
# Permission to use, copy, modify, and distribute this software for any
@ -18,7 +18,7 @@ AC_DIVERT_PUSH(1)dnl
esyscmd([sed "s/^/# /" COPYRIGHT])dnl
AC_DIVERT_POP()dnl
AC_REVISION($Revision: 1.294.2.23.2.39 $)
AC_REVISION($Revision: 1.294.2.23.2.51 $)
AC_INIT(lib/dns/name.c)
AC_PREREQ(2.13)
@ -261,6 +261,7 @@ AC_TRY_COMPILE(, [
AC_TYPE_SIZE_T
AC_CHECK_TYPE(ssize_t, int)
AC_CHECK_TYPE(uintptr_t,unsigned long)
AC_CHECK_TYPE(socklen_t,
[AC_DEFINE(ISC_SOCKADDR_LEN_T, socklen_t)],
[
@ -608,158 +609,7 @@ esac
#
AC_CHECK_FUNC(arc4random, AC_DEFINE(HAVE_ARC4RANDOM))
#
# Begin pthreads checking.
#
# First, decide whether to use multithreading or not.
#
# Enable multithreading by default on systems where it is known
# to work well, and where debugging of multithreaded programs
# is supported.
#
AC_MSG_CHECKING(whether to build with thread support)
case $host in
*-dec-osf*)
use_threads=true ;;
[*-solaris2.[0-6]])
# Thread signals are broken on Solaris 2.6; they are sometimes
# delivered to the wrong thread.
use_threads=false ;;
*-solaris*)
use_threads=true ;;
*-ibm-aix*)
use_threads=true ;;
*-hp-hpux10*)
use_threads=false ;;
*-hp-hpux11*)
use_threads=true ;;
*-sgi-irix*)
use_threads=true ;;
*-sco-sysv*uw*|*-*-sysv*UnixWare*)
# UnixWare
use_threads=false ;;
*-*-sysv*OpenUNIX*)
# UnixWare
use_threads=true ;;
*-netbsd*)
if test -r /usr/lib/libpthread.so ; then
use_threads=true
else
# Socket I/O optimizations introduced in 9.2 expose a
# bug in unproven-pthreads; see PR #12650
use_threads=false
fi
;;
*-openbsd*)
# OpenBSD users have reported that named dumps core on
# startup when built with threads.
use_threads=false ;;
*-freebsd*)
use_threads=false ;;
*-bsdi[234]*)
# Thread signals do not work reliably on some versions of BSD/OS.
use_threads=false ;;
*-bsdi5*)
use_threads=true ;;
*-linux*)
# Threads are disabled on Linux by default because most
# Linux kernels produce unusable core dumps from multithreaded
# programs, and because of limitations in setuid().
use_threads=false ;;
*)
use_threads=false ;;
esac
AC_ARG_ENABLE(threads,
[ --enable-threads enable multithreading])
case "$enable_threads" in
yes)
use_threads=true
;;
no)
use_threads=false
;;
'')
# Use system-dependent default
;;
*)
AC_MSG_ERROR([--enable-threads takes yes or no])
;;
esac
if $use_threads
then
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT(no)
fi
if $use_threads
then
#
# Search for / configure pthreads in a system-dependent fashion.
#
case "$host" in
*-netbsd*)
# NetBSD has multiple pthreads implementations. The
# recommended one to use is "unproven-pthreads". The
# older "mit-pthreads" may also work on some NetBSD
# versions. The PTL2 thread library does not
# currently work with bind9, but can be chosen with
# the --with-ptl2 option for those who wish to
# experiment with it.
CC="gcc"
AC_MSG_CHECKING(which NetBSD thread library to use)
AC_ARG_WITH(ptl2,
[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)],
use_ptl2="$withval", use_ptl2="no")
: ${LOCALBASE:=/usr/pkg}
if test "X$use_ptl2" = "Xyes"
then
AC_MSG_RESULT(PTL2)
AC_MSG_WARN(
[linking with PTL2 is highly experimental and not expected to work])
CC=ptlgcc
else
if test -r /usr/lib/libpthread.so
then
AC_MSG_RESULT(native)
LIBS="-lpthread $LIBS"
else
if test ! -d $LOCALBASE/pthreads
then
AC_MSG_RESULT(none)
AC_MSG_ERROR("could not find thread libraries")
fi
if $use_threads
then
AC_MSG_RESULT(mit-pthreads/unproven-pthreads)
pkg="$LOCALBASE/pthreads"
lib1="-L$pkg/lib -Wl,-R$pkg/lib"
lib2="-lpthread -lm -lgcc -lpthread"
LIBS="$lib1 $lib2 $LIBS"
CPPFLAGS="$CPPFLAGS -I$pkg/include"
STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include"
fi
fi
fi
;;
*)
AC_CHECK_LIB(pthread, pthread_create,,
AC_CHECK_LIB(pthread, __pthread_create,,
AC_CHECK_LIB(pthread, __pthread_create_system,,
AC_CHECK_LIB(c_r, pthread_create,,
AC_CHECK_LIB(c, pthread_create,,
AC_MSG_ERROR("could not find thread libraries"))))))
;;
esac
fi
sinclude(config.threads.in)dnl
if $use_threads
then
@ -790,7 +640,11 @@ then
*-freebsd*)
AC_CHECK_LIB(c_r, sigwait, AC_DEFINE(HAVE_SIGWAIT),)
case $host in
*-freebsd5.3|*-freebsd5.3.*)
*-freebsd5.[[012]]|*-freebsd5.[[012]].*);;
*-freebsd5.[[3456789]]|*-freebsd5.[[3456789]].*)
AC_DEFINE(NEED_PTHREAD_SCOPE_SYSTEM)
;;
*-freebsd6.*)
AC_DEFINE(NEED_PTHREAD_SCOPE_SYSTEM)
;;
esac
@ -884,7 +738,6 @@ fi
AC_SUBST(ALWAYS_DEFINES)
AC_SUBST(ISC_PLATFORM_USETHREADS)
ISC_THREAD_DIR=$thread_dir
AC_SUBST(ISC_THREAD_DIR)
@ -939,7 +792,7 @@ if test "X$GCC" = "Xyes"; then
STD_CWARNINGS="$STD_CWARNINGS -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat"
case "$host" in
*-hp-hpux*)
LDFLAGS="-Wl,+vnocompatwarnings $LDFALGS"
LDFLAGS="-Wl,+vnocompatwarnings $LDFLAGS"
;;
esac
else
@ -961,11 +814,11 @@ else
;;
*)
# Turn off the pointlessly noisy warnings.
STD_CWARNINGS="+w1 +W 474,530"
STD_CWARNINGS="+w1 +W 474,530,2193,2236"
;;
esac
CCOPT="$CCOPT -Ae -z"
LDFLAGS="-Wl,+vnocompatwarnings $LDFALGS"
LDFLAGS="-Wl,+vnocompatwarnings $LDFLAGS"
MKDEPPROG='cc -Ae -E -Wp,-M >/dev/null 2>>$TMP'
;;
*-sgi-irix*)
@ -1414,6 +1267,10 @@ char a[16],b[64]; return(inet_ntop(AF_INET6, a, b, sizeof(b)) == (char*)0);}],
[AC_MSG_RESULT(no)
ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_ntop.$O"
ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_ntop.c"
ISC_PLATFORM_NEEDNTOP="#define ISC_PLATFORM_NEEDNTOP 1"],
[AC_MSG_RESULT(assuming inet_ntop needed)
ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_ntop.$O"
ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_ntop.c"
ISC_PLATFORM_NEEDNTOP="#define ISC_PLATFORM_NEEDNTOP 1"])
@ -1437,7 +1294,13 @@ main() { char a[16]; return (inet_pton(AF_INET, "1.2.3", a) == 1 ? 1 :
ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_pton.c"
ISC_PLATFORM_NEEDPTON="#define ISC_PLATFORM_NEEDPTON 1"],
[AC_MSG_RESULT(assuming target platform has working inet_pton)
ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"])
ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"],
[AC_MSG_RESULT(assuming inet_pton needed)
ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_pton.$O"
ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_pton.c"
ISC_PLATFORM_NEEDPTON="#define ISC_PLATFORM_NEEDPTON 1"],
[AC_MSG_RESULT(assuming target platform has working inet_pton)
ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"])
AC_MSG_CHECKING([for inet_aton])
AC_TRY_LINK([
@ -1703,9 +1566,15 @@ AC_CHECK_FUNC(memmove,
AC_SUBST(ISC_PLATFORM_NEEDMEMMOVE)
AC_CHECK_FUNC(strtoul,
[ISC_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL"],
[ISC_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1"])
[ISC_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL"
LWRES_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL"
GENRANDOMLIB=""],
[ISC_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1"
LWRES_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1"
"GENRANDOMLIB=${ISCLIBS}"])
AC_SUBST(ISC_PLATFORM_NEEDSTRTOUL)
AC_SUBST(LWRES_PLATFORM_NEEDSTRTOUL)
AC_SUBST(GENRANDOMLIB)
AC_CHECK_FUNC(strlcpy,
[ISC_PLATFORM_NEEDSTRLCPY="#undef ISC_PLATFORM_NEEDSTRLCPY"],
@ -1760,6 +1629,9 @@ AC_SUBST(ISC_EXTRA_SRCS)
# will produce a inconsistant result in the later case. If the compiler
# fails due to seeing "%lld" we fall back to "l".
#
# Digital Unix 4.0 (gcc?) (long long) is 64 bits as is its long. It uses
# %ld even for (long long)/
#
# Win32 uses "%I64d", but that's defined elsewhere since we don't use
# configure on Win32.
#
@ -1776,12 +1648,16 @@ main() {
}
],
[AC_MSG_RESULT(ll)
ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'],
ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'
LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "ll"'],
[AC_MSG_RESULT(l)
ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'],
ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'
LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "l"'],
[AC_MSG_RESULT(assuming target platform uses ll)
ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'])
ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'
LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "ll"'])
AC_SUBST(ISC_PLATFORM_QUADFORMAT)
AC_SUBST(LWRES_PLATFORM_QUADFORMAT)
#
# Security Stuff
@ -1803,6 +1679,15 @@ AC_CHECK_HEADERS(sys/prctl.h)
#
AC_CHECK_FUNC(tzset, AC_DEFINE(HAVE_TZSET))
AC_MSG_CHECKING(for optarg decarartion)
AC_TRY_COMPILE([
#include <unistd.h>
],
[optarg = 0;],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
AC_DEFINE(NEED_OPTARG, 1, [Defined if extern char *optarg is not declared.])])
#
# BSD/OS, and perhaps some others, don't define rlim_t.
#
@ -1843,7 +1728,9 @@ ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE long long int"],
[AC_MSG_ERROR([unable to determine sizeof rlim_cur])
],[AC_MSG_ERROR(this cannot happen)])
],[AC_MSG_ERROR(this cannot happen)])
],[AC_MSG_ERROR(cannot determine type of rlim_cur when cross compiling - define rlim_t)])
],[
ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE long long int"
AC_MSG_RESULT(cannot determine type of rlim_cur when cross compiling - assuming long long int)])
])
AC_SUBST(ISC_PLATFORM_RLIMITTYPE)
@ -1957,31 +1844,51 @@ yes)
esac
AC_SUBST(ISC_PLATFORM_HAVEIFNAMETOINDEX)
#
# The following sets up how non-blocking i/o is established.
# Sunos, cygwin and solaris 2.x (x<5) require special handling.
#
case "$host" in
*-sunos*) AC_DEFINE(PORT_NONBLOCK, O_NDELAY);;
*-cygwin*) AC_DEFINE(PORT_NONBLOCK, O_NDELAY);;
*-solaris2.[[01234]])
AC_DEFINE(PORT_NONBLOCK, O_NONBLOCK)
AC_DEFINE(USE_FIONBIO_IOCTL, 1,
[Defined if you need to use ioctl(FIONBIO) instead a fcntl call to make non-blocking.])
;;
*) AC_DEFINE(PORT_NONBLOCK, O_NONBLOCK,
[Sets which flag to pass to open/fcntl to make non-blocking (O_NDELAY/O_NONBLOCK).])
;;
esac
#
# The following sections deal with tools used for formatting
# the documentation. They are all optional, unless you are
# a developer editing the documentation source.
#
# Directory trees where SGML files are commonly found.
sgmltrees="/usr/pkg/share/sgml /usr/local/share/sgml /usr/share/sgml"
#
# Look for openjade. Plain jade is no longer supported.
#
AC_PATH_PROGS(OPENJADE, openjade, openjade)
AC_SUBST(OPENJADE)
#
# Look for TeX.
#
AC_PATH_PROGS(JADETEX, jadetex, jadetex)
AC_SUBST(JADETEX)
AC_PATH_PROGS(LATEX, latex, latex)
AC_SUBST(LATEX)
AC_PATH_PROGS(PDFJADETEX, pdfjadetex, pdfjadetex)
AC_SUBST(PDFJADETEX)
AC_PATH_PROGS(PDFLATEX, pdflatex, pdflatex)
AC_SUBST(PDFLATEX)
#
# Look for xsltproc (libxslt)
#
AC_PATH_PROG(XSLTPROC, xsltproc, xsltproc)
AC_SUBST(XSLTPROC)
#
# Look for xmllint (libxml2)
#
AC_PATH_PROG(XMLLINT, xmllint, xmllint)
AC_SUBST(XMLLINT)
#
# Subroutine for searching for an ordinary file (e.g., a stylesheet)
@ -2018,74 +1925,60 @@ AC_SUBST($1)
])
#
# Look for the SGML catalog.
# Its location varies, so far we have seen:
# Look for Docbook-XSL stylesheets. Location probably varies by
# system. Guessing where it might be found, based on where SGML stuff
# lives on some systems. FreeBSD is the only one I'm sure of at the
# moment.
#
# NetBSD /usr/pkg/share/sgml/docbook/catalog
# FreeBSD /usr/local/share/sgml/docbook/catalog
# Linux /usr/local/share/dsssl/docbook/catalog
# /usr/share/sgml/docbook/dsssl-stylesheets/catalog
docbook_xsl_trees="/usr/pkg/share/xsl /usr/local/share/xsl /usr/share/xsl"
#
catalogpath=""
for d in $sgmltrees
# Look for stylesheets we need.
#
NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_HTML, docbook/html/docbook.xsl, $docbook_xsl_trees)
NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_XHTML, docbook/xhtml/docbook.xsl, $docbook_xsl_trees)
NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_MAN, docbook/manpages/docbook.xsl, $docbook_xsl_trees)
NOM_PATH_FILE(XSLT_DOCBOOK_CHUNK_HTML, docbook/html/chunk.xsl, $docbook_xsl_trees)
NOM_PATH_FILE(XSLT_DOCBOOK_CHUNK_XHTML, docbook/xhtml/chunk.xsl, $docbook_xsl_trees)
#
# Same dance for db2latex
#
# No idea where this lives except on FreeBSD.
#
db2latex_xsl_trees="/usr/local/share"
#
# Look for stylesheets we need.
#
NOM_PATH_FILE(XSLT_DB2LATEX_STYLE, db2latex/xsl/docbook.xsl, $db2latex_xsl_trees)
#
# Look for "admonition" image directory. Can't use NOM_PATH_FILE()
# because it's a directory, so just do the same things, inline.
#
AC_MSG_CHECKING(for db2latex/xsl/figures)
for d in $db2latex_xsl_trees
do
catalogpath="$catalogpath $d"
for s in docbook/dsssl-stylesheets
do
catalogpath="$catalogpath $d/$s"
done
dd=$d/db2latex/xsl/figures
if test -d $dd
then
XSLT_DB2LATEX_ADMONITIONS=$dd
AC_MSG_RESULT($dd)
break
fi
done
NOM_PATH_FILE(SGMLCATALOG, catalog, $catalogpath)
#
# Look for the HTML stylesheet html/docbook.dsl, used for
# formatting man pages in HTML. Its location varies,
# so far we have seen:
#
# NetBSD /usr/pkg/share/sgml/docbook/dsssl/modular/
# FreeBSD /usr/local/share/sgml/docbook/dsssl/modular/
# Linux /usr/local/share/dsssl/docbook/
# /usr/share/sgml/docbook/dsssl-stylesheets/
#
# Ditto for the print stylesheet print/docbook.dsl.
#
stylepath=""
for d in $sgmltrees
do
for s in docbook/dsssl/modular dsssl/docbook docbook/dsssl-stylesheets
do
stylepath="$stylepath $d/$s"
done
done
NOM_PATH_FILE(HTMLSTYLE, html/docbook.dsl, $stylepath)
NOM_PATH_FILE(PRINTSTYLE, print/docbook.dsl, $stylepath)
#
# Look for XML declarations.
# Its location varies, so far we have seen:
#
# NetBSD /usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/
# FreeBSD /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/
# Linux /usr/local/share/dsssl/docbook/dtds/decls/
# /usr/share/sgml/docbook/dsssl-stylesheets/dtds/decls/
#
xmlpath=""
for d in $sgmltrees
do
for s in docbook/dsssl/modular dsssl/docbook docbook/dsssl-stylesheets
do
xmlpath="$xmlpath $d/$s"
done
done
NOM_PATH_FILE(XMLDCL, dtds/decls/xml.dcl, $xmlpath)
#
# Look for docbook2man-spec.pl
#
NOM_PATH_FILE(DOCBOOK2MANSPEC, docbook2X/docbook2man-spec.pl, $sgmltrees)
if test "X$XSLT_DB2LATEX_ADMONITIONS" = "X"
then
AC_MSG_RESULT(not found)
XSLT_DB2LATEX_ADMONITIONS=db2latex/xsl/figures
fi
AC_SUBST(XSLT_DB2LATEX_ADMONITIONS)
#
# Substitutions
@ -2213,12 +2106,13 @@ AC_OUTPUT(
bin/dnssec/Makefile
doc/Makefile
doc/arm/Makefile
doc/arm/nominum-docbook-html.dsl
doc/arm/nominum-docbook-print.dsl
doc/arm/validate.sh
doc/misc/Makefile
docutil/docbook2man-wrapper.sh
doc/xsl/Makefile
isc-config.sh
doc/xsl/isc-docbook-chunk.xsl
doc/xsl/isc-docbook-html.xsl
doc/xsl/isc-docbook-latex.xsl
doc/xsl/isc-manpage.xsl
)
chmod a+x isc-config.sh

6
contrib/bind9/doc/Makefile.in
View file

@ -1,4 +1,4 @@
# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2000, 2001 Internet Software Consortium.
#
# Permission to use, copy, modify, and distribute this software for any
@ -13,7 +13,7 @@
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.
# $Id: Makefile.in,v 1.4.206.1 2004/03/06 13:16:14 marka Exp $
# $Id: Makefile.in,v 1.4.206.3 2005/09/13 00:34:54 marka Exp $
# This Makefile is a placeholder. It exists merely to make
# sure that its directory gets created in the object directory
@ -23,7 +23,7 @@ srcdir = @srcdir@
VPATH = @srcdir@
top_srcdir = @top_srcdir@
SUBDIRS = arm misc
SUBDIRS = arm misc xsl
TARGETS =
@BIND9_MAKE_RULES@

170
contrib/bind9/doc/arm/Bv9ARM-book.xml
View file

@ -1,24 +1,44 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd">
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- 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.
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.52 2005/02/09 03:48:57 marka Exp $ -->
<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.59 2005/10/10 00:22:24 marka Exp $ -->
<book>
<title>BIND 9 Administrator Reference Manual</title>
<bookinfo>
<copyright>
<year>2004</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000-2003</year>
<holder>Internet Software Consortium</holder>
</copyright>
</bookinfo>
<bookinfo>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Internet Software Consortium.</holder>
</copyright>
</bookinfo>
<chapter id="ch01">
<chapter id="Bv9ARM.ch01">
<title>Introduction </title>
<para>The Internet Domain Name System (<acronym>DNS</acronym>) consists of the syntax
to specify the names of entities in the Internet in a hierarchical
@ -368,7 +388,7 @@ be placed inside a firewall.</para>
</chapter>
<chapter id="ch02"><title><acronym>BIND</acronym> Resource Requirements</title>
<chapter id="Bv9ARM.ch02"><title><acronym>BIND</acronym> Resource Requirements</title>
<sect1>
<title>Hardware requirements</title>
@ -419,7 +439,7 @@ of the BIND 9 source distribution.</para>
</sect1>
</chapter>
<chapter id="ch03">
<chapter id="Bv9ARM.ch03">
<title>Name Server Configuration</title>
<para>In this section we provide some suggested configurations along
with guidelines for their use. We also address the topic of reasonable
@ -667,6 +687,7 @@ of a server.</para>
checks the syntax of a <filename>named.conf</filename> file.</para>
<cmdsynopsis label="Usage">
<command>named-checkconf</command>
<arg>-jvz</arg>
<arg>-t <replaceable>directory</replaceable></arg>
<arg><replaceable>filename</replaceable></arg>
</cmdsynopsis>
@ -734,25 +755,32 @@ of a server.</para>
<listitem><para>Retransfer the given zone from the master.</para></listitem>
</varlistentry>
<varlistentry><term><userinput>freeze <replaceable>zone</replaceable>
<varlistentry> <term><userinput>freeze <optional><replaceable>zone</replaceable>
<optional><replaceable>class</replaceable>
<optional><replaceable>view</replaceable></optional></optional></userinput></term>
<listitem><para>Suspend updates to a dynamic zone. This allows manual
<optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
<listitem><para>Suspend updates to a dynamic zone. If no zone is specified
then all zones are suspended. This allows manual
edits to be made to a zone normally updated by dynamic update. It
also causes changes in the journal file to be synced into the master
and the journal file to be removed. All dynamic update attempts will
be refused while the zone is frozen.</para></listitem>
</varlistentry>
<varlistentry><term><userinput>unfreeze <replaceable>zone</replaceable>
<varlistentry><term><userinput>thaw <optional><replaceable>zone</replaceable>
<optional><replaceable>class</replaceable>
<optional><replaceable>view</replaceable></optional></optional></userinput></term>
<listitem><para>Enable updates to a frozen dynamic zone. This causes
<optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
<listitem><para>Enable updates to a frozen dynamic zone. If no zone is
specified then all frozen zones are enabled. This causes
the server to reload the zone from disk, and re-enables dynamic updates
after the load has completed. After a zone is unfrozen, dynamic updates
after the load has completed. After a zone is thawed, dynamic updates
will no longer be refused.</para></listitem>
</varlistentry>
<varlistentry><term><userinput>notify <replaceable>zone</replaceable>
<optional><replaceable>class</replaceable>
<optional><replaceable>view</replaceable></optional></optional></userinput></term>
<listitem><para>Resend NOTIFY messages for the zone</para></listitem></varlistentry>
<varlistentry><term><userinput>reconfig</userinput></term>
<listitem><para>Reload the configuration file and load new zones,
but do not reload existing zone files even if they have changed.
@ -773,20 +801,21 @@ of a server.</para>
<command>logging</command> section of
<filename>named.conf</filename>.</para></listitem></varlistentry>
<varlistentry><term><userinput>dumpdb</userinput></term>
<listitem><para>Dump the server's caches to the dump file. </para></listitem></varlistentry>
<varlistentry><term><userinput>dumpdb <optional>-all|-cache|-zone</optional> <optional><replaceable>view ...</replaceable></optional></userinput></term>
<listitem><para>Dump the server's caches (default) and / or zones to the
dump file for the specified views. If no view is specified all
views are dumped.</para></listitem></varlistentry>
<varlistentry><term><userinput>stop</userinput></term>
<listitem><para>Stop the server,
making sure any recent changes
<varlistentry><term><userinput>stop <optional>-p</optional></userinput></term>
<listitem><para>Stop the server, making sure any recent changes
made through dynamic update or IXFR are first saved to the master files
of the updated zones.</para></listitem></varlistentry>
of the updated zones. If -p is specified named's process id is returned.</para></listitem></varlistentry>
<varlistentry><term><userinput>halt</userinput></term>
<varlistentry><term><userinput>halt <optional>-p</optional></userinput></term>
<listitem><para>Stop the server immediately. Recent changes
made through dynamic update or IXFR are not saved to the master files,
but will be rolled forward from the journal files when the server
is restarted.</para></listitem></varlistentry>
is restarted. If -p is specified named's process id is returned.</para></listitem></varlistentry>
<varlistentry><term><userinput>trace</userinput></term>
<listitem><para>Increment the servers debugging level by one. </para></listitem></varlistentry>
@ -801,12 +830,20 @@ of a server.</para>
<varlistentry><term><userinput>flush</userinput></term>
<listitem><para>Flushes the server's cache.</para></listitem></varlistentry>
<varlistentry><term><userinput>flushname</userinput> <replaceable>name</replaceable></term>
<listitem><para>Flushes the given name from the server's cache.</para></listitem></varlistentry>
<varlistentry><term><userinput>status</userinput></term>
<listitem><para>Display status of the server.
Note the number of zones includes the internal <command>bind/CH</command> zone
and the default <command>./IN</command> hint zone if there is not a
explicit root zone configured.</para></listitem></varlistentry>
<varlistentry><term><userinput>recursing</userinput></term>
<listitem><para>Dump the list of queries named is currently recursing
on.
</para></listitem></varlistentry>
</variablelist>
<para>In <acronym>BIND</acronym> 9.2, <command>rndc</command>
@ -957,7 +994,7 @@ reload the database. </para></entry>
</sect1>
</chapter>
<chapter id="ch04">
<chapter id="Bv9ARM.ch04">
<title>Advanced DNS Features</title>
<sect1 id="notify">
@ -1004,7 +1041,7 @@ protocol is specified in RFC 1996.
<para>All changes made to a zone using dynamic update are stored in the
zone's journal file. This file is automatically created by the
server when when the first dynamic update takes place. The name of
server when the first dynamic update takes place. The name of
the journal file is formed by appending the
extension <filename>.jnl</filename> to the
name of the corresponding zone file. The journal file is in a
@ -1123,7 +1160,7 @@ to those internal hosts. With the wildcard records, the mail will
be delivered to the bastion host, which can then forward it on to
internal hosts.</para>
<para>Here's an example of a wildcard MX record:</para>
<programlisting><literal>* IN MX 10 external1.example.com.</literal></programlisting>
<programlisting>* IN MX 10 external1.example.com.</programlisting>
<para>Now that they accept mail on behalf of anything in the internal
network, the bastion hosts will need to know how to deliver mail
to internal hosts. In order for this to work properly, the resolvers on
@ -1620,7 +1657,7 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
</sect1>
</chapter>
<chapter id="ch05"><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title>
<chapter id="Bv9ARM.ch05"><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title>
<sect1><title>The Lightweight Resolver Library</title>
<para>Traditionally applications have been linked with a stub resolver
library that sends recursive DNS queries to a local caching name
@ -1666,7 +1703,7 @@ be configured to act as a lightweight resolver daemon using the
</sect1></chapter>
<chapter id="ch06"><title><acronym>BIND</acronym> 9 Configuration Reference</title>
<chapter id="Bv9ARM.ch06"><title><acronym>BIND</acronym> 9 Configuration Reference</title>
<para><acronym>BIND</acronym> 9 configuration is broadly similar
to <acronym>BIND</acronym> 8; however, there are a few new areas
@ -1831,7 +1868,7 @@ which constitute an address match list can be any of the following:</para>
<listitem>
<simpara>a key ID, as defined by the <command>key</command> statement</simpara></listitem>
<listitem>
<simpara>the name of an address match list previously defined with
<simpara>the name of an address match list defined with
the <command>acl</command> statement</simpara></listitem>
<listitem>
<simpara>a nested address match list enclosed in braces</simpara></listitem></itemizedlist>
@ -2181,7 +2218,7 @@ installed.
<para>
To disable the command channel, use an empty <command>controls</command>
statement: <command>controls { };</command>.
statement: <command>controls { };</command>.
</para>
</sect2>
@ -2591,9 +2628,10 @@ The query log entry reports the client's IP address and port number. The
query name, class and type. It also reports whether the Recursion Desired
flag was set (+ if set, - if not set), EDNS was in use (E) or if the
query was signed (S).</para>
<programlisting><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
<computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
</programlisting>
<para><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
</para>
<para><computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
</para>
</entry>
</row>
<row rowsep = "0">
@ -2724,7 +2762,7 @@ statement in the <filename>named.conf</filename> file:</para>
<optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional>
<optional> dnssec-must-be-secure <replaceable>domain yes_or_no</replaceable>; </optional>
<optional> forward ( <replaceable>only</replaceable> | <replaceable>first</replaceable> ); </optional>
<optional> forwarders { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
<optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
<optional> dual-stack-servers <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>domain_name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ) ; ... }; </optional>
<optional> check-names ( <replaceable>master</replaceable> | <replaceable>slave</replaceable> | <replaceable>response</replaceable> )( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
<optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
@ -2958,7 +2996,7 @@ record does) the DNSKEY RRset is deemed to be trusted.
<varlistentry><term><command>dnssec-must-be-secure</command></term>
<listitem><para>
Specify heirachies which must / may not be secure (signed and validated).
Specify heirarchies which must / may not be secure (signed and validated).
If <userinput>yes</userinput> then named will only accept answers if they
are secure.
If <userinput>no</userinput> then normal dnssec validation applies
@ -3714,11 +3752,25 @@ in the configuration file.</para>
except zone transfers are performed using IPv6.</para>
</listitem></varlistentry>
<varlistentry><term><command>alt-transfer-source</command></term>
<listitem><para>An alternate transfer source if the one listed in
<command>transfer-source</command> fails and
<command>use-alt-transfer-source</command> is set.</para>
</listitem></varlistentry>
<varlistentry>
<term><command>alt-transfer-source</command></term>
<listitem>
<para>
An alternate transfer source if the one listed in
<command>transfer-source</command> fails and
<command>use-alt-transfer-source</command> is
set.
</para>
<note>
If you do not wish the alternate transfer source
to be used you should set
<command>use-alt-transfer-source</command>
appropriately and you should not depend upon
getting a answer back to the first refresh
query.
</note>
</listitem>
</varlistentry>
<varlistentry><term><command>alt-transfer-source-v6</command></term>
<listitem><para>An alternate transfer source if the one listed in
@ -4553,7 +4605,7 @@ Statement Grammar</title>
<optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
<optional> file <replaceable>string</replaceable> ; </optional>
<optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
<optional> forwarders { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
<optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
<optional> ixfr-base <replaceable>string</replaceable> ; </optional>
<optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
<optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
@ -5539,10 +5591,10 @@ be appended to any unqualified records. When a zone is first read
in there is an implicit <command>$ORIGIN</command> &#60;<varname>zone-name</varname>><command>.</command> The
current <command>$ORIGIN</command> is appended to the domain specified
in the <command>$ORIGIN</command> argument if it is not absolute.</para>
<programlisting><literal>$ORIGIN example.com.
WWW CNAME MAIN-SERVER</literal></programlisting>
<programlisting>$ORIGIN example.com.
WWW CNAME MAIN-SERVER</programlisting>
<para>is equivalent to</para>
<programlisting><literal>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</literal></programlisting></sect3>
<programlisting>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</programlisting></sect3>
<sect3><title>The <command>$INCLUDE</command> Directive</title>
<para>Syntax: <command>$INCLUDE</command>
<replaceable>filename</replaceable> <optional>
@ -5576,17 +5628,17 @@ resource records that only differ from each other by an iterator. <command>$GENE
be used to easily generate the sets of records required to support
sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA
delegation.</para>
<programlisting><literal>$ORIGIN 0.0.192.IN-ADDR.ARPA.
<programlisting>$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
$GENERATE 1-127 $ CNAME $.0</literal></programlisting>
$GENERATE 1-127 $ CNAME $.0</programlisting>
<para>is equivalent to</para>
<programlisting><literal>0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
<programlisting>0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
...
127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
</literal></programlisting>
</programlisting>
<informaltable colsep = "0" rowsep = "0">
<tgroup cols = "2" colsep = "0" rowsep = "0" tgroupstyle = "3Level-table">
<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/>
@ -5655,7 +5707,7 @@ and not part of the standard zone file format.</para>
</sect2>
</sect1>
</chapter>
<chapter id="ch07"><title><acronym>BIND</acronym> 9 Security Considerations</title>
<chapter id="Bv9ARM.ch07"><title><acronym>BIND</acronym> 9 Security Considerations</title>
<sect1 id="Access_Control_Lists"><title>Access Control Lists</title>
<para>Access Control Lists (ACLs), are address match lists that
you can set up and nickname for future use in <command>allow-notify</command>,
@ -5778,7 +5830,7 @@ all.</para>
</sect1></chapter>
<chapter id="ch08">
<chapter id="Bv9ARM.ch08">
<title>Troubleshooting</title>
<sect1>
<title>Common Problems</title>
@ -5837,7 +5889,7 @@ all.</para>
to read more.</para>
</sect1>
</chapter>
<appendix id="ch09">
<appendix id="Bv9ARM.ch09">
<title>Appendices</title>
<sect1>
<title>Acknowledgments</title>

1377
contrib/bind9/doc/arm/Bv9ARM.ch01.html
View file

File diff suppressed because it is too large Load diff

372
contrib/bind9/doc/arm/Bv9ARM.ch02.html
View file

@ -1,198 +1,95 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>BIND Resource Requirements</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
REL="PREVIOUS"
TITLE="Introduction "
HREF="Bv9ARM.ch01.html"><LINK
REL="NEXT"
TITLE="Name Server Configuration"
HREF="Bv9ARM.ch03.html"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>BIND 9 Administrator Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch01.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch03.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="ch02"
></A
>Chapter 2. <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> Resource Requirements</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>2.1. <A
HREF="Bv9ARM.ch02.html#AEN228"
>Hardware requirements</A
></DT
><DT
>2.2. <A
HREF="Bv9ARM.ch02.html#AEN236"
>CPU Requirements</A
></DT
><DT
>2.3. <A
HREF="Bv9ARM.ch02.html#AEN240"
>Memory Requirements</A
></DT
><DT
>2.4. <A
HREF="Bv9ARM.ch02.html#AEN245"
>Name Server Intensive Environment Issues</A
></DT
><DT
>2.5. <A
HREF="Bv9ARM.ch02.html#AEN248"
>Supported Operating Systems</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN228"
>2.1. Hardware requirements</A
></H1
><P
><ACRONYM
CLASS="acronym"
>DNS</ACRONYM
> hardware requirements have traditionally been quite modest.
<!--
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- 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.
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: Bv9ARM.ch02.html,v 1.10.2.1.8.8 2005/10/13 02:33:59 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 2. BIND Resource Requirements</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="prev" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction ">
<link rel="next" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Chapter 2. <span class="acronym">BIND</span> Resource Requirements</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="chapter" lang="en">
<div class="titlepage"><div><div><h2 class="title">
<a name="Bv9ARM.ch02"></a>Chapter 2. <span class="acronym">BIND</span> Resource Requirements</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547108">Hardware requirements</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547132">CPU Requirements</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547143">Memory Requirements</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547158">Name Server Intensive Environment Issues</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547303">Supported Operating Systems</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2547108"></a>Hardware requirements</h2></div></div></div>
<p><span class="acronym">DNS</span> hardware requirements have traditionally been quite modest.
For many installations, servers that have been pensioned off from
active duty have performed admirably as <ACRONYM
CLASS="acronym"
>DNS</ACRONYM
> servers.</P
><P
>The DNSSEC and IPv6 features of <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 may prove to be quite
active duty have performed admirably as <span class="acronym">DNS</span> servers.</p>
<p>The DNSSEC and IPv6 features of <span class="acronym">BIND</span> 9 may prove to be quite
CPU intensive however, so organizations that make heavy use of these
features may wish to consider larger systems for these applications.
<ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 is fully multithreaded, allowing full utilization of
multiprocessor systems for installations that need it.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN236"
>2.2. CPU Requirements</A
></H1
><P
>CPU requirements for <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 range from i486-class machines
<span class="acronym">BIND</span> 9 is fully multithreaded, allowing full utilization of
multiprocessor systems for installations that need it.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2547132"></a>CPU Requirements</h2></div></div></div>
<p>CPU requirements for <span class="acronym">BIND</span> 9 range from i486-class machines
for serving of static zones without caching, to enterprise-class
machines if you intend to process many dynamic updates and DNSSEC
signed zones, serving many thousands of queries per second.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN240"
>2.3. Memory Requirements</A
></H1
><P
>The memory of the server has to be large enough to fit the
cache and zones loaded off disk. The <B
CLASS="command"
>max-cache-size</B
>
signed zones, serving many thousands of queries per second.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2547143"></a>Memory Requirements</h2></div></div></div>
<p>The memory of the server has to be large enough to fit the
cache and zones loaded off disk. The <span><strong class="command">max-cache-size</strong></span>
option can be used to limit the amount of memory used by the cache,
at the expense of reducing cache hit rates and causing more <ACRONYM
CLASS="acronym"
>DNS</ACRONYM
>
at the expense of reducing cache hit rates and causing more <span class="acronym">DNS</span>
traffic. It is still good practice to have enough memory to load
all zone and cache data into memory &#8212; unfortunately, the best way
to determine this for a given installation is to watch the name server
in operation. After a few weeks the server process should reach
a relatively stable size where entries are expiring from the cache as
fast as they are being inserted.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN245"
>2.4. Name Server Intensive Environment Issues</A
></H1
><P
>For name server intensive environments, there are two alternative
fast as they are being inserted.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2547158"></a>Name Server Intensive Environment Issues</h2></div></div></div>
<p>For name server intensive environments, there are two alternative
configurations that may be used. The first is where clients and
any second-level internal name servers query a main name server, which
has enough memory to build a large cache. This approach minimizes
@ -201,84 +98,33 @@ is to set up second-level internal name servers to make queries independently.
In this configuration, none of the individual machines needs to
have as much memory or CPU power as in the first alternative, but
this has the disadvantage of making many more external queries,
as none of the name servers share their cached data.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN248"
>2.5. Supported Operating Systems</A
></H1
><P
>ISC <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 compiles and runs on a large number
as none of the name servers share their cached data.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2547303"></a>Supported Operating Systems</h2></div></div></div>
<p>ISC <span class="acronym">BIND</span> 9 compiles and runs on a large number
of Unix-like operating system and on Windows NT / 2000. For an up-to-date
list of supported systems, see the README file in the top level directory
of the BIND 9 source distribution.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="Bv9ARM.ch01.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="Bv9ARM.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="Bv9ARM.ch03.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Introduction</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Name Server Configuration</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
of the BIND 9 source distribution.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
<td width="20%" align="center"> </td>
<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Chapter 1. Introduction  </td>
<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
<td width="40%" align="right" valign="top"> Chapter 3. Name Server Configuration</td>
</tr>
</table>
</div>
</body>
</html>

1794
contrib/bind9/doc/arm/Bv9ARM.ch03.html
View file

File diff suppressed because it is too large Load diff

1846
contrib/bind9/doc/arm/Bv9ARM.ch04.html
View file

File diff suppressed because it is too large Load diff

352
contrib/bind9/doc/arm/Bv9ARM.ch05.html
View file

@ -1,265 +1,115 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>The BIND 9 Lightweight Resolver</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
REL="PREVIOUS"
TITLE="Advanced DNS Features"
HREF="Bv9ARM.ch04.html"><LINK
REL="NEXT"
TITLE="BIND 9 Configuration Reference"
HREF="Bv9ARM.ch06.html"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>BIND 9 Administrator Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch04.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch06.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="ch05"
></A
>Chapter 5. The <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 Lightweight Resolver</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>5.1. <A
HREF="Bv9ARM.ch05.html#AEN1044"
>The Lightweight Resolver Library</A
></DT
><DT
>5.2. <A
HREF="Bv9ARM.ch05.html#lwresd"
>Running a Resolver Daemon</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN1044"
>5.1. The Lightweight Resolver Library</A
></H1
><P
>Traditionally applications have been linked with a stub resolver
<!--
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- 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.
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: Bv9ARM.ch05.html,v 1.24.2.5.2.12 2005/10/13 02:34:00 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 5. The BIND 9 Lightweight Resolver</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="prev" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
<link rel="next" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="chapter" lang="en">
<div class="titlepage"><div><div><h2 class="title">
<a name="Bv9ARM.ch05"></a>Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2550652">The Lightweight Resolver Library</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2550652"></a>The Lightweight Resolver Library</h2></div></div></div>
<p>Traditionally applications have been linked with a stub resolver
library that sends recursive DNS queries to a local caching name
server.</P
><P
>IPv6 once introduced new complexity into the resolution process,
server.</p>
<p>IPv6 once introduced new complexity into the resolution process,
such as following A6 chains and DNAME records, and simultaneous
lookup of IPv4 and IPv6 addresses. Though most of the complexity was
then removed, these are hard or impossible
to implement in a traditional stub resolver.</P
><P
>Instead, <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 provides resolution services to local clients
to implement in a traditional stub resolver.</p>
<p>Instead, <span class="acronym">BIND</span> 9 provides resolution services to local clients
using a combination of a lightweight resolver library and a resolver
daemon process running on the local host. These communicate using
a simple UDP-based protocol, the "lightweight resolver protocol"
that is distinct from and simpler than the full DNS protocol.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="lwresd"
>5.2. Running a Resolver Daemon</A
></H1
><P
>To use the lightweight resolver interface, the system must
run the resolver daemon <B
CLASS="command"
>lwresd</B
> or a local
name server configured with a <B
CLASS="command"
>lwres</B
> statement.</P
><P
>By default, applications using the lightweight resolver library will make
that is distinct from and simpler than the full DNS protocol.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="lwresd"></a>Running a Resolver Daemon</h2></div></div></div>
<p>To use the lightweight resolver interface, the system must
run the resolver daemon <span><strong class="command">lwresd</strong></span> or a local
name server configured with a <span><strong class="command">lwres</strong></span> statement.</p>
<p>By default, applications using the lightweight resolver library will make
UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. The
address can be overridden by <B
CLASS="command"
>lwserver</B
> lines in
<TT
CLASS="filename"
>/etc/resolv.conf</TT
>.</P
><P
>The daemon currently only looks in the DNS, but in the future
it may use other sources such as <TT
CLASS="filename"
>/etc/hosts</TT
>,
NIS, etc.</P
><P
>The <B
CLASS="command"
>lwresd</B
> daemon is essentially a
address can be overridden by <span><strong class="command">lwserver</strong></span> lines in
<code class="filename">/etc/resolv.conf</code>.</p>
<p>The daemon currently only looks in the DNS, but in the future
it may use other sources such as <code class="filename">/etc/hosts</code>,
NIS, etc.</p>
<p>The <span><strong class="command">lwresd</strong></span> daemon is essentially a
caching-only name server that responds to requests using the lightweight
resolver protocol rather than the DNS protocol. Because it needs
to run on each host, it is designed to require no or minimal configuration.
Unless configured otherwise, it uses the name servers listed on
<B
CLASS="command"
>nameserver</B
> lines in <TT
CLASS="filename"
>/etc/resolv.conf</TT
>
<span><strong class="command">nameserver</strong></span> lines in <code class="filename">/etc/resolv.conf</code>
as forwarders, but is also capable of doing the resolution autonomously if
none are specified.</P
><P
>The <B
CLASS="command"
>lwresd</B
> daemon may also be configured with a
<TT
CLASS="filename"
>named.conf</TT
> style configuration file, in
<TT
CLASS="filename"
>/etc/lwresd.conf</TT
> by default. A name server may also
none are specified.</p>
<p>The <span><strong class="command">lwresd</strong></span> daemon may also be configured with a
<code class="filename">named.conf</code> style configuration file, in
<code class="filename">/etc/lwresd.conf</code> by default. A name server may also
be configured to act as a lightweight resolver daemon using the
<B
CLASS="command"
>lwres</B
> statement in <TT
CLASS="filename"
>named.conf</TT
>.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="Bv9ARM.ch04.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="Bv9ARM.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="Bv9ARM.ch06.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Advanced DNS Features</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 Configuration Reference</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
<span><strong class="command">lwres</strong></span> statement in <code class="filename">named.conf</code>.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
<td width="20%" align="center"> </td>
<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Chapter 4. Advanced DNS Features </td>
<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
<td width="40%" align="right" valign="top"> Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</td>
</tr>
</table>
</div>
</body>
</html>

13727
contrib/bind9/doc/arm/Bv9ARM.ch06.html
View file

File diff suppressed because it is too large Load diff

616
contrib/bind9/doc/arm/Bv9ARM.ch07.html
View file

@ -1,160 +1,78 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>BIND 9 Security Considerations</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
REL="PREVIOUS"
TITLE="BIND 9 Configuration Reference"
HREF="Bv9ARM.ch06.html"><LINK
REL="NEXT"
TITLE="Troubleshooting"
HREF="Bv9ARM.ch08.html"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>BIND 9 Administrator Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch06.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch08.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="ch07"
></A
>Chapter 7. <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 Security Considerations</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>7.1. <A
HREF="Bv9ARM.ch07.html#Access_Control_Lists"
>Access Control Lists</A
></DT
><DT
>7.2. <A
HREF="Bv9ARM.ch07.html#AEN4693"
><B
CLASS="command"
>chroot</B
> and <B
CLASS="command"
>setuid</B
> (for
UNIX servers)</A
></DT
><DT
>7.3. <A
HREF="Bv9ARM.ch07.html#dynamic_update_security"
>Dynamic Update Security</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="Access_Control_Lists"
>7.1. Access Control Lists</A
></H1
><P
>Access Control Lists (ACLs), are address match lists that
you can set up and nickname for future use in <B
CLASS="command"
>allow-notify</B
>,
<B
CLASS="command"
>allow-query</B
>, <B
CLASS="command"
>allow-recursion</B
>,
<B
CLASS="command"
>blackhole</B
>, <B
CLASS="command"
>allow-transfer</B
>,
etc.</P
><P
>Using ACLs allows you to have finer control over who can access
<!--
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- 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.
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: Bv9ARM.ch07.html,v 1.50.2.9.2.24 2005/10/13 02:34:02 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 7. BIND 9 Security Considerations</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="prev" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
<link rel="next" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="chapter" lang="en">
<div class="titlepage"><div><div><h2 class="title">
<a name="Bv9ARM.ch07"></a>Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2567222"><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
UNIX servers)</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567366">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567424">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="Access_Control_Lists"></a>Access Control Lists</h2></div></div></div>
<p>Access Control Lists (ACLs), are address match lists that
you can set up and nickname for future use in <span><strong class="command">allow-notify</strong></span>,
<span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-recursion</strong></span>,
<span><strong class="command">blackhole</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
etc.</p>
<p>Using ACLs allows you to have finer control over who can access
your name server, without cluttering up your config files with huge
lists of IP addresses.</P
><P
>It is a <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>good idea</I
></SPAN
> to use ACLs, and to
lists of IP addresses.</p>
<p>It is a <span class="emphasis"><em>good idea</em></span> to use ACLs, and to
control access to your server. Limiting access to your server by
outside parties can help prevent spoofing and DoS attacks against
your server.</P
><P
>Here is an example of how to properly apply ACLs:</P
><PRE
CLASS="programlisting"
>&#13;// Set up an ACL named "bogusnets" that will block RFC1918 space,
your server.</p>
<p>Here is an example of how to properly apply ACLs:</p>
<pre class="programlisting">
// Set up an ACL named "bogusnets" that will block RFC1918 space,
// which is commonly used in spoofing attacks.
acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
// Set up an ACL called our-nets. Replace this with the real IP numbers.
@ -173,328 +91,110 @@ zone "example.com" {
file "m/example.com";
allow-query { any; };
};
</PRE
><P
>This allows recursive queries of the server from the outside
unless recursion has been previously disabled.</P
><P
>For more information on how to use ACLs to protect your server,
see the <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>AUSCERT</I
></SPAN
> advisory at
<A
HREF="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos"
TARGET="_top"
>ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</A
></P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN4693"
>7.2. <B
CLASS="command"
>chroot</B
> and <B
CLASS="command"
>setuid</B
> (for
UNIX servers)</A
></H1
><P
>On UNIX servers, it is possible to run <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> in a <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>chrooted</I
></SPAN
> environment
(<B
CLASS="command"
>chroot()</B
>) by specifying the "<VAR
CLASS="option"
>-t</VAR
>"
option. This can help improve system security by placing <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> in
a "sandbox", which will limit the damage done if a server is compromised.</P
><P
>Another useful feature in the UNIX version of <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> is the
ability to run the daemon as an unprivileged user ( <VAR
CLASS="option"
>-u</VAR
> <VAR
CLASS="replaceable"
>user</VAR
> ).
We suggest running as an unprivileged user when using the <B
CLASS="command"
>chroot</B
> feature.</P
><P
>Here is an example command line to load <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> in a <B
CLASS="command"
>chroot()</B
> sandbox,
<B
CLASS="command"
>/var/named</B
>, and to run <B
CLASS="command"
>named</B
> <B
CLASS="command"
>setuid</B
> to
user 202:</P
><P
><KBD
CLASS="userinput"
>/usr/local/bin/named -u 202 -t /var/named</KBD
></P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN4716"
>7.2.1. The <B
CLASS="command"
>chroot</B
> Environment</A
></H2
><P
>In order for a <B
CLASS="command"
>chroot()</B
> environment to
</pre>
<p>This allows recursive queries of the server from the outside
unless recursion has been previously disabled.</p>
<p>For more information on how to use ACLs to protect your server,
see the <span class="emphasis"><em>AUSCERT</em></span> advisory at
<a href="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos" target="_top">ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</a></p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2567222"></a><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
UNIX servers)</h2></div></div></div>
<p>On UNIX servers, it is possible to run <span class="acronym">BIND</span> in a <span class="emphasis"><em>chrooted</em></span> environment
(<span><strong class="command">chroot()</strong></span>) by specifying the "<code class="option">-t</code>"
option. This can help improve system security by placing <span class="acronym">BIND</span> in
a "sandbox", which will limit the damage done if a server is compromised.</p>
<p>Another useful feature in the UNIX version of <span class="acronym">BIND</span> is the
ability to run the daemon as an unprivileged user ( <code class="option">-u</code> <em class="replaceable"><code>user</code></em> ).
We suggest running as an unprivileged user when using the <span><strong class="command">chroot</strong></span> feature.</p>
<p>Here is an example command line to load <span class="acronym">BIND</span> in a <span><strong class="command">chroot()</strong></span> sandbox,
<span><strong class="command">/var/named</strong></span>, and to run <span><strong class="command">named</strong></span> <span><strong class="command">setuid</strong></span> to
user 202:</p>
<p><strong class="userinput"><code>/usr/local/bin/named -u 202 -t /var/named</code></strong></p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="id2567366"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
<p>In order for a <span><strong class="command">chroot()</strong></span> environment to
work properly in a particular directory
(for example, <TT
CLASS="filename"
>/var/named</TT
>),
(for example, <code class="filename">/var/named</code>),
you will need to set up an environment that includes everything
<ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> needs to run.
From <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
>'s point of view, <TT
CLASS="filename"
>/var/named</TT
> is
<span class="acronym">BIND</span> needs to run.
From <span class="acronym">BIND</span>'s point of view, <code class="filename">/var/named</code> is
the root of the filesystem. You will need to adjust the values of options like
like <B
CLASS="command"
>directory</B
> and <B
CLASS="command"
>pid-file</B
> to account
like <span><strong class="command">directory</strong></span> and <span><strong class="command">pid-file</strong></span> to account
for this.
</P
><P
>&#13;Unlike with earlier versions of BIND, you will typically
<SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>not</I
></SPAN
> need to compile <B
CLASS="command"
>named</B
>
</p>
<p>
Unlike with earlier versions of BIND, you will typically
<span class="emphasis"><em>not</em></span> need to compile <span><strong class="command">named</strong></span>
statically nor install shared libraries under the new root.
However, depending on your operating system, you may need
to set up things like
<TT
CLASS="filename"
>/dev/zero</TT
>,
<TT
CLASS="filename"
>/dev/random</TT
>,
<TT
CLASS="filename"
>/dev/log</TT
>, and/or
<TT
CLASS="filename"
>/etc/localtime</TT
>.
</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN4734"
>7.2.2. Using the <B
CLASS="command"
>setuid</B
> Function</A
></H2
><P
>Prior to running the <B
CLASS="command"
>named</B
> daemon, use
the <B
CLASS="command"
>touch</B
> utility (to change file access and
modification times) or the <B
CLASS="command"
>chown</B
> utility (to
<code class="filename">/dev/zero</code>,
<code class="filename">/dev/random</code>,
<code class="filename">/dev/log</code>, and/or
<code class="filename">/etc/localtime</code>.
</p>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="id2567424"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
<p>Prior to running the <span><strong class="command">named</strong></span> daemon, use
the <span><strong class="command">touch</strong></span> utility (to change file access and
modification times) or the <span><strong class="command">chown</strong></span> utility (to
set the user id and/or group id) on files
to which you want <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
>
to write. Note that if the <B
CLASS="command"
>named</B
> daemon is running as an
to which you want <span class="acronym">BIND</span>
to write. Note that if the <span><strong class="command">named</strong></span> daemon is running as an
unprivileged user, it will not be able to bind to new restricted ports if the
server is reloaded.</P
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="dynamic_update_security"
>7.3. Dynamic Update Security</A
></H1
><P
>Access to the dynamic
server is reloaded.</p>
</div>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="dynamic_update_security"></a>Dynamic Update Security</h2></div></div></div>
<p>Access to the dynamic
update facility should be strictly limited. In earlier versions of
<ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> the only way to do this was based on the IP
<span class="acronym">BIND</span> the only way to do this was based on the IP
address of the host requesting the update, by listing an IP address or
network prefix in the <B
CLASS="command"
>allow-update</B
> zone option.
network prefix in the <span><strong class="command">allow-update</strong></span> zone option.
This method is insecure since the source address of the update UDP packet
is easily forged. Also note that if the IP addresses allowed by the
<B
CLASS="command"
>allow-update</B
> option include the address of a slave
<span><strong class="command">allow-update</strong></span> option include the address of a slave
server which performs forwarding of dynamic updates, the master can be
trivially attacked by sending the update to the slave, which will
forward it to the master with its own source IP address causing the
master to approve it without question.</P
><P
>For these reasons, we strongly recommend that updates be
master to approve it without question.</p>
<p>For these reasons, we strongly recommend that updates be
cryptographically authenticated by means of transaction signatures
(TSIG). That is, the <B
CLASS="command"
>allow-update</B
> option should
(TSIG). That is, the <span><strong class="command">allow-update</strong></span> option should
list only TSIG key names, not IP addresses or network
prefixes. Alternatively, the new <B
CLASS="command"
>update-policy</B
>
option can be used.</P
><P
>Some sites choose to keep all dynamically updated DNS data
prefixes. Alternatively, the new <span><strong class="command">update-policy</strong></span>
option can be used.</p>
<p>Some sites choose to keep all dynamically updated DNS data
in a subdomain and delegate that subdomain to a separate zone. This
way, the top-level zone containing critical data such as the IP addresses
of public web and mail servers need not allow dynamic update at
all.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="Bv9ARM.ch06.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="Bv9ARM.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="Bv9ARM.ch08.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 Configuration Reference</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Troubleshooting</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
all.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
<td width="20%" align="center"> </td>
<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference </td>
<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
<td width="40%" align="right" valign="top"> Chapter 8. Troubleshooting</td>
</tr>
</table>
</div>
</body>
</html>

360
contrib/bind9/doc/arm/Bv9ARM.ch08.html
View file

@ -1,135 +1,73 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Troubleshooting</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="BIND 9 Administrator Reference Manual"
HREF="Bv9ARM.html"><LINK
REL="PREVIOUS"
TITLE="BIND 9 Security Considerations"
HREF="Bv9ARM.ch07.html"><LINK
REL="NEXT"
TITLE="Appendices"
HREF="Bv9ARM.ch09.html"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>BIND 9 Administrator Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch07.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch09.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="ch08"
></A
>Chapter 8. Troubleshooting</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>8.1. <A
HREF="Bv9ARM.ch08.html#AEN4755"
>Common Problems</A
></DT
><DT
>8.2. <A
HREF="Bv9ARM.ch08.html#AEN4760"
>Incrementing and Changing the Serial Number</A
></DT
><DT
>8.3. <A
HREF="Bv9ARM.ch08.html#AEN4765"
>Where Can I Get Help?</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN4755"
>8.1. Common Problems</A
></H1
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN4757"
>8.1.1. It's not working; how can I figure out what's wrong?</A
></H2
><P
>The best solution to solving installation and
<!--
- Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- 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.
-
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- AND FITNESS. IN NO EVENT SHALL ISC 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.
-->
<!-- $Id: Bv9ARM.ch08.html,v 1.50.2.9.2.24 2005/10/13 02:34:02 marka Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 8. Troubleshooting</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="prev" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
<link rel="next" href="Bv9ARM.ch09.html" title="Appendix A. Appendices">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Chapter 8. Troubleshooting</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="chapter" lang="en">
<div class="titlepage"><div><div><h2 class="title">
<a name="Bv9ARM.ch08"></a>Chapter 8. Troubleshooting</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567630">Common Problems</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2567636">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567648">Incrementing and Changing the Serial Number</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567665">Where Can I Get Help?</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2567630"></a>Common Problems</h2></div></div></div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="id2567636"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
<p>The best solution to solving installation and
configuration issues is to take preventative measures by setting
up logging files beforehand. The log files provide a
source of hints and information that can be used to figure out
what went wrong and how to fix the problem.</P
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN4760"
>8.2. Incrementing and Changing the Serial Number</A
></H1
><P
>Zone serial numbers are just numbers-they aren't date
what went wrong and how to fix the problem.</p>
</div>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2567648"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
<p>Zone serial numbers are just numbers-they aren't date
related. A lot of people set them to a number that represents a
date, usually of the form YYYYMMDDRR. A number of people have been
testing these numbers for Y2K compliance and have set the number
@ -138,135 +76,49 @@ NAME="AEN4760"
numbers are used to indicate that a zone has been updated. If the
serial number on the slave server is lower than the serial number
on the master, the slave server will attempt to update its copy of
the zone.</P
><P
>Setting the serial number to a lower number on the master
the zone.</p>
<p>Setting the serial number to a lower number on the master
server than the slave server means that the slave will not perform
updates to its copy of the zone.</P
><P
>The solution to this is to add 2147483647 (2^31-1) to the
updates to its copy of the zone.</p>
<p>The solution to this is to add 2147483647 (2^31-1) to the
number, reload the zone and make sure all slaves have updated to
the new zone serial number, then reset the number to what you want
it to be, and reload the zone again.</P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN4765"
>8.3. Where Can I Get Help?</A
></H1
><P
>The Internet Software Consortium (<ACRONYM
CLASS="acronym"
>ISC</ACRONYM
>) offers a wide range
of support and service agreements for <ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> and <ACRONYM
CLASS="acronym"
>DHCP</ACRONYM
> servers. Four
it to be, and reload the zone again.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2567665"></a>Where Can I Get Help?</h2></div></div></div>
<p>The Internet Software Consortium (<span class="acronym">ISC</span>) offers a wide range
of support and service agreements for <span class="acronym">BIND</span> and <span class="acronym">DHCP</span> servers. Four
levels of premium support are available and each level includes
support for all <ACRONYM
CLASS="acronym"
>ISC</ACRONYM
> programs, significant discounts on products
support for all <span class="acronym">ISC</span> programs, significant discounts on products
and training, and a recognized priority on bug fixes and
non-funded feature requests. In addition, <ACRONYM
CLASS="acronym"
>ISC</ACRONYM
> offers a standard
non-funded feature requests. In addition, <span class="acronym">ISC</span> offers a standard
support agreement package which includes services ranging from bug
fix announcements to remote support. It also includes training in
<ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> and <ACRONYM
CLASS="acronym"
>DHCP</ACRONYM
>.</P
><P
>To discuss arrangements for support, contact
<A
HREF="mailto:info@isc.org"
TARGET="_top"
>info@isc.org</A
> or visit the
<ACRONYM
CLASS="acronym"
>ISC</ACRONYM
> web page at <A
HREF="http://www.isc.org/services/support/"
TARGET="_top"
>http://www.isc.org/services/support/</A
>
to read more.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="Bv9ARM.ch07.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="Bv9ARM.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="Bv9ARM.ch09.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><ACRONYM
CLASS="acronym"
>BIND</ACRONYM
> 9 Security Considerations</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Appendices</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
<span class="acronym">BIND</span> and <span class="acronym">DHCP</span>.</p>
<p>To discuss arrangements for support, contact
<a href="mailto:info@isc.org" target="_top">info@isc.org</a> or visit the
<span class="acronym">ISC</span> web page at <a href="http://www.isc.org/services/support/" target="_top">http://www.isc.org/services/support/</a>
to read more.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
<td width="20%" align="center"> </td>
<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations </td>
<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
<td width="40%" align="right" valign="top"> Appendix A. Appendices</td>
</tr>
</table>
</div>
</body>
</html>

1879
contrib/bind9/doc/arm/Bv9ARM.ch09.html
View file

File diff suppressed because it is too large Load diff

1073
contrib/bind9/doc/arm/Bv9ARM.html
View file

File diff suppressed because it is too large Load diff

8964
contrib/bind9/doc/arm/Bv9ARM.pdf Executable file
View file

File diff suppressed because one or more lines are too long

60
contrib/bind9/doc/arm/Makefile.in
View file

@ -1,4 +1,4 @@
# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2001, 2002 Internet Software Consortium.
#
# Permission to use, copy, modify, and distribute this software for any
@ -13,7 +13,7 @@
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.
# $Id: Makefile.in,v 1.8.2.2.8.3 2004/03/08 09:04:24 marka Exp $
# $Id: Makefile.in,v 1.8.2.2.8.5 2005/05/13 01:22:35 marka Exp $
srcdir = @srcdir@
VPATH = @srcdir@
@ -23,47 +23,41 @@ top_srcdir = @top_srcdir@
MANOBJS = Bv9ARM.html
PDFOBJS = Bv9ARM.pdf
distclean::
rm -f validate.sh
rm -f nominum-docbook-html.dsl nominum-docbook-print.dsl
rm -f HTML.index HTML.manifest
doc man:: ${MANOBJS}
doc man:: ${MANOBJS} ${PDFOBJS}
docclean manclean maintainer-clean::
rm -f *.html
clean::
rm -f Bv9ARM.aux Bv9ARM.brf Bv9ARM.glo Bv9ARM.idx
rm -f Bv9ARM.log Bv9ARM.out Bv9ARM.tex Bv9ARM.tex.tmp
Bv9ARM.html: Bv9ARM-book.xml nominum-docbook-html.dsl
${OPENJADE} -v \
-c ${SGMLCATALOG} \
-t sgml \
-d ./nominum-docbook-html.dsl \
${XMLDCL} ./Bv9ARM-book.xml
rm -f HTML.index HTML.manifest
docclean manclean maintainer-clean:: clean
rm -f *.html *.pdf
Bv9ARM-book.rtf: Bv9ARM-book.xml nominum-docbook-print.dsl
${OPENJADE} -v \
-c ${SGMLCATALOG} \
-t rtf \
-d ./nominum-docbook-print.dsl \
${XMLDCL} ./Bv9ARM-book.xml
Bv9ARM.html: Bv9ARM-book.xml
${XSLTPROC} --stringparam root.filename Bv9ARM \
${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl \
Bv9ARM-book.xml
Bv9ARM-book.tex: Bv9ARM-book.xml nominum-docbook-print.dsl
${OPENJADE} -v \
-c ${SGMLCATALOG} \
-d ./nominum-docbook-print.dsl \
-t tex \
${XMLDCL} ./Bv9ARM-book.xml
Bv9ARM.tex: Bv9ARM-book.xml
${XSLTPROC} ${top_srcdir}/doc/xsl/pre-latex.xsl Bv9ARM-book.xml | \
${XSLTPROC} ${top_srcdir}/doc/xsl/isc-docbook-latex.xsl - | \
@PERL@ latex-fixup.pl >$@.tmp
if test -s $@.tmp; then mv $@.tmp $@; else rm -f $@.tmp; exit 1; fi
Bv9ARM-book.dvi: Bv9ARM-book.tex
Bv9ARM.dvi: Bv9ARM.tex
rm -f Bv9ARM-book.aux Bv9ARM-book.dvi Bv9ARM-book.log
${JADETEX} ./Bv9ARM-book.tex || true
${JADETEX} ./Bv9ARM-book.tex || true
${JADETEX} ./Bv9ARM-book.tex || true
${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
Bv9ARM-book.pdf: Bv9ARM-book.tex
Bv9ARM.pdf: Bv9ARM.tex
rm -f Bv9ARM-book.aux Bv9ARM-book.pdf Bv9ARM-book.log
${PDFJADETEX} ./Bv9ARM-book.tex || true
${PDFJADETEX} ./Bv9ARM-book.tex || true
${PDFJADETEX} ./Bv9ARM-book.tex || true
${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@

928
contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt Normal file
View file

@ -0,0 +1,928 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories
Expires: February 2006 August 2005
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
<draft-ietf-dnsext-2929bis-01.txt>
Status of This Document
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Distribution of this draft is unlimited. It is intended to become
the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
DNS Working Group mailing list <namedroppers@ops.ietf.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System
(DNS) classes, RR types, operation codes, error codes, RR header
bits, and AFSDB subtypes.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS IANA Considerations August 2005
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Headers..............................3
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................6
3.1 RR TYPE IANA Considerations............................7
3.1.1 DNS TYPE Allocation Policy...........................8
3.1.2 Special Note on the OPT RR...........................9
3.1.3 The AFSDB RR Subtype Field...........................9
3.2 RR CLASS IANA Considerations...........................9
3.3 RR NAME Considerations................................11
4. Security Considerations................................11
Appendix: Changes from RFC 2929...........................12
Copyright and Disclaimer..................................13
Normative References......................................13
Informative References....................................14
Authors Addresses.........................................16
Expiration and File Name..................................16
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS IANA Considerations August 2005
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records"
(RRs) under domain names. DNS data is structured into CLASSes and
zones which can be independently maintained. See [RFC 1034, 1035,
2136, 2181, 4033] familiarity with which is assumed.
This document provides, either directly or by reference, general IANA
parameter assignment considerations applying across DNS query and
response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined, except for AFSDB RR considerations [RFC 1183] which are
included herein. This RFC obsoletes [RFC 2929].
IANA currently maintains a web page of DNS parameters. See
<http://www.iana.org/numbers.htm>.
"IETF Standards Action", "IETF Consensus", "Specification Required",
and "Private Use" are as defined in [RFC 2434].
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2929]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
The QR bit indicates whether the header is for a query or a response.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS IANA Considerations August 2005
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
Standards Action.
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
authority count (NSCOUNT), and additional information count (ARCOUNT)
express the number of records in each section for all opcodes except
Update. These fields have the same structure and data type for
Update but are instead the counts for the zone (ZOCOUNT),
prerequisite (PRCOUNT), update (UPCOUNT), and additional information
(ARCOUNT) sections.
2.1 One Spare Bit?
There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS
implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action.
2.2 Opcode Assignment
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query, Obsolete) [RFC 3425]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
New OpCode assignments require an IETF Standards Action as modified
by [RFC 4020].
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS IANA Considerations August 2005
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
The OPT RR provides an eight bit extension resulting in a 12 bit
RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
Error codes appearing in the DNS header and in these three RR types
all refer to the same error code space with the single exception of
error code 16 which has a different meaning in the OPT RR from its
meaning in other contexts. See table below.
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11 - 15 Available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RPC 2930]
20 BADNAME Duplicate key name [RPF 2930]
21 BADALG Algorithm not supported [RPF 2930]
22 - 3,840
0x0016 - 0x0F00 Available for assignment
3,841 - 4,095
0x0F01 - 0x0FFF Private Use
4,096 - 65,534
0x1000 - 0xFFFE Available for assignment
65,535
0xFFFF Reserved, can only be allocated by an IETF
Standards Action.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS IANA Considerations August 2005
Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment"
requires an IETF Consensus.
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671].
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS IANA Considerations August 2005
octets of the RDATA field.
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the TYPE
and in some cases the CLASS of the resource record.
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data. QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards except for the OPT Meta-RR which is
assigned TYPE 41. There have been DNS implementations which made
caching decisions based on the top bit of the bottom byte of the RR
TYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
[RFC 2845], and TKEY [RFC 2930].
There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
AXFR, and IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
Decimal
Hexadecimal
0
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by the DNS TYPE Allocation Policy as specified in
section 3.1.1.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by the DNS TYPE Allocation Policy as specified in
section 3.1.1.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS IANA Considerations August 2005
256 - 32,767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
TYPE Allocation Policy as specified in section 3.1.1.
32,768 - 65,279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65,280 - 65534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
3.1.1 DNS TYPE Allocation Policy
Parameter values specified above as assigned based on DNS TYPE
Allocation Policy. That is, Expert Review with the additional
requirement that the review be based on a complete template as
specified below which has been posted for three weeks to the
namedroppers@ops.ietf.org mailing list.
Partial or draft templates may be posted with the intend of
soliciting feedback.
DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
Date:
Name and email of originator:
Pointer to internet-draft or other document giving a detailed
description of the protocol use of the new RR Type:
What need is the new RR TYPE intended to fix?
What existing RR TYPE(s) come closest to filling that need and why are
they unsatisfactory?
Does the proposed RR TYPR require special handling within the DNS
different from an Unknown RR TYPE?
Comments:
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS IANA Considerations August 2005
3.1.2 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
3.1.3 The AFSDB RR Subtype Field
The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
RDATA field structure as the MX RR but the 16 bit unsigned integer
field at the beginning of the RDATA is interpreted as a subtype as
follows:
Decimal
Hexadecimal
0
0x0000 - Allocation requires IETF Standards Action.
1
0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
2
0x0002 - DCE/NCA root cell directory node [RFC 1183].
3 - 65,279
0x0003 - 0xFEFF - Allocation by IETF Consensus.
65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, allocation requires IETF Standards Action.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes; however, the label types are the same
and the null label is usable only as root in every CLASS. However,
as global networking and DNS have evolved, the IN, or Internet, CLASS
has dominated DNS use.
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT DNS IANA Considerations August 2005
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current CLASS assignments and considerations for future
assignments are as follows:
Decimal
Hexadecimal
0
0x0000 - Reserved, assignment requires an IETF Standards Action.
1
0x0001 - Internet (IN).
2
0x0002 - Available for assignment by IETF Consensus as a data CLASS.
3
0x0003 - Chaos (CH) [Moon 1981].
4
0x0004 - Hesiod (HS) [Dyer 1987].
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus for data
CLASSes only.
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus for
QCLASSes only.
254
0x00FE - QCLASS None [RFC 2136].
255
0x00FF - QCLASS Any [RFC 1035].
256 - 32,767
0x0100 - 0x7FFF - Assigned by IETF Consensus.
32,768 - 65,279
0x8000 - 0xFEFF - Assigned based on Specification Required as defined
in [RFC 2434].
65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT DNS IANA Considerations August 2005
3.3 RR NAME Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types are sometimes referred to as Text and Binary. Text labels can,
in fact, include any octet value including zero value octets but most
current uses involve only [US-ASCII]. For retrieval, Text labels are
defined to treat ASCII upper and lower case letter codes as matching
[insensitive]. Binary labels are bit sequences [RFC 2673]. The
Binary label type is Experimental [RFC 3363].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
1981] CLASSes are essentially for local use. The IN or Internet
CLASS is thus the only DNS CLASS in global use on the Internet at
this time.
A somewhat out-of-date description of name allocation in the IN Class
is given in [RFC 1591]. Some information on reserved top level
domain names is in BCP 32 [RFC 2606].
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 4033, 4034, 4035] for
secure DNS considerations.
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT DNS IANA Considerations August 2005
Appendix: Changes from RFC 2929
RFC Editor: This Appendix should be deleted for publication.
Changes from RFC 2929 to this draft:
1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
Allocation Policy" and add the specification of that policy. Change
some remaining "IETF Standards Action" allocation requirements to say
"as modified by [RFC 4020]".
2. Updated various RFC references.
3. Mentioned that the Binary label type is now Experimental and
IQuery is Obsolete.
4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
IETF Standards Action required.
5. Add an IANA allocation policy for the AFSDB RR Subtype field.
6. Addition of reference to case insensitive draft.
D. Eastlake 3rd [Page 12]
INTERNET-DRAFT DNS IANA Considerations August 2005
Copyright and Disclaimer
Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Normative References
[RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
[RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
D. Eastlake 3rd [Page 13]
INTERNET-DRAFT DNS IANA Considerations August 2005
[RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", September 2000.
[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
2002.
[RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
Informative References
[Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987,
[Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[RFC 1591] - Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000.
[RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", RFC 2606, June 1999.
[insensitive] - Eastlake, D., "Domain Name System (DNS) Case
D. Eastlake 3rd [Page 14]
INTERNET-DRAFT DNS IANA Considerations August 2005
Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
work in progress.
D. Eastlake 3rd [Page 15]
INTERNET-DRAFT DNS IANA Considerations August 2005
Authors Addresses
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554 (w)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires February 2006.
Its file name is draft-ietf-dnsext-2929bis-01.txt.
D. Eastlake 3rd [Page 16]

562
contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt Normal file
View file

@ -0,0 +1,562 @@
DNSEXT M. Stapp
Internet-Draft Cisco Systems, Inc.
Expires: August 13, 2005 T. Lemon
A. Gustafsson
Nominum, Inc.
February 9, 2005
A DNS RR for Encoding DHCP Information (DHCID RR)
<draft-ietf-dnsext-dhcid-rr-09.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
It is possible for multiple DHCP clients to attempt to update the
same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
the clients themselves perform the DNS updates, conflicts can arise.
To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
Stapp, et al. Expires August 13, 2005 [Page 1]
Internet-Draft The DHCID RR February 2005
proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients to which they refer.
This memo defines a distinct RR type for this purpose for use by DHCP
clients and servers, the "DHCID" RR.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4
3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4
3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4
3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4
3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6
5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1 Normative References . . . . . . . . . . . . . . . . . . . 8
9.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Stapp, et al. Expires August 13, 2005 [Page 2]
Internet-Draft The DHCID RR February 2005
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
2. Introduction
A set of procedures to allow DHCP [7] clients and servers to
automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
in "Resolution of DNS Name Conflicts" [1].
Conflicts can arise if multiple DHCP clients wish to use the same DNS
name. To resolve such conflicts, "Resolution of DNS Name Conflicts"
[1] proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients using them. In the
interest of clarity, it is preferable for this DHCP information to
use a distinct RR type. This memo defines a distinct RR for this
purpose for use by DHCP clients or servers, the "DHCID" RR.
In order to avoid exposing potentially sensitive identifying
information, the data stored is the result of a one-way MD5 [5] hash
computation. The hash includes information from the DHCP client's
REQUEST message as well as the domain name itself, so that the data
stored in the DHCID RR will be dependent on both the client
identification used in the DHCP protocol interaction and the domain
name. This means that the DHCID RDATA will vary if a single client
is associated over time with more than one name. This makes it
difficult to 'track' a client as it is associated with various domain
names.
The MD5 hash algorithm has been shown to be weaker than the SHA-1
algorithm; it could therefore be argued that SHA-1 is a better
choice. However, SHA-1 is significantly slower than MD5. A
successful attack of MD5's weakness does not reveal the original data
that was used to generate the signature, but rather provides a new
set of input data that will produce the same signature. Because we
are using the MD5 hash to conceal the original data, the fact that an
attacker could produce a different plaintext resulting in the same
MD5 output is not significant concern.
3. The DHCID RR
The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
DHCID RR is only defined in the IN class. DHCID RRs cause no
additional section processing. The DHCID RR is not a singleton type.
Stapp, et al. Expires August 13, 2005 [Page 3]
Internet-Draft The DHCID RR February 2005
3.1 DHCID RDATA format
The RDATA section of a DHCID RR in transmission contains RDLENGTH
bytes of binary data. The format of this data and its interpretation
by DHCP servers and clients are described below.
DNS software should consider the RDATA section to be opaque. DHCP
clients or servers use the DHCID RR to associate a DHCP client's
identity with a DNS name, so that multiple DHCP clients and servers
may deterministically perform dynamic DNS updates to the same zone.
From the updater's perspective, the DHCID resource record RDATA
consists of a 16-bit identifier type, in network byte order, followed
by one or more bytes representing the actual identifier:
< 16 bits > DHCP identifier used
< n bytes > MD5 digest
3.2 DHCID Presentation Format
In DNS master files, the RDATA is represented as a single block in
base 64 encoding identical to that used for representing binary data
in RFC 2535 [8]. The data may be divided up into any number of white
space separated substrings, down to single base 64 digits, which are
concatenated to form the complete RDATA. These substrings can span
lines using the standard parentheses.
3.3 The DHCID RR Type Codes
The DHCID RR Type Code specifies what data from the DHCP client's
request was used as input into the hash function. The type codes are
defined in a registry maintained by IANA, as specified in Section 7.
The initial list of assigned values for the type code is:
0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
0x0001 = The data portion from a DHCPv4 client's Client Identifier
option [9].
0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
client's Client Identifier option [10] or the DUID field from a
DHCPv4 client's Client Identifier option [12]).
0x0003 - 0xfffe = Available to be assigned by IANA.
0xffff = RESERVED
3.4 Computation of the RDATA
The DHCID RDATA is formed by concatenating the two type bytes with
Stapp, et al. Expires August 13, 2005 [Page 4]
Internet-Draft The DHCID RR February 2005
some variable-length identifying data.
< type > < data >
The RDATA for all type codes other than 0xffff, which is reserved for
future expansion, is formed by concatenating the two type bytes and a
16-byte MD5 hash value. The input to the hash function is defined to
be:
data = MD5(< identifier > < FQDN >)
The FQDN is represented in the buffer in unambiguous canonical form
as described in RFC 2535 [8], section 8.1. The type code and the
identifier are related as specified in Section 3.3: the type code
describes the source of the identifier.
When the updater is using the client's link-layer address as the
identifier, the first two bytes of the DHCID RDATA MUST be zero. To
generate the rest of the resource record, the updater computes a
one-way hash using the MD5 algorithm across a buffer containing the
client's network hardware type, link-layer address, and the FQDN
data. Specifically, the first byte of the buffer contains the
network hardware type as it appeared in the DHCP 'htype' field of the
client's DHCPREQUEST message. All of the significant bytes of the
chaddr field in the client's DHCPREQUEST message follow, in the same
order in which the bytes appear in the DHCPREQUEST message. The
number of significant bytes in the 'chaddr' field is specified in the
'hlen' field of the DHCPREQUEST message. The FQDN data, as specified
above, follows.
When the updater is using the DHCPv4 Client Identifier option sent by
the client in its DHCPREQUEST message, the first two bytes of the
DHCID RR MUST be 0x0001, in network byte order. The rest of the
DHCID RR MUST contain the results of computing an MD5 hash across the
payload of the option, followed by the FQDN. The payload of the
option consists of the bytes of the option following the option code
and length.
When the updater is using the DHCPv6 DUID sent by the client in its
REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
in network byte order. The rest of the DHCID RR MUST contain the
results of computing an MD5 hash across the payload of the option,
followed by the FQDN. The payload of the option consists of the
bytes of the option following the option code and length.
3.5 Examples
Stapp, et al. Expires August 13, 2005 [Page 5]
Internet-Draft The DHCID RR February 2005
3.5.1 Example 1
A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
Ethernet MAC address 01:02:03:04:05:06 using domain name
"client.example.com" uses the client's link-layer address to identify
the client. The DHCID RDATA is composed by setting the two type
bytes to zero, and performing an MD5 hash computation across a buffer
containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
address, and the domain name (represented as specified in
Section 3.4).
client.example.com. A 10.0.0.1
client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
3.5.2 Example 2
A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
in its DHCP request. The server updates the name "chi.example.com"
on the client's behalf, and uses the DHCP client identifier option
data as input in forming a DHCID RR. The DHCID RDATA is formed by
setting the two type bytes to the value 0x0001, and performing an MD5
hash computation across a buffer containing the seven bytes from the
client-id option and the FQDN (represented as specified in
Section 3.4).
chi.example.com. A 10.0.12.99
chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
4. Use of the DHCID RR
This RR MUST NOT be used for any purpose other than that detailed in
"Resolution of DNS Name Conflicts" [1]. Although this RR contains
data that is opaque to DNS servers, the data must be consistent
across all entities that update and interpret this record.
Therefore, new data formats may only be defined through actions of
the DHC Working Group, as a result of revising [1].
5. Updater Behavior
The data in the DHCID RR allows updaters to determine whether more
than one DHCP client desires to use a particular FQDN. This allows
site administrators to establish policy about DNS updates. The DHCID
RR does not establish any policy itself.
Updaters use data from a DHCP client's request and the domain name
Stapp, et al. Expires August 13, 2005 [Page 6]
Internet-Draft The DHCID RR February 2005
that the client desires to use to compute a client identity hash, and
then compare that hash to the data in any DHCID RRs on the name that
they wish to associate with the client's IP address. If an updater
discovers DHCID RRs whose RDATA does not match the client identity
that they have computed, the updater SHOULD conclude that a different
client is currently associated with the name in question. The
updater SHOULD then proceed according to the site's administrative
policy. That policy might dictate that a different name be selected,
or it might permit the updater to continue.
6. Security Considerations
The DHCID record as such does not introduce any new security problems
into the DNS. In order to avoid exposing private information about
DHCP clients to public scrutiny, a one-way hash is used to obscure
all client information. In order to make it difficult to 'track' a
client by examining the names associated with a particular hash
value, the FQDN is included in the hash computation. Thus, the RDATA
is dependent on both the DHCP client identification data and on each
FQDN associated with the client.
Administrators should be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCP clients
and servers SHOULD use some form of update authentication (e.g., TSIG
[11]) when performing DNS updates.
7. IANA Considerations
IANA is requested to allocate an RR type number for the DHCID record
type.
This specification defines a new number-space for the 16-bit type
codes associated with the DHCID RR. IANA is requested to establish a
registry of the values for this number-space.
Three initial values are assigned in Section 3.3, and the value
0xFFFF is reserved for future use. New DHCID RR type codes are
tentatively assigned after the specification for the associated type
code, published as an Internet Draft, has received expert review by a
designated expert. The final assignment of DHCID RR type codes is
through Standards Action, as defined in RFC 2434 [6].
8. Acknowledgements
Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
Ralph Droms for their review and suggestions.
Stapp, et al. Expires August 13, 2005 [Page 7]
Internet-Draft The DHCID RR February 2005
9. References
9.1 Normative References
[1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
9.2 Informative References
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[8] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
[12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
Stapp, et al. Expires August 13, 2005 [Page 8]
Internet-Draft The DHCID RR February 2005
Authors' Addresses
Mark Stapp
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: 978.936.1535
Email: mjs@cisco.com
Ted Lemon
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
Email: mellon@nominum.com
Andreas Gustafsson
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
Email: gson@nominum.com
Stapp, et al. Expires August 13, 2005 [Page 9]
Internet-Draft The DHCID RR February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stapp, et al. Expires August 13, 2005 [Page 10]

1397
contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt Normal file
View file

File diff suppressed because it is too large Load diff

616
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt Normal file
View file

@ -0,0 +1,616 @@
Network Working Group S. Weiler
Internet-Draft SPARTA, Inc
Updates: 4034, 4035 (if approved) May 23, 2005
Expires: November 24, 2005
Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is a collection of minor technical clarifications to
the DNSSECbis document set. It is meant to serve as a resource to
implementors as well as an interim repository of possible DNSSECbis
errata.
Weiler Expires November 24, 2005 [Page 1]
Internet-Draft DNSSECbis Implementation Notes May 2005
Proposed additions in future versions
An index sorted by the section of DNSSECbis being clarified.
A list of proposed protocol changes being made in other documents,
such as NSEC3 and Epsilon. This document would not make those
changes, merely provide an index into the documents that are making
changes.
Changes between -00 and -01
Document significantly restructured.
Added section on QTYPE=ANY.
Changes between personal submission and first WG draft
Added Section 2.1 based on namedroppers discussions from March 9-10,
2005.
Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
Added the DNSSECbis RFC numbers.
Figured out the confusion in Section 4.1.
Weiler Expires November 24, 2005 [Page 2]
Internet-Draft DNSSECbis Implementation Notes May 2005
Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4
2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4
2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5
2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5
3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6
3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7
4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7
4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7
4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
7.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 11
Weiler Expires November 24, 2005 [Page 3]
Internet-Draft DNSSECbis Implementation Notes May 2005
1. Introduction and Terminology
This document lists some minor clarifications and corrections to
DNSSECbis, as described in [1], [2], and [3].
It is intended to serve as a resource for implementors and as a
repository of items that need to be addressed when advancing the
DNSSECbis documents from Proposed Standard to Draft Standard.
In this version (-01 of the WG document), feedback is particularly
solicited on the structure of the document and whether the text in
the recently added sections is correct and sufficient.
Proposed substantive additions to this document should be sent to the
namedroppers mailing list as well as to the editor of this document.
The editor would greatly prefer text suitable for direct inclusion in
this document.
1.1 Structure of this Document
The clarifications to DNSSECbis are sorted according to the editor's
impression of their importance, starting with ones which could, if
ignored, lead to security and stability problems and progressing down
to clarifications that are likely to have little operational impact.
Mere typos and awkward phrasings are not addressed unless they could
lead to misinterpretation of the DNSSECbis documents.
1.2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2. Significant Concerns
This section provides clarifications that, if overlooked, could lead
to security issues or major interoperability problems.
2.1 Clarifications on Non-Existence Proofs
RFC4035 Section 5.4 slightly underspecifies the algorithm for
checking non-existence proofs. In particular, the algorithm there
might incorrectly allow the NSEC from the parent side of a zone cut
to prove the non-existence of either other RRs at that name in the
child zone or other names in the child zone. It might also allow a
NSEC at the same name as a DNAME to prove the non-existence of names
beneath that DNAME.
Weiler Expires November 24, 2005 [Page 4]
Internet-Draft DNSSECbis Implementation Notes May 2005
A parent-side delegation NSEC (one with the NS bit set, but no SOA
bit set, and with a singer field that's shorter than the owner name)
must not be used to assume non-existence of any RRs below that zone
cut (both RRs at that ownername and at ownernames with more leading
labels, no matter their content). Similarly, an NSEC with the DNAME
bit set must not be used to assume the non-existence of any
descendant of that NSEC's owner name.
2.2 Empty Non-Terminal Proofs
To be written, based on Roy Arends' May 11th message to namedroppers.
2.3 Validating Responses to an ANY Query
RFC4035 does not address now to validate responses when QTYPE=*. As
described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
may include a subset of the RRsets at a given name -- it is not
necessary to include all RRsets at the QNAME in the response.
When validating a response to QTYPE=*, validate all received RRsets
that match QNAME and QCLASS. If any of those RRsets fail validation,
treat the answer as Bogus. If there are no RRsets matching QNAME and
QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
clarified in this document). To be clear, a validator must not
insist on receiving all records at the QNAME in response to QTYPE=*.
3. Interoperability Concerns
3.1 Unknown DS Message Digest Algorithms
Section 5.2 of RFC4035 includes rules for how to handle delegations
to zones that are signed with entirely unsupported algorithms, as
indicated by the algorithms shown in those zone's DS RRsets. It does
not explicitly address how to handle DS records that use unsupported
message digest algorithms. In brief, DS records using unknown or
unsupported message digest algorithms MUST be treated the same way as
DS records referring to DNSKEY RRs of unknown or unsupported
algorithms.
The existing text says:
If the validator does not support any of the algorithms listed
in an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
Weiler Expires November 24, 2005 [Page 5]
Internet-Draft DNSSECbis Implementation Notes May 2005
To paraphrase the above, when determining the security status of a
zone, a validator discards (for this purpose only) any DS records
listing unknown or unsupported algorithms. If none are left, the
zone is treated as if it were unsigned.
Modified to consider DS message digest algorithms, a validator also
discards any DS records using unknown or unsupported message digest
algorithms.
3.2 Private Algorithms
As discussed above, section 5.2 of RFC4035 requires that validators
make decisions about the security status of zones based on the public
key algorithms shown in the DS records for those zones. In the case
of private algorithms, as described in RFC4034 Appendix A.1.1, the
eight-bit algorithm field in the DS RR is not conclusive about what
algorithm(s) is actually in use.
If no private algorithms appear in the DS set or if any supported
algorithm appears in the DS set, no special processing will be
needed. In the remaining cases, the security status of the zone
depends on whether or not the resolver supports any of the private
algorithms in use (provided that these DS records use supported hash
functions, as discussed in Section 3.1). In these cases, the
resolver MUST retrieve the corresponding DNSKEY for each private
algorithm DS record and examine the public key field to determine the
algorithm in use. The security-aware resolver MUST ensure that the
hash of the DNSKEY RR's owner name and RDATA matches the digest in
the DS RR. If they do not match, and no other DS establishes that
the zone is secure, the referral should be considered BAD data, as
discussed in RFC4035.
This clarification facilitates the broader use of private algorithms,
as suggested by [5].
3.3 Caution About Local Policy and Multiple RRSIGs
When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
suggests that "the local resolver security policy determines whether
the resolver also has to test these RRSIG RRs and how to resolve
conflicts if these RRSIG RRs lead to differing results." In most
cases, a resolver would be well advised to accept any valid RRSIG as
sufficient. If the first RRSIG tested fails validation, a resolver
would be well advised to try others, giving a successful validation
result if any can be validated and giving a failure only if all
RRSIGs fail validation.
If a resolver adopts a more restrictive policy, there's a danger that
Weiler Expires November 24, 2005 [Page 6]
Internet-Draft DNSSECbis Implementation Notes May 2005
properly-signed data might unnecessarily fail validation, perhaps
because of cache timing issues. Furthermore, certain zone management
techniques, like the Double Signature Zone-signing Key Rollover
method described in section 4.2.1.2 of [6] might not work reliably.
3.4 Key Tag Calculation
RFC4034 Appendix B.1 incorrectly defines the Key Tag field
calculation for algorithm 1. It correctly says that the Key Tag is
the most significant 16 of the least significant 24 bits of the
public key modulus. However, RFC4034 then goes on to incorrectly say
that this is 4th to last and 3rd to last octets of the public key
modulus. It is, in fact, the 3rd to last and 2nd to last octets.
4. Minor Corrections and Clarifications
4.1 Finding Zone Cuts
Appendix C.8 of RFC4035 discusses sending DS queries to the servers
for a parent zone. To do that, a resolver may first need to apply
special rules to discover what those servers are.
As explained in Section 3.1.4.1 of RFC4035, security-aware name
servers need to apply special processing rules to handle the DS RR,
and in some situations the resolver may also need to apply special
rules to locate the name servers for the parent zone if the resolver
does not already have the parent's NS RRset. Section 4.2 of RFC4035
specifies a mechanism for doing that.
4.2 Clarifications on DNSKEY Usage
Questions of the form "can I use a different DNSKEY for signing the
X" have occasionally arisen.
The short answer is "yes, absolutely". You can even use a different
DNSKEY for each RRset in a zone, subject only to practical limits on
the size of the DNSKEY RRset. However, be aware that there is no way
to tell resolvers what a particularly DNSKEY is supposed to be used
for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
authenticate any RRset in the zone. For example, if a weaker or less
trusted DNSKEY is being used to authenticate NSEC RRsets or all
dynamically updated records, that same DNSKEY can also be used to
sign any other RRsets from the zone.
Furthermore, note that the SEP bit setting has no effect on how a
DNSKEY may be used -- the validation process is specifically
prohibited from using that bit by RFC4034 section 2.1.2. It possible
to use a DNSKEY without the SEP bit set as the sole secure entry
Weiler Expires November 24, 2005 [Page 7]
Internet-Draft DNSSECbis Implementation Notes May 2005
point to the zone, yet use a DNSKEY with the SEP bit set to sign all
RRsets in the zone (other than the DNSKEY RRset). It's also possible
to use a single DNSKEY, with or without the SEP bit set, to sign the
entire zone, including the DNSKEY RRset itself.
4.3 Errors in Examples
The text in RFC4035 Section C.1 refers to the examples in B.1 as
"x.w.example.com" while B.1 uses "x.w.example". This is painfully
obvious in the second paragraph where it states that the RRSIG labels
field value of 3 indicates that the answer was not the result of
wildcard expansion. This is true for "x.w.example" but not for
"x.w.example.com", which of course has a label count of 4
(antithetically, a label count of 3 would imply the answer was the
result of a wildcard expansion).
The first paragraph of RFC4035 Section C.6 also has a minor error:
the reference to "a.z.w.w.example" should instead be "a.z.w.example",
as in the previous line.
5. IANA Considerations
This document specifies no IANA Actions.
6. Security Considerations
This document does not make fundamental changes to the DNSSEC
protocol, as it was generally understood when DNSSECbis was
published. It does, however, address some ambiguities and omissions
in those documents that, if not recognized and addressed in
implementations, could lead to security failures. In particular, the
validation algorithm clarifications in Section 2 are critical for
preserving the security properties DNSSEC offers. Furthermore,
failure to address some of the interoperability concerns in Section 3
could limit the ability to later change or expand DNSSEC, including
by adding new algorithms.
7. References
7.1 Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Weiler Expires November 24, 2005 [Page 8]
Internet-Draft DNSSECbis Implementation Notes May 2005
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2 Informative References
[5] Blacka, D., "DNSSEC Experiments",
draft-blacka-dnssec-experiments-00 (work in progress),
December 2004.
[6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practices-04 (work in
progress), May 2005.
Author's Address
Samuel Weiler
SPARTA, Inc
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Appendix A. Acknowledgments
The editor is extremely grateful to those who, in addition to finding
errors and omissions in the DNSSECbis document set, have provided
text suitable for inclusion in this document.
The lack of specificity about handling private algorithms, as
described in Section 3.2, and the lack of specificity in handling ANY
queries, as described in Section 2.3, were discovered by David
Blacka.
The error in algorithm 1 key tag calculation, as described in
Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake
contributed text for Section 3.4.
The bug relating to delegation NSEC RR's in Section 2.1 was found by
Roy Badami. Roy Arends found the related problem with DNAME.
The errors in the RFC4035 examples were found by Roy Arends, who also
contributed text for Section 4.3 of this document.
Weiler Expires November 24, 2005 [Page 9]
Internet-Draft DNSSECbis Implementation Notes May 2005
The editor would like to thank Olafur Gudmundsson and Scott Rose for
their substantive comments on the text of this document.
Weiler Expires November 24, 2005 [Page 10]
Internet-Draft DNSSECbis Implementation Notes May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weiler Expires November 24, 2005 [Page 11]

784
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt Normal file
View file

@ -0,0 +1,784 @@
DNSEXT D. Blacka
Internet-Draft Verisign, Inc.
Expires: January 19, 2006 July 18, 2005
DNSSEC Experiments
draft-ietf-dnsext-dnssec-experiments-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In the long history of the development of the DNS security extensions
[1] (DNSSEC), a number of alternate methodologies and modifications
have been proposed and rejected for practical, rather than strictly
technical, reasons. There is a desire to be able to experiment with
these alternate methods in the public DNS. This document describes a
methodology for deploying alternate, non-backwards-compatible, DNSSEC
methodologies in an experimental fashion without disrupting the
deployment of standard DNSSEC.
Blacka Expires January 19, 2006 [Page 1]
Internet-Draft DNSSEC Experiments July 2005
Table of Contents
1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1 Normative References . . . . . . . . . . . . . . . . . . 13
10.2 Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 14
Blacka Expires January 19, 2006 [Page 2]
Internet-Draft DNSSEC Experiments July 2005
1. Definitions and Terminology
Throughout this document, familiarity with the DNS system (RFC 1035
[4]) and the DNS security extensions ([1], [2], and [3].
The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
Blacka Expires January 19, 2006 [Page 3]
Internet-Draft DNSSEC Experiments July 2005
2. Overview
Historically, experimentation with DNSSEC alternatives has been a
problematic endeavor. There has typically been a desire to both
introduce non-backwards-compatible changes to DNSSEC, and to try
these changes on real zones in the public DNS. This creates a
problem when the change to DNSSEC would make all or part of the zone
using those changes appear bogus (bad) or otherwise broken to
existing DNSSEC-aware resolvers.
This document describes a standard methodology for setting up public
DNSSEC experiments. This methodology addresses the issue of co-
existence with standard DNSSEC and DNS by using unknown algorithm
identifiers to hide the experimental DNSSEC protocol modifications
from standard DNSSEC-aware resolvers.
Blacka Expires January 19, 2006 [Page 4]
Internet-Draft DNSSEC Experiments July 2005
3. Experiments
When discussing DNSSEC experiments, it is necessary to classify these
experiments into two broad categories:
Backwards-Compatible: describes experimental changes that, while not
strictly adhering to the DNSSEC standard, are nonetheless
interoperable with clients and server that do implement the DNSSEC
standard.
Non-Backwards-Compatible: describes experiments that would cause a
standard DNSSEC-aware resolver to (incorrectly) determine that all
or part of a zone is bogus, or to otherwise not interoperable with
standard DNSSEC clients and servers.
Not included in these terms are experiments with the core DNS
protocol itself.
The methodology described in this document is not necessary for
backwards-compatible experiments, although it certainly could be used
if desired.
Note that, in essence, this metholodolgy would also be used to
introduce a new DNSSEC algorithm, independently from any DNSSEC
experimental protocol change.
Blacka Expires January 19, 2006 [Page 5]
Internet-Draft DNSSEC Experiments July 2005
4. Method
The core of the methodology is the use of strictly "unknown"
algorithms to sign the experimental zone, and more importantly,
having only unknown algorithm DS records for the delegation to the
zone at the parent.
This technique works because of the way DNSSEC-compliant validators
are expected to work in the presence of a DS set with only unknown
algorithms. From [3], Section 5.2:
If the validator does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
And further:
If the resolver does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver will not be able to
verify the authentication path to the child zone. In this case,
the resolver SHOULD treat the child zone as if it were unsigned.
While this behavior isn't strictly mandatory (as marked by MUST), it
is unlikely that a validator would not implement the behavior, or,
more to the point, it will not violate this behavior in an unsafe way
(see below (Section 6).)
Because we are talking about experiments, it is RECOMMENDED that
private algorithm numbers be used (see [2], appendix A.1.1. Note
that secure handling of private algorithms requires special handing
by the validator logic. See [6] for futher details.) Normally,
instead of actually inventing new signing algorithms, the recommended
path is to create alternate algorithm identifiers that are aliases
for the existing, known algorithms. While, strictly speaking, it is
only necessary to create an alternate identifier for the mandatory
algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
aliased as well.
It is RECOMMENDED that for a particular DNSSEC experiment, a
particular domain name base is chosen for all new algorithms, then
the algorithm number (or name) is prepended to it. For example, for
experiment A, the base name of "dnssec-experiment-a.example.com" is
chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
experiment-a.example.com". However, any unique identifier will
Blacka Expires January 19, 2006 [Page 6]
Internet-Draft DNSSEC Experiments July 2005
suffice.
Using this method, resolvers (or, more specificially, DNSSEC
validators) essentially indicate their ability to understand the
DNSSEC experiment's semantics by understanding what the new algorithm
identifiers signify.
This method creates two classes of DNSSEC-aware servers and
resolvers: servers and resolvers that are aware of the experiment
(and thus recognize the experiments algorithm identifiers and
experimental semantics), and servers and resolvers that are unware of
the experiment.
This method also precludes any zone from being both in an experiment
and in a classic DNSSEC island of security. That is, a zone is
either in an experiment and only experimentally validatable, or it
isn't.
Blacka Expires January 19, 2006 [Page 7]
Internet-Draft DNSSEC Experiments July 2005
5. Defining an Experiment
The DNSSEC experiment must define the particular set of (previously
unknown) algorithms that identify the experiment, and define what
each unknown algorithm identifier means. Typically, unless the
experiment is actually experimenting with a new DNSSEC algorithm,
this will be a mapping of private algorithm identifiers to existing,
known algorithms.
Normally the experiment will choose a DNS name as the algorithm
identifier base. This DNS name SHOULD be under the control of the
authors of the experiment. Then the experiment will define a mapping
between known mandatory and optional algorithms into this private
algorithm identifier space. Alternately, the experiment MAY use the
OID private algorithm space instead (using algorithm number 254), or
may choose non-private algorithm numbers, although this would require
an IANA allocation (see below (Section 9).)
For example, an experiment might specify in its description the DNS
name "dnssec-experiment-a.example.com" as the base name, and provide
the mapping of "3.dnssec-experiment-a.example.com" is an alias of
DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
an alias of DNSSEC algorithm 5 (RSASHA1).
Resolvers MUST then only recognize the experiment's semantics when
present in a zone signed by one or more of these private algorithms.
In general, however, resolvers involved in the experiment are
expected to understand both standard DNSSEC and the defined
experimental DNSSEC protocol, although this isn't required.
Blacka Expires January 19, 2006 [Page 8]
Internet-Draft DNSSEC Experiments July 2005
6. Considerations
There are a number of considerations with using this methodology.
1. Under some circumstances, it may be that the experiment will not
be sufficiently masked by this technique and may cause resolution
problem for resolvers not aware of the experiment. For instance,
the resolver may look at the not validatable response and
conclude that the response is bogus, either due to local policy
or implementation details. This is not expected to be the common
case, however.
2. In general, it will not be possible for DNSSEC-aware resolvers
not aware of the experiment to build a chain of trust through an
experimental zone.
Blacka Expires January 19, 2006 [Page 9]
Internet-Draft DNSSEC Experiments July 2005
7. Transitions
If an experiment is successful, there may be a desire to move the
experiment to a standards-track extension. One way to do so would be
to move from private algorithm numbers to IANA allocated algorithm
numbers, with otherwise the same meaning. This would still leave a
divide between resolvers that understood the extension versus
resolvers that did not. It would, in essence, create an additional
version of DNSSEC.
An alternate technique might be to do a typecode rollover, thus
actually creating a definitive new version of DNSSEC. There may be
other transition techniques available, as well.
Blacka Expires January 19, 2006 [Page 10]
Internet-Draft DNSSEC Experiments July 2005
8. Security Considerations
Zones using this methodology will be considered insecure by all
resolvers except those aware of the experiment. It is not generally
possible to create a secure delegation from an experimental zone that
will be followed by resolvers unaware of the experiment.
Blacka Expires January 19, 2006 [Page 11]
Internet-Draft DNSSEC Experiments July 2005
9. IANA Considerations
IANA may need to allocate new DNSSEC algorithm numbers if that
transition approach is taken, or the experiment decides to use
allocated numbers to begin with. No IANA action is required to
deploy an experiment using private algorithm identifiers.
Blacka Expires January 19, 2006 [Page 12]
Internet-Draft DNSSEC Experiments July 2005
10. References
10.1 Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
10.2 Informative References
[4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Weiler, S., "Clarifications and Implementation Notes for
DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
progress), March 2005.
Author's Address
David Blacka
Verisign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
Phone: +1 703 948 3200
Email: davidb@verisign.com
URI: http://www.verisignlabs.com
Blacka Expires January 19, 2006 [Page 13]
Internet-Draft DNSSEC Experiments July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Blacka Expires January 19, 2006 [Page 14]

560
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt Normal file
View file

@ -0,0 +1,560 @@
Network Working Group S. Weiler
Internet-Draft SPARTA, Inc
Updates: 4034, 4035 (if approved) J. Ihren
Expires: November 13, 2005 Autonomica AB
May 12, 2005
Minimally Covering NSEC Records and DNSSEC On-line Signing
draft-ietf-dnsext-dnssec-online-signing-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes how to construct DNSSEC NSEC resource records
that cover a smaller range of names than called for by RFC4034. By
generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents
otherwise made possible by walking the chain of NSEC records in a
signed zone.
Weiler & Ihren Expires November 13, 2005 [Page 1]
Internet-Draft NSEC Epsilon May 2005
Changes from weiler-01 to ietf-00
Inserted RFC numbers for 4033, 4034, and 4035.
Specified contents of bitmap field in synthesized NSEC RR's, pointing
out that this relaxes a constraint in 4035. Added 4035 to the
Updates header.
Changes from weiler-00 to weiler-01
Clarified that this updates RFC4034 by relaxing requirements on the
next name field.
Added examples covering wildcard names.
In the 'better functions' section, reiterated that perfect functions
aren't needed.
Added a reference to RFC 2119.
Weiler & Ihren Expires November 13, 2005 [Page 2]
Internet-Draft NSEC Epsilon May 2005
Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . 4
2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4
3. Better Increment & Decrement Functions . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . 10
Weiler & Ihren Expires November 13, 2005 [Page 3]
Internet-Draft NSEC Epsilon May 2005
1. Introduction and Terminology
With DNSSEC [1], an NSEC record lists the next instantiated name in
its zone, proving that no names exist in the "span" between the
NSEC's owner name and the name in the "next name" field. In this
document, an NSEC record is said to "cover" the names between its
owner name and next name.
Through repeated queries that return NSEC records, it is possible to
retrieve all of the names in the zone, a process commonly called
"walking" the zone. Some zone owners have policies forbidding zone
transfers by arbitrary clients; this side-effect of the NSEC
architecture subverts those policies.
This document presents a way to prevent zone walking by constructing
NSEC records that cover fewer names. These records can make zone
walking take approximately as many queries as simply asking for all
possible names in a zone, making zone walking impractical. Some of
these records must be created and signed on demand, which requires
on-line private keys. Anyone contemplating use of this technique is
strongly encouraged to review the discussion of the risks of on-line
signing in Section 5.
The technique presented here may be useful to a zone owner that wants
to use DNSSEC, is concerned about exposure of its zone contents via
zone walking, and is willing to bear the costs of on-line signing.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2. Minimally Covering NSEC Records
This mechanism involves changes to NSEC records for instantiated
names, which can still be generated and signed in advance, as well as
the on-demand generation and signing of new NSEC records whenever a
name must be proven not to exist.
In the 'next name' field of instantiated names' NSEC records, rather
than list the next instantiated name in the zone, list any name that
falls lexically after the NSEC's owner name and before the next
instantiated name in the zone, according to the ordering function in
RFC4034 [2] section 6.2. This relaxes the requirement in section
4.1.1 of RFC4034 that the 'next name' field contains the next owner
name in the zone. This change is expected to be fully compatible
with all existing DNSSEC validators. These NSEC records are returned
whenever proving something specifically about the owner name (e.g.
that no resource records of a given type appear at that name).
Weiler & Ihren Expires November 13, 2005 [Page 4]
Internet-Draft NSEC Epsilon May 2005
Whenever an NSEC record is needed to prove the non-existence of a
name, a new NSEC record is dynamically produced and signed. The new
NSEC record has an owner name lexically before the QNAME but
lexically following any existing name and a 'next name' lexically
following the QNAME but before any existing name.
The generated NSEC record's type bitmap SHOULD have the RRSIG and
NSEC bits set and SHOULD NOT have any other bits set. This relaxes
the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
names that did not exist before the zone wsa signed.
The functions to generate the lexically following and proceeding
names need not be perfect nor consistent, but the generated NSEC
records must not cover any existing names. Furthermore, this
technique works best when the generated NSEC records cover as few
names as possible.
An NSEC record denying the existence of a wildcard may be generated
in the same way. Since the NSEC record covering a non-existent
wildcard is likely to be used in response to many queries,
authoritative name servers using the techniques described here may
want to pregenerate or cache that record and its corresponding RRSIG.
For example, a query for an A record at the non-instantiated name
example.com might produce the following two NSEC records, the first
denying the existence of the name example.com and the second denying
the existence of a wildcard:
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
).com 3600 IN NSEC +.com ( RRSIG NSEC )
Before answering a query with these records, an authoritative server
must test for the existence of names between these endpoints. If the
generated NSEC would cover existing names (e.g. exampldd.com or
*bizarre.example.com), a better increment or decrement function may
be used or the covered name closest to the QNAME could be used as the
NSEC owner name or next name, as appropriate. If an existing name is
used as the NSEC owner name, that name's real NSEC record MUST be
returned. Using the same example, assuming an exampldd.com
delegation exists, this record might be returned from the parent:
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
Like every authoritative record in the zone, each generated NSEC
record MUST have corresponding RRSIGs generated using each algorithm
(but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
described in RFC4035 [3] section 2.2. To minimize the number of
Weiler & Ihren Expires November 13, 2005 [Page 5]
Internet-Draft NSEC Epsilon May 2005
signatures that must be generated, a zone may wish to limit the
number of algorithms in its DNSKEY RRset.
3. Better Increment & Decrement Functions
Section 6.2 of RFC4034 defines a strict ordering of DNS names.
Working backwards from that definition, it should be possible to
define increment and decrement functions that generate the
immediately following and preceding names, respectively. This
document does not define such functions. Instead, this section
presents functions that come reasonably close to the perfect ones.
As described above, an authoritative server should still ensure than
no generated NSEC covers any existing name.
To increment a name, add a leading label with a single null (zero-
value) octet.
To decrement a name, decrement the last character of the leftmost
label, then fill that label to a length of 63 octets with octets of
value 255. To decrement a null (zero-value) octet, remove the octet
-- if an empty label is left, remove the label. Defining this
function numerically: fill the left-most label to its maximum length
with zeros (numeric, not ASCII zeros) and subtract one.
In response to a query for the non-existent name foo.example.com,
these functions produce NSEC records of:
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
The first of these NSEC RRs proves that no exact match for
foo.example.com exists, and the second proves that there is no
wildcard in example.com.
Both of these functions are imperfect: they don't take into account
constraints on number of labels in a name nor total length of a name.
As noted in the previous section, though, this technique does not
depend on the use of perfect increment or decrement functions: it is
sufficient to test whether any instantiated names fall into the span
Weiler & Ihren Expires November 13, 2005 [Page 6]
Internet-Draft NSEC Epsilon May 2005
covered by the generated NSEC and, if so, substitute those
instantiated owner names for the NSEC owner name or next name, as
appropriate.
4. IANA Considerations
Per RFC4041, IANA should think carefully about the protection of
their immortal souls.
5. Security Considerations
This approach requires on-demand generation of RRSIG records. This
creates several new vulnerabilities.
First, on-demand signing requires that a zone's authoritative servers
have access to its private keys. Storing private keys on well-known
internet-accessible servers may make them more vulnerable to
unintended disclosure.
Second, since generation of public key signatures tends to be
computationally demanding, the requirement for on-demand signing
makes authoritative servers vulnerable to a denial of service attack.
Lastly, if the increment and decrement functions are predictable, on-
demand signing may enable a chosen-plaintext attack on a zone's
private keys. Zones using this approach should attempt to use
cryptographic algorithms that are resistant to chosen-plaintext
attacks. It's worth noting that while DNSSEC has a "mandatory to
implement" algorithm, that is a requirement on resolvers and
validators -- there is no requirement that a zone be signed with any
given algorithm.
The success of using minimally covering NSEC record to prevent zone
walking depends greatly on the quality of the increment and decrement
functions chosen. An increment function that chooses a name
obviously derived from the next instantiated name may be easily
reverse engineered, destroying the value of this technique. An
increment function that always returns a name close to the next
instantiated name is likewise a poor choice. Good choices of
increment and decrement functions are the ones that produce the
immediately following and preceding names, respectively, though zone
administrators may wish to use less perfect functions that return
more human-friendly names than the functions described in Section 3
above.
Another obvious but misguided concern is the danger from synthesized
NSEC records being replayed. It's possible for an attacker to replay
an old but still validly signed NSEC record after a new name has been
Weiler & Ihren Expires November 13, 2005 [Page 7]
Internet-Draft NSEC Epsilon May 2005
added in the span covered by that NSEC, incorrectly proving that
there is no record at that name. This danger exists with DNSSEC as
defined in [-bis]. The techniques described here actually decrease
the danger, since the span covered by any NSEC record is smaller than
before. Choosing better increment and decrement functions will
further reduce this danger.
6. Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Samuel Weiler
SPARTA, Inc
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Johan Ihren
Autonomica AB
Bellmansgatan 30
Stockholm SE-118 47
Sweden
Email: johani@autonomica.se
Appendix A. Acknowledgments
Many individuals contributed to this design. They include, in
addition to the authors of this document, Olaf Kolkman, Ed Lewis,
Weiler & Ihren Expires November 13, 2005 [Page 8]
Internet-Draft NSEC Epsilon May 2005
Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
Jakob Schlyter, Bill Manning, and Joao Damas.
The key innovation of this document, namely that perfect increment
and decrement functions are not necessary, arose during a discussion
among the above-listed people at the RIPE49 meeting in September
2004.
Weiler & Ihren Expires November 13, 2005 [Page 9]
Internet-Draft NSEC Epsilon May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weiler & Ihren Expires November 13, 2005 [Page 10]

896
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt Normal file
View file

@ -0,0 +1,896 @@
DNSEXT R. Arends
Internet-Draft Telematica Instituut
Expires: January 19, 2006 M. Kosters
D. Blacka
Verisign, Inc.
July 18, 2005
DNSSEC Opt-In
draft-ietf-dnsext-dnssec-opt-in-07
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
cryptographically secured. Maintaining this cryptography is not
practical or necessary. This document describes an experimental
"Opt-In" model that allows administrators to omit this cryptography
and manage the cost of adopting DNSSEC with large zones.
Arends, et al. Expires January 19, 2006 [Page 1]
Internet-Draft DNSSEC Opt-In July 2005
Table of Contents
1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5
4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5
4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6
4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6
4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7
4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7
4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7
4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7
4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8
4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8
5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1 Normative References . . . . . . . . . . . . . . . . . . . 13
11.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16
Arends, et al. Expires January 19, 2006 [Page 2]
Internet-Draft DNSSEC Opt-In July 2005
1. Definitions and Terminology
Throughout this document, familiarity with the DNS system (RFC 1035
[1]), DNS security extensions ([3], [4], and [5], referred to in this
document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
[10]) is assumed.
The following abbreviations and terms are used in this document:
RR: is used to refer to a DNS resource record.
RRset: refers to a Resource Record Set, as defined by [8]. In this
document, the RRset is also defined to include the covering RRSIG
records, if any exist.
signed name: refers to a DNS name that has, at minimum, a (signed)
NSEC record.
unsigned name: refers to a DNS name that does not (at least) have a
NSEC record.
covering NSEC record/RRset: is the NSEC record used to prove
(non)existence of a particular name or RRset. This means that for
a RRset or name 'N', the covering NSEC record has the name 'N', or
has an owner name less than 'N' and "next" name greater than 'N'.
delegation: refers to a NS RRset with a name different from the
current zone apex (non-zone-apex), signifying a delegation to a
subzone.
secure delegation: refers to a signed name containing a delegation
(NS RRset), and a signed DS RRset, signifying a delegation to a
signed subzone.
insecure delegation: refers to a signed name containing a delegation
(NS RRset), but lacking a DS RRset, signifying a delegation to an
unsigned subzone.
Opt-In insecure delegation: refers to an unsigned name containing
only a delegation NS RRset. The covering NSEC record uses the
Opt-In methodology described in this document.
The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [7].
2. Overview
The cost to cryptographically secure delegations to unsigned zones is
high for large delegation-centric zones and zones where insecure
delegations will be updated rapidly. For these zones, the costs of
maintaining the NSEC record chain may be extremely high relative to
the gain of cryptographically authenticating existence of unsecured
zones.
This document describes an experimental method of eliminating the
Arends, et al. Expires January 19, 2006 [Page 3]
Internet-Draft DNSSEC Opt-In July 2005
superfluous cryptography present in secure delegations to unsigned
zones. Using "Opt-In", a zone administrator can choose to remove
insecure delegations from the NSEC chain. This is accomplished by
extending the semantics of the NSEC record by using a redundant bit
in the type map.
3. Experimental Status
This document describes an EXPERIMENTAL extension to DNSSEC. It
interoperates with non-experimental DNSSEC using the technique
described in [6]. This experiment is identified with the following
private algorithms (using algorithm 253):
"3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
and
"5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
RSASHA1.
Servers wishing to sign and serve zones that utilize Opt-In MUST sign
the zone with only one or more of these private algorithms. This
requires the signing tools and servers to support private algorithms,
as well as Opt-In.
Resolvers wishing to validate Opt-In zones MUST only do so when the
zone is only signed using one or more of these private algorithms.
The remainder of this document assumes that the servers and resolvers
involved are aware of and are involved in this experiment.
4. Protocol Additions
In DNSSEC, delegation NS RRsets are not signed, but are instead
accompanied by a NSEC RRset of the same name and (possibly) a DS
record. The security status of the subzone is determined by the
presence or absence of the DS RRset, cryptographically proven by the
NSEC record. Opt-In expands this definition by allowing insecure
delegations to exist within an otherwise signed zone without the
corresponding NSEC record at the delegation's owner name. These
insecure delegations are proven insecure by using a covering NSEC
record.
Since this represents a change of the interpretation of NSEC records,
resolvers must be able to distinguish between RFC standard DNSSEC
NSEC records and Opt-In NSEC records. This is accomplished by
"tagging" the NSEC records that cover (or potentially cover) insecure
delegation nodes. This tag is indicated by the absence of the NSEC
bit in the type map. Since the NSEC bit in the type map merely
indicates the existence of the record itself, this bit is redundant
Arends, et al. Expires January 19, 2006 [Page 4]
Internet-Draft DNSSEC Opt-In July 2005
and safe for use as a tag.
An Opt-In tagged NSEC record does not assert the (non)existence of
the delegations that it covers (except for a delegation with the same
name). This allows for the addition or removal of these delegations
without recalculating or resigning records in the NSEC chain.
However, Opt-In tagged NSEC records do assert the (non)existence of
other RRsets.
An Opt-In NSEC record MAY have the same name as an insecure
delegation. In this case, the delegation is proven insecure by the
lack of a DS bit in type map and the signed NSEC record does assert
the existence of the delegation.
Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
records and standard DNSSEC NSEC records. If a NSEC record is not
Opt-In, there MUST NOT be any insecure delegations (or any other
records) between it and the RRsets indicated by the 'next domain
name' in the NSEC RDATA. If it is Opt-In, there MUST only be
insecure delegations between it and the next node indicated by the
'next domain name' in the NSEC RDATA.
In summary,
o An Opt-In NSEC type is identified by a zero-valued (or not-
specified) NSEC bit in the type bit map of the NSEC record.
o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
the type bit map of the NSEC record.
and,
o An Opt-In NSEC record does not assert the non-existence of a name
between its owner name and "next" name, although it does assert
that any name in this span MUST be an insecure delegation.
o An Opt-In NSEC record does assert the (non)existence of RRsets
with the same owner name.
4.1 Server Considerations
Opt-In imposes some new requirements on authoritative DNS servers.
4.1.1 Delegations Only
This specification dictates that only insecure delegations may exist
between the owner and "next" names of an Opt-In tagged NSEC record.
Signing tools SHOULD NOT generate signed zones that violate this
restriction. Servers SHOULD refuse to load and/or serve zones that
violate this restriction. Servers also SHOULD reject AXFR or IXFR
Arends, et al. Expires January 19, 2006 [Page 5]
Internet-Draft DNSSEC Opt-In July 2005
responses that violate this restriction.
4.1.2 Insecure Delegation Responses
When returning an Opt-In insecure delegation, the server MUST return
the covering NSEC RRset in the Authority section.
In standard DNSSEC, NSEC records already must be returned along with
the insecure delegation. The primary difference that this proposal
introduces is that the Opt-In tagged NSEC record will have a
different owner name from the delegation RRset. This may require
implementations to search for the covering NSEC RRset.
4.1.3 Wildcards and Opt-In
Standard DNSSEC describes the practice of returning NSEC records to
prove the non-existence of an applicable wildcard in non-existent
name responses. This NSEC record can be described as a "negative
wildcard proof". The use of Opt-In NSEC records changes the
necessity for this practice. For non-existent name responses when
the query name (qname) is covered by an Opt-In tagged NSEC record,
servers MAY choose to omit the wildcard proof record, and clients
MUST NOT treat the absence of this NSEC record as a validation error.
The intent of the standard DNSSEC negative wildcard proof requirement
is to prevent malicious users from undetectably removing valid
wildcard responses. In order for this cryptographic proof to work,
the resolver must be able to prove:
1. The exact qname does not exist. This is done by the "normal"
NSEC record.
2. No applicable wildcard exists. This is done by returning a NSEC
record proving that the wildcard does not exist (this is the
negative wildcard proof).
However, if the NSEC record covering the exact qname is an Opt-In
NSEC record, the resolver will not be able to prove the first part of
this equation, as the qname might exist as an insecure delegation.
Thus, since the total proof cannot be completed, the negative
wildcard proof NSEC record is not useful.
The negative wildcard proof is also not useful when returned as part
of an Opt-In insecure delegation response for a similar reason: the
resolver cannot prove that the qname does or does not exist, and
therefore cannot prove that a wildcard expansion is valid.
The presence of an Opt-In tagged NSEC record does not change the
practice of returning a NSEC along with a wildcard expansion. Even
Arends, et al. Expires January 19, 2006 [Page 6]
Internet-Draft DNSSEC Opt-In July 2005
though the Opt-In NSEC will not be able to prove that the wildcard
expansion is valid, it will prove that the wildcard expansion is not
masking any signed records.
4.1.4 Dynamic Update
Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In
particular, it introduces the need for rules that describe when to
add or remove a delegation name from the NSEC chain. This document
does not attempt to define these rules. Until these rules are
defined, servers MUST NOT process DNS Dynamic Update requests against
zones that use Opt-In NSEC records. Servers SHOULD return responses
to update requests with RCODE=REFUSED.
4.2 Client Considerations
Opt-In imposes some new requirements on security-aware resolvers
(caching or otherwise).
4.2.1 Delegations Only
As stated in the "Server Considerations" section above, this
specification restricts the namespace covered by Opt-In tagged NSEC
records to insecure delegations only. Thus, resolvers MUST reject as
invalid any records that fall within an Opt-In NSEC record's span
that are not NS records or corresponding glue records.
4.2.2 Validation Process Changes
This specification does not change the resolver's resolution
algorithm. However, it does change the DNSSEC validation process.
Resolvers MUST be able to use Opt-In tagged NSEC records to
cryptographically prove the validity and security status (as
insecure) of a referral. Resolvers determine the security status of
the referred-to zone as follows:
o In standard DNSSEC, the security status is proven by the existence
or absence of a DS RRset at the same name as the delegation. The
existence of the DS RRset indicates that the referred-to zone is
signed. The absence of the DS RRset is proven using a verified
NSEC record of the same name that does not have the DS bit set in
the type map. This NSEC record MAY also be tagged as Opt-In.
o Using Opt-In, the security status is proven by the existence of a
DS record (for signed) or the presence of a verified Opt-In tagged
NSEC record that covers the delegation name. That is, the NSEC
record does not have the NSEC bit set in the type map, and the
delegation name falls between the NSEC's owner and "next" name.
Arends, et al. Expires January 19, 2006 [Page 7]
Internet-Draft DNSSEC Opt-In July 2005
Using Opt-In does not substantially change the nature of following
referrals within DNSSEC. At every delegation point, the resolver
will have cryptographic proof that the referred-to subzone is signed
or unsigned.
When receiving either an Opt-In insecure delegation response or a
non-existent name response where that name is covered by an Opt-In
tagged NSEC record, the resolver MUST NOT require proof (in the form
of a NSEC record) that a wildcard did not exist.
4.2.3 NSEC Record Caching
Caching resolvers MUST be able to retrieve the appropriate covering
Opt-In NSEC record when returning referrals that need them. This
requirement differs from standard DNSSEC in that the covering NSEC
will not have the same owner name as the delegation. Some
implementations may have to use new methods for finding these NSEC
records.
4.2.4 Use of the AD bit
The AD bit, as defined by [2] and [5], MUST NOT be set when:
o sending a Name Error (RCODE=3) response where the covering NSEC is
tagged as Opt-In.
o sending an Opt-In insecure delegation response, unless the
covering (Opt-In) NSEC record's owner name equals the delegation
name.
This rule is based on what the Opt-In NSEC record actually proves:
for names that exist between the Opt-In NSEC record's owner and
"next" names, the Opt-In NSEC record cannot prove the non-existence
or existence of the name. As such, not all data in the response has
been cryptographically verified, so the AD bit cannot be set.
5. Benefits
Using Opt-In allows administrators of large and/or changing
delegation-centric zones to minimize the overhead involved in
maintaining the security of the zone.
Opt-In accomplishes this by eliminating the need for NSEC records for
insecure delegations. This, in a zone with a large number of
delegations to unsigned subzones, can lead to substantial space
savings (both in memory and on disk). Additionally, Opt-In allows
for the addition or removal of insecure delegations without modifying
the NSEC record chain. Zones that are frequently updating insecure
delegations (e.g., TLDs) can avoid the substantial overhead of
Arends, et al. Expires January 19, 2006 [Page 8]
Internet-Draft DNSSEC Opt-In July 2005
modifying and resigning the affected NSEC records.
6. Example
Consider the zone EXAMPLE, shown below. This is a zone where all of
the NSEC records are tagged as Opt-In.
Example A: Fully Opt-In Zone.
EXAMPLE. SOA ...
EXAMPLE. RRSIG SOA ...
EXAMPLE. NS FIRST-SECURE.EXAMPLE.
EXAMPLE. RRSIG NS ...
EXAMPLE. DNSKEY ...
EXAMPLE. RRSIG DNSKEY ...
EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (
SOA NS RRSIG DNSKEY )
EXAMPLE. RRSIG NSEC ...
FIRST-SECURE.EXAMPLE. A ...
FIRST-SECURE.EXAMPLE. RRSIG A ...
FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG
FIRST-SECURE.EXAMPLE. RRSIG NSEC ...
NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
NS.NOT-SECURE.EXAMPLE. A ...
NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG
NOT-SECURE-2.EXAMPLE RRSIG NSEC ...
SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
SECOND-SECURE.EXAMPLE. DS ...
SECOND-SECURE.EXAMPLE. RRSIG DS ...
SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY
SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE.
NS.UNSIGNED.EXAMPLE. A ...
In this example, a query for a signed RRset (e.g., "FIRST-
SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
SECURE.EXAMPLE A") will result in a standard DNSSEC response.
A query for a nonexistent RRset will result in a response that
differs from standard DNSSEC by: the NSEC record will be tagged as
Opt-In, there may be no NSEC record proving the non-existence of a
Arends, et al. Expires January 19, 2006 [Page 9]
Internet-Draft DNSSEC Opt-In July 2005
matching wildcard record, and the AD bit will not be set.
A query for an insecure delegation RRset (or a referral) will return
both the answer (in the Authority section) and the corresponding
Opt-In NSEC record to prove that it is not secure.
Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
RCODE=NOERROR, AD=0
Answer Section:
Authority Section:
UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS
SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
Additional Section:
NS.UNSIGNED.EXAMPLE. A ...
In the Example A.1 zone, the EXAMPLE. node MAY use either style of
NSEC record, because there are no insecure delegations that occur
between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
Example A would still be a valid zone if the NSEC record for EXAMPLE.
was changed to the following RR:
EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS
RRSIG DNSKEY NSEC )
However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure
delegations in the range they define. (NOT-SECURE.EXAMPLE. and
UNSIGNED.EXAMPLE., respectively).
NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
part of the NSEC chain and also covered by an Opt-In tagged NSEC
record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
removed from the zone without modifying and resigning the prior NSEC
record. Delegations with names that fall between NOT-SECURE-
2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
resigning any NSEC records.
7. Transition Issues
Opt-In is not backwards compatible with standard DNSSEC and is
considered experimental. Standard DNSSEC compliant implementations
would not recognize Opt-In tagged NSEC records as different from
Arends, et al. Expires January 19, 2006 [Page 10]
Internet-Draft DNSSEC Opt-In July 2005
standard NSEC records. Because of this, standard DNSSEC
implementations, if they were to validate Opt-In style responses,
would reject all Opt-In insecure delegations within a zone as
invalid. However, by only signing with private algorithms, standard
DNSSEC implementations will treat Opt-In responses as unsigned.
It should be noted that all elements in the resolution path between
(and including) the validator and the authoritative name server must
be aware of the Opt-In experiment and implement the Opt-In semantics
for successful validation to be possible. In particular, this
includes any caching middleboxes between the validator and
authoritative name server.
8. Security Considerations
Opt-In allows for unsigned names, in the form of delegations to
unsigned subzones, to exist within an otherwise signed zone. All
unsigned names are, by definition, insecure, and their validity or
existence cannot by cryptographically proven.
In general:
o Records with unsigned names (whether existing or not) suffer from
the same vulnerabilities as records in an unsigned zone. These
vulnerabilities are described in more detail in [12] (note in
particular sections 2.3, "Name Games" and 2.6, "Authenticated
Denial").
o Records with signed names have the same security whether or not
Opt-In is used.
Note that with or without Opt-In, an insecure delegation may have its
contents undetectably altered by an attacker. Because of this, the
primary difference in security that Opt-In introduces is the loss of
the ability to prove the existence or nonexistence of an insecure
delegation within the span of an Opt-In NSEC record.
In particular, this means that a malicious entity may be able to
insert or delete records with unsigned names. These records are
normally NS records, but this also includes signed wildcard
expansions (while the wildcard record itself is signed, its expanded
name is an unsigned name).
For example, if a resolver received the following response from the
example zone above:
Arends, et al. Expires January 19, 2006 [Page 11]
Internet-Draft DNSSEC Opt-In July 2005
Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
RCODE=NOERROR
Answer Section:
Authority Section:
DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
RRSIG DNSKEY
EXAMPLE. RRSIG NSEC ...
Additional Section:
The resolver would have no choice but to believe that the referral to
NS.FORGED. is valid. If a wildcard existed that would have been
expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
have undetectably removed it and replaced it with the forged
delegation.
Note that being able to add a delegation is functionally equivalent
to being able to add any record type: an attacker merely has to forge
a delegation to nameserver under his/her control and place whatever
records needed at the subzone apex.
While in particular cases, this issue may not present a significant
security problem, in general it should not be lightly dismissed.
Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
In particular, zone signing tools SHOULD NOT default to Opt-In, and
MAY choose to not support Opt-In at all.
9. IANA Considerations
None.
10. Acknowledgments
The contributions, suggestions and remarks of the following persons
(in alphabetic order) to this draft are acknowledged:
Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
Wellington.
11. References
Arends, et al. Expires January 19, 2006 [Page 12]
Internet-Draft DNSSEC Opt-In July 2005
11.1 Normative References
[1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[6] Blacka, D., "DNSSEC Experiments",
draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
July 2005.
11.2 Informative References
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.
[9] Eastlake, D., "Secure Domain Name System Dynamic Update",
RFC 2137, April 1997.
[10] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001.
[12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
Arends, et al. Expires January 19, 2006 [Page 13]
Internet-Draft DNSSEC Opt-In July 2005
Authors' Addresses
Roy Arends
Telematica Instituut
Drienerlolaan 5
7522 NB Enschede
NL
Email: roy.arends@telin.nl
Mark Kosters
Verisign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
Phone: +1 703 948 3200
Email: markk@verisign.com
URI: http://www.verisignlabs.com
David Blacka
Verisign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
Phone: +1 703 948 3200
Email: davidb@verisign.com
URI: http://www.verisignlabs.com
Appendix A. Implementing Opt-In using "Views"
In many cases, it may be convenient to implement an Opt-In zone by
combining two separately maintained "views" of a zone at request
time. In this context, "view" refers to a particular version of a
zone, not to any specific DNS implementation feature.
In this scenario, one view is the secure view, the other is the
insecure (or legacy) view. The secure view consists of an entirely
signed zone using Opt-In tagged NSEC records. The insecure view
contains no DNSSEC information. It is helpful, although not
necessary, for the secure view to be a subset (minus DNSSEC records)
of the insecure view.
In addition, the only RRsets that may solely exist in the insecure
view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and
Arends, et al. Expires January 19, 2006 [Page 14]
Internet-Draft DNSSEC Opt-In July 2005
the zone apex NS RRset) MUST be signed and in the secure view.
These two views may be combined at request time to provide a virtual,
single Opt-In zone. The following algorithm is used when responding
to each query:
V_A is the secure view as described above.
V_B is the insecure view as described above.
R_A is a response generated from V_A, following RFC 2535bis.
R_B is a response generated from V_B, following DNS resolution as
per RFC 1035 [1].
R_C is the response generated by combining R_A with R_B, as
described below.
A query is DNSSEC-aware if it either has the DO bit [11] turned
on, or is for a DNSSEC-specific record type.
1. If V_A is a subset of V_B and the query is not DNSSEC-aware,
generate and return R_B, otherwise
2. Generate R_A.
3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise
4. Generate R_B and combine it with R_A to form R_C:
For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
records from R_A into R_B, EXCEPT the AUTHORITY section SOA
record, if R_B's RCODE = NOERROR.
5. Return R_C.
Arends, et al. Expires January 19, 2006 [Page 15]
Internet-Draft DNSSEC Opt-In July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arends, et al. Expires January 19, 2006 [Page 16]

839
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt Normal file
View file

@ -0,0 +1,839 @@
DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut
Expires: August 25, 2005 P. Koch
DENIC eG
J. Schlyter
NIC-SE
February 21, 2005
Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a
Arends, et al. Expires August 25, 2005 [Page 1]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
way forward.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5
2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9
2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10
2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11
2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Arends, et al. Expires August 25, 2005 [Page 2]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
1. Introduction
This report shall document the process of dealing with the NSEC
walking problem late in the Last Call for
[I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion
that took place in the DNSEXT WG during the first half of June 2004
as well as some additional ideas that came up subsequently.
This is an edited excerpt of the chairs' mail to the WG:
The working group consents on not including NSEC-alt in the
DNSSEC-bis documents. The working group considers to take up
"prevention of zone enumeration" as a work item.
There may be multiple mechanisms to allow for co-existence with
DNSSEC-bis. The chairs allow the working group a little over a
week (up to June 12, 2004) to come to consensus on a possible
modification to the document to enable gentle rollover. If that
consensus cannot be reached the DNSSEC-bis documents will go out
as-is.
To ease the process of getting consensus, a summary of the proposed
solutions and analysis of the pros and cons were written during the
weekend.
This summary includes:
An inventory of the proposed mechanisms to make a transition to
future work on authenticated denial of existence.
List the known Pros and Cons, possibly provide new arguments, and
possible security considerations of these mechanisms.
Provide a recommendation on a way forward that is least disruptive
to the DNSSEC-bis specifications as they stand and keep an open
path to other methods for authenticated denial of existence.
The descriptions of the proposals in this document are coarse and do
not cover every detail necessary for implementation. In any case,
documentation and further study is needed before implementaion and/or
deployment, including those which seem to be solely operational in
nature.
2. Transition Mechanisms
In the light of recent discussions and past proposals, we have found
several ways to allow for transition to future expansion of
authenticated denial. We tried to illuminate the paths and pitfalls
in these ways forward. Some proposals lead to a versioning of
DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
proposals are 'clean' but may cause delay, while again others may be
Arends, et al. Expires August 25, 2005 [Page 3]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
plain hacks.
Some paths do not introduce versioning, and might require the current
DNSSEC-bis documents to be fully updated to allow for extensions to
authenticated denial mechanisms. Other paths introduce versioning
and do not (or minimally) require DNSSEC-bis documents to be updated,
allowing DNSSEC-bis to be deployed, while future versions can be
drafted independent from or partially depending on DNSSEC-bis.
2.1 Mechanisms With Need of Updating DNSSEC-bis
Mechanisms in this category demand updates to the DNSSEC-bis document
set.
2.1.1 Dynamic NSEC Synthesis
This proposal assumes that NSEC RRs and the authenticating RRSIG will
be generated dynamically to just cover the (non existent) query name.
The owner name is (the) one preceding the name queried for, the Next
Owner Name Field has the value of the Query Name Field + 1 (first
successor in canonical ordering). A separate key (the normal ZSK or
a separate ZSK per authoritative server) would be used for RRSIGs on
NSEC RRs. This is a defense against enumeration, though it has the
presumption of online signing.
2.1.1.1 Coexistence and Migration
There is no change in interpretation other then that the next owner
name might or might not exist.
2.1.1.2 Limitations
This introduces an unbalanced cost between query and response
generation due to dynamic generation of signatures.
2.1.1.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents might need to be updated to indicate
that the next owner name might not be an existing name in the zone.
This is not a real change to the spec since implementers have been
warned not to synthesize with previously cached NSEC records. A
specific bit to identify the dynamic signature generating key might
be useful as well, to prevent it from being used to fake positive
data.
2.1.1.4 Cons
Unbalanced cost is a ground for DDoS. Though this protects against
Arends, et al. Expires August 25, 2005 [Page 4]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
enumeration, it is not really a path for versioning.
2.1.1.5 Pros
Hardly any amendments to DNSSEC-bis.
2.1.2 Add Versioning/Subtyping to Current NSEC
This proposal introduces versioning for the NSEC RR type (a.k.a.
subtyping) by adding a (one octet) version field to the NSEC RDATA.
Version number 0 is assigned to the current (DNSSEC-bis) meaning,
making this an 'Must Be Zero' (MBZ) for the to be published docset.
2.1.2.1 Coexistence and Migration
Since the versioning is done inside the NSEC RR, different versions
may coexist. However, depending on future methods, that may or may
not be useful inside a single zone. Resolvers cannot ask for
specific NSEC versions but may be able to indicate version support by
means of a to be defined EDNS option bit.
2.1.2.2 Limitations
There are no technical limitations, though it will cause delay to
allow testing of the (currently unknown) new NSEC interpretation.
Since the versioning and signaling is done inside the NSEC RR, future
methods will likely be restricted to a single RR type authenticated
denial (as opposed to e.g. NSEC-alt, which currently proposes three
RR types).
2.1.2.3 Amendments to DNSSEC-bis
Full Update of the current DNSSEC-bis documents to provide for new
fields in NSEC, while specifying behavior in case of unknown field
values.
2.1.2.4 Cons
Though this is a clean and clear path without versioning DNSSEC, it
takes some time to design, gain consensus, update the current
dnssec-bis document, test and implement a new authenticated denial
record.
2.1.2.5 Pros
Does not introduce an iteration to DNSSEC while providing a clear and
clean migration strategy.
Arends, et al. Expires August 25, 2005 [Page 5]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.3 Type Bit Map NSEC Indicator
Bits in the type-bit-map are reused or allocated to signify the
interpretation of NSEC.
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
the RDATA or introduce an alternative denial mechanism, invoked by
the specific type-bit-map-bits.
2.1.3.1 Coexistence and migration
Old and new NSEC meaning could coexist, depending how the signaling
would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR
types are available as well as those covering meta/query types or
types to be specifically allocated.
2.1.3.2 Limitations
This mechanism uses an NSEC field that was not designed for that
purpose. Similar methods were discussed during the Opt-In discussion
and the Silly-State discussion.
2.1.3.3 Amendments to DNSSEC-bis
The specific type-bit-map-bits must be allocated and they need to be
specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
interpretation. Also, behaviour of the resolver and validator must
be documented in case unknown values are encountered for the MBZ
field. Currently the protocol document specifies that the validator
MUST ignore the setting of the NSEC and the RRSIG bits, while other
bits are only used for the specific purpose of the type-bit-map field
2.1.3.4 Cons
The type-bit-map was not designed for this purpose. It is a
straightforward hack. Text in protocol section 5.4 was put in
specially to defend against this usage.
2.1.3.5 Pros
No change needed to the on-the-wire protocol as specified in the
current docset.
2.1.4 New Apex Type
This introduces a new Apex type (parallel to the zone's SOA)
indicating the DNSSEC version (or authenticated denial) used in or
Arends, et al. Expires August 25, 2005 [Page 6]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
for this zone.
2.1.4.1 Coexistence and Migration
Depending on the design of this new RR type multiple denial
mechanisms may coexist in a zone. Old validators will not understand
and thus ignore the new type, so interpretation of the new NSEC
scheme may fail, negative responses may appear 'bogus'.
2.1.4.2 Limitations
A record of this kind is likely to carry additional
feature/versioning indications unrelated to the current question of
authenticated denial.
2.1.4.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the absence of this type indicates dnssec-bis, and that the (mere)
presence of this type indicated unknown versions.
2.1.4.4 Cons
The only other 'zone' or 'apex' record is the SOA record. Though
this proposal is not new, it is yet unknown how it might fulfill
authenticated denial extensions. This new RR type would only provide
for a generalized signaling mechanism, not the new authenticated
denial scheme. Since it is likely to be general in nature, due to
this generality consensus is not to be reached soon.
2.1.4.5 Pros
This approach would allow for a lot of other per zone information to
be transported or signaled to both (slave) servers and resolvers.
2.1.5 NSEC White Lies
This proposal disables one part of NSEC (the pointer part) by means
of a special target (root, apex, owner, ...), leaving intact only the
ability to authenticate denial of existence of RR sets, not denial of
existence of domain names (NXDOMAIN). It may be necessary to have
one working NSEC to prove the absence of a wildcard.
2.1.5.1 Coexistence and Migration
The NSEC target can be specified per RR, so standard NSEC and 'white
lie' NSEC can coexist in a zone. There is no need for migration
because no versioning is introduced or intended.
Arends, et al. Expires August 25, 2005 [Page 7]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.5.2 Limitations
This proposal breaks the protocol and is applicable to certain types
of zones only (no wildcard, no deep names, delegation only). Most of
the burden is put on the resolver side and operational consequences
are yet to be studied.
2.1.5.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the NXDOMAIN responses may be insecure.
2.1.5.4 Cons
Strictly speaking this breaks the protocol and doesn't fully fulfill
the requirements for authenticated denial of existence. Security
implications need to be carefully documented: search path problems
(forged denial of existence may lead to wrong expansion of non-FQDNs
[RFC1535]) and replay attacks to deny existence of records.
2.1.5.5 Pros
Hardly any amendments to DNSSEC-bis. Operational "trick" that is
available anyway.
2.1.6 NSEC Optional via DNSSKEY Flag
A new DNSKEY may be defined to declare NSEC optional per zone.
2.1.6.1 Coexistence and Migration
Current resolvers/validators will not understand the Flag bit and
will have to treat negative responses as bogus. Otherwise, no
migration path is needed since NSEC is simply turned off.
2.1.6.2 Limitations
NSEC can only be made completely optional at the cost of being unable
to prove unsecure delegations (absence of a DS RR [RFC3658]). A next
to this approach would just disable authenticated denial for
non-existence of nodes.
2.1.6.3 Amendments to DNSSEC-bis
New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
be specified in the light of absence of authenticated denial.
Arends, et al. Expires August 25, 2005 [Page 8]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.6.4 Cons
Doesn't fully meet requirements. Operational consequences to be
studied.
2.1.6.5 Pros
Official version of the "trick" presented in (8). Operational
problems can be addressed during future work on validators.
2.1.7 New Answer Pseudo RR Type
A new pseudo RR type may be defined that will be dynamically created
(and signed) by the responding authoritative server. The RR in the
response will cover the QNAME, QCLASS and QTYPE and will authenticate
both denial of existence of name (NXDOMAIN) or RRset.
2.1.7.1 Coexistence and Migration
Current resolvers/validators will not understand the pseudo RR and
will thus not be able to process negative responses so testified. A
signaling or solicitation method would have to be specified.
2.1.7.2 Limitations
This method can only be used with online keys and online signing
capacity.
2.1.7.3 Amendments to DNSSEC-bis
Signaling method needs to be defined.
2.1.7.4 Cons
Keys have to be held and processed online with all security
implications. An additional flag for those keys identifying them as
online or negative answer only keys should be considered.
2.1.7.5 Pros
Expands DNSSEC authentication to the RCODE.
2.1.8 SIG(0) Based Authenticated Denial
2.1.8.1 Coexistence and Migration
Arends, et al. Expires August 25, 2005 [Page 9]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.8.2 Limitations
2.1.8.3 Amendments to DNSSEC-bis
2.1.8.4 Cons
2.1.8.5 Pros
2.2 Mechanisms Without Need of Updating DNSSEC-bis
2.2.1 Partial Type-code and Signal Rollover
Carefully crafted type code/signal rollover to define a new
authenticated denial space that extends/replaces DNSSEC-bis
authenticated denial space. This particular path is illuminated by
Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
posted to <namedroppers@ops.ietf.org> 2004-06-02.
2.2.1.1 Coexistence and Migration
To protect the current resolver for future versions, a new DNSSEC-OK
bit must be allocated to make clear it does or does not understand
the future version. Also, a new DS type needs to be allocated to
allow differentiation between a current signed delegation and a
'future' signed delegation. Also, current NSEC needs to be rolled
into a new authenticated denial type.
2.2.1.2 Limitations
None.
2.2.1.3 Amendments to DNSSEC-bis
None.
2.2.1.4 Cons
It is cumbersome to carefully craft an TCR that 'just fits'. The
DNSSEC-bis protocol has many 'borderline' cases that needs special
consideration. It might be easier to do a full TCR, since a few of
the types and signals need upgrading anyway.
Arends, et al. Expires August 25, 2005 [Page 10]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.2.1.5 Pros
Graceful adoption of future versions of NSEC, while there are no
amendments to DNSSEC-bis.
2.2.2 A Complete Type-code and Signal Rollover
A new DNSSEC space is defined which can exist independent of current
DNSSEC-bis space.
This proposal assumes that all current DNSSEC type-codes
(RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
future versions of DNSSEC. Any future version of DNSSEC has its own
types to allow for keys, signatures, authenticated denial, etcetera.
2.2.2.1 Coexistence and Migration
Both spaces can co-exist. They can be made completely orthogonal.
2.2.2.2 Limitations
None.
2.2.2.3 Amendments to DNSSEC-bis
None.
2.2.2.4 Cons
With this path we abandon the current DNSSEC-bis. Though it is easy
to role specific well-known and well-tested parts into the re-write,
once deployment has started this path is very expensive for
implementers, registries, registrars and registrants as well as
resolvers/users. A TCR is not to be expected to occur frequently, so
while a next generation authenticated denial may be enabled by a TCR,
it is likely that that TCR will only be agreed upon if it serves a
whole basket of changes or additions. A quick introduction of
NSEC-ng should not be expected from this path.
2.2.2.5 Pros
No amendments/changes to current DNSSEC-bis docset needed. It is
always there as last resort.
2.2.3 Unknown Algorithm in RRSIG
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
Arends, et al. Expires August 25, 2005 [Page 11]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
the RDATA or introduce an alternative denial mechanism, invoked by
the specific unknown signing algorithm. The different interpretation
would be signaled by use of different signature algorithms in the
RRSIG records covering the NSEC RRs.
When an entire zone is signed with a single unknown algorithm, it
will cause implementations that follow current dnssec-bis documents
to treat individual RRsets as unsigned.
2.2.3.1 Coexistence and migration
Old and new NSEC RDATA interpretation or known and unknown Signatures
can NOT coexist in a zone since signatures cover complete (NSEC)
RRSets.
2.2.3.2 Limitations
Validating resolvers agnostic of new interpretation will treat the
NSEC RRset as "not signed". This affects wildcard and non-existence
proof, as well as proof for (un)secured delegations. Also, all
positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
insecure/bogus to an old validator.
The algorithm version space is split for each future version of
DNSSEC. Violation of the 'modular components' concept. We use the
'validator' to protect the 'resolver' from unknown interpretations.
2.2.3.3 Amendments to DNSSEC-bis
None.
2.2.3.4 Cons
The algorithm field was not designed for this purpose. This is a
straightforward hack.
2.2.3.5 Pros
No amendments/changes to current DNSSEC-bis docset needed.
3. Recommendation
The authors recommend that the working group commits to and starts
work on a partial TCR, allowing graceful transition towards a future
version of NSEC. Meanwhile, to accomodate the need for an
immediately, temporary, solution against zone-traversal, we recommend
On-Demand NSEC synthesis.
Arends, et al. Expires August 25, 2005 [Page 12]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
This approach does not require any mandatory changes to DNSSEC-bis,
does not violate the protocol and fulfills the requirements. As a
side effect, it moves the cost of implementation and deployment to
the users (zone owners) of this mechanism.
4. Acknowledgements
The authors would like to thank Sam Weiler and Mark Andrews for their
input and constructive comments.
5. References
5.1 Normative References
[I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Massey, D., Larson, M. and S.
Rose, "DNS Security Introduction and Requirements",
Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
2004.
[I-D.ietf-dnsext-dnssec-protocol]
Arends, R., "Protocol Modifications for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
October 2004.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., "Resource Records for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-records-11,
October 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
5.2 Informative References
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, October
1993.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
Arends, et al. Expires August 25, 2005 [Page 13]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
RFC 2535, March 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
Authors' Addresses
Roy Arends
Telematica Instituut
Brouwerijstraat 1
Enschede 7523 XC
The Netherlands
Phone: +31 53 4850485
Email: roy.arends@telin.nl
Peter Koch
DENIC eG
Wiesenh"uttenplatz 26
Frankfurt 60329
Germany
Phone: +49 69 27235 0
Email: pk@DENIC.DE
Jakob Schlyter
NIC-SE
Box 5774
Stockholm SE-114 87
Sweden
Email: jakob@nic.se
URI: http://www.nic.se/
Arends, et al. Expires August 25, 2005 [Page 14]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arends, et al. Expires August 25, 2005 [Page 15]

928
contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt Normal file
View file

@ -0,0 +1,928 @@
INTERNET-DRAFT ECC Keys in the DNS
Expires: January 2006 July 2005
Elliptic Curve KEYs in the DNS
-------- ----- ---- -- --- ---
<draft-ietf-dnsext-ecc-key-07.txt>
Richard C. Schroeppel
Donald Eastlake 3rd
Status of This Document
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@ops.ietf.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The standard method for storing elliptic curve cryptographic keys and
signatures in the Domain Name System is specified.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
R. Schroeppel, et al [Page 1]
INTERNET-DRAFT ECC Keys in the DNS
Acknowledgement
The assistance of Hilarie K. Orman in the production of this document
is greatfully acknowledged.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright Notice...........................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Elliptic Curve Data in Resource Records.................3
3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10
5. Elliptic Curve SIG Resource Records....................11
6. Performance Considerations.............................13
7. Security Considerations................................13
8. IANA Considerations....................................13
Copyright and Disclaimer..................................14
Informational References..................................15
Normative Refrences.......................................15
Author's Addresses........................................16
Expiration and File Name..................................16
R. Schroeppel, et al [Page 2]
INTERNET-DRAFT ECC Keys in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. The DNS has been extended to include digital
signatures and cryptographic keys as described in [RFC 4033, 4034,
4035].
This document describes how to store elliptic curve cryptographic
(ECC) keys and signatures in the DNS so they can be used for a
variety of security purposes. Familiarity with ECC cryptography is
assumed [Menezes].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Elliptic Curve Data in Resource Records
Elliptic curve public keys are stored in the DNS within the RDATA
portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
structure shown below.
The research world continues to work on the issue of which is the
best elliptic curve system, which finite field to use, and how to
best represent elements in the field. So, representations are
defined for every type of finite field, and every type of elliptic
curve. The reader should be aware that there is a unique finite
field with a particular number of elements, but many possible
representations of that field and its elements. If two different
representations of a field are given, they are interconvertible with
a tedious but practical precomputation, followed by a fast
computation for each field element to be converted. It is perfectly
reasonable for an algorithm to work internally with one field
representation, and convert to and from a different external
representation.
R. Schroeppel, et al [Page 3]
INTERNET-DRAFT ECC Keys in the DNS
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S M -FMT- A B Z|
+-+-+-+-+-+-+-+-+
| LP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P (length determined from LP) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F (length determined from LF) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGJ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRDV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H (length determined from LH) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K (length determined from LK) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (length determined from LA) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALTA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (length determined from LB) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C (length determined from LC) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG |
R. Schroeppel, et al [Page 4]
INTERNET-DRAFT ECC Keys in the DNS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G (length determined from LG) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Y (length determined from LY) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SMFMTABZ is a flags octet as follows:
S = 1 indicates that the remaining 7 bits of the octet selects
one of 128 predefined choices of finite field, element
representation, elliptic curve, and signature parameters.
MFMTABZ are omitted, as are all parameters from LP through G.
LY and Y are retained.
If S = 0, the remaining parameters are as in the picture and
described below.
M determines the type of field underlying the elliptic curve.
M = 0 if the field is a GF[2^N] field;
M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
FMT is a three bit field describing the format of the field
representation.
FMT = 0 for a (mod P) field.
> 0 for an extension field, either GF[2^D] or GF[P^D].
The degree D of the extension, and the field polynomial
must be specified. The field polynomial is always monic
(leading coefficient 1.)
FMT = 1 The field polynomial is given explicitly; D is implied.
If FMT >=2, the degree D is given explicitly.
= 2 The field polynomial is implicit.
= 3 The field polynomial is a binomial. P>2.
= 4 The field polynomial is a trinomial.
= 5 The field polynomial is the quotient of a trinomial by a
short polynomial. P=2.
= 6 The field polynomial is a pentanomial. P=2.
Flags A and B apply to the elliptic curve parameters.
R. Schroeppel, et al [Page 5]
INTERNET-DRAFT ECC Keys in the DNS
A = 1 When P>=5, the curve parameter A is negated. If P=2, then
A=1 indicates that the A parameter is special. See the
ALTA parameter below, following A. The combination A=1,
P=3 is forbidden.
B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
then B=1 indicates an alternate elliptic curve equation is
used. When P=2 and B=1, an additional curve parameter C
is present.
The Z bit SHOULD be set to zero on creation of an RR and MUST be
ignored when processing an RR (when S=0).
Most of the remaining parameters are present in some formats and
absent in others. The presence or absence of a parameter is
determined entirely by the flags. When a parameter occurs, it is in
the order defined by the picture.
Of the remaining parameters, PFHKQABCGY are variable length. When
present, each is preceded by a one-octet length field as shown in the
diagram above. The length field does not include itself. The length
field may have values from 0 through 110. The parameter length in
octets is determined by a conditional formula: If LL<=64, the
parameter length is LL. If LL>64, the parameter length is 16 times
(LL-60). In some cases, a parameter value of 0 is sensible, and MAY
be represented by an LL value of 0, with the data field omitted. A
length value of 0 represents a parameter value of 0, not an absent
parameter. (The data portion occupies 0 space.) There is no
requirement that a parameter be represented in the minimum number of
octets; high-order 0 octets are allowed at the front end. Parameters
are always right adjusted, in a field of length defined by LL. The
octet-order is always most-significant first, least-significant last.
The parameters H and K may have an optional sign bit stored in the
unused high-order bit of their length fields.
LP defines the length of the prime P. P must be an odd prime. The
parameters LP,P are present if and only if the flag M=1. If M=0, the
prime is 2.
LF,F define an explicit field polynomial. This parameter pair is
present only when FMT = 1. The length of a polynomial coefficient is
ceiling(log2 P) bits. Coefficients are in the numerical range
[0,P-1]. The coefficients are packed into fixed-width fields, from
higher order to lower order. All coefficients must be present,
including any 0s and also the leading coefficient (which is required
to be 1). The coefficients are right justified into the octet string
of length specified by LF, with the low-order "constant" coefficient
at the right end. As a concession to storage efficiency, the higher
order bits of the leading coefficient may be elided, discarding high-
order 0 octets and reducing LF. The degree is calculated by
R. Schroeppel, et al [Page 6]
INTERNET-DRAFT ECC Keys in the DNS
determining the bit position of the left most 1-bit in the F data
(counting the right most bit as position 0), and dividing by
ceiling(log2 P). The division must be exact, with no remainder. In
this format, all of the other degree and field parameters are
omitted. The next parameters will be LQ,Q.
If FMT>=2, the degree of the field extension is specified explicitly,
usually along with other parameters to define the field polynomial.
DEG is a two octet field that defines the degree of the field
extension. The finite field will have P^DEG elements. DEG is
present when FMT>=2.
When FMT=2, the field polynomial is specified implicitly. No other
parameters are required to define the field; the next parameters
present will be the LQ,Q pair. The implicit field poynomial is the
lexicographically smallest irreducible (mod P) polynomial of the
correct degree. The ordering of polynomials is by highest-degree
coefficients first -- the leading coefficient 1 is most important,
and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
degree D is X^D (which is not irreducible). The next is X^D+1, which
is sometimes irreducible, followed by X^D-1, which isn't. Assuming
odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
X, X^D + X + 1, X^D + X - 1, etc.
When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
odd. The polynomial is determined by the degree and the low order
term K. Of all the field parameters, only the LK,K parameters are
present. The high-order bit of the LK octet stores on optional sign
for K; if the sign bit is present, the field polynomial is X^DEG - K.
When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
K. When P=2, the H and K parameters are implicitly 1, and are
omitted from the representation. Only DEG and DEGH are present; the
next parameters are LQ,Q. When P>2, then LH,H and LK,K are
specified. Either or both of LH, LK may contain a sign bit for its
parameter.
When FMT=5, then P=2 (only). The field polynomial is the exact
quotient of a trinomial divided by a small polynomial, the trinomial
divisor. The small polynomial is right-adjusted in the two octet
field TRDV. DEG specifies the degree of the field. The degree of
TRDV is calculated from the position of the high-order 1 bit. The
trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
DEGH is 0, the middle term is omitted from the trinomial. The
quotient must be exact, with no remainder.
When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
with the degrees of the middle terms given by the three 2-octet
R. Schroeppel, et al [Page 7]
INTERNET-DRAFT ECC Keys in the DNS
values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
> DEGJ > 0.
DEGH, DEGI, DEGJ are two-octet fields that define the degree of
a term in a field polynomial. DEGH is present when FMT = 4,
5, or 6. DEGI and DEGJ are present only when FMT = 6.
TRDV is a two-octet right-adjusted binary polynomial of degree <
16. It is present only for FMT=5.
LH and H define the H parameter, present only when FMT=4 and P
is odd. The high bit of LH is an optional sign bit for H.
LK and K define the K parameter, present when FMT = 3 or 4, and
P is odd. The high bit of LK is an optional sign bit for K.
The remaining parameters are concerned with the elliptic curve and
the signature algorithm.
LQ defines the length of the prime Q. Q is a prime > 2^159.
In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
member of the pair is an element from the finite field defined
earlier. The length field defines a long octet string. Field
elements are represented as (mod P) polynomials of degree < DEG, with
DEG or fewer coefficients. The coefficients are stored from left to
right, higher degree to lower, with the constant term last. The
coefficients are represented as integers in the range [0,P-1]. Each
coefficient is allocated an area of ceiling(log2 P) bits. The field
representation is right-justified; the "constant term" of the field
element ends at the right most bit. The coefficients are fitted
adjacently without regard for octet boundaries. (Example: if P=5,
three bits are used for each coefficient. If the field is GF[5^75],
then 225 bits are required for the coefficients, and as many as 29
octets may be needed in the data area. Fewer octets may be used if
some high-order coefficients are 0.) If a flag requires a field
element to be negated, each non-zero coefficient K is replaced with
P-K. To save space, 0 bits may be removed from the left end of the
element representation, and the length field reduced appropriately.
This would normally only happen with A,B,C, because the designer
chose curve parameters with some high-order 0 coefficients or bits.
If the finite field is simply (mod P), then the field elements are
simply numbers (mod P), in the usual right-justified notation. If
the finite field is GF[2^D], the field elements are the usual right-
justified polynomial basis representation.
R. Schroeppel, et al [Page 8]
INTERNET-DRAFT ECC Keys in the DNS
LA,A is the first parameter of the elliptic curve equation.
When P>=5, the flag A = 1 indicates A should be negated (mod
P). When P=2 (indicated by the flag M=0), the flag A = 1
indicates that the parameter pair LA,A is replaced by the two
octet parameter ALTA. In this case, the parameter A in the
curve equation is x^ALTA, where x is the field generator.
Parameter A often has the value 0, which may be indicated by
LA=0 (with no A data field), and sometimes A is 1, which may
be represented with LA=1 and a data field of 1, or by setting
the A flag and using an ALTA value of 0.
LB,B is the second parameter of the elliptic curve equation.
When P>=5, the flag B = 1 indicates B should be negated (mod
P). When P=2 or 3, the flag B selects an alternate curve
equation.
LC,C is the third parameter of the elliptic curve equation,
present only when P=2 (indicated by flag M=0) and flag B=1.
LG,G defines a point on the curve, of order Q. The W-coordinate
of the curve point is given explicitly; the Z-coordinate is
implicit.
LY,Y is the user's public signing key, another curve point of
order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always
present.
3. The Elliptic Curve Equation
(The coordinates of an elliptic curve point are named W,Z instead of
the more usual X,Y to avoid confusion with the Y parameter of the
signing key.)
The elliptic curve equation is determined by the flag octet, together
with information about the prime P. The primes 2 and 3 are special;
all other primes are treated identically.
If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+ A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
If A and/or B is negative (i.e., in the range from P/2 to P), and
P>=5, space may be saved by putting the sign bit(s) in the A and B
bits of the flags octet, and the magnitude(s) in the parameter
fields.
If M=1 and P=3, the B flag has a different meaning: it specifies an
alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
the right-hand-side is different. When P=3, this equation is more
R. Schroeppel, et al [Page 9]
INTERNET-DRAFT ECC Keys in the DNS
commonly used.
If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
parameter can often be 0 or 1, or be chosen as a single-1-bit value.
The flag B is used to select an alternate curve equation, Z^2 + C*Z =
W^3 + A*W + B. This is the only time that the C parameter is used.
4. How do I Compute Q, G, and Y?
The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then
the number of points is determined with Schoof's algorithm. This
number is factored, and if it has a large prime divisor, that number
is taken as Q.
G must be a point of order Q on the curve, satisfying the equation
Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC 1750] curve point, and
multiplying it by (number-of-points-on-curve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a
new random curve point is recalculated.
G is specified by giving its W-coordinate. The Z-coordinate is
calculated from the curve equation. In general, there will be two
possible Z values. The rule is to choose the "positive" value.
In the (mod P) case, the two possible Z values sum to P. The smaller
value is less than P/2; it is used in subsequent calculations. In
GF[P^D] fields, the highest-degree non-zero coefficient of the field
element Z is used; it is chosen to be less than P/2.
In the GF[2^N] case, the two possible Z values xor to W (or to the
parameter C with the alternate curve equation). The numerically
smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user's public
signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use.
R. Schroeppel, et al [Page 10]
INTERNET-DRAFT ECC Keys in the DNS
During the key generation process, a random [RFC 1750] number X must
be generated such that 1 <= X <= Q-1. X is the private key and is
used in the final step of public key generation where Y is computed
as
Y = X * G (as points on the elliptic curve)
If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
in the (mod P) case, or the high-order non-zero coefficient of Z >
P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
GF[2^N] case), then X must be replaced with Q-X. This will
correspond to the correct Z-coordinate.
5. Elliptic Curve SIG Resource Records
The signature portion of an RR RDATA area when using the EC
algorithm, for example in the RRSIG and SIG [RFC records] RRs is
shown below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R and S are integers (mod Q). Their length is specified by the LQ
field of the corresponding KEY RR and can also be calculated from the
SIG RR's RDLENGTH. They are right justified, high-order-octet first.
The same conditional formula for calculating the length from LQ is
used as for all the other length fields above.
The data signed is determined as specified in [RFC 2535]. Then the
following steps are taken where Q, P, G, and Y are as specified in
the public key [Schneier]:
hash = SHA-1 ( data )
Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two
different messages with the same K. K should be chosen from a
very large space: If an opponent learns a K value for a single
signature, the user's signing key is compromised, and a forger
can sign arbitrary messages. There is no harm in signing the
same message multiple times with the same key or different
keys.)
R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
R. Schroeppel, et al [Page 11]
INTERNET-DRAFT ECC Keys in the DNS
as an integer, and reduced (mod Q). (R must not be 0. In
this astronomically unlikely event, generate a new random K
and recalculate R.)
S = ( K^(-1) * (hash + X*R) ) mod Q.
S must not be 0. In this astronomically unlikely event, generate a
new random K and recalculate R and S.
If S > Q/2, set S = Q - S.
The pair (R,S) is the signature.
Another party verifies the signature as follows:
Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
valid EC sigature.
hash = SHA-1 ( data )
Sinv = S^(-1) mod Q.
U1 = (hash * Sinv) mod Q.
U2 = (R * Sinv) mod Q.
(U1 * G + U2 * Y) is computed on the elliptic curve.
V = (the W-coordinate of this point) interpreted as an integer
and reduced (mod Q).
The signature is valid if V = R.
The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
(R,Q-S) would be valid signatures for the same data. Note that a
signature that is valid for hash(data) is also valid for
hash(data)+Q or hash(data)-Q, if these happen to fall in the range
[0,2^160-1]. It's believed to be computationally infeasible to
find data that hashes to an assigned value, so this is only a
cosmetic blemish. The blemish can be eliminated by using Q >
2^160, at the cost of having slightly longer signatures, 42 octets
instead of 40.
We must specify how a field-element E ("the W-coordinate") is to be
interpreted as an integer. The field-element E is regarded as a
radix-P integer, with the digits being the coefficients in the
polynomial basis representation of E. The digits are in the ragne
[0,P-1]. In the two most common cases, this reduces to "the
obvious thing". In the (mod P) case, E is simply a residue mod P,
and is taken as an integer in the range [0,P-1]. In the GF[2^D]
R. Schroeppel, et al [Page 12]
INTERNET-DRAFT ECC Keys in the DNS
case, E is in the D-bit polynomial basis representation, and is
simply taken as an integer in the range [0,(2^D)-1]. For other
fields GF[P^D], it's necessary to do some radix conversion
arithmetic.
6. Performance Considerations
Elliptic curve signatures use smaller moduli or field sizes than
RSA and DSA. Creation of a curve is slow, but not done very often.
Key generation is faster than RSA or DSA.
DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
standardized to make larger transfers more efficient [RFC 2671].
However, it is still advisable at this time to make reasonable
efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security.
7. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
Some specific key generation considerations are given in the body
of this document.
8. IANA Considerations
The key and signature data structures defined herein correspond to
the value 4 in the Algorithm number field of the IANA registry
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in
defined in this document requires an IETF consensus as defined in
[RFC 2434].
R. Schroeppel, et al [Page 13]
INTERNET-DRAFT ECC Keys in the DNS
Copyright and Disclaimer
Copyright (C) The Internet Society 2005. This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
R. Schroeppel, et al [Page 14]
INTERNET-DRAFT ECC Keys in the DNS
Informational References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
August 1999.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June
2005.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
Curves", 1986, Springer Graduate Texts in mathematics #106.
Normative Refrences
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "Resource Records for the DNS Security Extensions", RFC
4034, March 2005.
R. Schroeppel, et al [Page 15]
INTERNET-DRAFT ECC Keys in the DNS
Author's Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: +1-505-844-9079(w)
Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in January 2006.
Its file name is draft-ietf-dnsext-ecc-key-07.txt.
R. Schroeppel, et al [Page 16]

754
contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt Normal file
View file

@ -0,0 +1,754 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Updates RFC 1034, 1035 Motorola Laboratories
Expires January 2006 July 2005
Domain Name System (DNS) Case Insensitivity Clarification
------ ---- ------ ----- ---- ------------- -------------
<draft-ietf-dnsext-insensitive-06.txt>
Donald E. Eastlake 3rd
Status of This Document
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the DNSEXT working group at namedroppers@ops.ietf.org.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Domain Name System (DNS) names are "case insensitive". This document
explains exactly what that means and provides a clear specification
of the rules. This clarification updates RFCs 1034 and 1035.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS Case Insensitivity
Acknowledgements
The contributions to this document of Rob Austein, Olafur
Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
are gratefully acknowledged.
Table of Contents
Status of This Document....................................1
Copyright Notice...........................................1
Abstract...................................................1
Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Case Insensitivity of DNS Labels........................3
2.1 Escaping Unusual DNS Label Octets......................3
2.2 Example Labels with Escapes............................4
3. Name Lookup, Label Types, and CLASS.....................4
3.1 Original DNS Label Types...............................5
3.2 Extended Label Type Case Insensitivity Considerations..5
3.3 CLASS Case Insensitivity Considerations................5
4. Case on Input and Output................................6
4.1 DNS Output Case Preservation...........................6
4.2 DNS Input Case Preservation............................6
5. Internationalized Domain Names..........................7
6. Security Considerations.................................8
Copyright and Disclaimer...................................9
Normative References.......................................9
Informative References....................................10
Changes Between Draft Version.............................11
-02 to -03 Changes........................................11
-03 to -04 Changes........................................11
-04 to -05 Changes........................................11
-05 to -06 Changes........................................12
Author's Address..........................................13
Expiration and File Name..................................13
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS Case Insensitivity
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. Each node in the DNS tree has a name consisting of
zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
case insensitive fashion. This document clarifies the meaning of
"case insensitive" for the DNS. This clarification updates RFCs 1034
and 1035 [STD 13].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Case Insensitivity of DNS Labels
DNS was specified in the era of [ASCII]. DNS names were expected to
look like most host names or Internet email address right halves (the
part after the at-sign, "@") or be numeric as in the in-addr.arpa
part of the DNS name space. For example,
foo.example.net.
aol.com.
www.gnu.ai.mit.edu.
or 69.2.0.192.in-addr.arpa.
Case varied alternatives to the above would be DNS names like
Foo.ExamplE.net.
AOL.COM.
WWW.gnu.AI.mit.EDU.
or 69.2.0.192.in-ADDR.ARPA.
However, the individual octets of which DNS names consist are not
limited to valid ASCII character codes. They are 8-bit bytes and all
values are allowed. Many applications, however, interpret them as
ASCII characters.
2.1 Escaping Unusual DNS Label Octets
In Master Files [STD 13] and other human readable and writable ASCII
contexts, an escape is needed for the byte value for period (0x2E,
".") and all octet values outside of the inclusive range of 0x21
("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS Case Insensitivity
One typographic convention for octets that do not correspond to an
ASCII printing graphic is to use a back-slash followed by the value
of the octet as an unsigned integer represented by exactly three
decimal digits.
The same convention can be used for printing ASCII characters so that
they will be treated as a normal label character. This includes the
back-slash character used in this convention itself which can be
expressed as \092 or \\ and the special label separator period (".")
which can be expressed as and \046 or \. respectively. It is
advisable to avoid using a backslash to quote an immediately
following non-printing ASCII character code to avoid implementation
difficulties.
A back-slash followed by only one or two decimal digits is undefined.
A back-slash followed by four decimal digits produces two octets, the
first octet having the value of the first three digits considered as
a decimal number and the second octet being the character code for
the fourth decimal digit.
2.2 Example Labels with Escapes
The first example below shows embedded spaces and a period (".")
within a label. The second one show a 5-octet label where the second
octet has all bits zero, the third is a backslash, and the fourth
octet has all bits one.
Donald\032E\.\032Eastlake\0323rd.example.
and a\000\\\255z.example.
3. Name Lookup, Label Types, and CLASS
The original DNS design decision was made that comparisons on name
lookup for DNS queries should be case insensitive [STD 13]. That is
to say, a lookup string octet with a value in the inclusive range of
0x41 to 0x5A, the upper case ASCII letters, MUST match the identical
value and also match the corresponding value in the inclusive range
0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet
with a lower case ASCII letter value MUST similarly match the
identical value and also match the corresponding value in the upper
case ASCII letter range.
(Historical Note: the terms "upper case" and "lower case" were
invented after movable type. The terms originally referred to the
two font trays for storing, in partitioned areas, the different
physical type elements. Before movable type, the nearest equivalent
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS Case Insensitivity
terms were "majuscule" and "minuscule".)
One way to implement this rule would be, when comparing octets, to
subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
before the comparison. Such an operation is commonly known as "case
folding" but implementation via case folding is not required. Note
that the DNS case insensitivity does NOT correspond to the case
folding specified in [iso-8859-1] or [iso-8859-2]. For example, the
octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
contexts, where they are interpreted as the upper and lower case
version of "Y" with an acute accent, they might.
3.1 Original DNS Label Types
DNS labels in wire-encoded names have a type associated with them.
The original DNS standard [RFC 1035] had only two types. ASCII
labels, with a length of from zero to 63 octets, and indirect (or
compression) labels which consist of an offset pointer to a name
location elsewhere in the wire encoding on a DNS message. (The ASCII
label of length zero is reserved for use as the name of the root node
of the name tree.) ASCII labels follow the ASCII case conventions
described herein and, as stated above, can actually contain arbitrary
byte values. Indirect labels are, in effect, replaced by the name to
which they point which is then treated with the case insensitivity
rules in this document.
3.2 Extended Label Type Case Insensitivity Considerations
DNS was extended by [RFC 2671] to have additional label type numbers
available. (The only such type defined so far is the BINARY type [RFC
2673] which is now Experimental [RFC 3363].)
The ASCII case insensitivity conventions only apply to ASCII labels,
that is to say, label type 0x0, whether appearing directly or invoked
by indirect labels.
3.3 CLASS Case Insensitivity Considerations
As described in [STD 13] and [RFC 2929], DNS has an additional axis
for data location called CLASS. The only CLASS in global use at this
time is the "IN" or Internet CLASS.
The handling of DNS label case is not CLASS dependent. With the
original design of DNS, it was intended that a recursive DNS resolver
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS Case Insensitivity
be able to handle new CLASSes that were unknown at the time of its
implementation. This requires uniform handling of label case
insensitivity. Should it become desireable, for example, to allocate
a CLASS with "case sensitive ASCII labels" for example, it would be
necessary to allocate a new label type for these labels.
4. Case on Input and Output
While ASCII label comparisons are case insensitive, [STD 13] says
case MUST be preserved on output, and preserved when convenient on
input. However, this means less than it would appear since the
preservation of case on output is NOT required when output is
optimized by the use of indirect labels, as explained below.
4.1 DNS Output Case Preservation
[STD 13] views the DNS namespace as a node tree. ASCII output is as
if a name was marshaled by taking the label on the node whose name is
to be output, converting it to a typographically encoded ASCII
string, walking up the tree outputting each label encountered, and
preceding all labels but the first with a period ("."). Wire output
follows the same sequence but each label is wire encoded and no
periods inserted. No "case conversion" or "case folding" is done
during such output operations, thus "preserving" case. However, to
optimize output, indirect labels may be used to point to names
elsewhere in the DNS answer. In determining whether the name to be
pointed to, for example the QNAME, is the "same" as the remainder of
the name being optimized, the case insensitive comparison specified
above is done. Thus such optimization may easily destroy the output
preservation of case. This type of optimization is commonly called
"name compression".
4.2 DNS Input Case Preservation
Originally, DNS data came from an ASCII Master File as defined in
[STD 13] or a zone transfer. DNS Dynamic update and incremental zone
transfers [RFC 1995] have been added as a source of DNS data [RFC
2136, 3007]. When a node in the DNS name tree is created by any of
such inputs, no case conversion is done. Thus the case of ASCII
labels is preserved if they are for nodes being created. However,
when a name label is input for a node that already exist in DNS data
being held, the situation is more complex. Implementations are free
to retain the case first loaded for such a label or allow new input
to override the old case or even maintain separate copies preserving
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS Case Insensitivity
the input case.
For example, if data with owner name "foo.bar.example" is loaded and
then later data with owner name "xyz.BAR.example" is input, the name
of the label on the "bar.example" node, i.e. "bar", might or might
not be changed to "BAR" in the DNS stored data or the actual input
case could be preserved. Thus later retrieval of data stored under
"xyz.bar.example" in this case can return all data with
"xyz.BAR.example" or all data with "xyz.bar.example" or even, when
more than one RR is being returned, a mixture of these two cases.
This last case is unlikely because optimization of answer length
through indirect labels tends to cause only copy of the name tail
("bar.example" or "BAR.example") to be used for all returned RRs.
Note that none of this has any effect on the number of completeness
of the RR set returned, only on the case of the names in the RR set
returned.
The same considerations apply when inputting multiple data records
with owner names differing only in case. For example, if an "A"
record is the first resourced record stored under owner name
"xyz.BAR.example" and then a second "A" record is stored under
"XYZ.BAR.example", the second MAY be stored with the first (lower
case initial label) name or the second MAY override the first so that
only an upper case initial label is retained or both capitalizations
MAY be kept in the DNS stored data. In any case, a retrieval with
either capitalization will retrieve all RRs with either
capitalization.
Note that the order of insertion into a server database of the DNS
name tree nodes that appear in a Master File is not defined so that
the results of inconsistent capitalization in a Master File are
unpredictable output capitalization.
5. Internationalized Domain Names
A scheme has been adopted for "internationalized domain names" and
"internationalized labels" as described in [RFC 3490, 3454, 3491, and
3492]. It makes most of [UNICODE] available through a separate
application level transformation from internationalized domain name
to DNS domain name and from DNS domain name to internationalized
domain name. Any case insensitivity that internationalized domain
names and labels have varies depending on the script and is handled
entirely as part of the transformation described in [RFC 3454] and
[RFC 3491] which should be seen for further details. This is not a
part of the DNS as standardized in STD 13.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS Case Insensitivity
6. Security Considerations
The equivalence of certain DNS label types with case differences, as
clarified in this document, can lead to security problems. For
example, a user could be confused by believing two domain names
differing only in case were actually different names.
Furthermore, a domain name may be used in contexts other than the
DNS. It could be used as a case sensitive index into some data base
or file system. Or it could be interpreted as binary data by some
integrity or authentication code system. These problems can usually
be handled by using a standardized or "canonical" form of the DNS
ASCII type labels, that is, always mapping the ASCII letter value
octets in ASCII labels to some specific pre-chosen case, either upper
case or lower case. An example of a canonical form for domain names
(and also a canonical ordering for them) appears in Section 6 of [RFC
4034]. See also [RFC 3597].
Finally, a non-DNS name may be stored into DNS with the false
expectation that case will always be preserved. For example, although
this would be quite rare, on a system with case sensitive email
address local parts, an attempt to store two "RP" records that
differed only in case would probably produce unexpected results that
might have security implications. That is because the entire email
address, including the possibly case sensitive local or left hand
part, is encoded into a DNS name in a readable fashion where the case
of some letters might be changed on output as described above.
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS Case Insensitivity
Copyright and Disclaimer
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Normative References
[ASCII] - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
[RFC 1034, 1035] - See [STD 13].
[RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
1996.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
[RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
Update", November 2000.
[RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
[RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[STD 13]
- P. Mockapetris, "Domain names - concepts and facilities", RFC
1034, November 1987.
- P. Mockapetris, "Domain names - implementation and
specification", RFC 1035, November 1987.
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT DNS Case Insensitivity
Informative References
[ISO 8859-1] - International Standards Organization, Standard for
Character Encodings, Latin-1.
[ISO 8859-2] - International Standards Organization, Standard for
Character Encodings, Latin-2.
[RFC 1591] - J. Postel, "Domain Name System Structure and
Delegation", March 1994.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
[RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
Name System (DNS) IANA Considerations", September 2000.
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
[RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
Foo", 1 April 2001.
[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
Internationalized String ("stringprep")", December 2002.
[RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", March 2003.
[RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (IDN)", March 2003.
[RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA)", March
2003.
[UNICODE] - The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/unicode/standard/standard.html>.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT DNS Case Insensitivity
Changes Between Draft Version
RFC Editor: The following summaries of changes between draft versions
are to be removed before publication.
-02 to -03 Changes
The following changes were made between draft version -02 and -03:
1. Add internationalized domain name section and references.
2. Change to indicate that later input of a label for an existing DNS
name tree node may or may not be normalized to the earlier input or
override it or both may be preserved.
3. Numerous minor wording changes.
-03 to -04 Changes
The following changes were made between draft versions -03 and -04:
1. Change to conform to the new IPR, Copyright, etc., notice
requirements.
2. Change in some section headers for clarity.
3. Drop section on wildcards.
4. Add emphasis on loss of case preservation due to name compression.
5. Add references to RFCs 1995 and 3092.
-04 to -05 Changes
The following changes were made between draft versions -04 and -05:
1. More clearly state that this draft updates RFCs 1034, 1035 [STD
13].
2. Add informative references to ISO 8859-1 and ISO 8859-2.
3. Fix hyphenation and capitalization nits.
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT DNS Case Insensitivity
-05 to -06 Changes
The following changes were made between draft version -05 and -06.
1. Add notation to the RFC Editor that the draft version change
summaries are to be removed before RFC publication.
2. Additional text explaining why labe case insensitivity is CLASS
independent.
3. Changes and additional text clarifying that the fact that
inconsistent case in data loaded into DNS may result in
unpredicatable or inconsistent case in DNS storage but has no effect
on the completeness of RR sets retrieved.
4. Add reference to [RFC 3363] and update reference to [RFC 2535] to
be to [RFC 4034].
D. Eastlake 3rd [Page 12]
INTERNET-DRAFT DNS Case Insensitivity
Author's Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires January 2006.
Its file name is draft-ietf-dnsext-insensitive-06.txt.
D. Eastlake 3rd [Page 13]

334
contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt Normal file
View file

@ -0,0 +1,334 @@
DNS Extensions Working Group J. Schlyter
Internet-Draft May 19, 2005
Expires: November 20, 2005
RFC 3597 Interoperability Report
draft-ietf-dnsext-interop3597-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo documents the result from the RFC 3597 (Handling of Unknown
DNS Resource Record Types) interoperability testing.
Schlyter Expires November 20, 2005 [Page 1]
Internet-Draft RFC 3597 Interoperability Report May 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3
3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3
3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3
3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4
3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4
3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4
4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . 6
Schlyter Expires November 20, 2005 [Page 2]
Internet-Draft RFC 3597 Interoperability Report May 2005
1. Introduction
This memo documents the result from the RFC 3597 (Handling of Unknown
DNS Resource Record Types) interoperability testing. The test was
performed during June and July 2004 by request of the IETF DNS
Extensions Working Group.
2. Implementations
The following is a list, in alphabetic order, of implementations
tested for compliance with RFC 3597:
DNSJava 1.6.4
ISC BIND 8.4.5
ISC BIND 9.3.0
NSD 2.1.1
Net::DNS 0.47 patchlevel 1
Nominum ANS 2.2.1.0.d
These implementations covers the following functions (number of
implementations tested for each function in paranthesis):
Authoritative Name Servers (4)
Full Recursive Resolver (2)
Stub Resolver (4)
DNSSEC Zone Signers (2)
All listed implementations are genetically different.
3. Tests
The following tests was been performed to validate compliance with
RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
and 5 ("Text Representation").
3.1 Authoritative Primary Name Server
The test zone data (Appendix A) was loaded into the name server
implementation and the server was queried for the loaded information.
3.2 Authoritative Secondary Name Server
The test zone data (Appendix A) was transferred using AXFR from
another name server implementation and the server was queried for the
transferred information.
Schlyter Expires November 20, 2005 [Page 3]
Internet-Draft RFC 3597 Interoperability Report May 2005
3.3 Full Recursive Resolver
A recursive resolver was queried for resource records from a domain
with the test zone data (Appendix A).
3.4 Stub Resolver
A stub resolver was used to query resource records from a domain with
the test zone data (Appendix A).
3.5 DNSSEC Signer
A DNSSEC signer was used to sign a zone with test zone data
(Appendix A).
4. Problems found
Two implementations had problems with text presentation of zero
length RDATA.
One implementation had problems with text presentation of RR type
code and classes >= 4096.
Bug reports were filed for problems found.
5. Summary
Unknown type codes works in the tested authoritative servers,
recursive resolvers and stub clients.
No changes are needed to advance RFC 3597 to draft standard.
6. Normative References
[1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
Author's Address
Jakob Schlyter
Email: jakob@rfc.se
Schlyter Expires November 20, 2005 [Page 4]
Internet-Draft RFC 3597 Interoperability Report May 2005
Appendix A. Test zone data
; A-record encoded as TYPE1
a TYPE1 \# 4 7f000001
a TYPE1 192.0.2.1
a A \# 4 7f000002
; draft-ietf-secsh-dns-05.txt
sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
; bogus test record (from RFC 3597)
type731 TYPE731 \# 6 abcd (
ef 01 23 45 )
; zero length RDATA (from RFC 3597)
type62347 TYPE62347 \# 0
Schlyter Expires November 20, 2005 [Page 5]
Internet-Draft RFC 3597 Interoperability Report May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schlyter Expires November 20, 2005 [Page 6]

1740
contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt Normal file
View file

File diff suppressed because it is too large Load diff

2072
contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt Normal file
View file

File diff suppressed because it is too large Load diff

464
contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt Normal file
View file

@ -0,0 +1,464 @@
INTERNET-DRAFT DSA Information in the DNS
OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
Motorola Laboratories
Expires: January 2006 July 2005
DSA Keying and Signature Information in the DNS
--- ------ --- --------- ----------- -- --- ---
<draft-ietf-dnsext-rfc2536bis-dsa-06.txt>
Donald E. Eastlake 3rd
Status of This Document
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the DNS extensions working group mailing list
<namedroppers@ops.ietf.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The standard method of encoding US Government Digital Signature
Algorithm keying and signature information for use in the Domain Name
System is specified.
Copyright Notice
Copyright (C) The Internet Society 2005. All Rights Reserved.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DSA Information in the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright Notice...........................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DSA Keying Information..................................3
3. DSA Signature Information...............................4
4. Performance Considerations..............................4
5. Security Considerations.................................5
6. IANA Considerations.....................................5
Copyright and Disclaimer...................................5
Normative References.......................................7
Informative References.....................................7
Authors Address............................................8
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DSA Information in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information [RFC 1034, 1035]. The DNS has been extended to
include digital signatures and cryptographic keys as described in
[RFC 4033, 4034, 4035] and additional work is underway which would
require the storage of keying and signature information in the DNS.
This document describes how to encode US Government Digital Signature
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
2. DSA Keying Information
When DSA public keys are stored in the DNS, the structure of the
relevant part of the RDATA part of the RR being used is the fields
listed below in the order given.
The period of key validity is not included in this data but is
indicated separately, for example by an RR such as RRSIG which signs
and authenticates the RR containing the keying information.
Field Size
----- ----
T 1 octet
Q 20 octets
P 64 + T*8 octets
G 64 + T*8 octets
Y 64 + T*8 octets
As described in [FIPS 186-2] and [Schneier], T is a key size
parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
is greater than 8 is reserved and the remainder of the data may have
a different format in that case.) Q is a prime number selected at
key generation time such that 2**159 < Q < 2**160. Thus Q is always
20 octets long and, as with all other fields, is stored in "big-
endian" network order. P, G, and Y are calculated as directed by the
[FIPS 186-2] key generation algorithm [Schneier]. P is in the range
2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
and Y are quantities modulo P and so can be up to the same length as
P and are allocated fixed size fields with the same number of octets
as P.
During the key generation process, a random number X must be
generated such that 1 <= X <= Q-1. X is the private key and is used
in the final step of public key generation where Y is computed as
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DSA Information in the DNS
Y = G**X mod P
3. DSA Signature Information
The portion of the RDATA area used for US Digital Signature Algorithm
signature information is shown below with fields in the order they
are listed and the contents of each multi-octet field in "big-endian"
network order.
Field Size
----- ----
T 1 octet
R 20 octets
S 20 octets
First, the data signed must be determined. Then the following steps
are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
specified in the public key [Schneier]:
hash = SHA-1 ( data )
Generate a random K such that 0 < K < Q.
R = ( G**K mod P ) mod Q
S = ( K**(-1) * (hash + X*R) ) mod Q
For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
3174].
Since Q is 160 bits long, R and S can not be larger than 20 octets,
which is the space allocated.
T is copied from the public key. It is not logically necessary in
the SIG but is present so that values of T > 8 can more conveniently
be used as an escape for extended versions of DSA or other algorithms
as later standardized.
4. Performance Considerations
General signature generation speeds are roughly the same for RSA [RFC
3110] and DSA. With sufficient pre-computation, signature generation
with DSA is faster than RSA. Key generation is also faster for DSA.
However, signature verification is an order of magnitude slower than
RSA when the RSA public exponent is chosen to be small, as is
recommended for some applications.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DSA Information in the DNS
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient, it
is still advisable at this time to make reasonable efforts to
minimize the size of RR sets containing keying and/or signature
inforamtion consistent with adequate security.
5. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
current DSA standard may limit the security of DSA. For particular
applications, implementors are encouraged to consider the range of
available algorithms and key sizes.
DSA assumes the ability to frequently generate high quality random
numbers. See [random] for guidance. DSA is designed so that if
biased rather than random numbers are used, high bandwidth covert
channels are possible. See [Schneier] and more recent research. The
leakage of an entire DSA private key in only two DSA signatures has
been demonstrated. DSA provides security only if trusted
implementations, including trusted random number generation, are
used.
6. IANA Considerations
Allocation of meaning to values of the T parameter that are not
defined herein (i.e., > 8 ) requires an IETF standards actions. It
is intended that values unallocated herein be used to cover future
extensions of the DSS standard.
Copyright and Disclaimer
Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DSA Information in the DNS
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DSA Information in the DNS
Normative References
[FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
Signature Standard, 27 January 2000.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Informative References
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987.
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
1999.
[RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
(DNS)", D. Eastlake 3rd. May 2001.
[RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
Jones, September 2001.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[Schneier] - "Applied Cryptography Second Edition: protocols,
algorithms, and source code in C" (second edition), Bruce Schneier,
1996, John Wiley and Sons, ISBN 0-471-11709-9.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DSA Information in the DNS
Authors Address
Donald E. Eastlake 3rd
Motorola Labortories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554(w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in January 2006.
Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
D. Eastlake 3rd [Page 8]

840
contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt Normal file
View file

@ -0,0 +1,840 @@
Network Working Group S. Josefsson
Internet-Draft August 30, 2005
Expires: March 3, 2006
Storing Certificates in the Domain Name System (DNS)
draft-ietf-dnsext-rfc2538bis-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Cryptographic public keys are frequently published and their
authenticity demonstrated by certificates. A CERT resource record
(RR) is defined so that such certificates and related certificate
revocation lists can be stored in the Domain Name System (DNS).
This document obsoletes RFC 2538.
Josefsson Expires March 3, 2006 [Page 1]
Internet-Draft Storing Certificates in the DNS August 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4
2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5
2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9
3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
4. Performance Considerations . . . . . . . . . . . . . . . . . . 10
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Josefsson Expires March 3, 2006 [Page 2]
Internet-Draft Storing Certificates in the DNS August 2005
1. Introduction
Public keys are frequently published in the form of a certificate and
their authenticity is commonly demonstrated by certificates and
related certificate revocation lists (CRLs). A certificate is a
binding, through a cryptographic digital signature, of a public key,
a validity interval and/or conditions, and identity, authorization,
or other information. A certificate revocation list is a list of
certificates that are revoked, and incidental information, all signed
by the signer (issuer) of the revoked certificates. Examples are
X.509 certificates/CRLs in the X.500 directory system or OpenPGP
certificates/revocations used by OpenPGP software.
Section 2 below specifies a CERT resource record (RR) for the storage
of certificates in the Domain Name System [1] [2].
Section 3 discusses appropriate owner names for CERT RRs.
Sections 4, 5, and 6 below cover performance, IANA, and security
considerations, respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3].
2. The CERT Resource Record
The CERT resource record (RR) has the structure given below. Its RR
type code is 37.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or CRL /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The type field is the certificate type as defined in section 2.1
below.
The key tag field is the 16 bit value computed for the key embedded
in the certificate, using the RRSIG Key Tag algorithm described in
Appendix B of [10]. This field is used as an efficiency measure to
pick which CERT RRs may be applicable to a particular key. The key
Josefsson Expires March 3, 2006 [Page 3]
Internet-Draft Storing Certificates in the DNS August 2005
tag can be calculated for the key in question and then only CERT RRs
with the same key tag need be examined. However, the key must always
be transformed to the format it would have as the public key portion
of a DNSKEY RR before the key tag is computed. This is only possible
if the key is applicable to an algorithm (and limits such as key size
limits) defined for DNS security. If it is not, the algorithm field
MUST BE zero and the tag field is meaningless and SHOULD BE zero.
The algorithm field has the same meaning as the algorithm field in
DNSKEY and RRSIG RRs [10], except that a zero algorithm field
indicates the algorithm is unknown to a secure DNS, which may simply
be the result of the algorithm not having been standardized for
DNSSEC.
2.1. Certificate Type Values
The following values are defined or reserved:
Value Mnemonic Certificate Type
----- -------- ----------------
0 reserved
1 PKIX X.509 as per PKIX
2 SPKI SPKI certificate
3 PGP OpenPGP packet
4 IPKIX The URL of an X.509 data object
5 ISPKI The URL of an SPKI certificate
6 IPGP The URL of an OpenPGP packet
7-252 available for IANA assignment
253 URI URI private
254 OID OID private
255-65534 available for IANA assignment
65535 reserved
The PKIX type is reserved to indicate an X.509 certificate conforming
to the profile being defined by the IETF PKIX working group. The
certificate section will start with a one-byte unsigned OID length
and then an X.500 OID indicating the nature of the remainder of the
certificate section (see 2.3 below). (NOTE: X.509 certificates do
not include their X.500 directory type designating OID as a prefix.)
The SPKI type is reserved to indicate the SPKI certificate format
[13], for use when the SPKI documents are moved from experimental
status.
The PGP type indicates an OpenPGP packet as described in [6] and its
extensions and successors. Two uses are to transfer public key
material and revocation signatures. The data is binary, and MUST NOT
be encoded into an ASCII armor. An implementation SHOULD process
Josefsson Expires March 3, 2006 [Page 4]
Internet-Draft Storing Certificates in the DNS August 2005
transferable public keys as described in section 10.1 of [6], but it
MAY handle additional OpenPGP packets.
The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
content that would have been in the "certificate, CRL or URL" field
of the corresponding (PKIX, SPKI or PGP) packet types. These types
are known as "indirect". These packet types MUST be used when the
content is too large to fit in the CERT RR, and MAY be used at the
implementer's discretion. They SHOULD NOT be used where the entire
UDP packet would have fit in 512 bytes.
The URI private type indicates a certificate format defined by an
absolute URI. The certificate portion of the CERT RR MUST begin with
a null terminated URI [5] and the data after the null is the private
format certificate itself. The URI SHOULD be such that a retrieval
from it will lead to documentation on the format of the certificate.
Recognition of private certificate types need not be based on URI
equality but can use various forms of pattern matching so that, for
example, subtype or version information can also be encoded into the
URI.
The OID private type indicates a private format certificate specified
by an ISO OID prefix. The certificate section will start with a one-
byte unsigned OID length and then a BER encoded OID indicating the
nature of the remainder of the certificate section. This can be an
X.509 certificate format or some other format. X.509 certificates
that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
type, not the OID private type. Recognition of private certificate
types need not be based on OID equality but can use various forms of
pattern matching such as OID prefix.
2.2. Text Representation of CERT RRs
The RDATA portion of a CERT RR has the type field as an unsigned
decimal integer or as a mnemonic symbol as listed in section 2.1
above.
The key tag field is represented as an unsigned decimal integer.
The algorithm field is represented as an unsigned decimal integer or
a mnemonic symbol as listed in [10].
The certificate / CRL portion is represented in base 64 [14] and may
be divided up into any number of white space separated substrings,
down to single base 64 digits, which are concatenated to obtain the
full signature. These substrings can span lines using the standard
parenthesis.
Josefsson Expires March 3, 2006 [Page 5]
Internet-Draft Storing Certificates in the DNS August 2005
Note that the certificate / CRL portion may have internal sub-fields,
but these do not appear in the master file representation. For
example, with type 254, there will be an OID size, an OID, and then
the certificate / CRL proper. But only a single logical base 64
string will appear in the text representation.
2.3. X.509 OIDs
OIDs have been defined in connection with the X.500 directory for
user certificates, certification authority certificates, revocations
of certification authority, and revocations of user certificates.
The following table lists the OIDs, their BER encoding, and their
length-prefixed hex format for use in CERT RRs:
id-at-userCertificate
= { joint-iso-ccitt(2) ds(5) at(4) 36 }
== 0x 03 55 04 24
id-at-cACertificate
= { joint-iso-ccitt(2) ds(5) at(4) 37 }
== 0x 03 55 04 25
id-at-authorityRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 38 }
== 0x 03 55 04 26
id-at-certificateRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 39 }
== 0x 03 55 04 27
3. Appropriate Owner Names for CERT RRs
It is recommended that certificate CERT RRs be stored under a domain
name related to their subject, i.e., the name of the entity intended
to control the private key corresponding to the public key being
certified. It is recommended that certificate revocation list CERT
RRs be stored under a domain name related to their issuer.
Following some of the guidelines below may result in the use in DNS
names of characters that require DNS quoting which is to use a
backslash followed by the octal representation of the ASCII code for
the character (e.g., \000 for NULL).
The choice of name under which CERT RRs are stored is important to
clients that perform CERT queries. In some situations, the clients
may not know all information about the CERT RR object it wishes to
retrieve. For example, a client may not know the subject name of an
X.509 certificate, or the e-mail address of the owner of an OpenPGP
key. Further, the client might only know the hostname of a service
that uses X.509 certificates or the Key ID of an OpenPGP key.
Josefsson Expires March 3, 2006 [Page 6]
Internet-Draft Storing Certificates in the DNS August 2005
Therefore, two owner name guidelines are defined: content-based owner
names and purpose-based owner names. A content-based owner name is
derived from the content of the CERT RR data; for example, the
Subject field in an X.509 certificate or the User ID field in OpenPGP
keys. A purpose-based owner name is a name that a client retrieving
CERT RRs MUST already know; for example, the host name of an X.509
protected service or the Key ID of an OpenPGP key. The content-based
and purpose-based owner name MAY be the same; for example, when a
client looks up a key based on the From: address of an incoming
e-mail.
Implementations SHOULD use the purpose-based owner name guidelines
described in this document, and MAY use CNAMEs of content-based owner
names (or other names), pointing to the purpose-based owner name.
3.1. Content-based X.509 CERT RR Names
Some X.509 versions permit multiple names to be associated with
subjects and issuers under "Subject Alternate Name" and "Issuer
Alternate Name". For example, X.509v3 has such Alternate Names with
an ASN.1 specification as follows:
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] EXPLICIT OR-ADDRESS.&Type,
directoryName [4] EXPLICIT Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER
}
The recommended locations of CERT storage are as follows, in priority
order:
1. If a domain name is included in the identification in the
certificate or CRL, that should be used.
2. If a domain name is not included but an IP address is included,
then the translation of that IP address into the appropriate
inverse domain name should be used.
3. If neither of the above is used, but a URI containing a domain
name is present, that domain name should be used.
4. If none of the above is included but a character string name is
included, then it should be treated as described for OpenPGP
names below.
Josefsson Expires March 3, 2006 [Page 7]
Internet-Draft Storing Certificates in the DNS August 2005
5. If none of the above apply, then the distinguished name (DN)
should be mapped into a domain name as specified in [4].
Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
uri <https://www.secure.john-doe.com:8080/>. The storage locations
recommended, in priority order, would be
1. john-doe.com,
2. www.secure.john-doe.com, and
3. Doe.com.xy.
Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
(c) string "James Hacker <hacker@mail.widget.foo.example>". The
storage locations recommended, in priority order, would be
1. widget.foo.example,
2. 201.13.251.10.in-addr.arpa, and
3. hacker.mail.widget.foo.example.
3.2. Purpose-based X.509 CERT RR Names
Due to the difficulty for clients that do not already possess a
certificate to reconstruct the content-based owner name, purpose-
based owner names are recommended in this section. Recommendations
for purpose-based owner names vary per scenario. The following table
summarizes the purpose-based X.509 CERT RR owner name guidelines for
use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
Scenario Owner name
------------------ ----------------------------------------------
S/MIME Certificate Standard translation of an RFC 2822 email
address. Example: An S/MIME certificate for
"postmaster@example.org" will use a standard
hostname translation of the owner name,
"postmaster.example.org".
TLS Certificate Hostname of the TLS server.
IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4
or IPv6 addresses, the fully qualified domain
name in the appropriate reverse domain.
An alternate approach for IPSEC is to store raw public keys [15].
Josefsson Expires March 3, 2006 [Page 8]
Internet-Draft Storing Certificates in the DNS August 2005
3.3. Content-based OpenPGP CERT RR Names
OpenPGP signed keys (certificates) use a general character string
User ID [6]. However, it is recommended by OpenPGP that such names
include the RFC 2822 [8] email address of the party, as in "Leslie
Example <Leslie@host.example>". If such a format is used, the CERT
should be under the standard translation of the email address into a
domain name, which would be leslie.host.example in this case. If no
RFC 2822 name can be extracted from the string name, no specific
domain name is recommended.
If a user has more than one email address, the CNAME type can be used
to reduce the amount of data stored in the DNS. Example:
$ORIGIN example.org.
smith IN CERT PGP 0 0 <OpenPGP binary>
john.smith IN CNAME smith
js IN CNAME smith
3.4. Purpose-based OpenPGP CERT RR Names
Applications that receive an OpenPGP packet containing encrypted or
signed data but do not know the email address of the sender will have
difficulties constructing the correct owner name and cannot use the
content-based owner name guidelines. However, these clients commonly
know the key fingerprint or the Key ID. The key ID is found in
OpenPGP packets, and the key fingerprint is commonly found in
auxilliary data that may be available. In this case, use of an owner
name identical to the key fingerprint and the key ID expressed in
hexadecimal [14] is recommended. Example:
$ORIGIN example.org.
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
F835EDA21E94B565716F IN CERT PGP ...
B565716F IN CERT PGP ...
If the same key material is stored for several owner names, the use
of CNAME may be used to avoid data duplication. Note that CNAME is
not always applicable, because it maps one owner name to the other
for all purposes, which may be sub-optimal when two keys with the
same Key ID are stored.
3.5. Owner names for IPKIX, ISPKI, and IPGP
These types are stored under the same owner names, both purpose- and
content-based, as the PKIX, SPKI and PGP types.
Josefsson Expires March 3, 2006 [Page 9]
Internet-Draft Storing Certificates in the DNS August 2005
4. Performance Considerations
Current Domain Name System (DNS) implementations are optimized for
small transfers, typically not more than 512 bytes including
overhead. While larger transfers will perform correctly and work is
underway to make larger transfers more efficient, it is still
advisable at this time to make every reasonable effort to minimize
the size of certificates stored within the DNS. Steps that can be
taken may include using the fewest possible optional or extension
fields and using short field values for necessary variable length
fields.
The RDATA field in the DNS protocol may only hold data of size 65535
octets (64kb) or less. This means that each CERT RR MUST NOT contain
more than 64kb of payload, even if the corresponding certificate or
certificate revocation list is larger. This document addresses this
by defining "indirect" data types for each normal type.
5. Contributors
The majority of this document is copied verbatim from RFC 2538, by
Donald Eastlake 3rd and Olafur Gudmundsson.
6. Acknowledgements
Thanks to David Shaw and Michael Graff for their contributions to
earlier works that motivated, and served as inspiration for, this
document.
This document was improved by suggestions and comments from Olivier
Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is
incomplete. We apologize to anyone we left out.
7. Security Considerations
By definition, certificates contain their own authenticating
signature. Thus, it is reasonable to store certificates in non-
secure DNS zones or to retrieve certificates from DNS with DNS
security checking not implemented or deferred for efficiency. The
results MAY be trusted if the certificate chain is verified back to a
known trusted key and this conforms with the user's security policy.
Alternatively, if certificates are retrieved from a secure DNS zone
with DNS security checking enabled and are verified by DNS security,
Josefsson Expires March 3, 2006 [Page 10]
Internet-Draft Storing Certificates in the DNS August 2005
the key within the retrieved certificate MAY be trusted without
verifying the certificate chain if this conforms with the user's
security policy.
If an organization chooses to issue certificates for it's employees,
placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
is in use, it is possible for someone to enumerate all employees of
the organization. This is usually not considered desirable, for the
same reason enterprise phone listings are not often publicly
published and are even mark confidential.
When the URI type is used, it should be understood that it introduces
an additional indirection that may allow for a new attack vector.
One method to secure that indirection is to include a hash of the
certificate in the URI itself.
CERT RRs are not used by DNSSEC [9], so there are no security
considerations related to CERT RRs and securing the DNS itself.
If DNSSEC is used, then the non-existence of a CERT RR and,
consequently, certificates or revocation lists can be securely
asserted. Without DNSSEC, this is not possible.
8. IANA Considerations
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
only be assigned by an IETF standards action [7]. This document
assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate
types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
based on RFC documentation of the certificate type. The availability
of private types under 0x00FD and 0x00FE should satisfy most
requirements for proprietary or private types.
The CERT RR reuses the DNS Security Algorithm Numbers registry. In
particular, the CERT RR requires that algorithm number 0 remain
reserved, as described in Section 2. The IANA is directed to
reference the CERT RR as a user of this registry and value 0, in
particular.
9. Changes since RFC 2538
1. Editorial changes to conform with new document requirements,
including splitting reference section into two parts and
updating the references to point at latest versions, and to add
some additional references.
Josefsson Expires March 3, 2006 [Page 11]
Internet-Draft Storing Certificates in the DNS August 2005
2. Improve terminology. For example replace "PGP" with "OpenPGP",
to align with RFC 2440.
3. In section 2.1, clarify that OpenPGP public key data are binary,
not the ASCII armored format, and reference 10.1 in RFC 2440 on
how to deal with OpenPGP keys, and acknowledge that
implementations may handle additional packet types.
4. Clarify that integers in the representation format are decimal.
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
terminology. Improve reference for Key Tag Algorithm
calculations.
6. Add examples that suggest use of CNAME to reduce bandwidth.
7. In section 3, appended the last paragraphs that discuss
"content-based" vs "purpose-based" owner names. Add section 3.2
for purpose-based X.509 CERT owner names, and section 3.4 for
purpose-based OpenPGP CERT owner names.
8. Added size considerations.
9. The SPKI types has been reserved, until RFC 2692/2693 is moved
from the experimental status.
10. Added indirect types IPKIX, ISPKI, and IPGP.
Appendix A. Copying conditions
Regarding the portion of this document that was written by Simon
Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to
anyone to use, modify, and distribute it in any way that does not
diminish the rights of anyone else to use, modify, and distribute it,
provided that redistributed derivative works do not contain
misleading author or version information. Derivative works need not
be licensed under similar terms.
10. References
10.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
Josefsson Expires March 3, 2006 [Page 12]
Internet-Draft Storing Certificates in the DNS August 2005
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
January 1998.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
10.2. Informative References
[11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.
[14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[15] Richardson, M., "A Method for Storing IPsec Keying Material in
DNS", RFC 4025, March 2005.
[16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
Josefsson Expires March 3, 2006 [Page 13]
Internet-Draft Storing Certificates in the DNS August 2005
Author's Address
Simon Josefsson
Email: simon@josefsson.org
Josefsson Expires March 3, 2006 [Page 14]
Internet-Draft Storing Certificates in the DNS August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Josefsson Expires March 3, 2006 [Page 15]

Some files were not shown because too many files have changed in this diff Show more