idnits 2.17.1 draft-dickson-dnsop-spartacus-system-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 issues found here. 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 date (October 15, 2014) is 3474 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop B. Dickson 3 Internet-Draft 4 Intended status: Standards Track October 15, 2014 5 Expires: April 18, 2015 7 System to transport DNS over HTTP using JSON 8 draft-dickson-dnsop-spartacus-system-00 10 Abstract 12 This is the SPARTACUS DNS gateway system. It is designed to 13 facilitate the transport of DNS messages opaquely, across problematic 14 sections of the Internet. It uses JSON encoding, and HTTP(S) as the 15 protocol for transport. 17 The main criteria of SPARTACUS is that it preserve DNS messages 18 verbatim, and that only properly formatted DNS messages are passed. 20 There are two modes (so far) defined: DNS forwarder (dns clients 21 point to a local gateway, which forwards to a remote gateway for 22 sending to a DNS resolver); and transparent proxy (DNS packets are 23 intercepted, passed to a local gateway, which sends them to the 24 remote gateway, with original destination IP address etc. encoded, 25 and used by the remote gateway as the destination). 27 DNS messages are NAT-friendly, so changes to IP or UDP headers do not 28 impact them. Thus, SPARTACUS does not interfere with TSIG, SIG(0), 29 or Eastlake Cookies. 31 This document describes the system, the components, and behavior, 32 with examples. 34 Author's Note 36 Intended Status: Proposed Standard. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 18, 2015. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 74 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 76 1.3.1. Comparison . . . . . . . . . . . . . . . . . . . . . 5 77 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.1. System Elements . . . . . . . . . . . . . . . . . . . . . 7 80 3.1.1. Node Types . . . . . . . . . . . . . . . . . . . . . 7 81 3.2. System Modes . . . . . . . . . . . . . . . . . . . . . . 7 82 3.2.1. Details on DNS Forwarder mode . . . . . . . . . . . . 8 83 3.2.2. Details on Transparent Proxy mode . . . . . . . . . . 9 84 3.3. Interoperability . . . . . . . . . . . . . . . . . . . . 11 85 3.3.1. In-scope and out-of-scope . . . . . . . . . . . . . . 11 86 4. Interactions and Behavior . . . . . . . . . . . . . . . . . . 12 87 4.1. DNS Gateway Encodings . . . . . . . . . . . . . . . . . . 13 88 4.2. UDP Packet Loss . . . . . . . . . . . . . . . . . . . . . 13 89 4.3. Malformed UDP response . . . . . . . . . . . . . . . . . 13 90 4.4. DNSSEC Validation Failure . . . . . . . . . . . . . . . . 14 91 5. Client-Server Selection and Topology Examples . . . . . . . . 14 92 5.1. Mixed Traffic Walk-Through . . . . . . . . . . . . . . . 16 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 98 9.2. Informative References . . . . . . . . . . . . . . . . . 18 99 Appendix A. DNS Message Encoding Examples . . . . . . . . . . . 18 100 A.1. Simple Query/Answer, No EDNS or DNS Server . . . . . . . 19 101 A.2. Simple Query/Answer, EDNS, no DNS Server . . . . . . . . 21 102 A.3. Simple Query/Answer, no EDNS, with DNS Server . . . . . . 24 103 A.4. Simple Query/Answer, with EDNS and DNS Server . . . . . . 28 104 Appendix B. Server Gateway HTML code . . . . . . . . . . . . . . 32 105 Appendix C. Server Gateway HTTP POST Handler Pseudo-code . . . . 32 106 Appendix D. Client Gateway Pseudo-code . . . . . . . . . . . . . 33 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 109 1. Introduction 111 DNS (The Domain Name System) has been deployed since the 1980's 112 [RFC1033][RFC1034][RFC1035]. Since that time, some of the original 113 Resource Record types have been made officially obsolete [RFC3425]. 114 Some elements have been clarified [RFC2181][RFC2308]. New Resource 115 Records have been added [RFC2136][RFC2845][RFC2930][RFC6891]. New 116 definitions of bits in the header have arisen, in part due to 117 DNSSEC's AD and CD bits [RFC4033][RFC4034][RFC4035][RFC5155]. 119 This has resulted in now-outdated implementations of stateful devices 120 (e.g. devices doing either NAT or packet inspection) interfering with 121 end-to-end communication between DNS speakers. Old devices or 122 implementations reject DNS packets that include these newer 123 capabilities, features, or format changes. 125 At the same time, there has arisen a variety of other devices and 126 systems whose deliberate function is to block, capture, or modify DNS 127 traffic, for profit or for ideological reasons. Examples include 128 hotel wifi systems, ISPs, and state actors. 130 Owing to the stateless nature of DNS over UDP, it is not possible to 131 distinguish between deliberate and accidental sources of DNS 132 interference. 134 1.1. Problem Statement 136 There is a need to provide ways of supporting incremental deployment 137 of new DNS features, in such a way as to prevent deliberate and/or 138 accidental interference in the communication between DNS speakers. 140 For example, DNS speakers could communicate over protected channels 141 and with data integrity validation via DNSSEC. The foremost 142 limitation is that the communication be over any other port/protocol 143 combination than UDP port 53. Ideally, the choice should be an 144 encoding that is compatible with whatever port/protocol combination 145 is selected (versus overloading the port/protocol with incompatible 146 payloads). 148 There is a further need for the communications channel(s) to be 149 standardized, and to not introduce further interoperability problems 150 at the DNS protocol level. Independent implementations need to 151 interoperate completely, to avoid merely pushing the compatibility 152 problem around. 154 In order to solve these problems (individually and/or collectively), 155 the SPARTACUS system has been developed. 157 1.2. Rationale 159 SPARTACUS (Secure, Private Aparatus for Resolution Transported Across 160 Constraining and/or Unmaintained Systems), is a system for encoding 161 and decoding DNS messages (the DNS payload of UDP or TCP packet 162 streams). 164 The SPARTACUS system consists of bidirectional DNS gateways for 165 transporting DNS over HTTP(S) using a JSON encoding scheme. This is 166 intended to create "bridges" between DNS speakers; perhaps a better 167 analogy would be "ferries", as there is no requirement for a tightly 168 bound relationship between individual Client nodes and Server nodes. 170 Standardizing the JSON encoding used by SPARTACUS, is intended to 171 ensure a greater likelihood of compatible, interoprable 172 implementations. 174 The goal is to transport DNS messages from any Client implementation 175 to any Server implementation. 177 Each gateway must be liberal in what it accepts (any valid DNS 178 message conforming to the relevant RFCs, regardless of DNS 179 implementation) and conservative in what it sends (all packets must 180 parse correctly as DNS messages). In order to ensure forward 181 compatibility, unknown Types and (in the case of OPT) sub-types, MUST 182 be accepted and transported. 184 DNS messages MUST traverse the encode/decode process unaltered. The 185 round-trip is designed to, and MUST be implemented to, preserve the 186 entire DNS message's fidelity. This means a 1:1 binary match between 187 input, encoding, decoding, and output. The lengths MUST match, and 188 messages MUST be identical, bit for bit. 190 A secondary objective of the encoding in JSON is the use of the same 191 names for data elements and structures as in the DNS RFCs. The idea 192 is to provide human-readable JSON encodings, for easier diagnostics 193 during development, and when investigating operational issues. 195 1.3. Related Work 197 A variety of other work exists, and provided inspiration for the 198 SPARTACUS work. This includes web/JSON DNS portals, for providing 199 DNS query responses in JSON format, often with a "looking glass" 200 functionality. FIXME format this list appropriately and decorate 201 with words. END FIXME 203 o Multi-location DNS Looking Glass - Tool for performing DNS queries 204 via RESTful interface in multiple locations, returning results in 205 JSON format 207 o DNS Looking Glass - Tool for performing DNS queries via RESTful 208 interface, returning results in JSON format 210 o DNS JSON - Source code project from circa 2009, partially 211 developed but incomplete/abandoned 213 o DNSSEC-trigger[trigger] - embedded control function in NLnetlabs' 214 Unbound resolver, for attempting DNS queries over TCP port 80 when 215 DNSSEC problems are encountered 217 o Various other web-based DNS lookup tools 219 1.3.1. Comparison 221 There has been at least one previous effort to develop code for a 222 DNS-JSON encoding, which appears to have been abandoned after one-way 223 encoding was done, circa 2009. The project focused on presenting 224 results to DNS queries in JSON format, with an intention to create a 225 client gateway, which never materialized. The project can be found 226 in two places ([JPF_jsondns] and [jsondns.org]). One major 227 difference is that DNS query response status is converted to HTTP 228 error codes, rather than being embedded in the JSON answer. This 229 makes it unsuitable for bidirectional use. Only a few DNS type codes 230 were implemented. 232 Another DNS JSON tool [fileformat.info], similarly focuses only on 233 answers, with a limited number of type codes. 235 Yet another tool for looking up DNS via HTTP with JSON responses is 236 the "dnsrest" [restdns.net]. It too focuses only on answer values, 237 and is similarly not able to fully produce results that can be turned 238 back into DNS answer packets. 240 The "DNS Looking Glass" [bortzmeyer.org], is primarily designed for 241 returning DNS answer data. As such, it lacks encoding suitable for a 242 bidirectional scheme. It is primarily focused on XML output, with 243 JSON output organized around DNS resolution meta-data, plus answer 244 data in a generic schema. (The schema itself is described in 245 [draft-bortzmeyer-dns-json].) 247 The "Multilocation DNS Looking Glass" [dns-lg.com], uses a RESTful 248 query mechanism of "node/qname/qtypename" to request the looking 249 glass (LG) to perform a DNS lookup for the qname and qtype, and 250 returns the response in a JSON format. The JSON format is generic, 251 encapsulating all types as string data in presentation format, with a 252 generic label of "rdata". This does not facilitate decoding easily, 253 as the JSON scheme provides no information for parsing the rdata 254 field. The type (qtype for the query, or type for answer/authority/ 255 additional) is in string (symbolic) form, and the elements are 256 objects and thus in unordered lists. The JSON scheme is fine for 257 one-way encoding for human readability, but not suitable for two-way 258 conversion back into DNS. 260 DNSSEC-trigger[trigger] can only be used in environments that use 261 NLnetlabs' Unbound resolver, or where Unbound can be deployed as a 262 replacement for existing recursive resolvers and/or stub resolvers. 264 A variety of other web lookup tools exist, predominantly producing 265 DNS validation (zone structure and hierarchy), maps, meta-data, or 266 literal output from the 'dig' tool, in formats as varied as the 267 purposes of the tools. Dig output, while being reasonably 268 deterministic, is not sufficiently well-formed as to facilitate 269 "screen scraping" as a parsing method. 271 2. Requirements 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 275 document are to be interpreted as described in [RFC2119]. 277 3. System Overview 279 The SPARTACUS system is designed to improve the reliability and 280 security of the DNS system, by providing the means to transport DNS 281 traffic across segments of the Internet. The goal is to bypass 282 problem areas which interfere with DNS communications, regardless of 283 root cause of the interference. 285 Some familiarity with the DNS protocol is assumed. 287 3.1. System Elements 289 The particular system elements used will differ, based on the mode of 290 operation of the Client. Clients may request the use of particular 291 resolvers via additional intra-element signalling. 293 3.1.1. Node Types 295 Base node types are the following: 297 o Standalone SPARTACUS Client forwarder 299 o Transparent SPARTACUS proxy Client 301 o Standalone SPARTACUS Server 303 o Apache module-based SPARTACUS Server 305 o Stub resolver 307 o External recursive resolver 309 o Client-side recursive resolver 311 o External authority server 313 Future node types are expected to include: 315 o Browser-integrated SPARTACUS client and stub resolver 317 o Mobile-device SPARTACUS client and stub resolver (with exposed 318 getdns API) 320 o SMTP-integrated SPARTACUS client and stub resolver 322 3.2. System Modes 324 The system has two modes of operation: 326 o DNS Forwarder - an opaque mode of operation, the Client/Server 327 pair act collectively as a single DNS forwarder. 329 o Transparent Proxy - In this mode, regular DNS traffic is diverted 330 by unspecified means to the SPARTACUS Client. 332 Additional intra-element signalling facilitates Clients requesting 333 particular resolvers' (recursive or authoritative) use. 335 3.2.1. Details on DNS Forwarder mode 337 The Server is configured to use a particular DNS recursive resolver, 338 with the optional ability to support Client-requested resolver(s) via 339 in-band signaling. If present, the Client-requested resolver IP 340 address is passed as an EDNS OPT value. The Server, if it is 341 configured to honor requested resolvers, uses this IP address instead 342 of the default. 344 Example: Problem caused by firewalls that do not support DNSSEC: 346 +------+ +--------------+ +----------+ 347 | | | | Blocked | | 348 | Stub +--> | Old Firewall +----+X+---> | Resolver | 349 | | | (no DNSSEC) | Packets | | 350 +------+ +--------------+ +----------+ 352 Figure 1 354 Example: How the stub client sees the SPARTACUS Client/Server pair, 355 in the opaque forwarder configuration: 357 +------+ +----------------------------------+ +----------+ 358 | | | | | | 359 | Stub +--> | Forwarder +----> | Resolver | 360 | | | with DNSSEC | | | 361 | | <--+ | <----+ | 362 +------+ +----------------------------------+ +----------+ 364 Figure 2 366 Example: How the Client/Server pair actually operates: 368 +------+ +--------+ +--------+ +----------+ 369 | | | | | | | | 370 | Stub +---> | Client +-------------> | Server +----> | Resolver | 371 | | DNS | | JSON/HTTP(S) | | DNS | | 372 | | <---+ | <-------------+ | <----+ | 373 +------+ +--------+ +--------+ +----------+ 375 Figure 3 377 Example: How the Client/Server bypass the old firewall: 379 +------+ +--------+ +--------------+ +--------+ +----------+ 380 | | | | | Old Firewall | | | | | 381 | Stub +-> | Client +------------------> | Server +-> | Resolver | 382 | | | | | (bypassed) | | | | | 383 | | <-+ | <------------------+ | <-+ | 384 +------+ +--------+ +--------------+ +--------+ +----------+ 386 Figure 4 388 3.2.2. Details on Transparent Proxy mode 390 Transparent Proxy mode supports transport of stub to recursive 391 traffic (all with the same destination IP address). 393 Transparent Proxy mode also supports use by a recursive resolver, to 394 handle recursive-to-authoritative traffic (with different destination 395 IP addresses per query). 397 From the perspective of the DNS client (stub or recursive), it 398 appears that the DNS query packet went to some IP address, and the 399 reply came back directly. 401 +----------+ +--------------+ 402 | +------------------------------------> | | 403 | Stub | | Recursive | 404 | src=SR | DNS UDP/53 SR<->RR | dst=RR | 405 | | | | 406 | | <------------------------------------+ | 407 +----------+ +--------------+ 409 Figure 5 411 +-----------+ 412 | +-----------------------------------> +--------------+ 413 | | | Authority #1 | 414 | | <-----------------------------------+ dst=AR_1 | 415 | | +--------------+ 416 | +-----------------------------------> +--------------+ 417 | Recursive | | Authority #2 | 418 | src=RR | <-----------------------------------+ dst=AR_2 | 419 | | +--------------+ 420 | | ... 421 | +-----------------------------------> +--------------+ 422 | | | Authority #N | 423 | | <-----------------------------------+ dst=AR_N | 424 +-----------+ +--------------+ 425 DNS UDP/53 RR<->AR_N (N=1,2,...) 427 Figure 6 429 In both use cases, the original IP destination is encoded as an EDNS 430 OPT value, and the DNS message (encoded as JSON) is sent to the 431 SPARTACUS Server. The Server sends the DNS message to the original 432 IP destination, with the SPARTACUS Server's IP address as the source. 433 The resulting answer DNS message is sent to the Client, which changes 434 the reply source IP address to the original destination IP address. 436 +-----------+ +-------+ +---------+ +---------------+ 437 | | | | | | | | 438 | +----------> | Trans.| | Server +-> | Authoritative | 439 | | | Proxy | | Gateway | | Resolver #1 | 440 | | <----------+ TP | | SG | <-+ AR_1 | 441 | | +-----+-+ +------+--+ +---------------+ 442 | | DNS UDP/53 | | DNS UDP/53 443 | Recursive | RR <-> AR_1 ^ v ^ | SG <-> AR_1 444 | Resolver | | | | 445 | RR | +---+-----+ | | 446 | | | Client +----+ | TCP/80 (or /443) 447 | | | Gateway | | JSON (EDNS: dst=AR_1) 448 | | | CG | <-----+ CG <-> SG 449 +-----------+ +---------+ 451 Figure 7 453 The only practical difference is that some intermediate devices see 454 JSON/HTTP(S) instead of DNS/UDP traffic. For some of those devices, 455 this is in fact the purpose of SPARTACUS - preventing those devices 456 from inspecting the DNS traffic in a problematic manner. 458 3.3. Interoperability 460 The purpose of this document is to ensure that independent 461 implementations of Client(s) and Server(s) can interoperate, so long 462 as each is permitted to interoprate with the other. 464 It is not required that Servers be operated in a completely "open" 465 manner. However, the more open Servers there are, the greater the 466 benefit. Like any web-based service, care should be given towards 467 managing available resources on a Server. In all likelihood, this 468 resource management may be most effectively handled via the web 469 server's own service management system. 471 3.3.1. In-scope and out-of-scope 473 The following items are out-of-scope, from an interoperability 474 standpoint. 476 This means that individual implementations may make independent 477 design decisions, without impacting interoperability. 479 o Choice(s) of default resolver (on Server) 481 o Server-side DNS retry and time-out values 483 o How Client(s) select Servers 485 The following items are in-scope, from an interoperability 486 standpoint. 488 o JSON encoding 490 o How to signal non-support of requested resolver(s) 492 o How to signal "no response" (timeout) on Server-resolver traffic 494 o Signalling/encoding of default,requested, and actually-used 495 resolvers 497 o Stripping of EDNS OPT private values 499 o Stripping of synthesized EDNS OPT record 501 The following items are optional, from an interoperability 502 standpoint. 504 o Whether and how to do edns-client-subnet (on Client) 505 o Whether to use TLS (HTTPS) on Client-Server traffic 507 o Whether to honor requested resolvers (on Server) 509 o Whether to support Transparent Proxy mode (on the Client) 511 o Whether to do DNSSEC validation 513 o Whether to do PKI validation of SSL certificates (if HTTPS is used 514 and CA-issued certs used) 516 o Whether to do DANE validation of SSL certificates (if HTTPS is 517 used and TLSA records exist) 519 o Whether IPv4 or IPv6 is supported 521 4. Interactions and Behavior 523 The Client Gateway needs to make informed decisions about Server 524 Gateways to use. Client Gateways may use pre-configured (static) 525 gateways, or may employ any number of strategies for selection of 526 Server Gateways. 528 In order to enble Client-controlled Server Selection, each Server 529 Gateway needs to advise the Client about default and actual DNS 530 Servers used. The Client optionally requests DNS Server(s) that the 531 Server should use. If present, the Server includes that in the 532 response. 534 The SPARTACUS client/server interaction occurs over TCP rather than 535 UDP. As such, other than TCP-based failures (RST aka "reset" for 536 example), every query MUST get a response (owing to the HTTP POST 537 standards). 539 Since the Server Gateway is performing DNS resolution using UDP 540 transport, it is possible that network packet loss may occur, 541 resulting in unanswered queries. 543 Also, there are reasons other than network-based packet loss that can 544 result in unanswered queries. DNS resolvers must attempt to infer 545 what causes queries to not be answered. 547 It is also possible that various other failure modes could occur, 548 which need to be handled on the basis of the nature of the failure. 550 Each of these is addressed in separate sections below. 552 4.1. DNS Gateway Encodings 554 The three DNS Server values (default, requested, actual) are 555 communicated via EDNS OPT type-length-value (TLV) tuples, using three 556 distinct types. Pre-standard experimental values are presently being 557 used. IANA will need to assign permanent OPT Type values for these 558 three type codes. 560 In order to ensure that the EDNS OPT record is only returned to the 561 original DNS client if it existing in the query, it is necessary to 562 identify cases where the DNS Server value encoding resulted in a 563 "new" OPT record, rather than being added to an existing record. In 564 such cases, an additional OPT TLV type is required, and is added to 565 the OPT record. A fourth OPT Type value needs to be assigned by IANA 566 for this purpose. 568 The new OPT codes are used to enable the Client and Server to 569 maintain all communication details inside the DNS message itself. 570 This simplifies the design, implementation, and operation of Clients 571 and Servers, and ensures forward/backward compatibility. OPT codes 572 specific to the Client-Server communication MUST be removed prior to 573 forwarding of DNS messages to DNS Clients and Servers. If the EDNS 574 OPT RR is synthesized (added to the DNS message), it MUST be removed. 576 4.2. UDP Packet Loss 578 In cases where the Server Gateway did not get a response from the DNS 579 Server, it needs to signal this back to the client. It needs to do 580 this so that the proper Client state is established. This prevents 581 time-out based (undefined) behavior on the Client from being 582 triggered. The Server needs to "pass along" packet loss status to 583 the Client to trigger well-defined Client behavior. 585 The mechanism is to use a Private EDNS OPT type/length/value (TLV), 586 with the original Question echoed back (to associate with the Query). 587 When receiving this TLV, the Client will treat this as a lost UDP 588 packet, and MUST NOT send back any UDP packet. The UDP client is 589 responsible for handling this lost UDP packet, per the DNS protocol. 591 4.3. Malformed UDP response 593 The malformed UDP packet may not be legitimate. To be conservative, 594 this condition is signaled back to the client, and the (actual) 595 received UDP packet is rejected/dropped. This is treated by the DNS 596 client as a lost UDP packet. 598 4.4. DNSSEC Validation Failure 600 If DNSSEC validation fails, the presumption needs to be made that the 601 failure is deliberate. The DNSSEC standards call for "SRVFAIL" 602 responses, so that is what a compliant implementation MUST return to 603 the UDP client. 605 If the Client and/or Server does DNSSEC Validation, it MUST correctly 606 implement Validation signalling via the AD and CD bits. 608 In other words, it MUST return the answer regardless of Validation if 609 the CD bit is set, and it MUST set the AD bit if Validation succeeds, 610 regardless of the presence and/or state of EDNS bit DO. 612 5. Client-Server Selection and Topology Examples 614 +-----------+ 615 | | 616 +--> | Server +--+ 617 +-----------+ | | Gateway 1 | | 618 | Client | | +-----------+ | +-----------+ 619 | Gateway +--+ +-----------+ +--> | | 620 | | | | | Recursive | 621 | Selects +-----> | Server +-----> | DNS | 622 | Random | | Gateway 2 | | Server | 623 | Server +--+ +-----------+ +--> | | 624 | Gateway | | +-----------+ | +-----------+ 625 +-----------+ | | | | 626 +--> | Server +--+ 627 | Gateway 3 | 628 +-----------+ 630 Figure 8 632 Figure 8 shows the same Recursive DNS Server being used, via multiple 633 Server Gateways. There are several benefits to doing this; they 634 include distributing load among multiple Server Gateways, and 635 reducing the amount of DNS traffic going via any single Server 636 Gateway. This limits the impact of the compromise of any single 637 Server Gateway, or of any single Server Certificate compromise. 639 +--------+ 640 | | 641 +-----> | Server | 642 +-----------+ | | GW 1 | +-----------+ 643 | Client | +---+----+ +------+-+ +--------+ | | 644 | Gateway | | | | | | | | 645 | | | Server | <--+ +---> | Server +--> | | 646 | Selects | | GW 2 | | | GW 4 | | DNS | 647 | Random | +--------+ +-+------+ +--------+ | Server | 648 | Server | | | | | 649 | Gateway | | Server | | | 650 | +------------> | GW 3 | | | 651 +-----------+ +--------+ +-----------+ 653 Figure 9 655 Figure 9 illustrates a path where more than one Server Gateway is 656 traversed during resolution. The objective here is to disassociate 657 the IDENTITY of the client from the CONTENT of the query/answer. The 658 association is only made directly on the first Server Gateway (and 659 only with respect to the Client Gateway). The actual association of 660 the source UDP client is only done on the Client Gateway itself, 661 which may or may not provide further privacy. Since there is more 662 than one Server-Server hop, this significantly reduces the ability to 663 infer associations between Query/Response and Client Gateways. 665 It should be noted that this looks very much like TOR (The Onion 666 Router), applied to JSON-encoded UDP DNS traffic. There is a 667 proposal for DNS privacy enhancements that applies a similar 668 techique, directly on UDP-based DNS queries/answers. FIXME add xref 669 here to reference to the appropriate Internet Draft. END FIXME 671 +---------------+ +--------+ +--------+ +------------+ +----------+ 672 | Client | | WWW/GW | | WWW/GW | | | | | 673 | Gateway | | Server | | Server | | Web Server | | | 674 | | | GW 3 | | GW 4 | | | | | 675 | Selects | +--------+ +--------+ +----------+ | | DNS | 676 | Among | | Gateway | | | Server | 677 | Most Recent | DNS traffic mingled | Server | | | | 678 | Web Server | with web traffic | Module +---> | | 679 | Gateways +---------------------> | GW 2 | | | | 680 +---------------+ (or encrypted) +----------+-+ +----------+ 682 Figure 10 684 Figure 10 illustrates one query/response when the client is 685 attempting to use something similar to steganography to preserve 686 privacy. In this context, the privacy against passive monitoring is 687 achieved by using un-blocked web servers which are also Server 688 Gateways. A MitM adversary cannot easily block this traffic without 689 blocking the entire site, or by inspecting every flow to/from the 690 site. A passive observer would similarly need to inspect all flows 691 to find the embedded, encoded DNS traffic. The DNS traffic would be 692 nearly indistinguishable from regular HTTP traffic. 694 Note that the use of TLS to protect the Client-Server traffic would 695 make it impossible to distinguish the DNS traffic from the other web 696 trafficin this situation. Combining this "tag-along" with TLS 697 provides both strong privacy and strong security. 699 5.1. Mixed Traffic Walk-Through 701 Suppose a client were to visit web sites "a" through "j" 702 sequentially, i.e. a,b,c,d,e,f,g,h,i,j. Suppose some of those were 703 also Server Gateways, represented by upper case (vs lower case for 704 web sites without Server Gateway capabilities). Thus the sequence 705 would be A,b,C,D,e,f,g,H,I,j. If the Client Gateway chose a Server 706 Gateway randomly from among the last four web sites visited, the 707 sequence of events after visiting A through D, would look like: 709 o Select Server from set {A,C,D}, look up "e". Visit "e". 711 o Select Server from set {C,D}, look up "f". Visit "f". 713 o Select Server from set {C,D}, look up "g". Visit "g". 715 o Select Server from set {D}, look up "h". Visit "h". 717 o Select Server from set {D,H}, look up "i". Visit "i". 719 o Select Server from set {H,I}, look up "j". Visit "j". 721 An observer close to the Client would see traffic within a given time 722 window, only to the same set of Web servers. An observer close to 723 any of the Web servers would only see traffic from a given client, 724 for a small interval of time after the first visit. 726 6. Security Considerations 728 (None per se.) Need to list considerations etc. 730 7. IANA Considerations 732 This document will eventually contain IANA-specific material. 734 8. Acknowledgements 736 To be added later. 738 9. References 740 9.1. Normative References 742 [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 743 1033, November 1987. 745 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 746 STD 13, RFC 1034, November 1987. 748 [RFC1035] Mockapetris, P., "Domain names - implementation and 749 specification", STD 13, RFC 1035, November 1987. 751 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 752 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 753 RFC 2136, April 1997. 755 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 756 Specification", RFC 2181, July 1997. 758 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 759 NCACHE)", RFC 2308, March 1998. 761 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 762 Wellington, "Secret Key Transaction Authentication for DNS 763 (TSIG)", RFC 2845, May 2000. 765 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 766 RR)", RFC 2930, September 2000. 768 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 769 2002. 771 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 772 Rose, "DNS Security Introduction and Requirements", RFC 773 4033, March 2005. 775 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 776 Rose, "Resource Records for the DNS Security Extensions", 777 RFC 4034, March 2005. 779 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 780 Rose, "Protocol Modifications for the DNS Security 781 Extensions", RFC 4035, March 2005. 783 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 784 Security (DNSSEC) Hashed Authenticated Denial of 785 Existence", RFC 5155, March 2008. 787 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 788 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 790 9.2. Informative References 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 [JPF_jsondns] 796 "DNS over HTTP", . 798 [jsondns.org] 799 Franusic, J., "Query DNS via REST", . 801 [fileformat.info] 802 Marcuse, A., "DNS in client-side JavaScript", 803 . 805 [restdns.net] 806 "REST-DNS", . 808 [bortzmeyer.org] 809 Bortzmeyer, S., "DNS Looking Glass", 810 . 812 [draft-bortzmeyer-dns-json] 813 Bortzmeyer, S., "DNS in JSON", 814 . 816 [dns-lg.com] 817 Cambus, F., "Multilocation DNS Looking Glass", 818 . 820 [trigger] NLnet Labs, "Dnssec-Trigger", 821 . 823 Appendix A. DNS Message Encoding Examples 825 The entire encoding of pairs of DNS messages follows. For each 826 pair,the first is the query, and the second is the response. 828 A.1. Simple Query/Answer, No EDNS or DNS Server 830 Query encoded in JSON: 832 "PACKET (RFC 1035)" : [ 833 "ROLE" : "client", 834 "DSIZE" : 26, 835 "DICTIONARY" : [ 836 "example", 837 "com", 838 "" 839 ], 840 "DSIZE2" : 26, 841 "Header" : [ 842 "ID" : 42, 843 "HFlags" : [ 844 "QR" : false, 845 "Opcode" : [ "Query" : 0 ], 846 "AA" : false, 847 "TC" : false, 848 "RD" : true, 849 "RA" : false, 850 "Z" : false, 851 "AD" : false, 852 "CD" : false, 853 "RCODE" : [ "NoError (RFC 1035)" : 0 ] 855 ], 856 "QDCOUNT" : 1, 857 "ANCOUNT" : 0, 858 "NSCOUNT" : 0, 859 "ARCOUNT" : 0 860 ], 861 "Question" : [ 862 "QUESTION (RFC 1035)" : [ 863 "QNAME" : [ "example.com." : 0 ], 864 "QTYPE" : [ "A" : 1 ], 865 "QCLASS" : [ "IN" : 1 ] 866 ] 867 ] 868 ] 870 Response encoded in JSON: 872 "PACKET (RFC 1035)" : [ 873 "ROLE" : "client", 874 "DSIZE" : 33, 875 "DICTIONARY" : [ 876 "example", 877 "com", 878 "", 879 "@0" 880 ], 881 "DSIZE2" : 33, 882 "Header" : [ 883 "ID" : 42, 884 "HFlags" : [ 885 "QR" : true, 886 "Opcode" : [ "Query" : 0 ], 887 "AA" : false, 888 "TC" : false, 889 "RD" : true, 890 "RA" : true, 891 "Z" : false, 892 "AD" : false, 893 "CD" : false, 894 "RCODE" : [ "NoError (RFC 1035)" : 0 ] 896 ], 897 "QDCOUNT" : 1, 898 "ANCOUNT" : 1, 899 "NSCOUNT" : 0, 900 "ARCOUNT" : 0 901 ], 902 "Question" : [ 903 "QUESTION (RFC 1035)" : [ 904 "QNAME" : [ "example.com." : 0 ], 905 "QTYPE" : [ "A" : 1 ], 906 "QCLASS" : [ "IN" : 1 ] 907 ] 908 ], 909 "Answer" : [ 910 "RR" : [ 911 "NAME" : [ "example.com." : 0 ], 912 "TYPE" : [ "A" : 1 ], 913 "CLASS" : [ "IN" : 1 ], 914 "TTL" : 5218, 915 "RDLENGTH" : 4, 916 "RDATA" : [ 917 "A" : [ 918 "Address" : "93.184.216.119" 919 ] 920 ] 921 ] 922 ] 923 ] 925 A.2. Simple Query/Answer, EDNS, no DNS Server 927 Query encoded in JSON: 929 "PACKET (RFC 1035)" : [ 930 "ROLE" : "client", 931 "DSIZE" : 31, 932 "DICTIONARY" : [ 933 "example", 934 "com", 935 "", 936 "" 937 ], 938 "DSIZE2" : 31, 939 "Header" : [ 940 "ID" : 42, 941 "HFlags" : [ 942 "QR" : false, 943 "Opcode" : [ "Query" : 0 ], 944 "AA" : false, 945 "TC" : false, 946 "RD" : true, 947 "RA" : false, 948 "Z" : false, 949 "AD" : false, 950 "CD" : false, 951 "RCODE" : [ "NoError (RFC 1035)" : 0 ] 953 ], 954 "QDCOUNT" : 1, 955 "ANCOUNT" : 0, 956 "NSCOUNT" : 0, 957 "ARCOUNT" : 1 958 ], 959 "Question" : [ 960 "QUESTION (RFC 1035)" : [ 961 "QNAME" : [ "example.com." : 0 ], 962 "QTYPE" : [ "A" : 1 ], 963 "QCLASS" : [ "IN" : 1 ] 964 ] 965 ], 966 "Additional" : [ 967 "RR" : [ 968 "NAME" : [ "." : 3 ], 969 "TYPE" : [ "OPT" : 41 ], 970 "Field3" : [ 971 "UDPSIZEFIELD" : [ 972 "UDPSIZE" : 1500 973 ] 974 ], 975 "Field4" : [ 976 "Extended_RCode_Flags" : [ 977 "ERCFlagbits" : [ 978 "RCode" : 0, 979 "Version" : 0, 980 "DO" : false, 981 "Resv" : 0 983 ] 984 ] 985 ], 986 "RDLENGTH" : 0, 987 "RDATA" : [ 988 "OPT (RFC 6891)" : [ 989 "TLV_LIST" : [ 991 ] 992 ] 993 ] 994 ] 995 ] 996 ] 998 Response encoded in JSON: 1000 "PACKET (RFC 1035)" : [ 1001 "ROLE" : "client", 1002 "DSIZE" : 38, 1003 "DICTIONARY" : [ 1004 "example", 1005 "com", 1006 "", 1007 "@0", 1008 "" 1009 ], 1010 "DSIZE2" : 38, 1011 "Header" : [ 1012 "ID" : 42, 1013 "HFlags" : [ 1014 "QR" : true, 1015 "Opcode" : [ "Query" : 0 ], 1016 "AA" : false, 1017 "TC" : false, 1018 "RD" : true, 1019 "RA" : true, 1020 "Z" : false, 1021 "AD" : false, 1022 "CD" : false, 1023 "RCODE" : [ "NoError (RFC 1035)" : 0 ] 1025 ], 1026 "QDCOUNT" : 1, 1027 "ANCOUNT" : 1, 1028 "NSCOUNT" : 0, 1029 "ARCOUNT" : 1 1030 ], 1031 "Question" : [ 1032 "QUESTION (RFC 1035)" : [ 1033 "QNAME" : [ "example.com." : 0 ], 1034 "QTYPE" : [ "A" : 1 ], 1035 "QCLASS" : [ "IN" : 1 ] 1036 ] 1037 ], 1038 "Answer" : [ 1039 "RR" : [ 1040 "NAME" : [ "example.com." : 0 ], 1041 "TYPE" : [ "A" : 1 ], 1042 "CLASS" : [ "IN" : 1 ], 1043 "TTL" : 4865, 1044 "RDLENGTH" : 4, 1045 "RDATA" : [ 1046 "A" : [ 1047 "Address" : "93.184.216.119" 1048 ] 1049 ] 1050 ] 1051 ], 1052 "Additional" : [ 1053 "RR" : [ 1054 "NAME" : [ "." : 4 ], 1055 "TYPE" : [ "OPT" : 41 ], 1056 "Field3" : [ 1057 "UDPSIZEFIELD" : [ 1058 "UDPSIZE" : 4000 1059 ] 1060 ], 1061 "Field4" : [ 1062 "Extended_RCode_Flags" : [ 1063 "ERCFlagbits" : [ 1064 "RCode" : 0, 1065 "Version" : 0, 1066 "DO" : false, 1067 "Resv" : 0 1068 ] 1069 ] 1070 ], 1071 "RDLENGTH" : 0, 1072 "RDATA" : [ 1073 "OPT (RFC 6891)" : [ 1074 "TLV_LIST" : [ 1076 ] 1077 ] 1078 ] 1079 ] 1080 ] 1081 ] 1083 A.3. Simple Query/Answer, no EDNS, with DNS Server 1085 Query encoded in JSON: 1087 "PACKET (RFC 1035)" : [ 1088 "ROLE" : "client", 1089 "DSIZE" : 31, 1090 "DICTIONARY" : [ 1091 "example", 1092 "com", 1093 "", 1094 "" 1095 ], 1096 "DSIZE2" : 31, 1097 "Header" : [ 1098 "ID" : 42, 1099 "HFlags" : [ 1100 "QR" : false, 1101 "Opcode" : [ "Query" : 0 ], 1102 "AA" : false, 1103 "TC" : false, 1104 "RD" : true, 1105 "RA" : false, 1106 "Z" : false, 1107 "AD" : false, 1108 "CD" : false, 1109 "RCODE" : [ "NoError (RFC 1035)" : 0 ] 1111 ], 1112 "QDCOUNT" : 1, 1113 "ANCOUNT" : 0, 1114 "NSCOUNT" : 0, 1115 "ARCOUNT" : 1 1116 ], 1117 "Question" : [ 1118 "QUESTION (RFC 1035)" : [ 1119 "QNAME" : [ "example.com." : 0 ], 1120 "QTYPE" : [ "A" : 1 ], 1121 "QCLASS" : [ "IN" : 1 ] 1122 ] 1123 ], 1124 "Additional" : [ 1125 "RR" : [ 1126 "NAME" : [ "." : 3 ], 1127 "TYPE" : [ "OPT" : 41 ], 1128 "Field3" : [ 1129 "UDPSIZEFIELD" : [ 1130 "UDPSIZE" : 1500 1131 ] 1132 ], 1133 "Field4" : [ 1134 "Extended_RCode_Flags" : [ 1135 "ERCFlagbits" : [ 1136 "RCode" : 0, 1137 "Version" : 0, 1138 "DO" : false, 1139 "Resv" : 0 1141 ] 1142 ] 1143 ], 1144 "RDLENGTH" : 19, 1145 "RDATA" : [ 1146 "OPT (RFC 6891)" : [ 1147 "TLV_LIST" : [ 1148 "TLV" : [ 1149 "TYPE" : [ "PrivateType65500" : 65500 ], 1150 "Len" : 13, 1151 "Data" : [ 1152 "PrivateType65500" : [ 1153 "GW_NAME" : [ "10:10" , "198.41.1.1" ] 1155 ] 1156 ] 1157 ], 1158 "TLV" : [ 1159 "TYPE" : [ "PrivateType65510" : 65510 ], 1160 "Len" : 0, 1161 "Data" : [ 1162 ] 1163 ], 1164 ] 1165 ] 1166 ] 1167 ] 1168 ] 1169 ] 1171 Response encoded in JSON: 1173 "PACKET (RFC 1035)" : [ 1174 "ROLE" : "client", 1175 "DSIZE" : 38, 1176 "DICTIONARY" : [ 1177 "example", 1178 "com", 1179 "", 1180 "@0", 1181 "" 1182 ], 1183 "DSIZE2" : 38, 1184 "Header" : [ 1185 "ID" : 42, 1186 "HFlags" : [ 1187 "QR" : true, 1188 "Opcode" : [ "Query" : 0 ], 1189 "AA" : false, 1190 "TC" : false, 1191 "RD" : true, 1192 "RA" : true, 1193 "Z" : false, 1194 "AD" : true, 1195 "CD" : false, 1196 "RCODE" : [ "NoError (RFC 1035)" : 0 ] 1198 ], 1199 "QDCOUNT" : 1, 1200 "ANCOUNT" : 1, 1201 "NSCOUNT" : 0, 1202 "ARCOUNT" : 1 1203 ], 1204 "Question" : [ 1205 "QUESTION (RFC 1035)" : [ 1206 "QNAME" : [ "example.com." : 0 ], 1207 "QTYPE" : [ "A" : 1 ], 1208 "QCLASS" : [ "IN" : 1 ] 1209 ] 1210 ], 1211 "Answer" : [ 1212 "RR" : [ 1213 "NAME" : [ "example.com." : 0 ], 1214 "TYPE" : [ "A" : 1 ], 1215 "CLASS" : [ "IN" : 1 ], 1216 "TTL" : 4084, 1217 "RDLENGTH" : 4, 1218 "RDATA" : [ 1219 "A" : [ 1220 "Address" : "93.184.216.119" 1221 ] 1222 ] 1223 ] 1224 ], 1225 "Additional" : [ 1226 "RR" : [ 1227 "NAME" : [ "." : 4 ], 1228 "TYPE" : [ "OPT" : 41 ], 1229 "Field3" : [ 1230 "UDPSIZEFIELD" : [ 1231 "UDPSIZE" : 512 1232 ] 1233 ], 1234 "Field4" : [ 1235 "Extended_RCode_Flags" : [ 1236 "ERCFlagbits" : [ 1237 "RCode" : 0, 1238 "Version" : 0, 1239 "DO" : false, 1240 "Resv" : 0 1242 ] 1243 ] 1244 ], 1245 "RDLENGTH" : 19, 1246 "RDATA" : [ 1247 "OPT (RFC 6891)" : [ 1248 "TLV_LIST" : [ 1249 "TLV" : [ 1250 "TYPE" : [ "PrivateType65500" : 65500 ], 1251 "Len" : 13, 1252 "Data" : [ 1253 "PrivateType65500" : [ 1254 "GW_NAME" : [ "10:10" , "198.41.1.1" ] 1256 ] 1257 ] 1258 ], 1259 "TLV" : [ 1260 "TYPE" : [ "PrivateType65510" : 65510 ], 1261 "Len" : 0, 1262 "Data" : [ 1263 ] 1264 ], 1266 ] 1267 ] 1268 ] 1269 ] 1270 ] 1271 ] 1273 A.4. Simple Query/Answer, with EDNS and DNS Server 1275 Query encoded in JSON: 1277 "PACKET (RFC 1035)" : [ 1278 "ROLE" : "client", 1279 "DSIZE" : 31, 1280 "DICTIONARY" : [ 1281 "example", 1282 "com", 1283 "", 1284 "" 1285 ], 1286 "DSIZE2" : 31, 1287 "Header" : [ 1288 "ID" : 42, 1289 "HFlags" : [ 1290 "QR" : false, 1291 "Opcode" : [ "Query" : 0 ], 1292 "AA" : false, 1293 "TC" : false, 1294 "RD" : true, 1295 "RA" : false, 1296 "Z" : false, 1297 "AD" : false, 1298 "CD" : false, 1299 "RCODE" : [ "NoError (RFC 1035)" : 0 ] 1301 ], 1302 "QDCOUNT" : 1, 1303 "ANCOUNT" : 0, 1304 "NSCOUNT" : 0, 1305 "ARCOUNT" : 1 1306 ], 1307 "Question" : [ 1308 "QUESTION (RFC 1035)" : [ 1309 "QNAME" : [ "example.com." : 0 ], 1310 "QTYPE" : [ "A" : 1 ], 1311 "QCLASS" : [ "IN" : 1 ] 1312 ] 1313 ], 1314 "Additional" : [ 1315 "RR" : [ 1316 "NAME" : [ "." : 3 ], 1317 "TYPE" : [ "OPT" : 41 ], 1318 "Field3" : [ 1319 "UDPSIZEFIELD" : [ 1320 "UDPSIZE" : 1500 1321 ] 1322 ], 1323 "Field4" : [ 1324 "Extended_RCode_Flags" : [ 1325 "ERCFlagbits" : [ 1326 "RCode" : 0, 1327 "Version" : 0, 1328 "DO" : false, 1329 "Resv" : 0 1331 ] 1332 ] 1333 ], 1334 "RDLENGTH" : 15, 1335 "RDATA" : [ 1336 "OPT (RFC 6891)" : [ 1337 "TLV_LIST" : [ 1338 "TLV" : [ 1339 "TYPE" : [ "PrivateType65500" : 65500 ], 1340 "Len" : 13, 1341 "Data" : [ 1342 "PrivateType65500" : [ 1343 "GW_NAME" : [ "10:10" , "198.41.1.1" ] 1345 ] 1346 ] 1347 ], 1349 ] 1350 ] 1351 ] 1352 ] 1353 ] 1354 ] 1355 Response encoded in JSON: 1357 "PACKET (RFC 1035)" : [ 1358 "ROLE" : "client", 1359 "DSIZE" : 38, 1360 "DICTIONARY" : [ 1361 "example", 1362 "com", 1363 "", 1364 "@0", 1365 "" 1366 ], 1367 "DSIZE2" : 38, 1368 "Header" : [ 1369 "ID" : 42, 1370 "HFlags" : [ 1371 "QR" : true, 1372 "Opcode" : [ "Query" : 0 ], 1373 "AA" : false, 1374 "TC" : false, 1375 "RD" : true, 1376 "RA" : true, 1377 "Z" : false, 1378 "AD" : true, 1379 "CD" : false, 1380 "RCODE" : [ "NoError (RFC 1035)" : 0 ] 1382 ], 1383 "QDCOUNT" : 1, 1384 "ANCOUNT" : 1, 1385 "NSCOUNT" : 0, 1386 "ARCOUNT" : 1 1387 ], 1388 "Question" : [ 1389 "QUESTION (RFC 1035)" : [ 1390 "QNAME" : [ "example.com." : 0 ], 1391 "QTYPE" : [ "A" : 1 ], 1392 "QCLASS" : [ "IN" : 1 ] 1393 ] 1394 ], 1395 "Answer" : [ 1396 "RR" : [ 1397 "NAME" : [ "example.com." : 0 ], 1398 "TYPE" : [ "A" : 1 ], 1399 "CLASS" : [ "IN" : 1 ], 1400 "TTL" : 4084, 1401 "RDLENGTH" : 4, 1402 "RDATA" : [ 1403 "A" : [ 1404 "Address" : "93.184.216.119" 1405 ] 1406 ] 1407 ] 1408 ], 1409 "Additional" : [ 1410 "RR" : [ 1411 "NAME" : [ "." : 4 ], 1412 "TYPE" : [ "OPT" : 41 ], 1413 "Field3" : [ 1414 "UDPSIZEFIELD" : [ 1415 "UDPSIZE" : 512 1416 ] 1417 ], 1418 "Field4" : [ 1419 "Extended_RCode_Flags" : [ 1420 "ERCFlagbits" : [ 1421 "RCode" : 0, 1422 "Version" : 0, 1423 "DO" : false, 1424 "Resv" : 0 1426 ] 1427 ] 1428 ], 1429 "RDLENGTH" : 15, 1430 "RDATA" : [ 1431 "OPT (RFC 6891)" : [ 1432 "TLV_LIST" : [ 1433 "TLV" : [ 1434 "TYPE" : [ "PrivateType65500" : 65500 ], 1435 "Len" : 13, 1436 "Data" : [ 1437 "PrivateType65500" : [ 1438 "GW_NAME" : [ "10:10" , "198.41.1.1" ] 1440 ] 1441 ] 1442 ], 1444 ] 1445 ] 1446 ] 1447 ] 1448 ] 1449 ] 1451 Appendix B. Server Gateway HTML code 1453 The entire HTML document needed on the Server for the Client to send/ 1454 receive JSON-encoded DNS messages follows: 1456 1457 1458
1459

1460 1462 1463

1464
1465 1466 1468 The "action" target needs to exist and be executable, and ideally be 1469 performance-optimized (e.g. via use of mod_perl). 1471 Appendix C. Server Gateway HTTP POST Handler Pseudo-code 1473 The following pseudo-code illustrates the high-level behavior of the 1474 HTML handler for the Server. 1476 The handler is passed the contents of the TEXTAREA, which will be the 1477 JSON-encoded DNS message. 1479 // initialize parser etc. 1480 // set up socket for UDP query/response to default Resolver 1481 // set up socket for UDP query/response to client-supplied Resolver 1482 // extract JSON-encoded DNS message from HTTP POST variable 'query' 1483 // save original Query-ID, assign new Query-ID (to avoid collisions) 1484 // decode DNS message (into DNS wire format) 1485 // if DNS message has OPT Resource Record 1486 // if OPT has Client-supplied Resolver option 1487 // extract Resolver value 1488 // delete Resolver option from OPT 1489 // endif 1490 // if OPT was synthesized by Client 1491 // delete OPT Resource Record 1492 // endif 1493 // send DNS message to Client-specified Resolver 1494 // else 1495 // send DNS message to default Resolver 1496 // endif 1497 // wait for response or timeout 1498 // if timeout && retry-count < max-retry-count 1499 // resend DNS message 1500 // elsif timeout && retry-count >= max-retry-count 1501 // send "retry-count-exceeded" via OPT (synthesized if necessary) 1502 // else 1503 // set DNS answer's Query-ID value to original Query-ID 1504 // encode DNS answer 1505 // send JSON-encoded answer to Client 1506 // endif 1508 Appendix D. Client Gateway Pseudo-code 1510 The following pseudo-code illustrates the high-level behavior of the 1511 Client. 1513 The Client in this example is pre-configured with a single Server 1514 Gateway's address. 1516 // initialize parser etc. 1517 // set up socket for UDP query/response (Listener) 1518 // set up HTTP connection to Server Gateway 1519 // do an HTTP "GET" to the predefined URL of the Server HTML code 1520 // extract HTML elements needed: handler, variable name 1521 // loop forever: 1522 // listen for DNS query packet 1523 // fork (to handle this packet) 1524 // if child 1525 // save old DNS Query-ID, set new Query-ID 1526 // if Use-Supplied-Resolver 1527 // if exits OPT 1528 // add client-supplied-resolver to OPT 1529 // else 1530 // synthesize OPT and add client-supplied-resolver 1531 // endif 1532 // endif 1533 // encode DNS message (into JSON) 1534 // write HTTP POST onto socket 1535 // wait for HTTP response 1536 // extract JSON-encoded answer from HTTP 1537 // decode DNS answer (from JSON) 1538 // if OPT 1539 // if OPT.option is error condition 1540 // drop answer and continue loop forever: 1541 // elsif OPT synthesized 1542 // delete OPT 1543 // elsif OPT.option SPARTACUS-specific value 1544 // delete option 1545 // endif 1546 // endif 1547 // set answer.Query-ID to saved value 1548 // send answer to sender 1549 // end-of-loop 1551 Author's Address 1553 Brian Dickson 1554 12047B 36th Ave NE 1555 Seattle, wA 98125 1557 Email: brian.peter.dickson@gmail.com