trust-anchor-telemetry
++ Logs trust-anchor-telemetry requests received by named. +
+unmatched
- In BIND 8, this enables keeping of + In BIND 8, this enabled keeping of statistics for every host that the name server interacts with. Not implemented in BIND 9. @@ -6527,128 +6537,71 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
+ In BIND 8, this option indicated network topology + so that preferential treatment could be given to + the topologicaly closest name servers when sending + queries. It is not implemented in BIND 9. +
+- All other things being equal, when the server chooses a name - server - to query from a list of name servers, it prefers the one that is - topologically closest to itself. The topology statement - takes an address_match_list and - interprets it - in a special way. Each top-level list element is assigned a - distance. - Non-negated elements get a distance based on their position in the - list, where the closer the match is to the start of the list, the - shorter the distance is between it and the server. A negated match - will be assigned the maximum distance from the server. If there - is no match, the address will get a distance which is further than - any non-negated list element, and closer than any negated element. - For example, -
- -topology {
- 10/8;
- !1.2.3/24;
- { 1.2/16; 3/8; };
-};
-
- - will prefer servers on network 10 the most, followed by hosts - on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the - exception of hosts on network 1.2.3 (netmask 255.255.255.0), which - is preferred least of all. -
-- The default topology is -
- - topology { localhost; localnets; };
-
-
- - The topology option - is not implemented in BIND 9. -
-The response to a DNS query may consist of multiple resource - records (RRs) forming a resource record set (RRset). - The name server will normally return the - RRs within the RRset in an indeterminate order - (but see the rrset-order - statement in the section called “RRset Ordering”). - The client resolver code should rearrange the RRs as appropriate, - that is, using any addresses on the local net in preference to - other addresses. - However, not all resolvers can do this or are correctly - configured. - When a client is using a local server, the sorting can be performed - in the server, based on the client's address. This only requires - configuring the name servers, not all the clients. + records (RRs) forming a resource record set (RRset). The name + server will normally return the RRs within the RRset in an + indeterminate order (but see the rrset-order + statement in the section called “RRset Ordering”). The client + resolver code should rearrange the RRs as appropriate, that is, + using any addresses on the local net in preference to other + addresses. However, not all resolvers can do this or are + correctly configured. When a client is using a local server, + the sorting can be performed in the server, based on the + client's address. This only requires configuring the name + servers, not all the clients.
- The sortlist statement (see below) - takes - an address_match_list and - interprets it even - more specifically than the topology - statement - does (the section called “Topology”). - Each top level statement in the sortlist must - itself be an explicit address_match_list with - one or two elements. The first element (which may be an IP - address, - an IP prefix, an ACL name or a nested address_match_list) - of each top level list is checked against the source address of + The sortlist statement (see below) takes an + address_match_list and interprets it in a + special way. Each top level statement in the + sortlist must itself be an explicit + address_match_list with one or two elements. + The first element (which may be an IP address, an IP prefix, an + ACL name or a nested address_match_list) of + each top level list is checked against the source address of the query until a match is found.
- Once the source address of the query has been matched, if - the top level statement contains only one element, the actual - primitive - element that matched the source address is used to select the - address - in the response to move to the beginning of the response. If the - statement is a list of two elements, then the second element is - treated the same as the address_match_list in - a topology statement. Each top - level element - is assigned a distance and the address in the response with the - minimum - distance is moved to the beginning of the response. + Once the source address of the query has been matched, if the + top level statement contains only one element, the actual + primitive element that matched the source address is used to + select the address in the response to move to the beginning of + the response. If the statement is a list of two elements, then + the second element is interpreted as a topology preference + list. Each top level element is assigned a distance and the + address in the response with the minimum distance is moved to + the beginning of the response.
- In the following example, any queries received from any of - the addresses of the host itself will get responses preferring - addresses - on any of the locally connected networks. Next most preferred are - addresses - on the 192.168.1/24 network, and after that either the - 192.168.2/24 - or - 192.168.3/24 network with no preference shown between these two - networks. Queries received from a host on the 192.168.1/24 network - will prefer other addresses on that network to the 192.168.2/24 - and - 192.168.3/24 networks. Queries received from a host on the - 192.168.4/24 - or the 192.168.5/24 network will only prefer other addresses on + In the following example, any queries received from any of the + addresses of the host itself will get responses preferring + addresses on any of the locally connected networks. Next most + preferred are addresses on the 192.168.1/24 network, and after + that either the 192.168.2/24 or 192.168.3/24 network with no + preference shown between these two networks. Queries received + from a host on the 192.168.1/24 network will prefer other + addresses on that network to the 192.168.2/24 and 192.168.3/24 + networks. Queries received from a host on the 192.168.4/24 or + the 192.168.5/24 network will only prefer other addresses on their directly connected networks.
@@ -6678,15 +6631,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };The following example will give reasonable behavior for the - local host and hosts on directly connected networks. It is similar - to the behavior of the address sort in BIND 4.9.x. Responses sent - to queries from the local host will favor any of the directly - connected + local host and hosts on directly connected networks. It is + similar to the behavior of the address sort in + BIND 4.9.x. Responses sent to queries from + the local host will favor any of the directly connected networks. Responses sent to queries from any other hosts on a - directly - connected network will prefer addresses on that same network. - Responses - to other queries will not be sorted. + directly connected network will prefer addresses on that same + network. Responses to other queries will not be sorted.
sortlist {
@@ -10431,38 +10382,52 @@ example.com. NS ns2.example.net.
is present, it is a configuration error for the
allow-update statement to be
present. The update-policy statement
- only examines the signer of a message; the source
+ (except when set to local) only
+ examines the signer of a message; the source
address is not relevant.
- There is a pre-defined update-policy
- rule which can be switched on with the command
+ A pre-defined update-policy rule can be
+ switched on with the command
update-policy local;.
Switching on this rule in a zone causes
- named to generate a TSIG session
- key and place it in a file, and to allow that key
- to update the zone. (By default, the file is
- /var/run/named/session.key, the key
- name is "local-ddns" and the key algorithm is HMAC-SHA256,
- but these values are configurable with the
+ named to generate a TSIG session key and
+ place it in a file. That key will then be allowed to update
+ the zone, if the update request is sent from localhost.
+ By default, the session key is stored in the file
+ /var/run/named/session.key; the key name
+ is "local-ddns" and the key algorithm is HMAC-SHA256.
+ These values are configurable with the
session-keyfile,
session-keyname and
session-keyalg options, respectively).
- A client running on the local system, and with appropriate
- permissions, may read that file and use the key to sign update
- requests. The zone's update policy will be set to allow that
- key to change any record within the zone. Assuming the
- key name is "local-ddns", this policy is equivalent to:
+ A client on the local system, if it is run with appropriate
+ permissions, may read the session key from the key file and
+ use the key to sign update requests. The zone's update
+ policy will be set to allow that key to change any record
+ within the zone. Assuming the key name is "local-ddns",
+ this policy is:
update-policy { grant local-ddns zonesub any; };
- The command nsupdate -l sends update
- requests to localhost, and signs them using the session key.
+ ...with an additional restriction that only clients
+ connecting from the local system will be permitted to send
+ updates.
+
+
+ Note that only one session key is generated; all zones
+ configured to use update-policy local
+ will accept the same key.
+
+
+ The command nsupdate -l implements this
+ feature, sending requests to localhost and signing them using
+ the key retrieved from the session key file.
@@ -12964,7 +12929,7 @@ HOST-127.EXAMPLE. MX 0 .
and not part of the standard zone file format.
- BIND 8 does not support the optional TTL and CLASS fields.
+ BIND 8 did not support the optional TTL and CLASS fields.
+ Previously, update-policy local; accepted + updates from any source so long as they were signed by the + locally-generated session key. This has been further restricted; + updates are now only accepted from locally configured addresses. + [RT #45492] +
+The lightweight resolver daemon and library (lwresd diff --git a/doc/arm/notes.html b/doc/arm/notes.html index f08ab2b490..b8fe20458a 100644 --- a/doc/arm/notes.html +++ b/doc/arm/notes.html @@ -484,6 +484,15 @@ anchor is now a fatal configuration error. [RT #46155]
+ Previously, update-policy local; accepted + updates from any source so long as they were signed by the + locally-generated session key. This has been further restricted; + updates are now only accepted from locally configured addresses. + [RT #45492] +
+The lightweight resolver daemon and library (lwresd