This commit was generated by cvs2svn to compensate for changes in r153816,
which included commits to RCS files with non-trunk default branches.
This commit is contained in:
Doug Barton
commit
51396b745e
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=153817
@ -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]
|
||||
|
||||
@ -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
1007
contrib/bind9/FAQ.xml
Normal file
File diff suppressed because it is too large
Load Diff
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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>
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
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;
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -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
|
||||
|
||||
@ -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;
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
|
||||
@ -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 -- 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 — 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
|
||||
> — recursion
|
||||
desired — 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> — recursion
|
||||
desired — 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>
|
||||
|
||||
@ -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.
|
||||
*/
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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 -- 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 — 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>
|
||||
|
||||
@ -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 $@ \
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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 <TBA\>. 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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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");
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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>
|
||||
|
||||
@ -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:
|
||||
/*
|
||||
|
||||
@ -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);
|
||||
|
||||
@ -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;
|
||||
|
||||
|
||||
@ -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();
|
||||
|
||||
@ -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
44
contrib/bind9/bin/named/include/named/ns_smf_globals.h
Normal 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 */
|
||||
@ -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:
|
||||
|
||||
@ -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),
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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>
|
||||
|
||||
@ -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();
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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().
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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>
|
||||
|
||||
@ -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;
|
||||
|
||||
@ -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 */
|
||||
|
||||
@ -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
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@ -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);
|
||||
}
|
||||
|
||||
|
||||
|
||||
@ -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);
|
||||
|
||||
@ -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);
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -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
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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\
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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>
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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>
|
||||
|
||||
@ -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
|
||||
> -- 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> — 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
152
contrib/bind9/config.threads.in
Normal 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
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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@
|
||||
|
||||
@ -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 "—">]>
|
||||
<!--
|
||||
- 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> <<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>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -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 — 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"
|
||||
> </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>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -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"
|
||||
> </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>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -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"
|
||||
> // 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
|
||||
> 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"
|
||||
> </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>
|
||||
|
||||
@ -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"
|
||||
> </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>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
8964
contrib/bind9/doc/arm/Bv9ARM.pdf
Executable file
8964
contrib/bind9/doc/arm/Bv9ARM.pdf
Executable file
File diff suppressed because one or more lines are too long
@ -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
928
contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt
Normal 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
562
contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt
Normal 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
1397
contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
Normal file
File diff suppressed because it is too large
Load Diff
@ -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]
|
||||
|
||||
@ -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]
|
||||
|
||||
@ -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
896
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
Normal 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
839
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
Normal 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
928
contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
Normal 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
754
contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt
Normal 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
334
contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt
Normal 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
1740
contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt
Normal file
File diff suppressed because it is too large
Load Diff
2072
contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
Normal file
2072
contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
Normal 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
464
contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
Normal 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
840
contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
Normal 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
Loading…
Reference in New Issue
Block a user