idnits 2.17.00 (12 Aug 2021) /tmp/idnits5884/draft-dickson-dnsop-spartacus-lang-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 15, 2014) is 2775 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 236 == Unused Reference: 'RFC1033' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC2308' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'RFC5011' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC5155' is defined on line 554, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 1033 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop B. Dickson 3 Internet-Draft 4 Expires: April 18, 2015 October 15, 2014 6 A Language to Describe the DNS Wire Format 7 draft-dickson-dnsop-spartacus-lang-00 9 Abstract 11 As part of the SPARTACUS DNS gateway system, building a full DNS 12 parser was necessary. Parsing DNS packets is the only way to avoid 13 propogating packets which are not correctly formatted DNS packets. 15 In order to facilitate building a new parser from scratch, the author 16 chose to build a parser-builder which takes as input, a description 17 of the DNS wire format. 19 This document describes the language created to facilitate this 20 description, and includes the resulting DNS wire format description 21 in this language. 23 Author's Note 25 Intended Status: Informational. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 18, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2.1. Comparison . . . . . . . . . . . . . . . . . . . . . 4 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Syntax Overview . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Name Space . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Syntax Elements . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Enumeration and RFC References . . . . . . . . . . . . . 7 71 4.3. Structural Elements . . . . . . . . . . . . . . . . . . . 8 72 4.4. Preprocessing Elements . . . . . . . . . . . . . . . . . 9 73 5. Interactions and Behavior . . . . . . . . . . . . . . . . . . 11 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 9.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Appendix A. DNS Message Format Encoding . . . . . . . . . . . . 13 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 DNS (The Domain Name System) has been around a long, long time. Over 86 that time, the original Resource Record types have in some cases been 87 made officially obsolete. Other, new Resource Records have been 88 added. New definitions of bits in the header have arisen. 90 There have even been extensions added, which are intended to be 91 backward compatible. The OPT pseudo-resource record, in particular, 92 overloads some of the standard field definitions in order to achieve 93 its goals. 95 The end result is a wire format which is potentially difficult to 96 parse. 98 In the interests of assisting future DNS endeavors, a complete 99 description of the DNS wire format has been produced, and a 100 comparitively simple language for facilitating this description has 101 been created. 103 1.1. Rationale 105 Re-inventing the wheel, figuratively speaking, is frowned upon. By 106 providing a description of the DNS wire format, and a language to 107 accomplish this description, the author hopes that future work in the 108 DNS arena might be made easier, at least in some cases. 110 The project which motivated this work, SPARTACUS (Secure, Private 111 Aparatus for Resolution Transported Across Constraining and/or 112 Unmaintained Systems), is intended to have multiple implementations 113 in a variety of languages and environments. Creating a standard 114 description of the DNS wire format, is intended to facilitate both an 115 easier implementation effort, and a greater likelihood of compatible, 116 interoprable implementations. 118 The SPARTACUS project is intended to create bidirectional DNS 119 gateways for transporting DNS over other protocols and encodings, 120 such as JSON over HTTP(S). This is intended to create "bridges" 121 between DNS speakers. THe goal is to transport DNS messages from any 122 DNS client implementation to any DNS server implementation. Each 123 gateway needs to be liberal in what it accepts (any valid DNS message 124 conforming to the relevant RFCs) and conservative in what it sends 125 (only packets which parse correctly). 127 A secondary objective of the encoding in JSON is the use of the same 128 names for data elements and structures as in the DNS RFCs. The idea 129 is to provide human-readable JSON encodings, for easier diagnostics 130 during development, and when investigating operational issues. 132 1.2. Related Work 134 A variety of other work exists, and provided inspiration for the 135 SPARTACUS work. This includes web/JSON DNS portals, for providing 136 DNS query responses in JSON format, often with a "looking glass" 137 functionality. 139 o Multi-location DNS Looking Glass - Tool for performing DNS queries 140 via RESTful interface in multiple locations, returning results in 141 JSON format 143 o DNS Looking Glass - Tool for performing DNS queries via RESTful 144 interface, returning results in JSON format 146 o DNS JSON - Source code project from circa 2009, partially 147 developed but incomplete/abandoned 149 o DNSSEC-trigger[trigger] - embedded control function in NLnetlabs' 150 Unbound resolver, for attempting DNS queries over TCP port 80 when 151 DNSSEC problems are encountered 153 o Various other web-based DNS lookup tools 155 1.2.1. Comparison 157 There has been at least one previous effort to develop code for a 158 DNS-JSON encoding, which appears to have been abandoned after one-way 159 encoding was done, circa 2009. The project focused on presenting 160 results to DNS queries in JSON format, with an intention to create a 161 client gateway, which never materialized. The project can be found 162 in two places ([JPF_jsondns] and [jsondns.org]). One major 163 difference is that DNS query response status is converted to HTTP 164 error codes, rather than being embedded in the JSON answer. This 165 makes it unsuitable for bidirectional use. Only a few DNS type codes 166 were implemented. 168 Another DNS JSON tool [fileformat.info], similarly focuses only on 169 answers, with a limited number of type codes. 171 Yet another tool for looking up DNS via HTTP with JSON responses is 172 the "dnsrest" [restdns.net]. It too focuses only on answer values, 173 and is similarly not able to fully produce results that can be turned 174 back into DNS answer packets. 176 The "DNS Looking Glass" [bortzmeyer.org], is primarily designed for 177 returning DNS answer data. As such, it lacks encoding suitable for a 178 bidirectional scheme. It is primarily focused on XML output, with 179 JSON output organized around DNS resolution meta-data, plus answer 180 data in a generic schema. (The schema itself is described in 181 [draft-bortzmeyer-dns-json].) 183 The "Multilocation DNS Looking Glass" [dns-lg.com], uses a RESTful 184 query mechanism of "node/qname/qtypename" to request the looking 185 glass (LG) to perform a DNS lookup for the qname and qtype, and 186 returns the response in a JSON format. The JSON format is generic, 187 encapsulating all types as string data in presentation format, with a 188 generic label of "rdata". This does not facilitate decoding easily, 189 as the JSON scheme provides no information for parsing the rdata 190 field. The type (qtype for the query, or type for answer/authority/ 191 additional) is in string (symbolic) form, and the elements are 192 objects and thus in unordered lists. The JSON scheme is fine for 193 one-way encoding for human readability, but not suitable for two-way 194 conversion back into DNS. 196 DNSSEC-trigger[trigger] can only be used in environments that use 197 NLnetlabs' Unbound resolver, or where Unbound can be deployed as a 198 replacement for existing recursive resolvers and/or stub resolvers. 200 A variety of other web lookup tools exist, predominantly producing 201 DNS validation (zone structure and hierarchy), maps, meta-data, or 202 literal output from the 'dig' tool, in formats as varied as the 203 purposes of the tools. Dig output, while being reasonably 204 deterministic, is not sufficiently well-formed as to facilitate 205 "screen scraping" as a parsing method. 207 2. Requirements 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [RFC2119]. 213 3. Syntax Overview 215 The syntax for the language is largely derived from only the abstract 216 element types required to express data types and structures in DNS. 217 In particular, the language has been kept as familiar and a simple as 218 possible. Design choices were made to avoid over-abstracting 219 elements which are by nature "difficult". Some objects have their 220 size defined by other objects' values, or arithmetic expressions of 221 values and literals. This includes array dimensions, and lengths of 222 strings. 224 The general syntactic style uses braces ("{" and "}"), similar to the 225 config files for BIND, for structural items. 227 Some familiarity with the DNS protocol is assumed. 229 3.1. Name Space 231 The name space of this language is tailored to the specific 232 environment. Names need only be unique within their specific scope. 234 Since DNS messages are processed as "first in, first out" objects, 235 the references to arrays have been simplified. Rather than keeping 236 track of the index to an array, e.g. "a.b[3].c", the index is 237 omitted, resulting in "a.b.c". 239 Relative object naming works the same as DNS search-list processing, 240 depth-first. For example, while parsing "a.b.c.d", the name "foo" 241 would refer the first of the following that exists: "a.b.c.foo", 242 "a.b.foo", "a.foo". 244 4. Syntax Elements 246 The syntactic elements of the language are base data types, 247 structural elements, and preprocessing constructs. Additional 248 elements provide the ability to annotate objects, and to define 249 mnemonics for values. 251 4.1. Data Types 253 Base data types are encoded as "name:type", for a small number of 254 predefined types and appropriate presentation formats: 256 o bitN - N-bit value, with 1-bit encoded as TRUE/FALSE. 258 o intN - unsigned N-bit integer, N is one of 8, 16, 32, 48. 260 o dotquad - IPv4 address. 262 o quadhex8 - IPv6 address. 264 o quadhex4 - 64-bit value (IPv6 prefix or IPv6 host-part). 266 o hex-string@EXPR - binary data of EXPR-specified length. 268 o base64@EXPR - binary data of EXPR-specified length. 270 o string - one or more character strings of 8-bit length and N-byte 271 string. 273 o string? - optional single string. 275 o fqdn - Fully Qualified Domain Name. 277 o mbox - Mailbox: Fully Qualified Domain Name preceded by username. 278 Wire format is identical to fqdn. 280 Example of a base64 object named "MAC" whose size is specified by 281 "MACsize", in context: 283 TSIG (RFC 2845) { 284 Algorithm:fqdn 285 TimeSigned:int48 286 Fudge:int16 287 MACsize:int16 288 MAC:base64@MACsize 289 OriginalID:int16 290 Error:int16 291 OtherSize:int16 292 OtherData:base64@OtherSize 293 } 295 When the parser decodes MACsize (e.g. as the unsigned integer "12"), 296 it would then decode 12 bytes of data into MAC, and convert that data 297 into base-64 (for encoding to JSON). 299 4.2. Enumeration and RFC References 301 The remainder of the elements of the language exist to permit 302 annotation of well-known values (such as "NXDOMAIN" for RCODE=3), and 303 for providing human-friendly RFC references. These are: 305 (RFC XXXX) - for any object name, associates a given RFC with it. 306 Added by the parser to the corresponding JSON string. 308 Enum ENUM_NAME - allows for integer types, to have mnemonics 309 associated with them, as "value:name" pairs. 311 Of ENUM_NAME - adds the name whenver the corresponding value is 312 parsed (for this integer-type object). 314 Example of RFC: 316 NSID (RFC 5001) { 317 NSIDContent:hex-string@*Len 318 } 320 When processing an NSID, the JSON string would be: 322 "NSID (RFC 5001)" 324 instead of 326 "NSID" 328 Example of enum: 330 enum classes { 331 1:IN 332 3:CH 333 254:NONE 334 255:ANY 335 } 337 CLASS:int16 of classes 339 When processing a CLASS object with value 1, the JSON encoding would 340 be: 342 "CLASS" : [ "IN" : 1 ] 344 instead of 346 "CLASS" : 1 348 4.3. Structural Elements 350 There are two structural elements: 352 o Structure - an ordered group of elements, including any 353 combination of Data Types and further Structural elements. There 354 is no limit on structure depth. 356 o Array - an Array has one child type, which can be either a Data 357 Type, or simple Structure. The size of the array can be explicit, 358 referencing the name of any integer type, or implicit, referencing 359 the name of an integer whose value is the total length of the 360 array. 362 o Switch and Case - similar to the C language elements, these 363 provide a way of encoding a sparse array. The Switch object has a 364 child Structure which consists only of Case objects. Each Case 365 object associates a value with a named object (Structure or Data 366 Type). The Switch references the name of an integer object type, 367 which is compared to the Case objects (when parsing data). 369 Example of simple structure: 371 HFlags { 372 QR:bit1 373 Opcode:bit4 374 AA:bit1 375 TC:bit1 376 RD:bit1 377 RA:bit1 378 Z:bit1 379 AD:bit1 380 CD:bit1 381 RCODE:bit4 382 } 384 Example of an array DAU_TYPES, in context: 386 LIST_LENGTH:int16 387 DAU_TYPES: array[LIST_LENGTH] DAU_TYPE { 388 ALG_CODE:int8 389 } 391 Example of switch Field3 based on object TYPE, and corresponding 392 cases ("case *" is equivalent to "default" in C): 394 TYPE:int16 of rrtype 395 Field3: switch TYPE { 396 case 41: UDPSIZEFIELD { 397 UDPSIZE:int16 398 } 399 case *: CLASSFIELD { 400 CLASS:int16 401 } 402 } 404 When parsing data, if the TYPE had value 41, when converted to JSON, 405 the object name "UDPSIZE" would appear, rather than "CLASS". 407 4.4. Preprocessing Elements 409 There are two elements which provide preprocessing capabilities: 411 o Define - objects are ways of doing logical cut/paste of input file 412 contents. 414 o Reference - to the same named object created with a "define", 415 results in a literal copy of the original range of file contents. 417 This operates much like "#define" does in the C language. By doing 418 this, identical structures and object types which occur in different 419 places can be maintained in one section of the file. In partucular, 420 the Resource Records from all three sections can be defined once. 422 Example of one define and two references to RDATATYPE. Note that an 423 object named RDLENGTH must be present in an ancestor of both parent 424 objects: 426 Input file before preprocessor: 428 define RDATATYPE { 429 case 1: A { 430 Address:dotquad 431 } 432 ... (lots of lines omitted for clarity) 433 case 256: URI { 434 GENERIC_RDATA:hex-string@RDLENGTH 435 } 436 } 438 Answer { 439 RR_LIST: array[HEADER.ANCOUNT] RR { 440 NAME:fqdn 441 TYPE:int16 of rrtype 442 CLASS:int16 of classes 443 TTL:int32 444 RDLENGTH:int16 445 RDATA: switch TYPE { 446 reference RDATATYPE 447 } 448 } 449 } 450 Authority { 451 RR_LIST: array[HEADER.NSCOUNT] RR { 452 NAME:fqdn 453 TYPE:int16 of rrtype 454 CLASS:int16 of classes 455 TTL:int32 456 RDLENGTH:int16 457 RDATA: switch TYPE { 458 reference RDATATYPE 459 } 460 } 461 } 463 Result of preprocessing: 465 Answer { 466 RR_LIST: array[HEADER.ANCOUNT] RR { 467 NAME:fqdn 468 TYPE:int16 of rrtype 469 CLASS:int16 of classes 470 TTL:int32 471 RDLENGTH:int16 472 RDATA: switch TYPE { 473 case 1: A { 474 Address:dotquad 475 } 476 ... (lots of lines omitted for clarity) 477 case 256: URI { 478 GENERIC_RDATA:hex-string@RDLENGTH 479 } 480 } 481 } 482 } 483 Authority { 484 RR_LIST: array[HEADER.NSCOUNT] RR { 485 NAME:fqdn 486 TYPE:int16 of rrtype 487 CLASS:int16 of classes 488 TTL:int32 489 RDLENGTH:int16 490 RDATA: switch TYPE { 491 case 1: A { 492 Address:dotquad 493 } 494 ... (lots of lines omitted for clarity) 495 case 256: URI { 496 GENERIC_RDATA:hex-string@RDLENGTH 497 } 498 } 499 } 500 } 502 5. Interactions and Behavior 504 6. Security Considerations 506 None per se. 508 7. IANA Considerations 510 This document contains no IANA-specific material. 512 8. Acknowledgements 514 To be added later. 516 9. References 518 9.1. Normative References 520 [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 521 1033, November 1987. 523 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 524 STD 13, RFC 1034, November 1987. 526 [RFC1035] Mockapetris, P., "Domain names - implementation and 527 specification", STD 13, RFC 1035, November 1987. 529 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 530 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 531 RFC 2136, April 1997. 533 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 534 Specification", RFC 2181, July 1997. 536 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 537 NCACHE)", RFC 2308, March 1998. 539 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 540 Rose, "DNS Security Introduction and Requirements", RFC 541 4033, March 2005. 543 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 544 Rose, "Resource Records for the DNS Security Extensions", 545 RFC 4034, March 2005. 547 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 548 Rose, "Protocol Modifications for the DNS Security 549 Extensions", RFC 4035, March 2005. 551 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 552 Trust Anchors", STD 74, RFC 5011, September 2007. 554 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 555 Security (DNSSEC) Hashed Authenticated Denial of 556 Existence", RFC 5155, March 2008. 558 9.2. Informative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 [JPF_jsondns] 564 "DNS over HTTP", . 566 [jsondns.org] 567 Franusic, J., "Query DNS via REST", . 569 [fileformat.info] 570 Marcuse, A., "DNS in client-side JavaScript", 571 . 573 [restdns.net] 574 "REST-DNS", . 576 [bortzmeyer.org] 577 Bortzmeyer, S., "DNS Looking Glass", 578 . 580 [draft-bortzmeyer-dns-json] 581 Bortzmeyer, S., "DNS in JSON", 582 . 584 [dns-lg.com] 585 Cambus, F., "Multilocation DNS Looking Glass", 586 . 588 [trigger] NLnet Labs, "Dnssec-Trigger", 589 . 591 Appendix A. DNS Message Format Encoding 593 The entire encoding of the DNS message format follows. 595 # opcodes 596 enum opcodes { 597 0:Query 598 2:Status 599 4:Notify 600 5:Update 601 } 603 # classes 604 enum classes { 605 1:IN 606 3:CH 607 254:NONE 608 255:ANY 609 } 611 enum ednstype { 612 3:NSID 613 5:DAU 614 6:DHU 615 7:N3U 616 } 617 enum rrtype { 618 1:A 619 28:AAAA 620 15:MX 621 2:NS 622 12:PTR 623 5:CNAME 624 39:DNAME 625 6:SOA 626 37:CERT 627 48:DNSKEY 628 43:DS 629 32769:DLV 630 47:NSEC 631 50:NSEC3 632 51:NSEC3PARAM 633 46:RRSIG 634 24:SIG 635 52:TLSA 636 44:SSHFP 637 249:TKEY 638 250:TSIG 639 35:NAPTR 640 33:SRV 641 99:SPF 642 16:TXT 643 18:AFSDB 644 19:X25 645 17:RP 646 21:RT 647 20:ISDN 648 29:LOC 649 27:GPOS 650 104:NID 651 105:L32 652 106:L64 653 107:LP 654 251:IXFR 655 252:AXFR 656 253:MAILB 657 254:MAILA 658 255:* 659 256:URI 660 257:CAA 661 32768:TA 662 41:OPT 663 } 665 # 666 # EDNS Option-codes follow 667 define EDNSTYPE { 668 case 3: NSID (RFC 5001) { 669 NSIDContent:hex-string@*Len 670 } 671 case 5: DAU (RFC 6975) { 672 LIST_LENGTH:int16 673 DAU_TYPES: array[LIST_LENGTH] DAU_TYPE { 674 ALG_CODE:int8 675 } 676 } 677 case 6: DHU (RFC 6975) { 678 LIST_LENGTH:int16 679 DHU_TYPES: array[LIST_LENGTH] DHU_TYPE { 680 ALG_CODE:int8 681 } 682 } 683 case 7: N3U (RFC 6975) { 684 LIST_LENGTH:int16 685 N3U_TYPES: array[LIST_LENGTH] NSU_TYPE { 686 ALG_CODE:int8 687 } 688 } 689 } 691 define RDATATYPE { 692 case 1: A { 693 Address:dotquad 694 } 695 case 28: AAAA { 696 Address:quadhex8 697 } 698 case 15: MX { 699 Preference:int16 700 MailExchanger:fqdn 701 } 703 case 2: NS { 704 Target:fqdn 705 } 706 case 12: PTR { 707 Target:fqdn 708 } 709 case 5: CNAME { 710 Target:fqdn 711 } 712 case 39: DNAME { 713 Target:fqdn 714 } 715 case 6: SOA { 716 MasterServerName:fqdn 717 MaintainerName:mbox 718 Serial:int32 719 Refresh:int32 720 Retry:int32 721 Expire:int32 722 NegativeTtl:int32 723 } 724 case 37: CERT (RFC 4398) { 725 Type:int16 726 KeyTag:int16 727 Algorithm:int8 728 Data:base64@RDLENGTH-5 729 } 730 case 48: DNSKEY (RFC 4034) { 731 Flags:int16 732 protocol:int8=3 733 Algorithm:int8 734 data:base64@RDLENGTH-4 735 #Tag:int16=%#(derived/calculated/optional?) 736 } 737 case 43: DS (RFC 4034) { 738 Keytag:int16 739 Algorithm:int8 740 DigestType:int8 741 DelegationKey:hex-string@RDLENGTH-4 742 } 743 case 32769: DLV { 744 Keytag:int16 745 Algorithm:int8 746 DigestType:int8 747 DelegationKey:hex-string@RDLENGTH-4 748 } 749 case 47: NSEC (RFC 4034) { 750 NextName:fqdn 751 FlagBits:hex-string@*RDLENGTH 752 } 753 case 50: NSEC3 (RFC 5155) { 754 Algorithm:int8 755 Flags { 756 ResvBits:bit7 757 OptOut:bit1 758 } 759 Iterations:int16 760 SaltLength:int8 761 Salt:hex-string@SaltLength 762 HashLength:int8 763 NextHash:hex-string@HashLength 764 FlagBits:hex-string@RDLENGTH-6-SaltLength-HashLength 765 } 766 case 51: NSEC3PARAM (RFC 5155) { 767 Algorithm:int8 768 Flags:int8 769 Iterations:int16 770 SaltLength:int8 771 Salt:hex-string@SaltLength 772 } 773 case 46: RRSIG (RFC 4034) { 774 Type:int16 775 Algorithm:int8 776 Labels:int8 777 OTTL:int32 778 SigExp:int32 779 SigInc:int32 780 Tag:int16 781 Signer:fqdn 782 Sig:base64@*RDLENGTH 783 } 784 case 24: SIG (RFC 2931) { 785 Type:int16 786 Algorithm:int8 787 Labels:int8 788 OTTL:int32 789 SigExp:int32 790 SigInc:int32 791 Tag:int16 792 Signer:fqdn 793 Sig:base64@*RDLENGTH 794 } 795 case 52: TLSA (RFC 6698) { 796 CertUsage:int8 797 Selector:int8 798 MatchType:int8 799 Data:hex-string@RDLENGTH-3 800 } 801 case 44: SSHFP (RFC 4255) { 802 Algorithm:int8 803 DigestType:int8 804 Fingerprint:hex-string@RDLENGTH-2 805 } 806 case 249: TKEY (RFC 2930) { 807 Algorithm:fqdn 808 Incep:int32 809 Exp:int32 810 Mode:int16 811 Error:int16 812 KeySize:int16 813 KeyData:hex-string@KeySize 814 OtherSize:int16 815 OtherData:hex-string@OtherSize 816 } 817 case 250: TSIG (RFC 2845) { 818 Algorithm:fqdn 819 TimeSigned:int48 820 Fudge:int16 821 MACsize:int16 822 MAC:base64@MACsize 823 OriginalID:int16 824 Error:int16 825 OtherSize:int16 826 OtherData:base64@OtherSize 827 } 828 case 35: NAPTR (RFC 3403) { 829 Order:int16 830 Preference:int16 831 Flags:string 832 Services:string 833 Regexp:string 834 Replacement:fqdn 835 } 836 case 33: SRV (RFC 2782) { 837 Port:int16 838 Priority:int16 839 Weight:int16 840 Server:fqdn 841 } 842 case 99: SPF (RFC 4408) { 843 Text:string@*RDLENGTH 844 } 845 case 16: TXT { 846 Text:string@*RDLENGTH 847 } 848 case 41: OPT (RFC 6891) { 849 TLV_LIST: array[*RDLENGTH] TLV { 850 TYPE:int16 of ednstype 851 Len:int16 852 Data: switch TYPE { 853 reference EDNSTYPE 854 } 855 } 856 } 857 ### 858 ### Obsolete Stuff Begins 859 ### 860 ## AFS & X25 stuff Begins 861 case 18: AFSDB (RFC 1183) { 862 SubType:int16 863 Hostname:fqdn 864 } 865 case 19: X25 (RFC 1183) { 866 PSDN:string 867 } 868 case 17: RP (RFC 1183) { 869 Who:mbox 870 What:fqdn 871 } 872 case 21: RT (RFC 1183) { 873 Preference:int16 874 Via:fqdn 875 } 876 case 20: ISDN (RFC 1183) { 877 Number:string 878 SA:string?@*RDLENGTH 879 } 880 ## X25 Stuff Ends 881 ## Other Obsolete Stuff 882 case 29: LOC (RFC 1876) { 883 Version:int8 884 Size:int8 885 HorPrec:int8 886 VertPrec:int8 887 Longitude:int32 888 Latitude:int32 889 Altitude:int32 890 } 891 case 27: GPOS (RFC 1712) { 892 Long:string 893 Lat:string 894 Alt:string 895 } 896 ### 897 ### ILNP Stuff 898 ### 899 case 104: NID (RFC 6742) { 900 Pref:int16 901 Node:quadhex4 902 } 903 case 105: L32 (RFC 6742) { 904 Pref:int16 905 ID:dotquad 906 } 907 case 106: L64 (RFC 6742) { 908 Pref:int16 909 ID:quadhex4 910 } 911 case 107: LP (RFC 6742) { 912 Pref:int16 913 Target:fqdn 914 } 915 ## 916 ## Basically unsupported types follow 917 case 251: IXFR { 918 GENERIC_RDATA:hex-string@RDLENGTH 919 } 920 case 252: AXFR { 921 GENERIC_RDATA:hex-string@RDLENGTH 922 } 923 case 253: MAILB { 924 GENERIC_RDATA:hex-string@RDLENGTH 925 } 926 case 254: MAILA { 927 GENERIC_RDATA:hex-string@RDLENGTH 928 } 929 case 255: * { 930 GENERIC_RDATA:hex-string@RDLENGTH 931 } 932 case 256: URI { 933 GENERIC_RDATA:hex-string@RDLENGTH 934 } 935 case 257: CAA { 936 GENERIC_RDATA:hex-string@RDLENGTH 937 } 938 case 32768: TA { 939 GENERIC_RDATA:hex-string@RDLENGTH 940 } 942 } 944 # Draft JSON typenames and element names/types 945 PACKET (RFC 1035) { 946 Header { 947 ID:int16 948 HFlags { 949 QR:bit1 950 Opcode:bit4 of opcodes 951 AA:bit1 952 TC:bit1 953 RD:bit1 954 RA:bit1 955 Z:bit1=0 956 AD:bit1 957 CD:bit1 958 RCODE:bit4 959 } 960 QDCOUNT:int16 961 ANCOUNT:int16 962 NSCOUNT:int16 963 ARCOUNT:int16 964 } 965 Question { 966 QContinuum: switch PACKET.Header.HFlags.Opcode { 967 case 0: QUESTION (RFC 1035) { 968 QNAME:fqdn 969 QTYPE:int16 970 QCLASS:int16 of classes 971 } 972 case 4: NOTIFY (RFC 1996) { 973 QNAME:fqdn 974 QTYPE:int16=SOA 975 QCLASS:int16 of classes 976 } 977 # NB: 978 # Opcode=UPDATE: Redefines Names & Semantics of sections as follows: 979 # ZONE 980 # Prerequisite 981 # Update 982 # Additional_Data 983 # (All sections may have data, even though QR=0) 984 # 985 case 5: ZONE (RFC 2136) { 986 ZNAME:fqdn 987 ZTYPE:int16=SOA 988 ZCLASS:int16 of classes 989 } 990 } 991 } 993 Answer { 994 RR_LIST: array[HEADER.ANCOUNT] RR { 995 NAME:fqdn 996 TYPE:int16 of rrtype 997 CLASS:int16 of classes 998 TTL:int32 999 RDLENGTH:int16 1000 RDATA: switch TYPE { 1001 reference RDATATYPE 1002 } 1003 } 1004 } 1005 Authority { 1006 RR_LIST: array[HEADER.NSCOUNT] RR { 1007 NAME:fqdn 1008 TYPE:int16 of rrtype 1009 CLASS:int16 of classes 1010 TTL:int32 1011 RDLENGTH:int16 1012 RDATA: switch TYPE { 1013 reference RDATATYPE 1014 } 1015 } 1016 } 1017 Additional { 1018 RR_LIST: array[HEADER.ARCOUNT] RR { 1019 NAME:fqdn 1020 TYPE:int16 of rrtype 1021 # do overload on CLASS and TTL for TYPE=41 (OPT) 1022 Field3: switch TYPE { 1023 case 41: UDPSIZEFIELD { 1024 UDPSIZE:int16 1025 } 1026 case *: CLASSFIELD { 1027 CLASS:int16 of classes 1028 } 1029 } 1030 Field4: switch TYPE { 1031 case 41: Extended_RCode_Flags { 1032 RCode:bit8 1033 Version:bit8 1034 DO:bit1 1035 Resv:bit15 1036 } 1037 case *: TTLFIELD { 1038 TTL:int32 1039 } 1040 } 1042 RDLENGTH:int16 1043 RDATA: switch TYPE { 1044 reference RDATATYPE 1045 } 1046 } 1047 } 1048 } 1050 Author's Address 1052 Brian Dickson 1053 12047B 36th Ave NE 1054 Seattle, WA 98125 1056 Email: brian.peter.dickson@gmail.com