BIND 10 trac3278, updated. 8b8c2e66adf20cfcfa6f35d07699f9609178242e [3278] minor grammar article fixes
BIND 10 source code commits
bind10-changes at lists.isc.org
Tue Dec 31 17:52:33 UTC 2013
The branch, trac3278 has been updated
via 8b8c2e66adf20cfcfa6f35d07699f9609178242e (commit)
via 9d2de0a4ada9b43f2facc559e8f4b71d34ffc931 (commit)
via 0525d51fb6a42cff3ce4d1638ed15d9a07ca5869 (commit)
via a21ab1ff7a67d4248cbb4e8415769384fdddc23b (commit)
from 543d7901daa0d5b7d5522cef6a37dd940c68a148 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 8b8c2e66adf20cfcfa6f35d07699f9609178242e
Author: Jeremy C. Reed <jreed at isc.org>
Date: Tue Dec 31 11:52:04 2013 -0600
[3278] minor grammar article fixes
commit 9d2de0a4ada9b43f2facc559e8f4b71d34ffc931
Author: Jeremy C. Reed <jreed at isc.org>
Date: Tue Dec 31 11:50:31 2013 -0600
[3278] add some ixfr and validator requirements
commit 0525d51fb6a42cff3ce4d1638ed15d9a07ca5869
Author: Jeremy C. Reed <jreed at isc.org>
Date: Tue Dec 31 11:50:11 2013 -0600
[3278] another TODO
commit a21ab1ff7a67d4248cbb4e8415769384fdddc23b
Author: Jeremy C. Reed <jreed at isc.org>
Date: Tue Dec 31 11:24:30 2013 -0600
[3278] some cleanup of RFC reference numbering
-----------------------------------------------------------------------
Summary of changes:
doc/requirements/TODO | 5 ++
doc/requirements/requirements.data | 170 +++++++++++++++++++++++++++++++-----
2 files changed, 154 insertions(+), 21 deletions(-)
-----------------------------------------------------------------------
diff --git a/doc/requirements/TODO b/doc/requirements/TODO
index 48cd37f..1217b46 100644
--- a/doc/requirements/TODO
+++ b/doc/requirements/TODO
@@ -11,3 +11,8 @@
- add unique test numbers to lettuce Scenario descriptive titles
- script to parse lettuce output to generate report
+
+- how to identify RFC entry like
+1. All RRs in the file should have the same class.
+in RFC1035:5.2
+(it is the not the first paragraph)?
diff --git a/doc/requirements/requirements.data b/doc/requirements/requirements.data
index afde4a2..31d22bb 100644
--- a/doc/requirements/requirements.data
+++ b/doc/requirements/requirements.data
@@ -5,7 +5,7 @@
1001000 Recommend rejecting obsolete MD RRs - RFC1035:3.3.4/5 master-file - - -
1001010 Optionally convert MD RRs to MX with preference 0 - RFC1035:3.3.4/5 master-file - - -
1001020 Recommend rejecting obsolete MF RRs - RFC1035:3.3.5/5 master-file - - -
-1001030 Optionally convert MF RRs to MX with preference 10 BUG: The RFC has an content mistake here. RFC1035:3.3.5/5 master-file - - -
+1001030 Optionally convert MF RRs to MX with preference 10 BUG: The RFC has a content mistake here. RFC1035:3.3.5/5 master-file - - -
1001040 NULL RRs are not allowed in master files. - RFC1035:3.3.10/3 master-file - - -
1001050 WKS RR ports and protocols may be defined using decimal numbers or mnemonics as defined in RFC1010. - RFC1035:3.4.2/6,RFC1035:3.4.2/10 master-file - - -
1001060 Multiple values for a type are defined using multiple resource records. - RFC1035:3.6.5 master-file - -
@@ -18,30 +18,30 @@
10011130 An $INCLUDE control entry definition line may have a comment. - RFC1035:5.1/5,RFC1035:5.1/9 master-file - -
10011140 An $INCLUDE control entry definition line may optionally define the relative domain origin with an optional second argument. - RFC1035:5.1/5,RFC1035:5.1/9 master-file - -
10011150 Blank lines are allowed anywhere. - RFC1035:5.1/8 master-file - -
-10011160 The $ORIGIN control entry sets the current origin for relative domain names to the value set in its first (and only) argument. - RFC1035:5.1.2,RFC1035:5.1.4 master-file - -
-10011170 The $INCLUDE control entry inserts the file (filename is first argument) into the current file. - RFC1035:5.1.2,RFC1035:5.1.4 master-file - -
-10011180 The $INCLUDE control entry canno change the origin of the parent file. - RFC1035:5.1.4 master-file - -
+10011160 The $ORIGIN control entry sets the current origin for relative domain names to the value set in its first (and only) argument. - RFC1035:5.1/4,RFC1035:5.1/9 master-file - -
+10011170 The $INCLUDE control entry inserts the file (filename is first argument) into the current file. - RFC1035:5.1/5,RFC1035:5.1/9 master-file - -
+10011180 The $INCLUDE control entry cannot change the origin of the parent file. - RFC1035:5.1/9 master-file - -
10011190 $ORIGIN names that do not end with a dot are usually interpreted as a warning, and should be reported. - ? master-file - -
10011200 $ORIGIN names that do not end with a dot are interpreted as a normal name, relative to the current origin. - ? master-file - -
10011200 If the $INCLUDE named file cannot be loaded it is an issue, and usually treated as an error; if treated as a warning, it is ignored for processing. TODO: what is usually? when to choose? ? master-file - - -
-10011190 A line that is not a $ control entry is a resource record. - RFC1035:5.1.2,RFC1035:5.1.5 master-file - -
-10011200 If the RR begins with a blank, then the owner name is the last stated owner. - RFC1035:5.1.5 master-file - -
-10011210 If the RR begins with a name, then the owner name is reset to that name. BUG: RFC says domain-name which implies "terminated by a label with zero length" trailing period. RFC1035:5.1.5 master-file - - -
+10011190 A line that is not a $ control entry and is not a comment is a resource record. - RFC1035:5.1/10 master-file - -
+10011200 If the RR begins with a blank, then the owner name is the last stated owner. - RFC1035:5.1/10 master-file - -
+10011210 If the RR begins with a name, then the owner name is reset to that name. BUG: RFC says domain-name which implies "terminated by a label with zero length" trailing period. RFC1035:5.1/10 master-file - - -
10011230 If there was no previous owner name, this is an issue and usually interpreted as an error; if treated as a warning, the RR can be checked but will not be added to the zone. TODO ? master-file - - -
-10011240 The RR contents begin with an optional TTL, or optional class field, or optionally both; the order of the optional class and TTL fields does not matter. TODO: need to describe when not recognized? RFC1035:5.1.6,RFC1035:5.1.7 master-file - - -
-10011250 If the optional class field is omitted, then it defaults to last explicitly defined class. - RFC1035:5.1.7 master-file - -
-10011260 The class field uses standard mnemonics. - RFC1035:5.1.7 master-file - -
-10011270 The RR contents contain type and RDATA fields; the RDATA is appropriate to the type and optional class. - RFC1035:5.1.7 master-file - -
-10011280 The TTL field is a decimal integer. TODO: this changed RFC1035:5.1.7 master-file - - -
-10011300 Quoting conventions may be used for domain names. - RFC1035:5.1.8 master-file - -
-10011310 A domain name without an ending dot '.' is relative and has the origin appended to it; the origin may be from a $ORIGIN or $INCLUDE control entry, or defined by an master file loading routine argument. - RFC1035:5.1.8 master-file - -
-10011320 If there is no origin (to use for a relative name), it is an error. - RFC1035:5.1.8 master-file - -
-10011330 If there is no origin (to use for a relative name), it is an issue that is usually interpreted as an error; if treated as a warning, the domain name is considered absolute. TODO: conflicts with m1132 ? master-file - - -
-10011340 Quoted strings (starting and ending with '"' characters) may contain any character including spaces, except a quote; a quote '"' may be used with a '\"'. - RFC1035:5.1.9 master-file - -
+10011240 The RR contents begin with an optional TTL, or optional class field, or optionally both; the order of the optional class and TTL fields does not matter. TODO: need to describe when not recognized? RFC1035:5.1/12,RFC1035:5.1/14 master-file - - -
+10011250 If the optional class field is omitted, then it defaults to last explicitly defined class. - RFC1035:5.1/14 master-file - -
+10011260 The class field uses standard mnemonics. - RFC1035:5.1/14 master-file - -
+10011270 The RR contents contain type and RDATA fields; the RDATA is appropriate to the type and optional class. - RFC1035:5.1/14 master-file - -
+10011280 The TTL field is a decimal integer. TODO: this changed RFC1035:5.1/14 master-file - - -
+10011300 Quoting conventions may be used for domain names. - RFC1035:5.1/15 master-file - -
+10011310 A domain name without an ending dot '.' is relative and has the origin appended to it; the origin may be from a $ORIGIN or $INCLUDE control entry, or defined by a master file loading routine argument. - RFC1035:5.1/15 master-file - -
+10011320 If there is no origin (to use for a relative name), it is an error. - RFC1035:5.1/15 master-file - -
+10011330 If there is no origin (to use for a relative name), it is an issue that is usually interpreted as an error; if treated as a warning, the domain name is considered absolute. TODO: conflicts with 10011320 ? master-file - - -
+10011340 Quoted strings (starting and ending with '"' characters) may contain any character including spaces, except a quote; a quote '"' may be used with a '\"'. - RFC1035:5.1/16 master-file - -
10011350 A missing closing '"' is an issue, and usually treated as an error; if treated as a warning, then the end of file is treated as the closing quote. - ? master-file - -
-10011360 The @ by itself is treated as the origin. - RFC1035:5.1.10 master-file - -
-10011370 A backslash not followed by a digit may be used so the character as literal (and doesn't have a special meaning). - RFC1035:5.1.9,RFC1035:5.1.10 master-file - -
-10011380 A backslash followed by three digits results in its corresponding ASCII character and is used literally. BUG: RFC says "decimal number" but really is "decimal ASCII character" RFC1035:5.1.10 master-file - - -
+10011360 The @ by itself is treated as the origin. - RFC1035:5.1/19 master-file - -
+10011370 A backslash not followed by a digit may be used so the character as literal (and doesn't have a special meaning). - RFC1035:5.1/20,RFC1035:5.1/21 master-file - -
+10011380 A backslash followed by three digits results in its corresponding ASCII character and is used literally. BUG: RFC says "decimal number" but really is "decimal ASCII character" RFC1035:5.1/21 master-file - - -
10011390 Parentheses do not nest; a second open parenthesis before a close parenthesis is an issue, and usually considered a warning; if treated as a warning, it is ignored. TODO: where documented? ? master-file - - -
10011400 A missing closing parenthesis is considered an issue, and usually interpreted as an error; If treated as a warning, the end of file is treated as the closing parenthesis. TODO: where documented? ? master-file - - -
10011410 A TTL is a positive number (or 0); it is stored in a signed 32 bit number; the maximum is 2147483647. BUG: RFC1035:2.3.4 says positive but it can be zero. RFC1035:2.3.4,RFC1035:3.2.1,RFC1035:4.1.3,RFC2181:8 master-file - - -
@@ -51,7 +51,7 @@
10011450 Only one SOA RR should exist. BUG: the RFC is vague since has only one should be present at the top -- what about elsewhere in same master file? RFC1035:5.2.2 master-file - - -
10011460 If a SOA appears again with the same value, it is considered an issue and usually treated as a warning; if treated as a warning then the second value is ignored. TODO ? master-file - - -
10011470 If a SOA appears again with a different value, it is considered an issue and usually treated as an error; if treated as a warning then the second value is ignored. TODO ? master-file - - -
-10011480 If glue is required for delegations (NS records) then it must be present. TODO: define how to require it RFC1035:5.2.2.3 master-file - - -
+10011480 If glue is required for delegations (NS records) then it must be present. TODO: define how to require it RFC1035:5.2/5#3 master-file - - -
10011490 For required glue, if neither an A nor an AAAA record is present, this is an issue and usually treated as a warning; if treated as a warning the zone is loaded without the necessary data and the delegation is broken. TODO ? master-file - - -
10011500 Information outside of the authority for the zone (out-of-bailiwick data), other than glue, is an issue, and usually considered an error; if interpreted as a warning, it is ignored. TODO: RFC1035:5.2/2.4 master-file - - RFC is vague; where to define if its a error or not?
10011510 An $TTL control entry definition line may have a comment. - RFC2308:4/4 master-file - -
@@ -63,3 +63,131 @@
10011560 The RDATA for an unknown type begins with '\#' (backslash-pound), whitespace, the RDATA length in sockets specified with an unsigned decimal integer, whitespace, and then zero or more words of hexadecimal (even nummber of digits) encoding of the data; an empty RDATA can be represented with '\# 0'. - RFC3597:5/3,RFC3597:5/4 master-file - -
10011570 The generic \# RDATA representation may be used for known types; but if known, the later processing must apply type-specific rules. - RFC3597:5/5,RFC3597:5/6 master-file - -
10011580 Any error with the generic RDATA format, such as not having enough hexadecimal data for the length, is an issue usually considered an error; if considered as a warning, then the RR is skipped. TODO: where documented? ? master-file - - -
+2000010 To request an IXFR, client sends an IXFR message with its current SOA serial number. - RFC1995:2/1 ixfr-client - - -
+2000020 The IXFR server keeps differences between newest zone and several older versions. - RFC1995:2/2 ixfr-server - - -
+2000030 The IXFR server may choose to transfer entire zone instead of differences. - RFC1995:2/2 ixfr - - -
+2000040 When the client is updated with an IXFR, the updated zone should be saved to stable storage before the client serves queries. - RFC1995:2/3 ixfr-client - - -
+2000050 If the server receives an IXFR query with the same or newer serial number as its own, it should reply with a single SOA record. - RFC1995:2/4 ixfr-server - - -
+2000060 Opcode is query, QR bit is 1 (response) TODO: AXFR RFC1995 ixfr - - -
+2000070 QNAME is the name of the zone, QTYPE is IXFR TODO: AXFR RFC1995 ixfr - - -
+2000080 Answer section comprises SOA record of the zone TODO: AXFR RFC1995 ixfr - - -
+2000090 Authority and Additional sections are empty TODO: AXFR RFC1995 ixfr - - -
+2000100 The server should support IXFR over both TCP and UDP. - RFC1995:2/5/a ixfr-server - - -
+2000110 If the server receives a UDP IXFR query, and the response (format described in requirements 4/2 and 4/3) fits in a UDP packet, it should return the response via UDP. - RFC1995:2/5/b ixfr-server - - -
+2000120 If the server receives a UDP IXFR query, and the response (format described in requirements 4/1, 4/2 and 4/3) does not fit in a UDP packet, it should return the single SOA record response with server's current serial version (format described in requirement 2/4). via UDP. RFC1995:2/5/c,RFC1995:7/8 ixfr-server - - -
+2000130 The client should first query the server by sending out an IXFR query over UDP in the format specified in requirement 3/1. - RFC1995:2/6/a ixfr-client - - -
+2000140 If the response to the IXFR query indicates that the server does not recognise IXFR, the client should try an AXFR request (preceded with a query for the SOA). TODO: example of not recognizing? RFC1995:2/6/b ixfr-client - - -
+2000150 If the response to the IXFR query is a packet containing the entire zone, the transfer is complete. - RFC1995:2/6/c ixfr-client - - -
+2000160 If the response to the IXFR query is a UDP packet containing an SOA (format described in requirement 2/4) whose serial number is equal to or less than the serial number of the client, the server does not have a newer zone than the client, and the client should stop the transaction. - RFC1995:2/6/d ixfr-client - - -
+2000170 If the response to the IXFR query is a UDP packet containing an SOA (format described in requirement 2/4) whose serial number is greater that the serial number of the client, the client should retry the IXFR query using TCP. Single SOA / not an entire zone. RFC1995:2/5/c, RFC1995:2/6/e ixfr-client - - -
+2000180 The server should enable UDP checksums for all responses. - RFC1995:2/7/a ixfr-client - - -
+2000190 A client that receives an IXFR UDP packet is a checksum of 0 should ignore it and retry the IXFR using TCP. - RFC1995:2/7/b ixfr-client - - -
+2000200 The IANA assigned IXFR query type number is 251. - RFC1995:2/8 ixfr - - -
+2000210 Opcode is query, QR bit is 0 (query) TODO normal DNS query RFC1995 ixfr - - -
+2000220 QNAME is the name of the zone, QTYPE is IXFR TODO normal DNS query RFC1995 ixfr - - -
+2000230 The IXFR query packet QTYPE is IXFR. - RFC1995:3 ixfr - - -
+2000240 The Authority section for an IXFR query contains the zone's SOA on the client. - RFC1995:3 ixfr - - -
+2000250 The Answer and Additional sections are empty TODO normal DNS query RFC1995 ixfr - - -
+2000260 If incremental zone transfer is not available, the entire zone is returned using AXFR behaviour except the QTYPE is IXFR. - RFC1995:4/1 ixfr - - -
+2000270 The entire zone response has the SOA for the first and last resource records. - RFC1995:4/1 ixfr - - -
+2000280 Opcode is query, QR bit is 1 (response) TODO RFC1995 ixfr - - -
+2000290 QNAME is the name of the zone, QTYPE is IXFR TODO RFC1995 ixfr - - -
+2000300 Answer section comprises: 1. SOA record of the zone; 2. All other records in the zone; 3. SOA record of the zone TODO RFC1995 ixfr - - -
+2000310 Authority and Additional sections are empty Note that by requirement 2/5/c, if the response does not fit within a UDP packet, an SOA record must be returned indicating that the IXFR should be retried over TCP. RFC1995 ixfr - - -
+2000320 If incremental zone transfer is available, the server returns a message comprising one or more difference sequences: - RFC1995:4/2 ixfr - - -
+2000330 Opcode is query, QR bit is 1 (response) TODO RFC1995 ixfr - - -
+2000340 QNAME is the name of the zone, QTYPE is IXFR TODO RFC1995 ixfr - - -
+2000350 The Answer section for when an incremental zone transfer is available comprises: 1. SOA record of the zone on the server; 2. Difference sequences; 3. SOA record of the zone on the server. - RFC1995:4/2 ixfr - - -
+2000360 Authority and Additional sections are empty TODO RFC1995 ixfr - - -
+2000370 The Answer section of an incremental response begins with two different SOA records: the server's current SOA and the older client SOA version. - RFC1995:4/8 ixfr - - -
+2000380 In the Answer section response for differences, each difference sequence represents one update to the zone and comprises: 1) The SOA of the older version of the zone; 2) A list of RRs that should be deleted from the client's copy of that version of the zone; 3) The SOA of the newer version of the zone; 4) A list of added newer RRs. - RFC1995:4/3 ixfr - - -
+2000390 If an RR is part of an RRset, only the RR that changed is included in the difference sequence (not the entire RRset). - RFC1995:4/6 ixfr - - -
+2000400 When processing difference sequences, the client must remove the RRs to be deleted before adding the new RRs. - RFC1995:4/4 ixfr-client - - -
+2000410 Difference sequences in the response must be ordered in order of oldest first to newest/current last. - RFC1995:4/5 ixfr - - -
+2000420 Difference sequences in the response must be ordered in order of ascending SOA. - RFC1995:4/5 ixfr - - -
+2000430 The application of the IXFR received by the client should be atomic. Either all differences specified in an IXFR must be applied to the zone or none of them must be applied. - RFC1995:4/7 ixfr - - -
+2000440 The server may remove previous zone versions at any time. - RFC1995:5/1 ixfr-server - - -
+2000450 The server should remove old versions of the zone if the total length of an IXFR response (from that version of the zone) would be greater than the length of an AXFR. TODO: what does BIND 9 do? RFC1995:5/2/a ixfr - - -
+2000460 The server probably should not send an IXFR if the total length of an IXFR response would be greater than the length of an AXFR. Per the purpose of IXFR, but this is not a stated rule. Anyways this can't happen if server already removed it per RFC1995:5/2/a. TODO: what does BIND 9 do? RFC1995:5/2/b ixfr - - -
+2000470 The server may get rid of versions of the zone older than the SOA expire time. This requirement is optional. RFC1995:5/3 ixfr-server - - -
+2000480 The server may condense multiple difference sequences into a single difference sequence by dropping intermediate versions. This requirement is optional. - RFC1995:6/1,RFC1995:6/4,RFC1995:7/7 ixfr-server - - -
+2000490 If a server receives a request containing an SOA for which it holds no difference information, it should attempt to perform a full zone transfer (i.e. return the entire zone in a packet if possible, or return a single SOA to indicate that an AXFR over TCP should be tried (as in requirement 2/6/e)). - RFC1995:6/5 ixfr - - -
+2000500 When the SOA refresh time is reached, the client sends an IXFR request to the server. - RFC1995:2/1 ixfr-client - - -
+2000510 When a NOTIFY is received by a client, it sends an IXFR request to the server. - RFC1995:2/1 ixfr-client - - -
+2000520 If an IXFR packet is received that includes one or more deletions of records that are not in the zone, the entire IXFR update should be rejected. Such a situation would imply that the version of the zone in the IXFR client is not the same as the same version of that zone in the IXFR server. As a result, applying the IXFR could corrupt the zone further. RFC1995 ixfr - - -
+2000530 An incremental difference response indicates a record is removed by listing the previous record in the previous section (started with older SOA) and not listing it in the current section (started with current SOA). - RFC1995:7/6 ixfr - - -
+3000010 Enable/disable validation per view. - - validator bind9/bin/named/server.c - -
+3000020 If no trust anchor, turn off AD bit. Just in case? - validator bind9/lib/dns/message.c - -
+3000030 If flagged as optout, turn off AD bit. - - validator bind9/lib/dns/message.c - -
+3000040 If CD flag was set on client query, then set the CD flag for recursive query. - - validator bind9/lib/dns/resolver.c - -
+3000050 If question is under a secure entry point, then set CD flag for recursive query. - - validator bind9/lib/dns/resolver.c - -
+3000060 If question is within working DLV, then set CD flag for recursive query. - - validator bind9/lib/dns/resolver.c - -
+3000070 Clear CD flag if EDNS is not in use. - - validator bind9/lib/dns/resolver.c - -
+3000080 If is glue, don't validate. - - validator bind9/lib/dns/resolver.c - -
+3000090 If out-of-bailiwick data, don't validate -- so only validated if within context of the query to the domain that owns the records. - - validator bind9/lib/dns/resolver.c - -
+3000100 Ignore non-answer data that is missing signature. - - validator bind9/lib/dns/resolver.c - -
+3000110 Change the TTL of the dataset or the signature set to the smaller of their TTLs. - - validator bind9/lib/dns/resolver.c - -
+3000120 A no-answer response should only include a DS RRset if it also includes a NS RRset (it is a referral). If not, FORMERR. - - validator bind9/lib/dns/resolver.c - -
+3000130 In a referral, if the DS exists, its name must match the NS name. If not, FORMERR. - - validator bind9/lib/dns/resolver.c - -
+3000140 NSEC3 records are not allowed to appear in the answer section. If not, FORMERR. - - validator bind9/lib/dns/resolver.c - -
+3000150 CNAME response for RRSIG query results in FORMERR. - - validator bind9/lib/dns/resolver.c - -
+3000160 CNAME response for DNSKEY query results in FORMERR. - - validator bind9/lib/dns/resolver.c - -
+3000170 CNAME response for NSEC query results in FORMERR. - - validator bind9/lib/dns/resolver.c - -
+3000180 Make sure AD flag is not set if answer section or authority section data is not validated. - - validator bind9/lib/dns/message.c - -
+3000190 If flagged as optout, turn off AD bit. - - validator bind9/lib/dns/message.c - -
+3000200 Don't compress names nor convert rdataset to wire format. - - validator bind9/lib/dns/ncache.c - -
+3000210 - - - ? bind9/lib/dns/ncache.c - -
+3000220 DLV RRset algorithm must be SHA256 or SHA1 (or GOST if built with GOST). - - validator bind9/lib/dns/validator.c - -
+3000230 If a DNSKEY is a zone key (flag bit 7 is 1), the DNSKEY owner name must be same as the zone name. - RFC4034:2.1.1 validator or server - - -
+3000240 If a DNSKEY is not a zone key (i.e. flag bit 7 is 0), the DNSKEY must not be used to verify a RRSIG and must not be used for validation. - RFC4034:2.1.1, RFC4034:5.2 validator or server - - -
+3000250 DNSKEY Flag bits 0-6 and 8-14 must be ignored. - RFC4034:2.1.1 validator or server - - -
+3000260 When creating DNSKEY, flag bits 0-6 and 8-14 must be set to zero. - RFC4034:2.1.1 validator or server - - -
+3000270 DNSKEY is invalid if the protocol is not 3. - RFC4034:2.1.2 validator or server - - -
+3000280 The DNSSEC flag field can only be 0, 256, or 257. - RFC4034:2.2 validator or server - - -
+3000290 The DNSKEY Algorithm field is an unsigned decimal integer or algorithm mnemonic. TODO: complete this, see A.1 RFC4034:2.2 validator or server - - -
+3000300 DNSKEY Public key must be in Base64 (and whitespace allowed). - RFC4034:2.2 validator or server - - -
+3000310 RRSIG and NSEC are the only allowed RR for a name that has a CNAME. Supercedes:RFC1034. TODO: updated in RFC... for NSEC3 too. RFC4034:3, RFC4034:4 validator or server - - -
+3000320 RRSIG class must be same as the class for the RRset it is the signature for. - RFC4034:3, RFC4034:3.1.8.1 validator or server - - -
+3000330 RRSIG TTL must be same as the TTL for the RRset it is the signature for. If the RRset has different TTLs, then there will be individual RRSIG RRs for each different TTL value. TODO: confirm this? RFC4034:3 validator or server - - -
+3000340 The RRSIG labels field must not count wildcard (*) or root (.) label. - RFC4034:3.1.3 signer - - -
+3000350 A wildcard label (*) is included in the owner name of the corresponding RRSIG. - RFC4034:3.1.3, RFC4034:3.1.8.1 validator or server or signer - - -
+3000360 RRSIG must not be used for authentication before the RRSIG inception. - RFC4034:3.1.5 validator - - -
+3000370 RRSIG must not be used for authentication after the RRSIG expiration. - RFC4034:3.1.5 validator - - -
+3000380 RRSIG inception/expiration comparisons must use RFC1982 serial number arithmetic. TODO RFC4034:3.1.5 validator - - -
+3000390 RRSIG "signer's name" field must contain the name of the zone covered by the signature. - RFC4034:3.1.7 signer AND validator - - -
+3000400 Do not use DNS name compression on RRSIG signer's name field when transmitting. TODO: why? Should this be checked on validator side too? RFC4034:3.1.7 auth - - -
+3000410 RRSIG owner name is the same as the owner name of the RRset it covers. - RFC4034:3.1.8.1 validator or server - - -
+3000420 All the RR types in the RRset must be listed in corresponding RRSIGs's type covered field. - RFC4034:3.1.8.1 validator or server - - -
+3000430 DNS names in each RR RDATA must be in canonical form. TODO: why? RFC4034:3.1.8.1 validator or server - - -
+3000440 Each TTL in the covered RRset is checked to be the same as the RRSIG's original TTL field. - RFC4034:3.1.8.1 validator or server - - -
+3000450 In a signed zone, the RRset must be sorted in canonical order. - RFC4034:3.1.8.1 validator or server - - -
+3000460 The RRSIG type covered field is a RR Type or a TYPEnumber representation (see RFC3597:5). - RFC4034:3.2 validator or server - - -
+3000470 The RRSIG Algorithm field is an unsigned decimal integer or algorithm mnemonic. TODO: complete this, see A.1 RFC4034:3.2 validator or server - - -
+3000480 The RRSIG labels field is unsigned decimal number. - RFC4034:3.2 validator or server - - -
+3000490 The RRSIG Original TTL field is unsigned decimal number. - RFC4034:3.2 validator or server - - -
+3000500 The representation of the RRSIG expiration or inception field is either a 14 digit YYYYMMDDHHmmSS format or unsigned decimal integer of 1 to 10 digits. - RFC4034:3.2 validator or server - - -
+3000510 The RRSIG key tag field is unsigned decimal number. - RFC4034:3.2 validator or server - - -
+3000520 RRSIG signature field must be in Base64 (and whitespace allowed). - RFC4034:3.2 validator or server - - -
+3000530 Every authoritative name (so not glue) in a zone must be part of the NSEC chain. Or in other words, if zone only contains glue records, then don't include any NSEC. - RFC4034:4, RFC4034:4.1.1, RFC4034:4.1.2 validator or server - - -
+3000540 NSEC TTL should be the same as the SOA minimum TTL to help negative caching. - RFC4034:4 signer - - -
+3000550 Do not use DNS name compression on NSEC next Domain name field when transmitting. TODO: why? Should this be checked on validator side too? RFC4034:4.1.1 validator or server - - -
+3000560 Do not list glue records or other non-authoritative owner names in the NSEC Next Domain name unless an authoritative owner name is at same name. TODO: What is an example of a non-authoritative record in zone that is not a glue record? RFC4034:4.1.1 validator or server - - -
+3000570 NSEC Type Bit Maps field that represent pseudo-types must be clear. TODO: what is a pseudo-type? RFC4034:4.1.2 validator or server - - -
+3000580 Pseudo-types must be ignored. TODO: what does this mean in context of NSEC? TODO: what is a pseudo-type? RFC4034:4.1.2 validator - - -
+3000590 NSEC type bit map blocks must not be included when no types present. -OR does it mean- NSEC should not exist if no types present. TODO: what does this mean? RFC4034:4.1.2 validator or server - - -
+3000600 NSEC type bit map must omit any trailing zero octets. If missing, then thet are interpreted as zero octets. TODO: example? RFC4034:4.1.2 validator or server - - -
+3000610 - TODO: ``Bits corresponding to the delegation NS RRset and the RR types for which the parent zone has authoritative data MUST be set; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear.'' TODO: explain and example? RFC4034:4.1.2 validator or server - - -
+3000620 The NSEC Type Bits Maps field is represented by a RR Type or a TYPEnumber representation (see RFC3597:5). - RFC4034:4.2 validator or server - - -
+3000630 DS record is authoritative in the parent. - RFC4034:5 validator or server - - -
+3000640 The only digest algorithm for DS is SHA-1. TODO: what updates this? RFC4034:5.1.4 validator or server - - -
+3000650 A DS must not be used for validation, if it refers to a DNSKEY that does not have Flags bit 7 (zone key) set. - RFC4034:5.2 validator or server - - -
+3000660 The DS key tag field is unsigned decimal number. - RFC4034:5.3 validator or server - - -
+3000670 The DS Algorithm field is an unsigned decimal integer or algorithm mnemonic. TODO: complete this, see A.1 RFC4034:5.3 validator or server - - -
+3000680 The DS digest type field is unsigned decimal number. - RFC4034:5.3 validator or server - - -
+3000690 The DS digest field is represented in case-insensitive hexadecimal (and whitespace is allowed). - RFC4034:5.3 validator or server - - -
+3000700 Canonical name ordering is required for NSEC chain. Uppercase US-ASCII latters are treated as if they are lowercase. - RFC4034:6 server - - -
+3000710 In resource record sorting, uppercase US-ASCII letters are treated as if they are lowercase. - RFC4034:6.1 RFC4034:6.2 server - - -
+3000720 The US-ASCII DNS names in the RDATA are made lowercase for A6, AFSDB, CNAME, DNAME, HINFO, HINFO, KX, MB, MD, MF, MG, MINFO, MR, MX, NAPTR, NS, NSEC, NXT, PTR, PX, RP, RRSIG, RT, SIG, SOA, and SRV. - RFC4034:6.2 validator or server - - -
+3000730 RRset cannot contain multiple records with same name, class, type and RDATA. It is a protocol error. It may remove the duplicates (and leave one). TODO: see RFC2181 RFC4034:6.3 validator or server - - -
+3000740 Two different DNSKEY records may have same name, algorithm and key tag. So do not use key tag to select DNSKEY record. - RFC4034:8, RFC4034:B validator or server - - -
+3000750 Server must implement all mandatory algorithms. TODO: what are they? RFC4034:A validator or server - - -
More information about the bind10-changes
mailing list