idnits 2.17.1 draft-ietf-nat-dns-alg-04.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 172 has weird spacing: '...nes, as the p...' == 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 ...' == (17 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 89 -- Looks like a reference, but probably isn't: 'Ref 4' on line 425 -- Looks like a reference, but probably isn't: 'Ref 1' on line 90 == Unused Reference: '1' is defined on line 1215, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1222, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1231, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1233, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1236, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1239, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1241, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1244, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1250, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1256, 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 (~~), 24 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 address 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 address 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 (ex: user@666.42.7.11) instead of server name 57 (ex: user@private.com) as sender ID; HTML files that include IP 58 address instead of names in URLs, etc. Use of IP address in 59 place of host name in payload represents a problem as the packet 60 traverses a NAT device because NATs alter network and transport 61 headers to suit an address realm, but not payload. 63 DNS provides Name to address mapping. Whereas, NAT performs 64 address translation (in network and transport headers) in 65 datagrams traversing between private and external address realms. 66 DNS Application Level Gateway (DNS_ALG) outlined in this document 67 helps translate Name-to-Private-Address mapping in DNS payloads 68 into Name-to-external-address mapping and vice versa using state 69 information available on NAT. 71 A Network Address Port Translator (NAPT) performs address and 72 Transport level port translations (i.e, TCP, UDP ports and ICMP 73 query IDs). DNS name mapping granularity, however, is limited to 74 IP addresses and does not extend to transport level identifiers. 75 As a result, the DNS_ALG processing for an NAPT configuration is 76 simplified in that all host addresses in private network are 77 bound to a single external address. The DNS name lookup for 78 private hosts (from external hosts) do not mandate fresh 79 private-external address binding, as all private hosts are bound 80 to a single pre-defined external address. However, reverse name 81 lookups for the NAPT external address will not map to any of 82 the private hosts and will simply map to the NAPT router. 83 Suffices to say, the processing requirements for a DNS_ALG 84 supporting NAPT configuration are a mere subset of Basic NAT. 85 Hence, the discussion in the remainder of the document will focus 86 mainly on Basic NAT, Bi-directional NAT and Twice NAT 87 configurations, with no specific reference to NAPT setup. 89 Definitions for DNS and related terms may be found in [Ref 3] and 90 [Ref 4]. Definitions for NAT related terms may be found in [Ref 1]. 92 2. Requirement for DNS extensions. 94 There are many ways to ensure that a host name is mapped to an 95 address relevant within an address realm. In the following 96 sections, we will identify where DNS extensions would be needed. 98 Typically, organizations have two types of authoritative name 99 servers. Internal authoritative name servers identify all (or 100 majority of) corporate resources within the organization. Only a 101 portion of these hosts are allowed to be accessed by the external 102 world. The remaining hosts and their names are unique to the 103 private network. Hosts visible to the external world and the 104 authoritative name server that maps their names to network 105 addresses are often configured within a DMZ (De-Militarized Zone) 106 in front of a firewall. We will refer the hosts and name servers 107 within DMZ as DMZ hosts and DMZ name servers respectively. DMZ 108 host names are end-to-end unique in that their FQDNs do not 109 overlap with any end node that communicates with it . 111 \ | / 112 +-----------------------+ 113 |Service Provider Router| 114 +-----------------------+ 115 WAN | 116 Stub A .........|\|.... 117 | 118 +-----------------+ 119 |Stub Router w/NAT| 120 +-----------------+ 121 | 122 | DMZ - Network 123 ------------------------------------------------------------ 124 | | | | | 125 +--+ +--+ +--+ +--+ +----------+ 126 |__| |__| |__| |__| | Firewall | 127 /____\ /____\ /____\ /____\ +----------+ 128 DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web | 129 Server Server etc. | 130 | 131 Internal hosts (Private IP network) | 132 ------------------------------------------------------------ 133 | | | | 134 +--+ +--+ +--+ +--+ 135 |__| |__| |__| |__| 136 /____\ /____\ /____\ /____\ 137 Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server 139 Figure 1: DMZ network configuration of a private Network. 141 Figure 1 above illustrates configuration of a private network which 142 includes a DMZ. Actual configurations may vary. Internal name servers 143 are accessed by users within the private network only. Internal DNS 144 queries and responses do not cross the private network boundary. DMZ 145 name servers and DMZ hosts on the other hand are end-to-end unique 146 and could be accessed by external as well as internal hosts. 147 Throughout this document, our focus will be limited to DMZ hosts and 148 DMZ name servers and will not include internal hosts and internal 149 name servers, unless they happen to be same. 151 2.1. DMZ hosts assigned static external addresses on NAT 153 Take the case where DMZ hosts are assigned static external 154 addresses on the NAT device. Note, all hosts within private domain, 155 including the DMZ hosts are identified by their private addresses. 156 Static mapping on the NAT device allows the DMZ hosts to be 157 identified by their public addresses in the external domain. 159 2.1.1. Private networks with no DMZ name servers 161 Take the case where a private network has no DMZ name server 162 for itself. If the private network is connected to a single service 163 provider for external connectivity, the DMZ hosts may be listed 164 by their external addresses in the authoritative name servers of 165 the service provider within their forward and in-add.arpa reverse 166 zones. 168 If the network is connected to multiple service providers, the 169 DMZ host names may be listed by their external address(es) within 170 the authoritative name servers of each of the service providers. 171 This is particularly significant in the case of in-addr.arpa reverse 172 zones, as the private network may be assigned different address 173 prefixes by the service providers. 175 In both cases, externally generated DNS lookups will not reach the 176 private network. A large number of NAT based private domains 177 pursue this option to have their DMZ hosts listed by their 178 external addresses on service provider's name servers. 180 2.1.2. Private networks with DMZ name servers 182 Take the case where a private network opts to keep an authoritative 183 DMZ name server for the zone within the network itself. If the 184 network is connected to a single service provider, the DMZ name 185 server may be configured to obviate DNS payload interceptions as 186 follows. The hosts in DMZ name server must be mapped to their 187 statically assigned external addresses and the internal name server 188 must be configured to bypass the DMZ name server for queries 189 concerning external hosts. This scheme ensures that DMZ name 190 servers are set for exclusive access to external hosts alone (not 191 even to the DMZ hosts) and hence can be configured with external 192 addresses only. 194 The above scheme requires careful administrative planning to ensure 195 that DMZ name servers are not contacted by the private hosts 196 directly or indirectly (through the internal name servers). Using 197 DNS-ALG would obviate the administrative ordeals with this approach. 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 address realm (i.e., private or external). 216 3. Interactions between NAT and DNS_ALG 218 This document operates on the paradigm that interconnecting address 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 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 Clearly, setting TTL to be 0 will create more traffic than if the 385 addresses were static, because name-to-address mapping is not cached. 386 Specifically, network based applications will be required to use 387 names rather than addresses for identifying peer nodes and must use 388 DNS for every name resolution, as name-to-address mapping cannot be 389 shared from the previously run applications. 391 In addition, NAT would be requested to initiate a bind-holdout timer 392 following the assignment. If no session is initiated to the private 393 host within the Bind-holdout time period, NAT would terminate the 394 temporary binding. 396 3.3. Outgoing Queries 398 For Basic and bi-directional NATs, there is no need to distinguish 399 between temporary and committed bindings for outgoing queries. This 400 is because, DNS_ALG does not modify the DNS packets directed to or 401 from external name servers (used during outbound sessions), unlike 402 the inbound DNS sessions. 404 Say, a private host needs to communicate with an external host. 405 The DNS query goes to the internal name server (if there 406 exists one) and from there to the appropriate authoritative/cache 407 name server outside the private domain. The reply follows the 408 same route but neither the query nor the response are subject to 409 DNS_ALG translations. 411 This however will not be the case with address isolated twice NAT 412 private and external domains. In such a case, NAT would intercept 413 all DNS packets and make address modifications to payload as 414 discussed in the previous section. Temporary Private to external 415 address bindings are created when responses are sent by private DNS 416 servers and temporary external to private address bindings are 417 created when responses are sent by external DNS servers. 419 4. DNS payload modifications by DNS-ALG 421 Typically, UDP is employed as the transport mechanism for DNS 422 queries and responses and TCP for Zone refresh activities. In 423 either case, name servers are accessed using a well-known DNS 424 server port 53 (decimal) and all DNS payloads have the following 425 format of data [Ref 4]. While NAT is responsible for the 426 translation of IP and TCP/UDP headers of a DNS packet, DNS-ALG 427 is responsible for updating the DNS payload. 429 The header section within the DNS payload is always present and 430 includes fields specifying which of the remaining sections are 431 present. The header identifies if the message is a query or a 432 response. No changes are required to be made by DNS-ALG to the 433 Header section. DNS_ALG would parse only the DNS payloads whose 434 QCLASS is set to IN (IP class). 436 +---------------------+ 437 | Header | 438 +---------------------+ 439 | Question | the question for the name server 440 +---------------------+ 441 | Answer | RRs answering the question 442 +---------------------+ 443 | Authority | RRs pointing toward an authority 444 +---------------------+ 445 | Additional | RRs holding additional information 446 +---------------------+ 448 4.1. Question section 450 The question section contains QDCOUNT (usually 1) entries, as 451 specified in Header section, with each of the entries in the 452 following format: 454 1 1 1 1 1 1 455 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 456 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 457 | | 458 / QNAME / 459 / / 460 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 461 | QTYPE | 462 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 463 | QCLASS | 464 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 466 4.1.1. PTR type Queries 468 DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified 469 Domain Names) fall within IN-ADDR.ARPA domain and replace the 470 address octets (in reverse order) preceding the string 471 "IN-ADDR.ARPA" with the corresponding assigned address octets 472 in reverse order, only if the address binding is active on 473 the NAT router. If the address preceding the string 474 "IN-ADDR.ARPA" falls within the NAT address map, but does not 475 have at least a temporary address binding, DNS_ALG would simply 476 simply respond back (as a DNS name server would) with a response 477 code (RCODE) of 5 (REFUSED to respond due to policy reasons) 478 and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section 479 of the response. 481 Note that the above form of host address to host name type queries 482 will likely yield different results at different times, depending 483 upon address bind status in NAT at a given time. 485 For example, a resolver that wanted to find out the hostname 486 corresponding to address 198.76.29.1 (externally) would pursue a 487 query of the form: 488 QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA. 490 DNS_ALG would intervene and if the address 198.76.29.1 is 491 internally mapped to a private address of 10.0.0.1, modify the 492 query as below and forward to DMZ name server within private 493 network. 495 QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA 497 Presumably, the DMZ name server is the authoritative name server 498 for 10.IN-ADDR.ARPA zone and will respond with an RR of the 499 following form in answer section. DNS_ALG translations of the 500 response RRs will be considered in a following section. 502 1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_domain 504 An example of Inverse translation is e-mail programs using 505 inverse translation to trace e-mail originating hosts for spam 506 prevention. Verify if the address from which the e-mail was sent 507 does indeed belong to the same domain name the sender claims in 508 sender ID. 510 Query modifications of this nature will likely change the length 511 of DNS payload. As a result, the corresponding IP and TCP/UDP 512 header checksums must be updated. In case of TCP based queries, 513 the sequence number deltas must be tracked by NAT so that the 514 delta can be applied to subsequent sequence numbers in datagrams 515 in the same direction and acknowledgement numbers in datagrams in 516 the opposite direction. In case of UDP based queries, message 517 sizes are restricted to 512 bytes (not counting the IP or UDP 518 headers). Longer messages must be truncated and the TC bit should 519 be set in the header. 521 Lastly, any compressed domain names using pointers to represent 522 common domain denominations must be updated to reflect new 523 pointers with the right offset, if the original domain name had 524 to be translated by NAT. 526 4.1.2. A, MX, NS and SOA type Queries 528 For these queries, DNS_ALG would not modify any of the fields in 529 the query section, not even the name field. 531 4.1.3. AXFR type Queries 533 AXFR is a special zone transfer type query. Zone transfers from 534 private address realm must be avoided for address assignments 535 that are not static. Typically, TCP is used for AXFR requests. 537 When changes are made to a zone, they must be distributed to all 538 name servers. The general model of automatic zone transfer or 539 refreshing is that one of the name servers is the master or 540 primary for the zone. Changes are coordinated at the primary, 541 typically by editing a master file for the zone. After editing, 542 the administrator signals the master server to load the new zone. 543 The other non-master or secondary servers for the zone 544 periodically check the SERIAL field of the SOA for the zone for 545 changes (at some polling intervals) and obtain new zone copies 546 when changes have been made. 548 Zone transfer is usually from primary to backup name servers. In 549 the case of NAT supported private networks, primary and backup 550 servers are advised to be located in the same private domain 551 (say, private.zone) so zone transfer is not across the domain 552 and DNS_ALG support for zone transfer is not an issue. In 553 the case a secondary name server is located outside the private 554 domain, zone transfers must not be permitted for non-static 555 address assignments. Primary and secondary servers are required 556 to be within the same private domain because all references to 557 data in the zone had to be captured. With dynamic address 558 assignments and bindings, it is impossible to translate the 559 axfr data to be up-to-date. Hence, if a secondary server for 560 private.zone were to be located external to the domain, it 561 would contain bad data. Note, however, the requirement outlined 562 here is not in confirmence with RFC 2182, which recommends 563 primary and secondary servers to be placed at topologically and 564 geographically dispersed locations on the Internet. 566 During zone transfers, DNS_ALG must examine all A type records 567 and replace the original address octets with their statically 568 assigned address octets. DNS_ALG could also examine if there is 569 an attempt to transfer records for hosts that are not assigned 570 static addresses and drop those records alone or drop the whole 571 transfer. This would minimize misconfiguration and human errors. 573 4.1.4. Dynamic Updates to the DNS. 575 An authoritative name server can have dynamic updates from the 576 nodes within the zone without intervention from NAT and DNS-ALG, 577 so long as one avoids spreading a DNS zone across address 578 realms. We recommend keeping a DNS zone within the same realm 579 it is responsible for. By doing this, DNS update traffic will 580 not cross address realms and hence will not be subject to 581 consideration by DNS-ALG. 583 Further, if dynamic updates do cross address realms, and the 584 updates must always be secured via DNSSEC, then such updates are 585 clearly out of scope for DNS-ALG (as described in section 7). 587 4.2. Resource records in all other sections 589 The answer, authority, and additional sections all share the same 590 format, with a variable number of resource records. The number of 591 RRs specific to each of the sections may be found in the 592 corresponding count fields in DNS header. Each resource record 593 has the following format: 595 The TTL value supplied in the original RRs will be left unchanged 596 for static address assignments. For dynamic address assignments, 597 DNS_ALG will modify the TTL to be 0, so the RRs are used just for 598 the transaction in progress, and not cached. RFC 2181 requires 599 all RRs in an RRset (RRs with the same name, class and type, but 600 with different RDATA) to have the same TTL. So if the TTL of an 601 RR is set to 0, all other RRs within the same RRset will also 602 be adjusted by the DNS-ALG to be 0. 604 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 605 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 606 | | 607 / / 608 / NAME / 609 | | 610 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 611 | TYPE | 612 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 613 | CLASS | 614 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 615 | TTL | 616 | | 617 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 618 | RDLENGTH | 619 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 620 / RDATA / 621 / / 622 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 624 4.2.1. PTR type RRs 626 The considerations specified in the Question section 627 is equally valid with names for PTR type RRs. Private address 628 preceding the string "IN-ADDR.ARPA" (in reverse order of 629 octets) must be replaced by its external address assignment 630 (in reverse order), if a binding exists. The remaining fields 631 for this RR remain unchanged. 633 4.2.2. A type RRs 635 The RDATA for A records is a 4-byte IP address. DNS_ALG would 636 simply replace the original address in RDATA with its externally 637 assigned IP address, if it succeeded in finding an address 638 binding. Successful address translation should cause no 639 changes to payload length. Only the transport header checksum 640 would need updating. In case of failure to find an address 641 binding, DNS_ALG would have to drop the record and decrement 642 the corresponding COUNT field in the header section. 644 4.2.3. CNAME, MX, NS and SOA type RRs 646 No changes required to be made by DNS_ALG for these RRs, as the 647 RDATA does not contain any IP addresses. The host names within 648 the RDATA remain unchanged between realms. 650 5. Illustration of DNS_ALG in conjunction with Bi-directional NAT 652 The following diagram illustrates the operation of DNS_ALG in a 653 a bi-directional NAT router. We will illustrate by walking 654 through how name lookup and reverse name lookup queries are 655 processed. 657 . 658 ________________ . External.com 659 ( ) . 660 ( ) . +-------------+ 661 +--+ ( Internet )-.---|Border Router| 662 |__|------ ( ) . +-------------+ 663 /____\ (________________) . | 664 Root | . | 665 DNS Server | . --------------- 666 +---------------+ . | | 667 |Provider Router| . +--+ +--+ 668 +---------------+ . |__| |__| 669 | . /____\ /____\ 670 | . DNS Server Host X 671 External domain | . 171.68.1.1 171.68.10.1 672 ............................|............................... 673 Private domain | 674 | Private.com 675 | 676 +--------------------------------------+ 677 |Bi-Directional NAT router with DNS_ALG| 678 | | 679 | Private addresses: 172.19/16 | 680 | External addresses: 131.108.1/24 | 681 +--------------------------------------+ 682 | | 683 ---------- ---------- 684 | | DNS Server 685 +--+ +--+ Authoritative 686 |__| |__| for private.com 687 /____\ /____\ 688 Host A DNS Server 689 172.19.1.10 172.19.2.1 690 (Mapped to 131.108.1.8) 692 Figure 3: DNS-ALG operation in Bi-Directional NAT setup 694 The above diagram depicts a scenario where a company private.com 695 using private address space 172.19/16 connects to the Internet 696 using bi-directional NAT. DNS_ALG is embedded in the NAT device 697 to make necessary DNS payload changes. NAT is configured to 698 translate the private addresses space into an external address 699 block of 131.108.1/24. NAT is also configured with a static 700 translation for private.com's DNS server, so it can be referred 701 in the external domain by a valid address. 703 The company external.com is located in the external domain, using 704 a registered address block of 171.68/16. Also shown in the 705 topology is a root DNS server. 707 Following simplifications are made to the above configuration: 709 * private.com is not multihomed and all traffic to the external 710 space transits a single NAT. 712 * The DNS server for private.com is authoritative for the 713 private.com domain and points to the root server for all 714 other DNS resolutions. The same is true for the DNS server 715 in external.com. 717 * The internal name servers for private.com and external.com 718 are same as their DMZ name servers. The DNS servers for these 719 domains are configured with addresses private to the 720 organization. 722 * The name resolvers on host nodes do not have recursion 723 available on them and desire recursive service from servers. 724 All name servers are assumed to be able to provide 725 recursive service. 727 5.1. Outgoing Name-lookup queries 729 Say, Host A in private.com needs to perform a name lookup for 730 host X in external.com to initiate a session with X. This would 731 proceed as follows. 733 1. Host A sends a UDP based name lookup query (A record) for 734 "X.External.Com" to its local DNS server. 736 2. Local DNS server sends the query to the root server enroute 737 NAT. NAT would change the IP and UDP headers to reflect DNS 738 server's statically assigned external address. DNS_ALG will 739 make no changes to the payload. 741 3. The root server, in turn, refers the local DNS server to query 742 the DNS server for External.com. This referal transits the NAT 743 enroute to the local DNS server. NAT would simply translate 744 the IP and UDP headers of the incoming packet to reflect DNS 745 server's private address. No changes to the payload by DNS_ALG. 747 4. Private.com DNS server will now send the query to the DNS server 748 for external.com, once again, enroute NAT. Just as with the query 749 to root, The NAT router would change the IP and UDP headers to 750 reflect the DNS server's statically assigned external address. 751 And, DNS_ALG will make no changes to the payload. 753 5. The DNS server for external.com replies with the IP address 754 171.68.10.1. This reply also transits the NAT. NAT would 755 translate the IP and UDP headers of the incoming packet to 756 reflect DNS server's private address. Once again, no changes 757 to the payload by DNS_ALG. 759 6. The DNS server in Private.com replies to host A. 761 When Host A finds the address of Host X, A initiates a session with 762 host X, using a destination IP address of 171.68.10.1. This datagram 763 and any others that follow in this session will be translated as 764 usual by NAT. 766 Note, DNS_ALG does not change the payload for DNS packets in 767 either direction. 769 5.2. Reverse name lookups originated from private domain 771 This scenario builds on the previous case by having host A in 772 Private.com perform a reverse name lookup on 171.68.10.1, which 773 is host X's global address. Following is a sequence of events. 775 1. Host A sends a UDP based inverse name lookup query (PTR record) 776 for "1.10.68.171.IN-ADDR.ARPA." to its local DNS server. 778 2. Local DNS server sends the query to the root server enroute 779 NAT. As before, NAT would change the IP and UDP headers to 780 reflect DNS server's statically assigned external address. 781 DNS_ALG will make no changes to the payload. 783 3. The root server, in turn, refers the local DNS server to query 784 the DNS server for External.com. This referal transits the NAT 785 enroute to the local DNS server. NAT would simply translate 786 the IP and UDP headers of the incoming packet to reflect DNS 787 server's private address. No changes to the payload by DNS_ALG. 789 4. Private.com DNS server will now send the query to the DNS server 790 for external.com, once again, enroute NAT. Just as with the query 791 to root, The NAT router would change the IP and UDP headers to 792 reflect the DNS server's statically assigned external address. 794 And, DNS_ALG will make no changes to the payload. 796 5. The DNS server for external.com replies with the host name 797 of "X.External.Com.". This reply also transits the NAT. NAT would 798 translate the IP and UDP headers of the incoming packet to 799 reflect DNS server's private address. Once again, no changes 800 to the payload by DNS_ALG. 802 6. The DNS server in Private.com replies to host A. 804 Note, DNS_ALG does not change the payload in either direction. 806 5.3. Incoming Name-lookup queries 808 This time, host X in external.com wishes to initiate a session with 809 host A in Private.com. Below are the sequence of events that take 810 place. 812 1. Host X sends a UDP based name lookup query (A record) for 813 "A.Private.com" to its local DNS server. 815 2. Local DNS server in External.com sends the query to root server. 817 3. The root server, in turn, refers the DNS server in External.com 818 to query the DNS server for private.com, 820 4. External.com DNS server will now send the query to the DNS server 821 for Private.com. This query traverses the NAT router. NAT would 822 change the IP and UDP headers of the packet to reflect the DNS 823 server's private address. DNS_ALG will make no changes to the 824 payload. 826 5. The DNS server for Private.com replies with the IP address 827 172.19.1.10 for host A. This reply also transits the NAT. NAT 828 would translate the IP and UDP headers of the outgoing packet 829 from the DNS server. 831 DNS_ALG will request NAT to (a) setup a temporary binding for 832 Host A (172.19.1.10) with an external address and (b) initiate 833 Bind-holdout timer. When NAT successfully sets up a temporary 834 binding with an external address (say, 131.108.1.12), DNS_ALG 835 would modify the payload to replace A's private address with 836 its external assigned address and set the Cache timeout to 0. 838 6. The server in External.com replies to host X 840 When Host X finds the address of Host A, X initiates a session with 841 A, using a destination IP address of 131.108.1.12. This datagram and 842 any others that follow in this session will be translated as usual 843 by the NAT. 845 Note, DNS_ALG changes only the response packets from the DNS server 846 for Private domain. 848 5.4. Reverse name lookups originated from external domain 850 This scenario builds on the previous case (section 5.3) by having 851 host X in External.com perform a reverse name lookup on 131.108.1.12, 852 which is host A's assigned external address. The following sequence 853 of events take place. 855 1. Host X sends a UDP based inverse name lookup query (PTR record) 856 for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server. 858 2. Local DNS server in External.com sends the query to the root 859 server. 861 3. The root server, in turn, refers the local DNS server to query 862 the DNS server for Private.com. 864 4. External.com DNS server will now send the query to the DNS server 865 for Private.com. This query traverses the NAT router. NAT would 866 change the IP and UDP headers to reflect the DNS server's private 867 address. 869 DNS_ALG will enquire NAT for the private address associated 870 with the external address of 131.108.1.12 and modify the payload, 871 replacing 131.108.1.12 with the private address of 172.19.1.10. 873 5. The DNS server for Private.com replies with the host name 874 of "A.Private.Com.". This reply also transits the NAT. NAT would 875 translate the IP and UDP headers of the incoming packet to 876 reflect DNS server's private address. 878 Once again, DNS_ALG will enquire NAT for the assigned external 879 address associated with the private address of 172.19.1.10 and 880 modify the payload, replacing 172.19.1.10 with the assigned 881 external address of 131.108.1.12. 883 6. The DNS server in External.com replies to host X. 885 Note, DNS_ALG changes the query as well as response packets from DNS 886 server for Private domain. 888 6. Illustration of DNS_ALG in conjunction with Twice-NAT 890 The following diagram illustrates the operation of DNS_ALG in a 891 Twice NAT router. As before, we will illustrate by walking through 892 how name lookup and reverse name lookup queries are processed. 894 . 895 ________________ . External.com 896 ( ) . 897 ( ) . +-------------+ 898 +--+ ( Internet )-.---|Border Router| 899 |__|------ ( ) . +-------------+ 900 /____\ (________________) . | 901 Root | . | 902 DNS Server | . --------------- 903 +---------------+ . | | 904 |Provider Router| . +--+ +--+ 905 +---------------+ . |__| |__| 906 | . /____\ /____\ 907 | . DNS Server Host X 908 External domain | . 171.68.1.1 171.68.10.1 909 ............................|............................... 910 Private domain | 911 | Private.com 912 | 913 +-------------------------------------------+ 914 | Twice-NAT router with DNS_ALG | 915 | | 916 | Private addresses: 171.68/16 | 917 | Assigned External addresses: 131.108.1/24 | 918 | | 919 | External addresses: 171.68/16 | 920 | Assigned Private addresses: 10/8 | 921 +-------------------------------------------+ 922 | | 923 ---------- ---------- 924 | | DNS Server 925 +--+ +--+ Authoritative 926 |__| |__| for private.com 927 /____\ /____\ 928 Host A DNS Server 929 171.68.1.10 171.68.2.1 930 (Mapped to 131.108.1.8) 932 Figure 4: DNS-ALG operation in Twice-NAT setup 934 In this scenario, hosts in private.com were not numbered from the 935 RFC 1918 reserved 172.19/16 space, but rather were numbered with the 936 globally-routable 171.68/16 network, the same as external.com. Not 937 only does private.com need translation service for its own host 938 addresses, but it also needs translation service if any of those 939 hosts are to be able to exchange datagrams with hosts in 940 external.com. Twice-NAT accommodates the transition by translating 941 the overlapping address space used in external.com with a unique 942 address block (10/8) from RFC 1918 address space. Routes are set up 943 within the private domain to direct datagrams destined for the 944 address block 10/8 through Twice-NAT device to the external global 945 network space. 947 Simplifications and assumptions made in section 5.0 will be valid 948 here as well. 950 6.1. Outgoing Name-lookup queries 952 Say, Host A in private.com needs to perform a name lookup for 953 host X in external.com (host X has a FQDN of X.external.com), 954 to find its address. This would would proceed as follows. 956 1. Host A sends a UDP based name lookup query (A record) for 957 "X.External.Com" to its local DNS server. 959 2. Local DNS server sends the query to the root server enroute 960 NAT. NAT would change the IP and UDP headers to reflect DNS 961 server's statically assigned external address. DNS_ALG will 962 make no changes to the payload. 964 3. The root server, in turn, refers the local DNS server to query 965 the DNS server for External.com. This referal transits the NAT 966 enroute to the local DNS server. NAT would simply translate 967 the IP and UDP headers of the incoming packet to reflect DNS 968 server's private address. 970 DNS_ALG will request NAT for an assigned private address for 971 the referral server and replace the external address with its 972 assigned private address in the payload. 974 4. Private.com DNS server will now send the query to the DNS server 975 for external.com, using its assigned private address, via NAT. 976 This time, NAT would change the IP and UDP headers to reflect the 977 External addresses of the DNS servers. I.e., Private.com DNS 978 server's IP address is changed to its assigned external address 979 and External.Com DNS server's assigned Private address is 980 changed to its external address. 982 DNS_ALG will make no changes to the payload. 984 5. The DNS server for external.com replies with the IP address 985 171.68.10.1. This reply also transits the NAT. NAT would 986 once again translate the IP and UDP headers of the incoming 987 to reflect the private addresses of the DNS servers. 988 I.e., Private.com DNS server's IP address is changed to its 989 private address and External.Com DNS server's external 990 address is changed to its assigned Private address. 992 DNS_ALG will request NAT to (a) set up a temporary binding for 993 Host X (171.68.10.1) with a private address and (b) initiate 994 Bind-holdout timer. When NAT successfully sets up temporary 995 binding with a private address (say, 10.0.0.254), DNS_ALG would 996 modify the payload to replace X's external address with its 997 assigned private address and set the Cache timeout to 0. 999 6. The DNS server in Private.com replies to host A. 1001 When Host A finds the address of Host X, A initiates a session with 1002 host X, using a destination IP address of 10.0.0.254. This datagram 1003 and any others that follow in this session will be translated as 1004 usual by Twice NAT. 1006 Note, the DNS_ALG has had to change payload in both directions. 1008 6.2. Reverse name lookups originated from private domain 1010 This scenario builds on the previous case by having host A in 1011 Private.com perform a reverse name lookup on 10.0.0.254, which 1012 is host X's assigned private address. Following is a sequence 1013 of events. 1015 1. Host A sends a UDP based inverse name lookup query (PTR record) 1016 for "254.0.0.10.IN-ADDR.ARPA." to its local DNS server. 1018 2. Local DNS server sends the query to the root server enroute 1019 NAT. As before, NAT would change the IP and UDP headers to 1020 reflect DNS server's statically assigned external address. 1022 DNS_ALG will translate the private assigned address 10.0.0.254 1023 with its external address 171.68.10.1. 1025 3. The root server, in turn, refers the local DNS server to query 1026 the DNS server for External.com. This referal transits the NAT 1027 enroute to the local DNS server. NAT would simply translate 1028 the IP and UDP headers of the incoming packet to reflect DNS 1029 server's private address. 1031 As with the original query, DNS_ALG will translate the private 1032 assigned address 10.0.0.254 with its external address 1033 171.68.10.1. In addition, DNS_ALG will replace the external 1034 address of the referal server (i.e., the DNS server for 1035 External.com) with its assigned private address in the payload. 1037 4. Private.com DNS server will now send the query to the DNS server 1038 for external.com, using its statically assigned private address, 1039 via NAT. This time, NAT would change the IP and UDP headers to 1040 reflect the External addresses of the DNS servers. I.e., 1041 Private.com DNS server's IP address is changed to its assigned 1042 external address and External.Com DNS server's assigned Private 1043 address is changed to its external address. 1045 As with the original query, DNS_ALG will translate the private 1046 assigned address 10.0.0.254 with its external address 1047 171.68.10.1. 1049 5. The DNS server for external.com replies with the FQDN of 1050 "X.External.Com.". This reply also transits the NAT. NAT would 1051 once again translate the IP and UDP headers of the incoming 1052 to reflect the private addresses of the DNS servers. 1053 I.e., Private.com DNS server's IP address is changed to its 1054 private address and External.Com DNS server's external 1055 address is changed to its assigned Private address. 1057 Once again, DNS_ALG will translate the query section, replacing 1058 the external address 171.68.10.1 with its assigned private 1059 address of 10.0.0.254 1061 6. The DNS server in Private.com replies to host A. 1063 Note, the DNS_ALG has had to change payload in both directions. 1065 6.3. Incoming Name-lookup queries 1067 This time, host X in external.com wishes to initiate a session with 1068 host A in Private.com. Below are the sequence of events that take 1069 place. 1071 1. Host X sends a UDP based name lookup query (A record) for 1072 "A.Private.com" to its local DNS server. 1074 2. Local DNS server in External.com sends the query to root server. 1076 3. The root server, in turn, refers the DNS server in External.com 1077 to query the DNS server for private.com, 1079 4. External.com DNS server will now send the query to the DNS server 1080 for Private.com. This query traverses the NAT router. NAT would 1081 change the IP and UDP headers to reflect the private addresses of 1082 the DNS servers. I.e., Private.com DNS server's IP address is 1083 changed to its private address and External.Com DNS server's 1084 external address is changed to assigned Private address. 1086 DNS_ALG will make no changes to the payload. 1088 5. The DNS server for Private.com replies with the IP address 1089 171.68.1.10 for host A. This reply also transits the NAT. NAT 1090 would once again translate the IP and UDP headers of the incoming 1091 to reflect the external addresses of the DNS servers. I.e., 1092 Private.com DNS server's IP address is changed to its 1093 assigned external address and External.Com DNS server's 1094 assigned private address is changed to its external address. 1096 DNS_ALG will request NAT to (a) set up temporary binding for 1097 Host A (171.68.1.10) with an external address and (b) initiate 1098 Bind-holdout timer. When NAT succeeds in finding an external 1099 address (say, 131.108.1.12) to temporarily bind to host A, 1100 DNS_ALG would modify the payload to replace A's private address 1101 with its external assigned address and set the Cache timeout to 0. 1103 6. The server in External.com replies to host X 1105 When Host X finds the address of Host A, X initiates a session with 1106 A, using a destination IP address of 131.108.1.12. This datagram and 1107 any others that follow in this session will be translated as usual 1108 by the NAT. 1110 Note, DNS_ALG changes only the response packets from the DNS server 1111 for Private domain. 1113 6.4. Reverse name lookups originated from external domain 1115 This scenario builds on the previous case (section 6.3) by having 1116 host X in External.com perform a reverse name lookup on 131.108.1.12, 1117 which is host A's assigned external address. The following sequence 1118 of events take place. 1120 1. Host X sends a UDP based inverse name lookup query (PTR record) 1121 for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server. 1123 2. Local DNS server in External.com sends the query to the root 1124 server. 1126 3. The root server, in turn, refers the local DNS server to query 1127 the DNS server for Private.com. 1129 4. External.com DNS server will now send the query to the DNS server 1130 for Private.com. This query traverses the NAT router. NAT would 1131 change the IP and UDP headers to reflect the private addresses of 1132 the DNS servers. I.e., Private.com DNS server's IP address is 1133 changed to its private address and External.Com DNS server's 1134 external address is changed to assigned Private address. 1136 DNS_ALG will enquire NAT for the private address associated 1137 with the external address of 131.108.1.12 and modify the payload, 1138 replacing 131.108.1.12 with the private address of 171.68.1.10. 1140 5. The DNS server for Private.com replies with the host name 1141 of "A.Private.Com.". This reply also transits the NAT. NAT would 1142 once again translate the IP and UDP headers of the incoming 1143 to reflect the external addresses of the DNS servers. I.e., 1144 Private.com DNS server's IP address is changed to its 1145 assigned external address and External.Com DNS server's 1146 assigned private address is changed to its external address. 1148 Once again, DNS_ALG will enquire NAT for the assigned external 1149 address associated with the private address of 172.19.1.10 and 1150 modify the payload, replacing 171.68.1.10 with the assigned 1151 external address of 131.108.1.12. 1153 6. The DNS server in External.com replies to host X. 1155 Note, DNS_ALG changes the query as well as response packets from DNS 1156 server for Private domain. 1158 7. DNS-ALG limitations and Future Work 1160 NAT increases the probability of mis-addressing. For example, 1161 same local address may be bound to different public address at 1162 different times and vice versa. As a result, hosts that cache 1163 the name to address mapping for longer periods than the NAT 1164 router is configured to hold the map are likely to misaddress 1165 their sessions. Note, this is mainly an issue with bad host 1166 implementations that hold DNS records longer than the TTL 1167 in them allows and is not directly attributable to the 1168 mechanism described here. 1170 DNS_ALG cannot support secure DNS name servers in the private 1171 domain. I.e., Signed replies from an authoritative DNS name server 1172 in the DMZ to queries originating from the external world will be 1173 broken by the DNS-ALG. At best, DNS-ALG would be able to transform 1174 secure dnssec data into unprotected data. End-node demanding DNS 1175 replies to be signed may reject replies that have been tampered with 1176 by DNS_ALG. Since, the DNS server does not have a way to find 1177 where the queries come from (i.e., internal or external), it will 1178 most likely have to resort to the common denomination of today's 1179 insecure DNS. Both are serious limitations to DNS_ALG. Zone 1180 transfers between DNS-SEC servers is also impacted the same way, 1181 if the transfer crosses address realms. 1183 The good news, however, is that only end-nodes in DMZ pay the 1184 price for the above limitation in a traditional NAT (or, a 1185 bi-directional NAT), as external end-nodes may not access internal 1186 hosts due to DNS replies not being secure. However, for outgoing 1187 sessions (from private network) in a bi-directional NAT setup, 1188 the DNS queries can be signed and securely accepted by DMZ and 1189 other internal hosts since DNS_ALG does not intercept outgoing 1190 DNS queries and incoming replies. Lastly, zone transfers between 1191 DNS-SEC servers within the same private network are not impacted. 1193 Clearly, with DNS SEC deployment in DNS servers and end-host 1194 resolvers, the scheme suggested in this document will not work. 1196 8. Security considerations. 1198 If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG 1199 will fail because it won't be able to perform payload modifications. 1200 Alternately, if packets must be preserved in an address realm, 1201 DNS_ALG will need to hold the secret key to decrypt/verify payload 1202 before forwarding packets to a different realm. For example, if 1203 DNS-ALG, NAT and IPsec gateway (providing secure tunneling service) 1204 are resident on the same device, DNS-ALG will have access to the 1205 IPsec security association keys. The preceding section, "DNS-ALG 1206 limitations and Future Work" has coverage on DNS_ALG security 1207 considerations. 1209 Further, with DNS-ALG, there is a possibility of denial of service 1210 attack from a malicious user, as outlined in section 3.1. 1211 Section 3.1 suggests some ways to counter this attack. 1213 REFERENCES 1215 [1] P. Srisuresh, M. Holdrege, "The IP Network Address 1216 Translator (NAT) terminology and considerations", 1217 - Work in progress. 1219 [2] K. Egevang, P. Francis, "The IP Network Address Translator 1220 (NAT)", RFC 1631. 1222 [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, 1223 Lear, E. "Address Allocation for Private Internets", RFC 1918 1225 [4] P. Mockapetris, "Domain Names - Concepts and facilities", 1226 RFC 1034. 1228 [5] P. Mockapetris, "Domain Names - Implementation and 1229 Specification", RFC 1035. 1231 [6] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700. 1233 [7] R. Braden, "Requirements for Internet Hosts -- Communication 1234 Layers", RFC 1122. 1236 [8] R. Braden, "Requirements for Internet Hosts -- Application 1237 and Support", RFC 1123. 1239 [9] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812. 1241 [10] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address 1242 Behaviour Today", RFC 2101. 1244 [11] Donald E. Eastlake, "Domain Name System Security Extensions", 1245 RFC 2535 1247 [12] P. Vixie, S. Thompson, Y. Rekhter and J. Bound, "Dynamic 1248 Updates in the Domain Name System (DNS UPDATE)", RFC 2136 1250 [13] D. Eastlake, "Secure Domain Name System Dynamic Update", 1251 RFC 2137 1253 [14] R. Elz and R. Bush, "Clarifications to the DNS 1254 specification", RFC 2181 1256 [15] R. Elz, R. Bush, S. Bradner and M. Patton, "Selection and 1257 Operation of Secondary DNS Servers", RFC 2182 1259 Authors' Addresses 1261 Pyda Srisuresh 1262 Lucent technologies 1263 Pleasanton, CA 94588-8519 1264 U.S.A. 1266 Phone: +1 (925) 737-2153 1267 Fax: +1 (925) 737-2110 1268 e-mail: suresh@ra.lucent.com 1269 George Tsirtsis 1270 Internet Transport Group 1271 B29 Room 129 1272 BT Laboratories 1273 Martlesham Heath 1274 IPSWICH 1275 Suffolk IP5 3RE 1276 England 1278 Phone: +44 1473 640756 1279 Fax: +44 1473 640709 1280 e-mail: george@gideon.bt.co.uk 1282 Praveen Akkiraju 1283 cisco Systems 1284 170 West Tasman Drive 1285 San Jose, CA 95134 USA 1287 Phone: +1 (408) 526-5066 1288 e-mail: spa@cisco.com 1290 Andy Heffernan 1291 Juniper Networks, Inc. 1292 385 Ravensdale Drive. 1293 Mountain View, CA 94043 USA 1295 Phone: +1 (650) 526-8037 1296 Fax: +1 (650) 526-8001 1297 e-mail: ahh@juniper.net