idnits 2.17.1 draft-ietf-nat-dns-alg-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 36 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 17 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 331 has weird spacing: '... In order ...' == Line 333 has weird spacing: '.... This reque...' == Line 336 has weird spacing: '... lookup for t...' == Line 337 has weird spacing: '...through its ...' == Line 338 has weird spacing: '...ttached to th...' == (16 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9082 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Ref 3' on line 88 -- Looks like a reference, but probably isn't: 'Ref 4' on line 418 -- Looks like a reference, but probably isn't: 'Ref 1' on line 89 == Unused Reference: '1' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1194, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1197, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1200, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1203, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1205, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1213, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1222, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1631 (ref. '2') (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2535 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2137 (ref. '13') (Obsoleted by RFC 3007) Summary: 10 errors (**), 0 flaws (~~), 22 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NAT Working Group P. Srisuresh, Lucent Technologies 2 INTERNET-DRAFT G. Tsirtsis, BT Laboratories 3 Category: Informational P. Akkiraju, Cisco Systems 4 Expire in six months A. Heffernan, Juniper Networks 5 June 1999 7 DNS extensions to Network Address Translators (DNS_ALG) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may 16 also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Domain Name Service(DNS) provides name to address mapping within 33 a routing class (ex: IP). Network Address Translators (NATs) 34 attempt to provide transparent routing between hosts in disparate 35 routing realms of the same routing class. Typically, NATs exist at 36 the border of a stub domain, hiding private addresses from external 37 addresses. This document identifies the need for DNS extensions 38 to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) 39 can meet the need. DNS_ALG modifies payload transparently to alter 40 address mapping of hosts as DNS packets cross one routing realm 41 into another. The document also illustrates the operation of 42 DNS_ALG with specific examples. 44 1. Introduction 46 Network Address Translators (NATs) are often used when network's 47 internal IP addresses cannot be used outside the network either 48 for privacy reasons or because they are invalid for use outside 49 the network. 51 Ideally speaking, a host name uniquely identifies a host and its 52 address is used to locate routes to the host. However, host name 53 and address are often not distinguished and used interchangeably 54 by applications. Applications embed IP address instead of host 55 name in payload. Examples would be e-mails that specify their MX 56 server address instead of server name as sender ID; HTML files 57 that include IP address instead of names in URLs, etc. Use of IP 58 address in place of host name in payload represents a problem as 59 the packet traverses a NAT device because NATs alter network and 60 transport headers to suit a routing realm, but not payload. 62 DNS provides Name to address mapping. Whereas, NAT performs 63 address translation (in network and transport headers) in 64 datagrams traversing between private and external routing realms. 65 DNS Application Level Gateway (DNS_ALG) outlined in this document 66 helps translate Name-to-Private-Address mapping in DNS payloads 67 into Name-to-external-address mapping and vice versa using state 68 information available on NAT. 70 A Network Address Port Translator (NAPT) performs address and 71 Transport level port translations (i.e, TCP, UDP ports and ICMP 72 query IDs). DNS name mapping granularity, however, is limited to 73 IP addresses and does not extend to transport level identifiers. 74 As a result, the DNS_ALG processing for an NAPT configuration is 75 simplified in that all host addresses in private network are 76 bound to a single external address. The DNS name lookup for 77 private hosts (from external hosts) do not mandate fresh 78 private-external address binding, as all private hosts are bound 79 to a single pre-defined external address. However, reverse name 80 lookups for the NAPT external address will not map to any of 81 the private hosts and will simply map to the NAPT router. 82 Suffices to say, the processing requirements for a DNS_ALG 83 supporting NAPT configuration are a mere subset of Basic NAT. 84 Hence, the discussion in the remainder of the document will focus 85 mainly on Basic NAT, Bi-directional NAT and Twice NAT 86 configurations, with no specific reference to NAPT setup. 88 Definitions for DNS and related terms may be found in [Ref 3] and 89 [Ref 4]. Definitions for NAT related terms may be found in [Ref 1]. 91 2. Requirement for DNS extensions. 93 There are many ways to ensure that a host name is mapped to an 94 address relevant within a routing realm. In the following 95 sections, we will identify where DNS extensions would be needed. 97 Typically, organizations have two types of authoritative name 98 servers. Internal authoritative name servers identify all (or 99 majority of) corporate resources within the organization. Only a 100 portion of these hosts are allowed to be accessed by the external 101 world. The remaining hosts and their names are unique to the 102 private network. Hosts visible to the external world and the 103 authoritative name server that maps their names to network 104 addresses are often configured within a DMZ (De-Militarized Zone) 105 in front of a firewall. We will refer the hosts and name servers 106 within DMZ as DMZ hosts and DMZ name servers respectively. DMZ 107 host names are end-to-end unique in that their FQDNs do not 108 overlap with any end node that communicates with it . 110 \ | / 111 +-----------------------+ 112 |Service Provider Router| 113 +-----------------------+ 114 WAN | 115 Stub A .........|\|.... 116 | 117 +-----------------+ 118 |Stub Router w/NAT| 119 +-----------------+ 120 | 121 | DMZ - Network 122 ------------------------------------------------------------ 123 | | | | | 124 +--+ +--+ +--+ +--+ +----------+ 125 |__| |__| |__| |__| | Firewall | 126 /____\ /____\ /____\ /____\ +----------+ 127 DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web | 128 Server Server etc. | 129 | 130 Internal hosts (Private IP network) | 131 ------------------------------------------------------------ 132 | | | | 133 +--+ +--+ +--+ +--+ 134 |__| |__| |__| |__| 135 /____\ /____\ /____\ /____\ 136 Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server 138 Figure 1: DMZ network configuration of a private Network. 140 Figure 1 above illustrates configuration of a private network which 141 includes a DMZ. Actual configurations may vary. Internal name servers 142 are accessed by users within private network only. Internal DNS 143 queries and responses do not cross the private routing boundary. DMZ 144 name servers and DMZ hosts on the other hand are end-to-end unique 145 and could be accessed by external as well as internal hosts. 146 Throughout this document, our focus will be limited to DMZ hosts and 147 DMZ name servers and will not include internal hosts and internal 148 name servers, unless they happen to be same. 150 2.1. DMZ hosts assigned static external addresses on NAT 152 Take the case where DMZ hosts are assigned static external 153 addresses on the NAT device. Note, all hosts within private domain, 154 including the DMZ hosts are identified by their private addresses. 155 Static mapping on the NAT device allows the the DMZ hosts to be 156 identified by their public addresses in the external domain. 158 2.1.1. Private networks with no DMZ name servers 160 Take the case where a private network has no DMZ name server 161 for itself. If the private network is connected to a single service 162 provider for external connectivity, the DMZ hosts may be listed 163 by their external addresses in the authoritative name servers of 164 the service provider itself. 166 If the network is connected to multiple service providers, the 167 DMZ host names may be listed by their external address(es) within 168 the authoritative name servers of each of the service providers, 169 especially if the private network is assigned different address 170 prefixes by the service providers. 172 In both cases, externally generated DNS lookups will not reach the 173 private network. A large number of NAT based private domains 174 pursue this option to have their DMZ hosts listed by their 175 external addresses on service provider's name servers. 177 2.1.2. Private networks with DMZ name servers 179 Take the case where a private network opts to keep an authoritative 180 DMZ name server for the zone within the network itself. If the 181 network is connected to a single service provider, the DMZ name 182 server may be configured to obviate DNS payload interceptions as 183 follows. The hosts in DMZ name server must be mapped to their 184 statically assigned external addresses and the internal name server 185 must be configured to bypass the DMZ name server for queries 186 concerning external hosts. This scheme ensures that DMZ name 187 servers are set for exclusive access to external hosts alone (not 188 even to the DMZ hosts) and hence can be configured with external 189 addresses only. 191 The above scheme fails to scale when the private network is 192 connected to multiple service providers, assigning different 193 network addresses to the DMZ hosts. DNS extensions to NAT 194 would prove useful here. It is conceivable, however, to 195 have a separate pair of DMZ servers (primary and secondary) 196 configured for each network address prefix assigned by a 197 service provider for the organization. 199 2.2. DMZ hosts assigned external addresses dynamically on NAT 201 Take the case where DMZ hosts in a private network are assigned 202 external addresses dynamically by NAT. While the addresses issued 203 to these hosts are fixed within the private network, their 204 externally known addresses are ephemeral, as determined by NAT. 205 In such a scenario, it is mandatory for the private organization 206 to have a DMZ name server in order to allow access to DMZ hosts 207 by their name. 209 The DMZ name server would be configured with private addresses 210 for DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing 211 on NAT device will intercept the DNS packets directed to or from 212 the DMZ name server(s) and perform transparent payload translations 213 so that a DMZ host name has the right address mapping within 214 each routing boundary (i.e., private or external). 216 3. Interactions between NAT and DNS_ALG 218 This document operates on the paradigm that interconnecting routing 219 realms may have overlapping address space. But, names of hosts 220 within interconnected realms must be end-to-end unique in order for 221 them to be accessed by all hosts. In other words, there cannot be 222 an overlap of FQDNs between end nodes communicating with each other. 223 The following diagram illustrates how a DNS packet traversing a NAT 224 device (with DNS_ALG) is subject to header and payload translations. 225 A DNS packet can be a TCP or UDP packet with the source or 226 destination port set to 53. NAT would translate the IP and TCP/UDP 227 headers of the DNS packet and notify DNS-ALG to perform DNS payload 228 changes. DNS-ALG would interact with NAT and use NAT state 229 information to modify payload, as necessary. 231 Original-IP 232 packet 233 || 234 || 235 vv 236 +---------------------------------+ +-----------------------+ 237 | | |DNS Appl. Level Gateway| 238 |Network Address Translation (NAT)|--->| (DNS_ALG) | 239 | -IP & Transport header mods |<---| -DNS payload mods | 240 | | | | 241 +---------------------------------+ +-----------------------+ 242 || 243 || 244 vv 245 Translated-IP 246 packet 248 Figure 2: NAT & DNS-ALG in the translation path of DNS packets 250 3.1. Address Binding considerations 252 We will make a distinction between "Temporary Address Binding" and 253 "Committed Address Binding" in NATs. This distinction becomes 254 necessary because the DNS_ALG will allow external users to create 255 state on NAT, and thus the potential for denial-of-service attacks. 256 Temporary address binding is the phase in which an address binding 257 is reserved without any NAT sessions using the binding. Committed 258 address binding is the phase in which there exists at least one 259 NAT session using the binding between the external and private 260 addresses. Both types of bindings are used by DNS_ALG to modify 261 DNS payloads. NAT uses only the committed address bindings to 262 modify the IP and Transport headers of datagrams pertaining to 263 NAT sessions. 265 For statically mapped addresses, the above distinction is not 266 relevant. For dynamically mapped addresses, temporary address 267 binding often precedes committed binding. Temporary binding occurs 268 when DMZ name server is queried for a name lookup. Name query is 269 likely a pre-cursor to a real session between query originator 270 and the queried host. The temporary binding becomes committed only 271 when NAT sees the first packet of a session between query initiator 272 and queried host. 274 A configurable parameter, "Bind-holdout time" may be defined for 275 dynamic address assignments as the maximum period of time for which 276 a temporary address binding is held active without transitioning 277 into a committed binding. With each use of temporary binding by 278 DNS_ALG (to modify DNS payload), this Bind-holdout period is 279 renewed. A default Bind-holdout time of a couple of minutes might 280 suffice for most DNS-ALG implementations. Note, it is possible for a 281 committed address binding to occur without ever having to be 282 preceded by a temporary binding. Lastly, when NAT is ready to unbind 283 a committed address binding, the binding is transitioned into a 284 temporary binding and kept in that phase for an additional 285 Bind-holdout period. The binding is freed only upon expiry of 286 Bind-holdout time. The Bind-holdout time preceding the 287 committed-address-binding and the address-unbinding are required to 288 ensure that end hosts have sufficient time in which to initiate a 289 data session subsequent to a name lookup. 291 For example, say a private network with address prefix 10/8 is 292 mapped to 198.76.29/24. When an external hosts makes a DNS query 293 to host7, bearing address 10.0.0.7, the DMZ name server within 294 private network responds with an A type RR for host7 as: 296 host7 A 10.0.0.7 298 DNS_ALG would intercept the response packet and if 10.0.0.7 is not 299 assigned an external address already, it would request NAT to create 300 a temporary address binding with an external address and start 301 Bind-holdout timer to age the binding. Say, the assigned external 302 address is 198.76.29.1. DNS-ALG would use this temporary binding to 303 modify the RR in DNS response, replacing 10.0.0.7 with its external 304 address and reply with: 306 host7 A 198.76.29.1 308 When query initiator receives DNS response, only the assigned 309 external address is seen. Within a short period (presumably before 310 the bind-holdout time expires), the query initiator would 311 initiate a session with host7. When NAT notices the start of new 312 session directed to 198.76.29.1, NAT would terminate 313 Bind-holdout timer and transition the temporary binding between 314 198.76.29.1 and 10.0.0.7 into a committed binding. 316 To minimize denial of service attacks, where a malicious user 317 keeps attempting name resolutions, without ever initiating a 318 connection, NAT would have to monitor temporary address bindings 319 that have not transitioned into committed bindings. There could 320 be a limit on the number of temporary bindings and attempts to 321 generate additional temporary bindings could be simply rejected. 322 There may be other heuristic solutions to counter this type 323 of malicious attacks. 325 We will consider bi-directional NAT to illustrate the use of 326 temporary binding by DNS_ALG in the following sub-sections, even 327 though the concept is applicable to other flavors of NATs as well. 329 3.2. Incoming queries 331 In order to initiate incoming sessions, an external host obtains 332 the V4 address of the DMZ-host it is trying to connect to by making 333 a DNS request. This request constitutes prelude to the start of 334 a potential new session. 336 The external host resolver makes a name lookup for the DMZ host 337 through its DNS server. When the DNS server does not have a 338 record of IPv4 address attached to this name, the lookup query 339 is redirected at some point to the the Primary/Backup DNS server 340 (i.e., in DMZ) of the private stub domain. 342 Enroute to DMZ name server, DNS_ALG would intercept the datagram 343 and modify the query as follows. 345 a) For Host name to Host address query requests: 346 Make no change to the DNS payload. 348 b) For Host address to Host name queries: 349 Replace the external V4 address octets (in reverse order) 350 preceding the string "IN-ADDR.ARPA" with the corresponding 351 private V4 address, if such an address binding exists 352 already. However, if a binding does not exist, the DNS_ALG 353 would simply respond (as a name server would) with a 354 response code (RCODE) of 5 (REFUSED to respond due to policy 355 reasons) and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the 356 header section of the response. 358 In the opposite direction, as DNS response traverses from the 359 DNS server in private network, DNS_ALG would once again intercept 360 the packet and modify as follows. 362 a) For a host name to host address query requests, replace the 363 private address sent by DMZ name server with a public 364 address internally assigned by the NAT router. If a public 365 address is not previously assigned to the host's private 366 address, NAT would assign one at this time. 368 b) For host address to host name queries, replace the private 369 address octets preceding the string "IN-ADDR.ARPA" in 370 response RRs with their external address assignments. 371 There is a chance here that by the time the DMZ name server 372 replies, the bind-holdout timer in NAT for the address in 373 question has expired. In such a case, DNS_ALG would simply 374 drop the reply. The sender will have to resend the query 375 (as would happen when a router enroute drops the response). 377 For static address assignments, the TTL value supplied in the 378 original RR will be left unchanged. For dynamic address assignments, 379 DNS_ALG would modify the TTL value on DNS resource records (RRs) to 380 be 0, implying that the RRs should only be used for transaction in 381 progress, and not be cached. For compatibility with broken 382 implementations, TTL of 1 might in practice work better. 384 In addition, NAT would be requested to initiate a bind-holdout timer 385 following the assignment. If no session is initiated to the private 386 host within the Bind-holdout time period, NAT would terminate the 387 temporary binding. 389 3.3. Outgoing Queries 391 For Basic and bi-directional NATs, there is no need to distinguish 392 between temporary and committed bindings for outgoing queries. This 393 is because, DNS_ALG does not modify the DNS packets directed to or 394 from external name servers (used during outbound sessions), unlike 395 the inbound DNS sessions. 397 Say, a private host needs to communicate with an external host. 398 The DNS query goes to the internal name server (if there 399 exists one) and from there to the appropriate authoritative/cache 400 name server outside the private domain. The reply follows the 401 same route but neither the query nor the response are subject to 402 DNS_ALG translations. 404 This however will not be the case with address isolated twice NAT 405 private and external domains. In such a case, NAT would intercept 406 all DNS packets and make address modifications to payload as 407 discussed in the previous section. Temporary Private to external 408 address bindings are created when responses are sent by private DNS 409 servers and temporary external to private address bindings are 410 created when responses are sent by external DNS servers. 412 4. DNS payload modifications by DNS-ALG 414 Typically, UDP is employed as the transport mechanism for DNS 415 queries and responses and TCP for Zone refresh activities. In 416 either case, name servers are accessed using a well-known DNS 417 server port 53 (decimal) and all DNS payloads have the following 418 format of data [Ref 4]. The header section is always present and 419 includes fields specifying which of the remaining sections are 420 present. The header identifies if the message is a query or a 421 response. No changes are required to be made by NATs to the 422 Header section. DNS_ALG would parse only the DNS payloads whose 423 QCLASS is set to IN (IP class). 425 +---------------------+ 426 | Header | 427 +---------------------+ 428 | Question | the question for the name server 429 +---------------------+ 430 | Answer | RRs answering the question 431 +---------------------+ 432 | Authority | RRs pointing toward an authority 433 +---------------------+ 434 | Additional | RRs holding additional information 435 +---------------------+ 437 4.1. Question section 439 The question section contains QDCOUNT (usually 1) entries, as 440 specified in Header section, with each of the entries in the 441 following format: 443 1 1 1 1 1 1 444 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 445 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 446 | | 447 / QNAME / 448 / / 449 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 450 | QTYPE | 451 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 452 | QCLASS | 453 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 455 4.1.1. PTR type Queries 457 DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified 458 Domain Names) fall within IN-ADDR.ARPA domain and replace the 459 address octets (in reverse order) preceding the string 460 "IN-ADDR.ARPA" with the corresponding assigned address octets 461 in reverse order, only if the address binding is active on 462 the NAT router. If the address preceding the string 463 "IN-ADDR.ARPA" falls within the NAT address map, but does not 464 have at least a temporary address binding, DNS_ALG would simply 465 simply respond back (as a DNS name server would) with a response 466 code (RCODE) of 5 (REFUSED to respond due to policy reasons) 467 and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section 468 of the response. 470 Note that the above form of host address to host name type queries 471 will likely yield different results at different times, depending 472 upon address bind status in NAT at a given time. 474 For example, a resolver that wanted to find out the hostname 475 corresponding to address 198.76.29.1 (externally) would pursue a 476 query of the form: 477 QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA. 479 DNS_ALG would intervene and if the address 198.76.29.1 is 480 internally mapped to a private address of 10.0.0.1, modify the 481 query as below and forward to DMZ name server within private 482 network. 484 QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA 486 Presumably, the DMZ name server is the authoritative name server 487 for 10.IN-ADDR.ARPA zone and will respond with an RR of the 488 following form in answer section. DNS_ALG translations of the 489 response RRs will be considered in a following section. 491 1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_domain 493 An example of Inverse translation is e-mail programs using 494 inverse translation to trace e-mail originating hosts for spam 495 prevention. Verify if the address from which the e-mail was sent 496 does indeed belong to the same domain name the sender claims in 497 sender ID. 499 Query modifications of this nature will likely change the length 500 of DNS payload. As a result, the corresponding IP and TCP/UDP 501 header checksums must be updated. In case of TCP based queries, 502 the sequence number deltas must be tracked by NAT so that the 503 delta can be applied to subsequent sequence numbers in datagrams 504 in the same direction and acknowledgement numbers in datagrams in 505 the opposite direction. In case of UDP based queries, message 506 sizes are restricted to 512 bytes (not counting the IP or UDP 507 headers). Longer messages must be truncated and the TC bit should 508 be set in the header. 510 Lastly, any compressed domain names using pointers to represent 511 common domain denominations must be updated to reflect new 512 pointers with the right offset, if the original domain name had 513 to be translated by NAT. 515 4.1.2. A, MX, NS and SOA type Queries 516 For these queries, DNS_ALG would not modify any of the fields in 517 the query section, not even the name field. 519 4.1.3. AXFR type Queries 521 AXFR is a special zone transfer type query. Zone transfers from 522 private routing realm must be avoided for address assignments 523 that are not static. Typically, TCP is used for AXFR requests. 525 When changes are made to a zone, they must be distributed to all 526 name servers. The general model of automatic zone transfer or 527 refreshing is that one of the name servers is the master or 528 primary for the zone. Changes are coordinated at the primary, 529 typically by editing a master file for the zone. After editing, 530 the administrator signals the master server to load the new zone. 531 The other non-master or secondary servers for the zone 532 periodically check the SERIAL field of the SOA for the zone for 533 changes (at some polling intervals) and obtain new zone copies 534 when changes have been made. 536 Zone transfer is usually from primary to backup name servers. In 537 the case of NAT supported private networks, both primary and 538 backup servers will likely be in the same private domain. 539 In such a case, zone transfer does not cross the realm and 540 DNS_ALG support for zone transfer is not an issue. In the case a 541 secondary name server is located outside the premisis of private 542 network, zone transfers must not be permitted for non-static 543 address assignments. 545 During zone transfers, DNS_ALG must examine all A type records 546 and replace the original address octets with their statically 547 assigned address octets. DNS_ALG could also examine if there is 548 an attempt to transfer records for hosts that are not assigned 549 static addresses and drop those records alone or drop the whole 550 transfer. This would minimize misconfiguration and human errors. 552 4.1.4. Dynamic Updates to the DNS. 554 An authoritative name server can have dynamic updates from the 555 nodes within the zone without intervention from NAT and DNS-ALG, 556 so long as one avoids spreading a DNS zone across routing 557 realms. We recommend keeping a DNS zone within the same realm 558 it is responsible for. By doing this, DNS update traffic will 559 not cross routing realms and hence will not be subject to 560 consideration by DNS-ALG. 562 Further, if dynamic updates do cross routing relams, and the 563 updates must always be secured via DNSSEC, then such updates are 564 clearly out of scope for DNS-ALG (as described in section 7). 566 4.2. Resource records in all other sections 568 The answer, authority, and additional sections all share the same 569 format, with a variable number of resource records. The number of 570 RRs specific to each of the sections may be found in the 571 corresponding count fields in DNS header. Each resource record 572 has the following format: 574 1 1 1 1 1 1 575 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 576 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 577 | | 578 / / 579 / NAME / 580 | | 581 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 582 | TYPE | 583 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 584 | CLASS | 585 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 586 | TTL | 587 | | 588 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 589 | RDLENGTH | 590 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 591 / RDATA / 592 / / 593 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 595 The TTL value supplied in the original RRs is left unchanged For 596 static address assignments. For dynamic address assignments, 597 DNS_ALG would modify the TTL to be 0, so the RRs are used just 598 for the transaction in progress, and not cached. 600 4.2.1. PTR type RRs 602 The considerations specified in the Question section 603 is equally valid with names for PTR type RRs. Private address 604 preceding the string "IN-ADDR.ARPA" (in reverse order of 605 octets) must be replaced by its external address assignment 606 (in reverse order), if a binding exists. The remaining fields 607 for this RR remain unchanged. 609 4.2.2. A type RRs 610 The RDATA for A records is a 4-byte IP address. DNS_ALG would 611 simply replace the original address in RDATA with its externally 612 assigned IP address, if it succeeded in finding an address 613 binding. Successful address translation should cause no 614 changes to payload length. Only the transport header checksum 615 would need updating. In case of failure to find an address 616 binding, DNS_ALG would have to drop the record and decrement 617 the corresponding COUNT field in the header section. 619 4.2.3. CNAME, MX, NS and SOA type RRs 621 No changes required to be made by DNS_ALG for these RRs, as the 622 RDATA does not contain any IP addresses. The host names within 623 the RDATA remain unchanged between realms. 625 5. Illustration of DNS_ALG in conjunction with Bi-directional NAT 627 The following diagram illustrates the operation of DNS_ALG in a 628 a bi-directional NAT router. We will illustrate by walking 629 through how name lookup and reverse name lookup queries are 630 processed. 632 . 633 ________________ . External.com 634 ( ) . 635 ( ) . +-------------+ 636 +--+ ( Internet )-.---|Border Router| 637 |__|------ ( ) . +-------------+ 638 /____\ (________________) . | 639 Root | . | 640 DNS Server | . --------------- 641 +---------------+ . | | 642 |Provider Router| . +--+ +--+ 643 +---------------+ . |__| |__| 644 | . /____\ /____\ 645 | . DNS Server Host X 646 External domain | . 171.68.1.1 171.68.10.1 647 ............................|............................... 648 Private domain | 649 | Private.com 650 | 651 +--------------------------------------+ 652 |Bi-Directional NAT router with DNS_ALG| 653 | | 654 | Private addresses: 172.19/16 | 655 | External addresses: 131.108.1/24 | 656 +--------------------------------------+ 657 | | 658 ---------- ---------- 659 | | DNS Server 660 +--+ +--+ Authoritative 661 |__| |__| for private.com 662 /____\ /____\ 663 Host A DNS Server 664 172.19.1.10 172.19.2.1 665 (Mapped to 131.108.1.8) 667 Figure 3: DNS-ALG operation in Bi-Directional NAT setup 669 The above diagram depicts a scenario where a company private.com 670 using private address space 172.19/16 connects to the Internet 671 using bi-directional NAT. DNS_ALG is embedded in the NAT device 672 to make necessary DNS payload changes. NAT is configured to 673 translate the private addresses space into an external address 674 block of 131.108.1/24. NAT is also configured with a static 675 translation for private.com's DNS server, so it can be referred 676 in the external domain by a valid address. 678 The company external.com is located in the external domain, using 679 a registered address block of 171.68/16. Also shown in the 680 topology is a root DNS server. 682 Following simplifications are made to the above configuration: 684 * private.com is not multihomed and all traffic to the external 685 space transits a single NAT. 687 * The DNS server for private.com is authoritative for the 688 private.com domain and points to the root server for all 689 other DNS resolutions. The same is true for the DNS server 690 in external.com. 692 * The internal name servers for private.com and external.com 693 are same as their DMZ name servers. The DNS servers for these 694 domains are configured with addresses private to the 695 organization. 697 * The name resolvers on host nodes do not have recursion 698 available on them and desire recursive service from servers. 699 All name servers are assumed to be able to provide 700 recursive service. 702 5.1. Outgoing Name-lookup queries 704 Say, Host A in private.com needs to perform a name lookup for 705 host X in external.com to initiate a session with X. This would 706 proceed as follows. 708 1. Host A sends a UDP based name lookup query (A record) for 709 "X.External.Com" to its local DNS server. 711 2. Local DNS server sends the query to the root server enroute 712 NAT. NAT would change the IP and UDP headers to reflect DNS 713 server's statically assigned external address. DNS_ALG will 714 make no changes to the payload. 716 3. The root server, in turn, refers the local DNS server to query 717 the DNS server for External.com. This referal transits the NAT 718 enroute to the local DNS server. NAT would simply translate 719 the IP and UDP headers of the incoming packet to reflect DNS 720 server's private address. No changes to the payload by DNS_ALG. 722 4. Private.com DNS server will now send the query to the DNS server 723 for external.com, once again, enroute NAT. Just as with the query 724 to root, The NAT router would change the IP and UDP headers to 725 reflect the DNS server's statically assigned external address. 726 And, DNS_ALG will make no changes to the payload. 728 5. The DNS server for external.com replies with the IP address 729 171.68.10.1. This reply also transits the NAT. NAT would 730 translate the IP and UDP headers of the incoming packet to 731 reflect DNS server's private address. Once again, no changes 732 to the payload by DNS_ALG. 734 6. The DNS server in Private.com replies to host A. 736 When Host A finds the address of Host X, A initiates a session with 737 host X, using a destination IP address of 171.68.10.1. This datagram 738 and any others that follow in this session will be translated as 739 usual by NAT. 741 Note, DNS_ALG does not change the payload for DNS packets in 742 either direction. 744 5.2. Reverse name lookups originated from private domain 746 This scenario builds on the previous case by having host A in 747 Private.com perform a reverse name lookup on 171.68.10.1, which 748 is host X's global address. Following is a sequence of events. 750 1. Host A sends a UDP based inverse name lookup query (PTR record) 751 for "1.10.68.171.IN-ADDR.ARPA." to its local DNS server. 753 2. Local DNS server sends the query to the root server enroute 754 NAT. As before, NAT would change the IP and UDP headers to 755 reflect DNS server's statically assigned external address. 756 DNS_ALG will make no changes to the payload. 758 3. The root server, in turn, refers the local DNS server to query 759 the DNS server for External.com. This referal transits the NAT 760 enroute to the local DNS server. NAT would simply translate 761 the IP and UDP headers of the incoming packet to reflect DNS 762 server's private address. No changes to the payload by DNS_ALG. 764 4. Private.com DNS server will now send the query to the DNS server 765 for external.com, once again, enroute NAT. Just as with the query 766 to root, The NAT router would change the IP and UDP headers to 767 reflect the DNS server's statically assigned external address. 769 And, DNS_ALG will make no changes to the payload. 771 5. The DNS server for external.com replies with the host name 772 of "X.External.Com.". This reply also transits the NAT. NAT would 773 translate the IP and UDP headers of the incoming packet to 774 reflect DNS server's private address. Once again, no changes 775 to the payload by DNS_ALG. 777 6. The DNS server in Private.com replies to host A. 779 Note, DNS_ALG does not change the payload in either direction. 781 5.3. Incoming Name-lookup queries 783 This time, host X in external.com wishes to initiate a session with 784 host A in Private.com. Below are the sequence of events that take 785 place. 787 1. Host X sends a UDP based name lookup query (A record) for 788 "A.Private.com" to its local DNS server. 790 2. Local DNS server in External.com sends the query to root server. 792 3. The root server, in turn, refers the DNS server in External.com 793 to query the DNS server for private.com, 795 4. External.com DNS server will now send the query to the DNS server 796 for Private.com. This query traverses the NAT router. NAT would 797 change the IP and UDP headers of the packet to reflect the DNS 798 server's private address. DNS_ALG will make no changes to the 799 payload. 801 5. The DNS server for Private.com replies with the IP address 802 172.19.1.10 for host A. This reply also transits the NAT. NAT 803 would translate the IP and UDP headers of the outgoing packet 804 from the DNS server. 806 DNS_ALG will request NAT to (a) setup a temporary binding for i 807 Host A (172.19.1.10) with an external address and (b) initiate 808 Bind-holdout timer. When NAT successfully sets up a temporary 809 binding with an external address (say, 131.108.1.12), DNS_ALG 810 would modify the payload to replace A's private address with 811 its external assigned address and set the Cache timeout to 0. 813 6. The server in External.com replies to host X 815 When Host X finds the address of Host A, X initiates a session with 816 A, using a destination IP address of 131.108.1.12. This datagram and 817 any others that follow in this session will be translated as usual 818 by the NAT. 820 Note, DNS_ALG changes only the response packets from the DNS server 821 for Private domain. 823 5.4. Reverse name lookups originated from external domain 825 This scenario builds on the previous case (section 5.3) by having 826 host X in External.com perform a reverse name lookup on 131.108.1.12, 827 which is host A's assigned external address. The following sequence 828 of events take place. 830 1. Host X sends a UDP based inverse name lookup query (PTR record) 831 for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server. 833 2. Local DNS server in External.com sends the query to the root 834 server. 836 3. The root server, in turn, refers the local DNS server to query 837 the DNS server for Private.com. 839 4. External.com DNS server will now send the query to the DNS server 840 for Private.com. This query traverses the NAT router. NAT would 841 change the IP and UDP headers to reflect the DNS server's private 842 address. 844 DNS_ALG will enquire NAT for the private address associated 845 with the external address of 131.108.1.12 and modify the payload, 846 replacing 131.108.1.12 with the private address of 172.19.1.10. 848 5. The DNS server for Private.com replies with the host name 849 of "A.Private.Com.". This reply also transits the NAT. NAT would 850 translate the IP and UDP headers of the incoming packet to 851 reflect DNS server's private address. 853 Once again, DNS_ALG will enquire NAT for the assigned external 854 address associated with the private address of 172.19.1.10 and 855 modify the payload, replacing 172.19.1.10 with the assigned 856 external address of 131.108.1.12. 858 6. The DNS server in External.com replies to host X. 860 Note, DNS_ALG changes the query as well as response packets from DNS 861 server for Private domain. 863 6. Illustration of DNS_ALG in conjunction with Twice-NAT 865 The following diagram illustrates the operation of DNS_ALG in a 866 Twice NAT router. As before, we will illustrate by walking through 867 how name lookup and reverse name lookup queries are processed. 869 . 870 ________________ . External.com 871 ( ) . 872 ( ) . +-------------+ 873 +--+ ( Internet )-.---|Border Router| 874 |__|------ ( ) . +-------------+ 875 /____\ (________________) . | 876 Root | . | 877 DNS Server | . --------------- 878 +---------------+ . | | 879 |Provider Router| . +--+ +--+ 880 +---------------+ . |__| |__| 881 | . /____\ /____\ 882 | . DNS Server Host X 883 External domain | . 171.68.1.1 171.68.10.1 884 ............................|............................... 885 Private domain | 886 | Private.com 887 | 888 +-------------------------------------------+ 889 | Twice-NAT router with DNS_ALG | 890 | | 891 | Private addresses: 171.68/16 | 892 | Assigned External addresses: 131.108.1/24 | 893 | | 894 | External addresses: 171.68/16 | 895 | Assigned Private addresses: 10/8 | 896 +-------------------------------------------+ 897 | | 898 ---------- ---------- 899 | | DNS Server 900 +--+ +--+ Authoritative 901 |__| |__| for private.com 902 /____\ /____\ 903 Host A DNS Server 904 171.68.1.10 171.68.2.1 905 (Mapped to 131.108.1.8) 907 Figure 4: DNS-ALG operation in Twice-NAT setup 909 In this scenario, hosts in private.com were not numbered from the 910 RFC 1918 reserved 172.19/16 space, but rather were numbered with the 911 globally-routable 171.68/16 network, the same as external.com. Not 912 only does private.com need translation service for its own host 913 addresses, but it also needs translation service if any of those 914 hosts are to be able to exchange datagrams with hosts in 915 external.com. Twice-NAT accommodates the transition by translating 916 the overlapping address space used in external.com with a unique 917 address block (10/8) from RFC 1918 address space. Routes are set up 918 within the private domain to direct datagrams destined for the 919 address block 10/8 through Twice-NAT device to the external global 920 network space. 922 Simplifications and assumptions made in section 5.0 will be valid 923 here as well. 925 6.1. Outgoing Name-lookup queries 927 Say, Host A in private.com needs to perform a name lookup for 928 host X in external.com (host X has a FQDN of X.external.com), 929 to find its address. This would would proceed as follows. 931 1. Host A sends a UDP based name lookup query (A record) for 932 "X.External.Com" to its local DNS server. 934 2. Local DNS server sends the query to the root server enroute 935 NAT. NAT would change the IP and UDP headers to reflect DNS 936 server's statically assigned external address. DNS_ALG will 937 make no changes to the payload. 939 3. The root server, in turn, refers the local DNS server to query 940 the DNS server for External.com. This referal transits the NAT 941 enroute to the local DNS server. NAT would simply translate 942 the IP and UDP headers of the incoming packet to reflect DNS 943 server's private address. 945 DNS_ALG will request NAT for an assigned private address for 946 the referral server and replace the external address with its 947 assigned private address in the payload. 949 4. Private.com DNS server will now send the query to the DNS server 950 for external.com, using its assigned private address, via NAT. 951 This time, NAT would change the IP and UDP headers to reflect the 952 External addresses of the DNS servers. I.e., Private.com DNS 953 server's IP address is changed to its assigned external address 954 and External.Com DNS server's assigned Private address is 955 changed to its external address. 957 DNS_ALG will make no changes to the payload. 959 5. The DNS server for external.com replies with the IP address 960 171.68.10.1. This reply also transits the NAT. NAT would 961 once again translate the IP and UDP headers of the incoming 962 to reflect the private addresses of the DNS servers. 963 I.e., Private.com DNS server's IP address is changed to its 964 private address and External.Com DNS server's external 965 address is changed to its assigned Private address. 967 DNS_ALG will request NAT to (a) set up a temporary binding for 968 Host X (171.68.10.1) with a private address and (b) initiate 969 Bind-holdout timer. When NAT successfully sets up temporary 970 binding with a private address (say, 10.0.0.254), DNS_ALG would 971 modify the payload to replace X's external address with its 972 assigned private address and set the Cache timeout to 0. 974 6. The DNS server in Private.com replies to host A. 976 When Host A finds the address of Host X, A initiates a session with 977 host X, using a destination IP address of 10.0.0.254. This datagram 978 and any others that follow in this session will be translated as 979 usual by Twice NAT. 981 Note, the DNS_ALG has had to change payload in both directions. 983 6.2. Reverse name lookups originated from private domain 985 This scenario builds on the previous case by having host A in 986 Private.com perform a reverse name lookup on 10.0.0.254, which 987 is host X's assigned private address. Following is a sequence 988 of events. 990 1. Host A sends a UDP based inverse name lookup query (PTR record) 991 for "254.0.0.10.IN-ADDR.ARPA." to its local DNS server. 993 2. Local DNS server sends the query to the root server enroute 994 NAT. As before, NAT would change the IP and UDP headers to 995 reflect DNS server's statically assigned external address. 997 DNS_ALG will translate the private assigned address 10.0.0.254 998 with its external address 171.68.10.1. 1000 3. The root server, in turn, refers the local DNS server to query 1001 the DNS server for External.com. This referal transits the NAT 1002 enroute to the local DNS server. NAT would simply translate 1003 the IP and UDP headers of the incoming packet to reflect DNS 1004 server's private address. 1006 As with the original query, DNS_ALG will translate the private 1007 assigned address 10.0.0.254 with its external address 1008 171.68.10.1. In addition, DNS_ALG will replace the external 1009 address of the referal server (i.e., the DNS server for 1010 External.com) with its assigned private address in the payload. 1012 4. Private.com DNS server will now send the query to the DNS server 1013 for external.com, using its statically assigned private address, 1014 via NAT. This time, NAT would change the IP and UDP headers to 1015 reflect the External addresses of the DNS servers. I.e., 1016 Private.com DNS server's IP address is changed to its assigned 1017 external address and External.Com DNS server's assigned Private 1018 address is changed to its external address. 1020 As with the original query, DNS_ALG will translate the private 1021 assigned address 10.0.0.254 with its external address 1022 171.68.10.1. 1024 5. The DNS server for external.com replies with the FQDN of 1025 "X.External.Com.". This reply also transits the NAT. NAT would 1026 once again translate the IP and UDP headers of the incoming 1027 to reflect the private addresses of the DNS servers. 1028 I.e., Private.com DNS server's IP address is changed to its 1029 private address and External.Com DNS server's external 1030 address is changed to its assigned Private address. 1032 Once again, DNS_ALG will translate the query section, replacing 1033 the external address 171.68.10.1 with its assigned private 1034 address of 10.0.0.254 1036 6. The DNS server in Private.com replies to host A. 1038 Note, the DNS_ALG has had to change payload in both directions. 1040 6.3. Incoming Name-lookup queries 1042 This time, host X in external.com wishes to initiate a session with 1043 host A in Private.com. Below are the sequence of events that take 1044 place. 1046 1. Host X sends a UDP based name lookup query (A record) for 1047 "A.Private.com" to its local DNS server. 1049 2. Local DNS server in External.com sends the query to root server. 1051 3. The root server, in turn, refers the DNS server in External.com 1052 to query the DNS server for private.com, 1054 4. External.com DNS server will now send the query to the DNS server 1055 for Private.com. This query traverses the NAT router. NAT would 1056 change the IP and UDP headers to reflect the private addresses of 1057 the DNS servers. I.e., Private.com DNS server's IP address is 1058 changed to its private address and External.Com DNS server's 1059 external address is changed to assigned Private address. 1061 DNS_ALG will make no changes to the payload. 1063 5. The DNS server for Private.com replies with the IP address 1064 171.68.1.10 for host A. This reply also transits the NAT. NAT 1065 would once again translate the IP and UDP headers of the incoming 1066 to reflect the external addresses of the DNS servers. I.e., 1067 Private.com DNS server's IP address is changed to its 1068 assigned external address and External.Com DNS server's 1069 assigned private address is changed to its external address. 1071 DNS_ALG will request NAT to (a) set up temporary binding for 1072 Host A (171.68.1.10) with an external address and (b) initiate 1073 Bind-holdout timer. When NAT succeeds in finding an external 1074 address (say, 131.108.1.12) to temporarily bind to host A, 1075 DNS_ALG would modify the payload to replace A's private address 1076 with its external assigned address and set the Cache timeout to 0. 1078 6. The server in External.com replies to host X 1080 When Host X finds the address of Host A, X initiates a session with 1081 A, using a destination IP address of 131.108.1.12. This datagram and 1082 any others that follow in this session will be translated as usual 1083 by the NAT. 1085 Note, DNS_ALG changes only the response packets from the DNS server 1086 for Private domain. 1088 6.4. Reverse name lookups originated from external domain 1090 This scenario builds on the previous case (section 6.3) by having 1091 host X in External.com perform a reverse name lookup on 131.108.1.12, 1092 which is host A's assigned external address. The following sequence 1093 of events take place. 1095 1. Host X sends a UDP based inverse name lookup query (PTR record) 1096 for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server. 1098 2. Local DNS server in External.com sends the query to the root 1099 server. 1101 3. The root server, in turn, refers the local DNS server to query 1102 the DNS server for Private.com. 1104 4. External.com DNS server will now send the query to the DNS server 1105 for Private.com. This query traverses the NAT router. NAT would 1106 change the IP and UDP headers to reflect the private addresses of 1107 the DNS servers. I.e., Private.com DNS server's IP address is 1108 changed to its private address and External.Com DNS server's 1109 external address is changed to assigned Private address. 1111 DNS_ALG will enquire NAT for the private address associated 1112 with the external address of 131.108.1.12 and modify the payload, 1113 replacing 131.108.1.12 with the private address of 171.68.1.10. 1115 5. The DNS server for Private.com replies with the host name 1116 of "A.Private.Com.". This reply also transits the NAT. NAT would 1117 once again translate the IP and UDP headers of the incoming 1118 to reflect the external addresses of the DNS servers. I.e., 1119 Private.com DNS server's IP address is changed to its 1120 assigned external address and External.Com DNS server's 1121 assigned private address is changed to its external address. 1123 Once again, DNS_ALG will enquire NAT for the assigned external 1124 address associated with the private address of 172.19.1.10 and 1125 modify the payload, replacing 171.68.1.10 with the assigned 1126 external address of 131.108.1.12. 1128 6. The DNS server in External.com replies to host X. 1130 Note, DNS_ALG changes the query as well as response packets from DNS 1131 server for Private domain. 1133 7. DNS-ALG limitations and Future Work 1135 NAT increases the probability of mis-addressing. For example, 1136 same local address may be bound to different public address at 1137 different times and vice versa. As a result, hosts that cache 1138 the name to address mapping for longer periods than the NAT 1139 router is configured to hold the map are likely to misaddress 1140 their sessions. Note, this is mainly an issue with bad host 1141 implementations that hold DNS records longer than the TTL 1142 in them allows and is not directly attributable to the 1143 mechanism described here. 1145 DNS_ALG cannot support secure DNS name servers in the private 1146 domain. I.e., an authoritative DNS name server in the DMZ cannot 1147 sign replies to queries that originate from the external world. 1148 Since the DNS server does not have a way to find where the queries 1149 come from (i.e., internal or external), it will most likely have 1150 to resort to the common denomination of today's insecure DNS. 1152 Secondly, an end-node that demands DNS replies to be signed will 1153 reject replies that have been tampered with by DNS_ALG. Both are 1154 serious limitations to DNS_ALG. Zone transfers between DNS-SEC 1155 servers is also impacted the same way, if the transfer crosses 1156 routing realms. 1158 The good news, however, is that only end-nodes in DMZ pay the 1159 price for the above limitation in a traditional NAT (or, a 1160 bi-directional NAT), as external end-nodes may not access internal 1161 hosts due to DNS replies not being secure. However, for outgoing 1162 sessions (from private network) in a bi-directional NAT setup, 1163 the DNS queries can be signed and securely accepted by DMZ and 1164 other internal hosts since DNS_ALG does not intercept outgoing 1165 DNS queries and incoming replies. Lastly, zone transfers between 1166 DNS-SEC servers within the same private network are not impacted. 1168 Clearly, with DNS SEC deployment in DNS servers and end-host 1169 resolvers, the scheme suggested in this document will not work. 1171 8. Security considerations. 1173 If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG 1174 will fail because it won't be able to perform payload modifications. 1175 Alternately, if packets must be preserved in a routing realm, 1176 DNS_ALG will need to hold the secret key to decrypt/verify payload 1177 before forwarding packets to a different realm. For example, if 1178 DNS-ALG, NAT and IPsec gateway (providing secure tunneling service) 1179 are resident on the same device, DNS-ALG will have access to the 1180 IPsec security association keys. The preceding section, "DNS-ALG 1181 limitations and Future Work" has coverage on DNS_ALG security 1182 considerations. 1184 REFERENCES 1186 [1] P. Srisuresh, M. Holdrege, "The IP Network Address 1187 Translator (NAT) terminology and considerations", 1188 - Work in progress, 1189 October 1998 1191 [2] K. Egevang, P. Francis, "The IP Network Address Translator 1192 (NAT)", RFC 1631. 1194 [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, 1195 Lear, E. "Address Allocation for Private Internets", RFC 1918 1197 [4] P. Mockapetris, "Domain Names - Concepts and facilities", 1198 RFC 1034. 1200 [5] P. Mockapetris, "Domain Names - Implementation and 1201 Specification", RFC 1035. 1203 [6] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700. 1205 [7] R. Braden, "Requirements for Internet Hosts -- Communication 1206 Layers", RFC 1122. 1208 [8] R. Braden, "Requirements for Internet Hosts -- Application 1209 and Support", RFC 1123. 1211 [9] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812. 1213 [10] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address 1214 Behaviour Today", RFC 2101. 1216 [11] Donald E. Eastlake, "Domain Name System Security Extensions", 1217 RFC 2535 1219 [12] P. Vixie, S. Thompson, Y. Rekhter and J. Bound, "Dynamic 1220 Updates in the Domain Name System (DNS UPDATE)", RFC 2136 1222 [13] D. Eastlake, "Secure Domain Name System Dynamic Update", 1223 RFC 2137 1225 Authors' Addresses 1227 Pyda Srisuresh 1228 Lucent technologies 1229 Pleasanton, CA 94588-8519 1230 U.S.A. 1232 Phone: +1 (925) 737-2153 1233 Fax: +1 (925) 737-2110 1234 e-mail: suresh@ra.lucent.com 1236 George Tsirtsis 1237 Internet Transport Group 1238 B29 Room 129 1239 BT Laboratories 1240 Martlesham Heath 1241 IPSWICH 1242 Suffolk IP5 3RE 1243 England 1244 Phone: +44 1473 640756 1245 Fax: +44 1473 640709 1246 e-mail: george@gideon.bt.co.uk 1248 Praveen Akkiraju 1249 cisco Systems 1250 170 West Tasman Drive 1251 San Jose, CA 95134 USA 1253 Phone: +1 (408) 526-5066 1254 e-mail: spa@cisco.com 1256 Andy Heffernan 1257 Juniper Networks, Inc. 1258 385 Ravensdale Drive. 1259 Mountain View, CA 94043 USA 1261 Phone: +1 (650) 526-8037 1262 Fax: +1 (650) 526-8001 1263 e-mail: ahh@juniper.net