1$Id: REQUIREMENTS,v 1.2 2022/09/24 17:38:17 christos Exp $ 2 3 4NSD Requirements and Specifications 5______________________________________________________________________ 6 7A. Scope. 8 9NSD is a complete implementation of an authoritative DNS 10nameserver. This document describes the basic requirements and 11specifications for this implementation. 12 13B. Requirements 14 15B.1. General Requirements 16 17These requirements are in order of importance: 18 191. Conformity to the relevant DNS RFCs 20 21 If complying with the letter of the RFCs will cause a conflict with 22 high load resilience reasoned trade-offs will be made and 23 documented. 24 252 Code diversity from other implementations 26 27 NSD is developed from scratch and does not share code or design 28 with other implementations. 29 303. Authoritative server only 31 32 NSD is designed to provide authoritative answers only. There are 33 no facilities for caching or recursion. 34 354. Open source 36 37 The code will be open source after the first public release. 38 395. Regression tested against bind8/9 40 41 Extensive regression tests with real trace data and synthetic 42 exceptional data will be carried out. For the real traces any 43 differences with bind8/9 will be documented. Should there be 44 substantial differences a bind8/9 compatibility option will be 45 considered. The testing tools will be published separately as much 46 as possible. 47 486. Resilience to high load 49 50 As many as UDP queries answered as possible per time interval. 51 Aware of useless queries and limiting answers to conserve output 52 bandwidth. This may supersede strict RFC compliance. Mitigation of 53 DDoS attacks as far as feasible. 54 557. Documentation 56 57 The implementation will be well documented with the aim of allowing 58 others to understand its operation in order to be able to maintain 59 the code. This includes these requirements, a general design 60 document and well documented code. 61 628. Reviewed code 63 64 All code will be reviewed by at least two persons other than the 65 primary author before being included in a release version. 66 679. Simplicity 68 69 NSD will not do things that are not strictly necessary for its 70 task: authoritative name serving. If in doubt a feature is more 71 likely not to be included. 72 73 The code strives to be as simple and straightforward as possible, 74 even if it looks stupid ;-). 75 7610. Reasonable Portability 77 78 Should be reasonably portable across hardware architectures and OS 79 platforms. Rough targets: 80 (Intel/SPARC/Alpha)(FreeBSD,Linux,Solaris) 81 8211. Maintenance for initial period 83 84 NLnet Labs and the RIPE NCC will support NSD for at least 12 85 months after publication. 86 87 88B.2. Explicit NON-Requirements 89 901. No caching 91 92 NSD will not provide cached or recursive answers. 93 942. No slavish responsiveness 95 96 NSD may decide to limit answers to queries it considers malicious 97 or useless if this enables it to provide better service to queries 98 it considers valid. Conserving output bandwidth is a consideration. 99 1003. No end-user friendliness 101 102 NSD operators are considered to have basic Unix and networking 103 knowledge and are also considered to be able to read and understand 104 reasonably written user documentation. 105 1064. No creeping featurism 107 108 NSD will not implement any functionality that is not strictly 109 necessary for the task of authoritative name serving. Examples: 110 round robin sequence of RRset members in consecutive answers, 111 Also no dynamic plugins. 112 113C. Technical Specification. 114 115 116C.0 Environment 117 118 The server runs with the least possible permissions. 119 120 NSD will not implement special VM work-arounds to accommodate zones 121 larger than order 10 million RRs in 32-bit address space machines. 122 Operators requiring huge-zone support can use 64-bit machines. 123 124 125C.1. Zone file format and RR records. 126 127 Zone file format as specified in rfc1035 (5.1), including the $TTL 128 entry for default TTL as in RFC2308 (4) and the binary label format 129 as in RFC2673. 130 131 We implement most RRs currently assigned by IANA 132 (http://www.iana.org/assignments/dns-parameters) except for RRs 133 that are obsoleted by IANA or assigned experimental, those MAY not 134 be implemented. See below and/or release notes. 135 136 Zone file MUST not contain errors. i.e. the zonecompiler may fail 137 or produce unpredictable results when: 138 - RRs that are obsolete and not implemented are encountered. 139 - Syntax errors are found (RFC1035 5.2) 140 + not all RRs are of the same zone 141 + not exactly one SOA RR is present at the top of the zone. 142 + delegations are present but required glue is not present. 143 + Out of Zone, non-glue data is encountered. 144 + not all RRs in a RRset have the same TTL (RFC2181 5.2) 145 + if a DNAME exists at node N there may not be any other data 146 at 'N' (except CNAME or DNAME) and there MUST not be any 147 other data at subnodes of 'N' (RFC 2672 section 3). 148 - The default minimum TTL is not specified by the $TTL directive 149 150 Zones that are parsed by the zonecompiler will be served by the nsd 151 daemon. 152 153 Only zone files of CLASS "IN" are supported. 154 155 The zone file parser sets the TTL of those RRs that do not have 156 their TTL defined to the minimum TTL as defined by the $TTL 157 directive unless the RR is part of a RRset and the TTL is set for 158 one of the RRs in the RRset. 159 160 Parsing of the names in zone files is case insensitive 161 (Note: RFC1035 2.3.3 also see 1034 3.1 162 163 "The basic rule is that case can be discarded only when data is 164 used to define structure in a database, and two names are 165 identical when compared in a case insensitive manner." 166 ) 167 168 The database relies on case; all names will be parsed to lower 169 case. Case of dnames in RDATA will be preserved except for dnames 170 for which dname compression in RDATA is allowed, those dname fields 171 are converted to lower case. (for that subset of RRs compression 172 has preference over case preservation). Also see Appendix B for 173 dname compression in RDATA. 174 175 176 DNSSEC consideration (as of 2.0.0): 177 178 DNSSEC processing of data in a zone will only take place if that 179 zone is marked to be secure. A zone is marked secure if the SOA 180 record is signed. The zone data is not cryptographically checked at 181 the time the zone db is generated; 182 183 NSD always clears the AD flag on answering data from a secure zone 184 in the database. 185 186 NSD always copies the CD bit from the query to the response. 187 188 NSD does not include the DNSKEY RRset in the additional section on 189 queries for the SOA or NS records at the zone apex. It is not 190 clear whether including the DNSKEY RRset is advantageous and not 191 doing so simplifies NSD. 192 193 194C.2. Server and connection management. 195 196 The server listens on port 53. The server answers with the same IP 197 address and port (53) as the queries has been sent to. Replies are 198 sent to the address/port the queries originated from. (rfc 2181 4) 199 200 UDP. 201 202 The server is optimized to handle UDP queries. Large packet sizes 203 are supported. The size is set by the OS 204 (e.g. net.inet.udp.maxdgram on FreeBSD). 205 206 207 TCP. 208 209 The server accepts TCP connections. 210 211 Note that there may be one or more DNS messages in the stream. Each 212 message is prepended with a 2 byte size (rfc 1035 4.2.2) 213 214 Connection management (rfc1035 4.2.2.) 215 + the server should not block other activities waiting for TCP data 216 217 + The server should assume that the client will initiate 218 connection closing and should delay closing its end of the 219 connection until all outstanding client requests have been 220 satisfied. 221 222 + For closing dormant connections the timeout should be in the 223 order of 2 minutes. 224 225 226 NSD specific: 227 228 + The maximum number of open TCP connections is configurable. 229 230 It is assumed the OS copes with attacks on the TCP stack (e.g 231 like SYN attacks) 232 233 234 235C.3 Incoming DNS Message processing. 236 237 NSD specific choices. 238 These issues are not addressed in the RFCs. Behavior is defined below. 239 240 + Non parsable messages are replied to with a FORMERR. 241 242 + Each UDP packet only carries one DNS Message. Any data behind 243 the DNS message is considered garbage and is ignored. 244 245 + Incoming DNS messages with the QR bit set to 1 (response) are 246 discarded. (In spirit of rfc 1035 sect 7.3) 247 248 + RD is copied into the response (rfc 1035 4.1.1) the RA bit is 249 set to 0 and the QUERYID is copied into the response message. 250 251 252 + OPCODE 0 (QUERY) results in normal handling 253 of packet (rfc1035) 254 OPCODE 1 (IQUERY) results in RCODE=4 NOTIMPL (rfc1035) 255 OPCODE 2 (STATUS) results in RCODE=4 NOTIMPL (rfc1035) 256 OPCODE 3 (RESERVED) results in RCODE=4 NOTIMPL 257 OPCODE 4 (NOTIFY) results in RCODE=4 access control list 258 processing and then handling of the notify. (rfc1995) 259 OPCODE 5 (UPDATE) results in RCODE=4 NOTIMPL (rfc2136 sect 3) 260 261 + AA bit in query packet is ignored. 262 263 + TC bit set in a query packet is answered with FORMERR. 264 265 [This must always be a broken implementation since the max 266 length of the name is 255 octets.] 267 268 269 + RCODES are ignored. 270 271 + QDCOUNT=1 results in further processing. 272 QDCOUNT!=1 results in RCODE=1 FORMERR 273 274 + QCLASS=IN results in further processing. 275 276 + QCLASS=ANY results in further processing with the AA bit in the 277 response off (rfc 1035 6.2) 278 279 + QLASS=CHAOS only leads to further processing if the queries are 280 for the names ID.SERVER or VERSION.SERVER. Any other query in that 281 namespace will lead to RCODE=REFUSED. 282 For QTYPE other than TXT a NOERROR with a trivial SOA RR in the 283 AUTHORITY section will be returned. 284 Behavior for QTYPE=TXT is defined in draft-ietf-dnsop-serverid-00.txt 285 286 287 + QCLASS!=IN && QCLASS!=ANY && QCLASS!=CHAOS results in RCODE=REFUSED 288 289 [Background: BIND8 generates a SERVFAIL but I would say that a A 290 NOERROR message with empty Answer, Authority and 291 Additional section is also a good answer and more in the 292 spirit of RFC 1034 section 4.3.1. 293 294 We choose to mimic the behavior of bind. 295 296 BIND9 generates a status RCODE=5 REFUSED. 297 ] 298 299 + Other sections should be empty otherwise FORMERR. 300 + except, EDNS and TSIG opt records are allowed. 301 + TSIG signature is checked, otherwise a TSIG error. 302 303 + Presence of OPT RR indicates support of EDNS (rfc2671). If the 304 VERSION > 0 then the server will respond with an OPT with 305 RCODE=BADVERSION and VERSION=0 (The server supports EDNS0) In 306 further processing ENDS0 support is taken into account. 307 308 + If the DNSSEC OK bit (DO bit) is set then the query will be 309 processed as a DNSSEC request. Although RFC3225 does not 310 explicitly specify this NSD clears the DO bit in the answer. 311 312 313C 4 Further Query processing. 314 315 Preconditions: 316 317 + the QCLASS is either IN or ANY. For both classes the IN class 318 zones are searched in the same manner. The difference in the 319 response will be in the Authority information. 320 321 + It is known if the requester supports EDNS0 322 323 + There is only one query in the DNS message to be answered. 324 325 + The RD & message ID of the incoming query has been copied into 326 the response message. 327 328 + It is known if the requester wants DNSSEC processing as indicated by 329 the DO bit being set. 330 331 332C 4.1 Actions based on QTYPE of incoming Query. 333 334 If QTYPE>=249 we are dealing with special queries. 335 336 case QTYPE=TKEY 337 338 case QTYPE=TSIG 339 340 case QTYPE=IXFR respond with RCODE=5 (REFUSED) 341 342 case QTYPE=AXFR respond with AXFR (TSIG is supported) 343 344 345 case QTYPE=MAILB proceed with processing. 346 case QTYPE=MAILA proceed with processing. 347 348 case QTYPE=ANY proceed with processing. 349 350 QTYPE < 249 process the query 351 352 353 Further processing of the packet is based on the algorithm from 354 1034 as modified by (rfc2672 4). Below is the algorithm as applies 355 to an authoritative cache-less server and with the preconditions from 356 above. We have also included DNSSEC considerations (rfc2535 and 357 rfc3225) 358 359 The first versions of NSD will not have DNSSEC processing 360 implemented. (Read this as the DO bit is not set). 361 362 1. Search the available zones for the zone which is the nearest 363 ancestor to QNAME. If such a zone is found, go to step 2, 364 otherwise step 3. 365 366 2. Start matching down, label by label, in the zone. The matching 367 process can terminate several ways: 368 369 370 a. If the whole of QNAME is matched, we have found the node. 371 372 If the data at the node is a CNAME, and QTYPE doesn't match 373 CNAME, copy the CNAME RR into the answer section of the 374 response, change QNAME to the canonical name in the CNAME RR, 375 and go back to step 1. If the DO bit is set in the query the 376 RRSIG(CNAME) needs to be copied in the answer section as well. 377 378 379 Otherwise, copy all RRs which match QTYPE into the answer 380 section. 381 Also copy corresponding RRSIGs into the answer section 382 if the DO bit was set, goto step 4. 383 384 If QTYPE is 'ANY' copy all RRs including the security related 385 RR types regardless if the DO bit was set into the answer section. 386 387 If none of the RRtypes matched QTYPE, the DO bit was set and the 388 zone is marked secure then the answer section is left empty and 389 390 391 392 b. If a match would take us out of the authoritative data, we have 393 a referral. This happens when we encounter a node with NS RRs 394 marking cuts along the bottom of a zone. 395 396 Copy the NS RRs for the subzone into the authority section of 397 the reply. 398 399 If the DO bit has been set then 400 401 if the zone is marked secure then 402 403 if there is a NSEC record or DS record then 404 405 include the DS bit and associated RRSIG(DS) into the 406 authority section if the DS record is present for this 407 delegation. If there is no DS record present for this 408 delegation then include the NSEC record with the 409 corresponding RRSIG(NSEC) in the authority section. 410 411 else 412 413 we are in an opt-in part of the zone and we should 414 include the NSEC RR of the last secured RR in the 415 zone and the corresponding RRSIG(NSEC) into the authority 416 section of the answer. 417 418 fi 419 fi 420 421 Put whatever addresses are available into the 422 additional section, using glue RRs if the addresses are not 423 available from authoritative data. If the DO bit was set then 424 also copy the RRSIGs for the addresses for which the server is 425 authoritative. 426 427 Go to step 4. 428 429 c. If at some label, a match is impossible (i.e., the 430 corresponding label does not exist), look to see whether the 431 last label matched has a DNAME record. 432 433 BEGIN DNAME (supported as of NSD 3.0) 434 435 If a DNAME record exists at that point, copy that record into 436 the answer section, if the DO bit is set also copy the RRSIG. 437 438 If substitution of its <target> for its <owner> in 439 QNAME would overflow the legal size for a 440 <domain-name>, set RCODE to YXDOMAIN [DNSUPD] and 441 exit; otherwise perform the substitution and 442 continue. If the query was not extended [EDNS0] 443 with a Version indicating understanding of the DNAME 444 record, the server SHOULD synthesize a CNAME record 445 as described above and include it in the answer 446 section. Go back to step 1. Note that there should 447 be no descendants of a DNAME in the same zone 448 (rfc2672 3). So if a DNAME has been found only go to 449 step 1 if another zone can be found. 450 451 NSD will refuse to zonecompile a zone that has descendants 452 of a DNAME. It always synthesizes CNAME records. 453 454 END DNAME 455 456 If there was no DNAME record, look to see if the "*" label 457 exists. 458 459 If the "*" label does not exist, check whether the name we 460 are looking for is the original QNAME in the query or a name 461 we have followed due to a CNAME. If the name is original, 462 set an authoritative name error (RCODE=3 NXDOMAIN) in the 463 response, if the DO bit was set then include the appropriate 464 NSEC records (see section 4.5.) in the authority section, 465 then exit. 466 467 If the "*" label does exist, match RRs at that node against 468 QTYPE. If any match, copy them into the answer section, but 469 set the owner of the RR to be QNAME, and not the node with 470 the "*" label. If the DO bit is set copy the RRSIG for the * 471 label and matching QTYPE also set the owner of the RRSIG RR to 472 be QNAME). In addition a NSEC record indicating that no 473 specific matches are possible should be returned in the 474 additional section. 475 476 Otherwise just exit. 477 478 479 Go to step 4. 480 481 3. If a there was no delegation of authoritative data return the root 482 delegation in the authority section and continue with 4. 483 484 Also see Appendix B.1 485 486 4. Using local data only, attempt to add other RRs which may be 487 useful to the additional section of the query if the DO bit was 488 set in the query then for retrieval of SOA or NS a DNSKEY of the 489 same name should be added. For retrieval of type A, AAAA or A6 RRs 490 the DNSKEY should also be included. 491 See section 4.2 as well. 492 493 494 495 Note that on a QNAME match the NS records are not copied into the AUTH 496 section (This is a requirement from step 4 'matching down the cache' 497 from rfc1034 4.3.2). This is a requirement only for caching 498 servers. BIND8 will copy the NS in the Auth section for 499 authoritative server too. 500 501 502 503 504C 4.2 Additional Data processing. 505 506 507 Additional data is added as long as there is space in the packet. 508 509 When processing the additional section priority is (rfc 2535 3.5 and 510 rfc 2874 4) 511 + A 512 + A6 513 + AAAA 514 + DNSKEY 515 516 For truncation see section C.4.4 517 518 If the DO bit is set RRSIGs will be included with the additional data. 519 520 Although not specified in the RFCs we will assume the following priority: 521 Note that A glue is always added before any AAAA glue. 522 523 + A 524 + RRSIG A 525 + A6 526 + RRSIG A6 527 + AAAA 528 + RRSIG AAAA 529 + DNSKEY 530 + RRSIG DNSKEY 531 532 NSD will act as being authoritative for one zone without having the 533 other zones in cache. In other words: 534 535 If a NSD is authoritative for say both ripe.net and nlnetlabs.nl and 536 both these zones are secondary for each others NS. Then, at least 537 with my zone parser a query for ripe.net NS would return 538 539 540 ANSWER: 541 ripe.net NS ns.ripe.net 542 NS ns.nlnetlabs.nl 543 Additional 544 ns.ripe.net A 10.0.0.1 545 546 547 and not 548 549 ANSWER: 550 ripe.net NS ns.ripe.net 551 NS ns.nlnetlabs.nl 552 Additional 553 ns.ripe.net A 10.1.0.1 554 ns.nlnetlabs.nl A 10.2.0.2 555 556 This behavior is a consequence of NSD using precompiled packets. These 557 are 'constructed' zone by zone. It is an optimisation of speed versus 558 network optimisation. 559 560 In NSD2 and later this behaviour still exists, even though the packets 561 are constructed at run time, only information from the current zone 562 is added to a response. 563 564C 4.3 Label compression in RDATA 565 566 In the spirit of RFC 1035 section 3.3. and 4.4.1 ("Pointers can 567 only be used for occurrences of a domain name where the format is not 568 class specific.") we only do label compression for labels in rdata 569 for which this is specifically mentioned in the RFC defining the RR. 570 571 572 -NS, SOA, CNAME, and PTR (rfc 1035 3.3) 573 574 Others defined in (rfc 1035 3.3) are not compressed. 575 576 BIND8 does compression for all RR from rfc 1035 for which dnames 577 appear in the rdata. 578 579 (Note that other RFCs do refer to e.g. MX dname in rdata being 580 compressed (e.g. rfc2974 4.). 581 582 -MB, MG, MR, MINFO, MX also have compressed dnames. 583 These RRs and their compression are described in RFC 883. 584 585 -NSEC, RRSIG and DNSKEY MUST NOT have dname compression (rfc 4034). 586 587 For RRs not mentioned here no label compression in the rdata is 588 performed. 589 590 591 592C 4.4 Truncation handling. (as rfc2181 9) 593 594 If inclusion of a RR set that is REQUIRED in either the answer or 595 authority section leads to message truncation. The section is left 596 empty and the truncation (TC) bit is set. If the DO bit is set RRSIG 597 RRs are required in the answer and authority section. 598 599 Inclusion of NS RRs in the authority section when QTYPE=DNSKEY is 600 removed since NSD version 3.2.3. QTYPE=DS followed in version 3.2.7. 601 This is to prevent resolvers from unnecessarily falling back to TCP. 602 Only DNSKEY and DS records are considered, because it showed that 603 especially these DNS packets are 'troublesome'. 604 605 The feature 'minimize responses' is included since NSD 3.2.9. 606 NS RRsets that would go into the Authority section in positive 607 responses are not considered REQUIRED and therefore will NOT lead 608 to setting of the TC bit. The minimal response size is: 609 - 512 in case of no EDNS; 610 - 1460 in case of EDNS/IPv4; 611 - 1220 in case of EDNS/IPv6; 612 - the advertized buffer size if that value is smaller than the 613 the EDNS defaults. 614 615 The feature can be disabled during build time with 616 --disable-minimal-responses. 617 618 If inclusion of an RRset in the Additional section is not possible 619 RRs are omitted one by one. This may lead to incomplete RRsets. 620 Omission of RRs from the Additional section because of message size 621 constraints will NOT lead to setting of the TC bit. (rfc2181 9) We 622 allow for incomplete RRsets in the additional section. 623 624 625C 4.5 NSEC processing. 626 627 The NSEC record is required to be in the authority section if a QNAME 628 or a QTYPE cannot be matched (see section 5 or RFC2535). 629 630 If the DO bit on the query is not set then NSEC records should only be 631 required if QNAME and QTYPE match. 632 633 If the do bit on the query is set then we have to do NSEC processing if 634 a zone is marked as secure otherwise we should do nothing. 635 636 If the QNAME matches a name in the zone but the QTYPE does not match 637 then the answer section should remain empty and the Authority 638 section should have either the NSEC RR that matches QNAME or the NSEC 639 RR (opt-in) that indicates QNAME is in an insecure part of the zone. 640 641C 4.6 Timeout management. 642 643 NSD manages timeouts on the SOAs for secondary zones according to RFC. 644 Timeouts are randomized, to avoid network bursts. The randomization 645 used is 90-100% of the original value - meaning that it can never be 646 delayed. This means zones cannot expire later than they should. 647 It does mean the average timeout becomes 95% of the original. 648 The random number calculation is primitive but fast. It is about spreading 649 load not about randomness per se (in the crypto sense). 650 651------------------------------------------------------------------------------- 652 653Appendix A 654 655IANA list of RR records 656 657 658RR records details. 659 "A" 1, # RFC 1035, Section 3.4.1 660 No additional processing 661 662 "NS" 2, # RFC 1035, Section 3.3.11 663 Additional A type processing. 664 dname compression in RDATA 665 666 "MD" 3, # RFC 1035, Section 3.3.4 (obsolete) 667 "MF" 4, # RFC 1035, Section 3.3.5 (obsolete) 668 669 "CNAME" 5, # RFC 1035, Section 3.3.1 670 No additional section processing. 671 dname compression in RDATA 672 673 "SOA" 6, # RFC 1035, Section 3.3.13 674 No additional section processing. 675 SOA TTL semantics updated by rfc2308 676 dname compression in RDATA 677 678 "MB" 7, # RFC 1035, Section 3.3.3 679 Additional processing type A of MADNAME 680 681 682 "MG" 8, # RFC 1035, Section 3.3.6 683 No additional section processing. 684 685 "MR" 9, # RFC 1035, Section 3.3.8 686 No additional section processing. 687 688 689 690 "NULL" 10, # RFC 1035, Section 3.3.10 691 NOT IMPLEMENTED 692 Not allowed in master files. (Not implemented in BIND) 693 694 695 696 "WKS" 11, # RFC 1035, Section 3.4.2 (deprecated in favor of MX 697 [RFC-1123] but not Obsolete) 698 699 700 "PTR" 12, # RFC 1035, Section 3.3.12 701 No additional section processing. 702 dname compression in RDATA 703 704 705 "HINFO" 13, # RFC 1035, Section 3.3.2 706 No additional section processing. 707 708 "MINFO" 14, # RFC 1035, Section 3.3.7 709 No additional section processing. 710 711 "MX" 15, # RFC 1035, Section 3.3.9 712 Additional section processing type A of host in Exchange 713 714 "TXT" 16, # RFC 1035, Section 3.3.14 715 No additional section processing. 716 717 "RP" 17, # RFC 1183, Section 2.2 718 No additional section processing. 719 720 "AFSDB" 18, # RFC 1183, Section 1 721 type A additional section processing for <hostname> 722 dname compression for hostname 723 724 "X25" 19, # RFC 1183, Section 3.1 725 No additional section processing. 726 727 728 "ISDN" 20, # RFC 1183, Section 3.2 729 No additional section processing. 730 731 "RT" 21, # RFC 1183, Section 3.3 732 type X25, ISDN, and A additional section processing 733 for <intermediate-host>. 734 dname compression for intermediate-host. 735 736 737 "NSAP" 22, # RFC 1706, Section 5 738 No additional section processing. 739 NSAP requires special parsing rules. 740 741 742 "NSAP_PTR" 23, # RFC 1348 (obsolete) 743 744 "SIG" 24, # RFC 2535, Section 745 4.1.7: signers name field MAY be compressed. 746 4.1.8.1: SIG(0) specification. 747 748 See section 4.2 for additional section processing. 749 SIG signers name field MAY be compressed. (2535 4.1.7) 750 751 "KEY" 25, # RFC 2535, Section 752 753 See section RFC 2535 3.5 on inclusion of keys. 754 755 "PX" 26, # RFC 2163, 756 757 section 4 says: 758 759 PX records cause no additional section processing 760 761 All normal DNS conventions, like default values, 762 wildcards, abbreviations and message 763 compression, apply also for all the components 764 of the PX RR. 765 766 Compression is not explicitly mentioned: 767 This label is CLASS specific: NO compression. 768 769 770 "GPOS" 27, # RFC 1712 (obsolete) 771 "AAAA" 28, # RFC 1886, Section 2.1 772 "LOC" 29, # RFC 1876 773 No requirements on additional section processing. 774 775 "NXT" 30, # RFC 2535 776 No requirements on additional section processing. 777 NXT dname field MAY be compressed. (2535 4.2) 778 779 780 "EID" 31, # draft-ietf-nimrod-dns-xx.txt e.g. http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt 781 782 "NIMLOC" 32, # draft-ietf-nimrod-dns-xx.txt e.g. http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt 783 784 "SRV" 33, # RFC 2782 785 No dname compression of target field. (rfc2782 page 4) 786 787 788 "ATMA" 34, # [Dobrowski] 789 790 791 "NAPTR" 35, # RFC 2168, 2915 792 Contains regular expressions. Take care of escaping 793 backslashes while parsing 794 (rfc2915 p6): 'Replacement' field: no compression 795 796 "KX" 36, # RFC 2230 797 798 KX records MUST cause type A additional section 799 processing for the host specified by EXCHANGER. 800 In the event that the host processing the DNS 801 transaction supports IPv6, KX records MUST also 802 cause type AAAA additional section processing. 803 804 The KX RDATA field MUST NOT be compressed. 805 (rfc2230 section 3) 806 807 808 "CERT" 37, # RFC 2538 809 No dnames in rdata 810 811 812 "A6" 38, # RFC 2874 813 No dnames in rdata 814 815 "DNAME" 39, # RFC 2672 816 817 NO dname compression of target field. (rfc2672 sect 3) 818 819 "SINK" 40, # [Eastlake] 820 821 "OPT" 41, # RFC 2671 822 Pseudo RR. Not in zone files. 823 824 "APL" 42 # RFC 3123 825 An APL RR with empty RDATA is valid and implements an empty list. 826 827 "DS" 43, # RFC 4033, 4034, 4035. 828 Included with referrals. 829 830 "SSHFP" 44, # SSH Key Fingerprint, RFC 4255 831 832 "IPSECKEY" 45, # RFC 4025 833 Public key RSA/DSA for use in IPSEC. 834 835 "RRSIG" 46, # RFC 4033, 4034, 4035. RFC 3755. 836 Signature, uncompressed dnames. 837 838 "NSEC" 47, # RFC 4033, 4034, 4035. RFC 3755. 839 Signed next ownername, to disprove rrset types and 840 domain name existence. Uncompressed dnames. 841 842 "DNSKEY" 48, # RFC 4033, 4034, 4035. RFC 3755. 843 Key for zone signing or key signing. Public key part. 844 845 "DHCID" 49, # draft-ietf-dnsext-dhcid-rr-13.txt 846 847 "NSEC3" 50, # RFC 5155. 848 "NSEC3PARAM" 51, # RFC 5155. 849 850 "TLSA" 52, # RFC 6698. 851 852 Unknown 53 - 98, 853 854 "SPF" 99, # RFC 4408 (Experimental). 855 856 "UINFO" 100, # [IANA-Reserved] 857 "UID" 101, # [IANA-Reserved] 858 "GID" 102, # [IANA-Reserved] 859 "UNSPEC" 103, # [IANA-Reserved] 860 861 "NID" 104, # RFC 6742 862 "L32" 105, # RFC 6742 863 "L64" 106, # RFC 6742 864 "LP" 107, # RFC 6742 865 866 "EUI48" 108, # RFC 7043 867 "EUI64" 109, # RFC 7043 868 869 "TKEY" 249, # RFC 2930 870 "TSIG" 250, # RFC 2845 871 "IXFR" 251, # RFC 1995 872 "AXFR" 252, # RFC 1035 873 "MAILB" 253, # RFC 1035 (MB, MG, MR) 874 "MAILA" 254, # RFC 1035 (obsolete - see MX) 875 "ANY" 255, # RFC 1035 876 "URI" 256, # RFC 7553 877 "CAA" 257, # RFC 6844 878 879______________________________________________________________________ 880 881Appendix B Details on specific design and implementation choices. 882 883 884B.1. Returning the root delegation when no answer can be found 885 886 From RFC1034/1035 it is not obvious if returning a root delegation 887 is a (non-)requirement for authoritative servers. 888 889 We have decided not to implement a root-hints since an 890 authoritative server should in normal circumstances only receive 891 queries for which the server is authoritative. 892 893 Also see RFC 1123 section 6.1.2.5. 894 895 Whenever an answer cannot been provided we return a SERVFAIL. It 896 has been argued that this is a policy decision and thus a REFUSE 897 should be returned. However, in the spirit of RFC1034/1035 a server 898 should return cached data, if that cache cannot be reached a SERVFAIL 899 is an appropriate response. 900 901 Also see the discussion on the 'namedroppers list' Starting April 902 2002 with subject "name server without root cache " 903 (ftp://ops.ietf.org/pub/lists/) 904 905 906 907 908 909______________________________________________________________________ 910 911Appendix C (Planned) Features 912 913NSD Version 1.0.0. and above 914 915 The first release ( 1.0.0 ) contains an implementation of the 916 standard RFC 1034 and RFC 1035, of proposed standards RFC2181 917 (clarifications), RFC2308 (negative caching). 918 919 AXFR is not implemented in v1.0.0. 920 921 922 The RRs specified in the following RFCs are implemented in v1.0.0 923 924 - RFC 1183 (Multiple RRs) 925 - RFC 1706 (NSAP) (Informational) 926 - RFC 1876 (LOC RR) 927 - RFC 1886 (AAAA RR) 928 - RFC 2230 (KX RR) (Informational) 929 - RFC 2536 (CERT RR) 930 - RFC 2671 (EDNS0) 931 - RFC 2782 (SRV) 932 - RFC 2915 (NAPTR RR) 933 - RFC 2915 (SRV RR) 934 935 - Version 1.0.1 will also support features from 936 draft-ietf-dnsop-serverid-00.txt: The following names have associated 937 TXT RRs in the CHAOS class: ID.SERVER. and VERSION.SERVER. 938 939 - RFC2535 (DNSSEC) will be implemented in (1.1.0) once the current 940 drafts DS and OPT-IN have made it to the standards track. 941 (DNSSEC also includes RFC2536 (DSA), RFC2537 (RSA), RFC3225 (DO 942 bit) 943 944 Version 1.1.0 will not allow wildcards in DNSEC signed zones. 945 946NSD Version 2.0. and above 947 948 - AXFR will be implemented in 1.0.1 with simple IP based ACLs. In 949 1.1.0. AXFR will also supported with RFC 2845 (TSIG) 950 Using external tool nsd-xfer, that supports TSIG to download 951 a zone from a server. 952 953 - DNSSEC supported RRSIG/NSEC/DNSKEY, RFC 4033, 4034, 4035. 954 955 - wildcards allowed in dnssec secured zones. 956 957 - RFC 2673 (Binary labels) 958 - RFC 2874 (A6) 959 960NSD Version 3.0. and above 961 962 AXFR: - NSD serves AXFR, with TSIG if needed. 963 - NSD requests AXFR from xfrd. This is noncompliant with RFC. 964 It does not ask for the SOA serial number using a query 965 beforehand (nsd-xfer does). It terminates the AXFR after 966 the first packet if it determines the AXFR is not needed. 967 968 RFC 1995 (IXFR) support only for making requests to other servers. 969 - IXFR is not served. 970 971 RFC 1996 (NOTIFY): 972 - will ignore extraneous data in notify (instead of checking 973 if they differ from content in zone). Only checks SOA serial. 974 This is too hard, since other information is not available in 975 xfrd, the process that handles the notify. 976 - Will not send notify to NS-servers of a zone. Only notify 977 sent to 'notify:' entries in config file. 978 - Incoming has an ip-based and key-based access control list. 979 - can be with TSIG. 980 981 RFC 2845 (TSIG): 982 - TSIG is supported for notify, axfr, ixfr, regular queries. 983 984 RFC 2672 (DNAME) support. 985 986 Secondary zones: - follows SOA timers. (NSD 2 and before did not) 987 (RFC 1034, 1035). 988 989 RFC 4509 (SHA-256 DS) support. 990 991 RFC 4635 (HMAC SHA TSIG) support for mandatory algorithms: hmac-md5, 992 hmac-sha1, hmac-sha256. 993 994 RFC 5001 (NSID) support. 995 996 RFC 5155 (NSEC3) support. 997 998 RFC 5702 (SHA-2) support. 999 1000 RFC 5936 (AXFR) support. 1001 1002 RFC 6605 (ECDSA) support. 1003 1004 RFC 6698 (DANE) support for TLSA RR type. 1005 1006 RFC 6742 (ILNP) support for NID, L32, L64, LP RR types. 1007 1008 RFC 6844 (CAA) support for CAA RR type. 1009 1010 RFC 7043 (EUI48+64) support for EUI48, EUI64 RR types. 1011 1012 RFC 7553 support for URI RR type. 1013 1014Not implemented: 1015 1016 RFC2136 (Dynamic update) are not implemented and will not be implemented as 1017 zone control is not implemented in NSD itself. 1018 1019 1020Appendix D. Changes to this file. 1021 102214 january 2014 (Matthijs Mekking) 1023- Updated file with CAA RRtype support. 1024 102518 june 2013 (Matthijs Mekking). 1026- Updated file with EUI48 and EUI64 RRtype support. 1027 102825 april 2013 (Matthijs Mekking). 1029- Removed requirements label compression for RP, RT and AFSDB. 1030 103119 november 2012 (Matthijs Mekking). 1032- Updated file with RFC 6698 (DANE) support for TLSA RR type and 1033 RFC 6742 (ILNP) support for NID, L32, L64, LP RR types. 1034 103517 april 2012 (Matthijs Mekking). 1036- Updated file with RFC 5936 (AXFR) and RFC 6605 (ECDSA) support. 1037 103817 october 2011 (Matthijs Mekking). 1039- Updated file with RFC 5702 (SHA-2) and RFC 4509 (SHA-256 DS) support. 1040 104117 october 2011 (Matthijs Mekking). 1042- Added section on minimal responses. 1043 104424 february 2010 (Matthijs Mekking). 1045- Updated file with RFC 5001 (NSID) and RFC 5155 (NSEC3) support (version 1046 3.0.0 and above). 1047 104830 october 2008 (Matthijs Mekking). 1049- Added support for RFC 4635 (HMAC SHA TSIG). 1050 105126 july 2006 (Wouter Wijngaards). 1052- Comments changed to background items. 1053- KEY->DNSKEY, SIG->RRSIG in the text, dnssec-bis style. 1054 1055______________________________________________________________________ 1056$Id: REQUIREMENTS,v 1.2 2022/09/24 17:38:17 christos Exp $ 1057 1058