idnits 2.17.1 draft-ietf-nat-dns-alg-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. 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 33 instances of lines with control characters in the document. == 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 330 has weird spacing: '... In order ...' == Line 332 has weird spacing: '.... This reque...' == Line 335 has weird spacing: '... lookup for t...' == Line 336 has weird spacing: '...through its ...' == Line 337 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 (October 1998) is 9325 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 90 -- Looks like a reference, but probably isn't: 'Ref 4' on line 419 -- Looks like a reference, but probably isn't: 'Ref 1' on line 92 == Unused Reference: '1' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1177, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1183, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1194, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1197, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1202, 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 2065 (ref. '11') (Obsoleted by RFC 2535) Summary: 12 errors (**), 0 flaws (~~), 19 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NAT Working Group P. Srisuresh, Lucent Technologies 3 INTERNET-DRAFT G. Tsirtsis, BT Laboratories 4 Category: Informational P. Akkiraju, Cisco Systems 5 Expire in six months A. Heffernan, Juniper Networks 6 October 1998 8 DNS extensions to Network Address Translators (DNS_ALG) 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 Abstract 34 Domain Name Service(DNS) provides name to address mapping within 35 a routing class (ex: IP). Network Address Translators (NATs) 36 provide transparent routing between hosts in disparate routing 37 realms of the same routing class. Typically, NATs exist at the 38 border of a stub domain, hiding private addresses from external 39 addresses. This document identifies the need for DNS extensions 40 to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) 41 can meet the need. DNS_ALG modifies payload transparently to alter 42 address mapping of hosts as DNS packets cross one routing realm 43 into another. The document also illustrates the operation of 44 DNS_ALG with specific examples. 46 1. Introduction 48 Network Address Translators (NATs) are often used when network's 49 internal IP addresses cannot be used outside the network either 50 for privacy reasons or because they are invalid for use outside 51 the network. 53 Ideally speaking, a host name uniquely identifies a host and its 54 address is used to locate routes to the host. However, host name 55 and address are often not distinguished and used interchangeably 56 by applications. Applications embed IP address instead of host 57 name in payload. Examples would be e-mails that specify their MX 58 server address instead of server name as sender ID; HTML files 59 that include IP address instead of names in URLs, etc. Use of IP 60 address in place of host name in payload represents a problem as 61 the packet traverses a NAT device because NATs alter network and 62 transport headers to suit a routing realm, but not payload. 64 DNS provides Name to address mapping. Whereas, NAT performs 65 address translation (in network and transport headers) in 66 datagrams traversing between private and external routing realms. 67 DNS Application Level Gateway (DNS_ALG) outlined in this document 68 helps translate Name-to-Private-Address mapping in DNS payloads 69 into Name-to-external-address mapping and vice versa using state 70 information available on NAT. 72 A Network Address Port Translator (NAPT) performs address and 73 Transport level port translations (i.e, TCP, UDP ports and ICMP 74 query IDs). DNS name mapping granularity, however, is limited to 75 IP addresses and does not extend to transport level identifiers. 76 As a result, the DNS_ALG processing for an NAPT configuration is 77 simplified in that all host addresses in private network are 78 bound to a single external address. The DNS name lookup for 79 private hosts (from external hosts) do not mandate fresh 80 private-external address binding, as all private hosts are bound 81 to a single pre-defined external address. However, reverse name 82 lookups for the NAPT external address will not map to any of 83 the private hosts and will simply map to the NAPT router. 84 Suffices to say, the processing requirements for a DNS_ALG 85 supporting NAPT configuration are a mere subset of Basic NAT. 86 Hence, the discussion in the remainder of the document will focus 87 mainly on Basic NAT, Bi-directional NAT and Twice NAT 88 configurations, with no specific reference to NAPT setup. 90 Definitions for DNS and related terms may be found in [Ref 3] and 91 [Ref 4]. Definitions for NAT and related terms may be found in 92 [Ref 1]. 94 2. Requirement for DNS extensions. 96 There are many ways to ensure that a host name is mapped to an 97 address relevant within a routing realm. In the following 98 sections, we will identify where DNS extensions would be needed. 100 Typically, organizations have two types of authoritative name 101 servers. Internal authoritative name servers identify all (or 102 majority of) corporate resources within the organization. Only a 103 portion of these hosts are allowed to be accessed by the external 104 world. The remaining hosts and their names are unique to the 105 private network. Hosts visible to the external world and the 106 authoritative name server that maps their names to network 107 addresses are often configured within a DMZ (De-Militarized Zone) 108 in front of a firewall. We will refer the hosts and name servers 109 within DMZ as DMZ hosts and DMZ name servers respectively. DMZ 110 host names are end-to-end unique. The figure below illustrates 111 configuration of a private network which includes a DMZ. Actual 112 configurations may vary. 114 \ | / 115 +-----------------------+ 116 |Service Provider Router| 117 +-----------------------+ 118 WAN | 119 | 120 Stub A .........|\|.... 121 | 122 | 123 +-----------------+ 124 |Stub Router w/NAT| 125 +-----------------+ 126 | 127 | DMZ - Network 128 ------------------------------------------------------------ 129 | | | | | 130 +--+ +--+ +--+ +--+ +----------+ 131 |__| |__| |__| |__| | Firewall | 132 /____\ /____\ /____\ /____\ +----------+ 133 DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web | 134 Server Server etc. | 135 | 136 Internal hosts (Private IP network) | 137 ------------------------------------------------------------ 138 | | | | 139 +--+ +--+ +--+ +--+ 140 |__| |__| |__| |__| 141 /____\ /____\ /____\ /____\ 143 Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server 145 Figure 1: DMZ network configuration of a private Network. 147 Internal name servers are accessed by users within private network 148 only. Internal DNS queries and responses do not cross the private 149 routing boundary. DMZ name servers and DMZ hosts on the other hand 150 are end-to-end unique and could be accessed by external as well as 151 internal hosts. Throughout this document, our focus will be limited 152 to DMZ hosts and DMZ name servers and will not include internal 153 hosts and internal name servers, unless they happen to be same. 155 2.1. DMZ hosts assigned static external addresses 157 Take the case where DMZ hosts are assigned static external 158 addresses. These hosts must be identified by their private 159 addresses within private domain and by their public addresses 160 in the external domain. 162 2.1.1. Private networks with no DMZ name servers 164 Take the case where a private network has no DMZ name server 165 for itself. If the private network is connected to a single service 166 provider for external connectivity, the DMZ hosts may be listed 167 by their external addresses in the authoritative name servers of 168 the service provider itself. 170 If the network is connected to multiple service providers, the 171 DMZ host names may be listed by their external address(es) within 172 the authoritative name servers of each of the service providers, 173 especially if the private network is assigned different address 174 prefixes by the service providers. 176 In both cases, externally generated DNS lookups will not reach the 177 private network. A large number of NAT based private domains 178 pursue this option to have their DMZ hosts listed by their 179 external addresses on service provider's name servers. 181 2.1.2. Private networks with DMZ name servers 183 Take the case where a private network opts to keep an authoritative 184 DMZ name server for the zone within the network itself. If the 185 network is connected to a single service provider, DMZ name server 186 be configured to obviate DNS payload interceptions as follows. The 187 hosts in DMZ name server must be mapped to their statically assigned 188 external addresses and the internal name server must be configured 189 to bypass the DMZ name server for queries concerning external hosts. 191 This scheme ensures that DMZ name servers are set for exclusive 192 access to external hosts alone (not even to the DMZ hosts) and hence 193 can be configured with external addresses only. 195 The above scheme fails to scale when the private network is 196 connected to multiple service providers, assigning different 197 network addresses to the DMZ hosts. DNS extensions to NAT 198 would prove useful here. It is conceivable, however, to 199 have a separate pair of DMZ servers (primary and secondary) 200 configured for each network address prefix assigned by a 201 service provider for the organization. 203 2.2. DMZ hosts assigned external addresses dynamically 205 Take the case where DMZ hosts in a private network are assigned 206 external addresses dynamically by NAT. While the addresses issued 207 to these hosts are fixed within the private network, their 208 externally known addresses are ephemeral, as determined by NAT. 209 In such a scenario, it is mandatory for the private organization 210 to have a DMZ name server in order to allow access to DMZ hosts 211 by their name. 213 The DMZ name server would be configured with private addresses 214 for DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing 215 on NAT device will intercept the DNS packets directed to or from 216 the DMZ name server(s) and perform transparent payload translations 217 so that a DMZ host name has the right address mapping within 218 each routing boundary (i.e., private or external). 220 3. Interactions between NAT and DNS_ALG 222 This document operates on the paradigm that interconnecting routing 223 realms may have overlapping address space. But, names of hosts 224 within interconnected realms must be end-to-end unique in order for 225 them to be accessed by all hosts. The following diagram illustrates 226 how a DNS packet traversing a NAT device (with DNS_ALG) is subject 227 to header and payload translations. NAT would translate the IP and 228 TCP/UDP headers of the DNS packet and notify DNS-ALG to perform DNS 229 payload changes. DNS-ALG would interact with NAT and use NAT state 230 information to modify payload, as necessary. 232 Original-IP 233 packet 234 || 235 || 236 vv 237 +---------------------------------+ +-----------------------+ 238 | | |DNS Appl. Level Gateway| 239 |Network Address Translation (NAT)|--->| (DNS_ALG) | 240 | -IP & Transport header mods |<---| -DNS payload mods | 241 | | | | 242 +---------------------------------+ +-----------------------+ 243 || 244 || 245 vv 246 Translated-IP 247 packet 249 Figure 2: NAT & DNS-ALG in the translation path of DNS packets 251 3.1. Address Binding considerations 253 We will make a distinction between "Temporary Address Binding" and 254 "Committed Address Binding" in NATs. This distinction becomes 255 necessary because the DNS_ALG will allow external users to create 256 state on NAT, and thus the potential for denial-of-service attacks. 257 Temporary address binding is the phase in which an address binding 258 is reserved without any NAT sessions using the binding. Committed 259 address binding is the phase in which there exists at least one 260 NAT session using the binding between the external and private 261 addresses. Both types of bindings are used by DNS_ALG to modify 262 DNS payloads. NAT uses only the committed address bindings to 263 modify the IP and Transport headers of datagrams pertaining to 264 NAT sessions. 266 For statically mapped addresses, the above disctinction is not 267 relevant. For dynamically mapped addresses, temporary address 268 binding often precedes committed binding. Temporary binding occurs 269 when DMZ name server is queried for a name lookup. Name query is 270 likely a pre-cursor to a real session between query originator 271 and the queried host. The temporary binding becomes committed only 272 when NAT sees the first packet of a session between query initiator 273 and queried host. 275 A "Bind-holdout time" may be defined for dynamic address assignments 276 as the maximum period of time for which a temporary address binding 277 is held active without transitioning into a committed binding. With 278 each use of temporary binding by DNS_ALG (to modify DNS payload), 279 this Bind-holdout period is renewed. Note, it is possible for a 280 committed address binding to occur without ever having to be 281 preceded by a temporary binding. Lastly, when NAT is ready to unbind 282 a committed address binding, the binding is transitioned into a 283 temporary binding and kept in that phase for an additional 284 Bind-holdout period. The binding is freed only upon expiry of 285 Bind-holdout time. The Bind-holdout time preceding the 286 committed-address-binding and the address-unbinding are required to 287 ensure that end hosts have sufficient time in which to initiate a 288 data session subsequent to a name lookup. 290 For example, say a private network with address prefix 10/8 is 291 mapped to 198.76.29/24. When an external hosts makes a DNS query 292 to host7, bearing address 10.0.0.7, the DMZ name server within 293 private network responds with an A type RR for host7 as: 295 host7 A 10.0.0.7 297 DNS_ALG would intercept the response packet and if 10.0.0.7 is not 298 assigned an external address already, it would request NAT to create 299 a temporary address binding with an external address and start 300 Bind-holdout timer to age the binding. Say, the assigned external 301 address is 198.76.29.1. DNS-ALG would use this temporary binding to 302 modify the RR in DNS response, replacing 10.0.0.7 with its external 303 address and reply with: 305 host7 A 198.76.29.1 307 When query initiator receives DNS response, only the assigned 308 external address is seen. Within a short period (presumably before 309 the bind-holdout time expires), the query initiator would 310 initiate a session with host7. When NAT notices the start of new 311 session directed to 198.76.29.1, NAT would terminate 312 Bind-holdout timer and transition the temporary binding between 313 198.76.29.1 and 10.0.0.7 into a committed binding. 315 To minimize denial of service attacks, where a malicious user 316 keeps attempting name resolutions, without ever initiating a 317 connection, NAT would have to monitor temporary address bindings 318 that have not transitioned into committed bindings. There could 319 be a limit on the number of temporary bindings and attempts to 320 generate additional temporary bindings could be simply rejected. 321 There may be other heuristic solutions to counter this type 322 of malicious attacks. 324 We will consider bi-directional NAT to illustrate the use of 325 temporary binding by DNS_ALG in the following sub-sections, even 326 though the concept is applicable to other flavors of NATs as well. 328 3.2. Incoming queries 330 In order to initiate incoming sessions, an external host obtains 331 the V4 address of the DMZ-host it is trying to connect to by making 332 a DNS request. This request constitutes prelude to the start of 333 a potential new session. 335 The external host resolver makes a name lookup for the DMZ host 336 through its DNS server. When the DNS server does not have a 337 record of IPv4 address attached to this name, the lookup query 338 is redirected at some point to the the Primary/Backup DNS server 339 (i.e., in DMZ) of the private stub domain. 341 Enroute to DMZ name server, DNS_ALG would intercept the datagram 342 and modify the query as follows. 344 a) For Host name to Host address query requests: 345 Make no change to the DNS payload. 347 b) For Host address to Host name queries: 348 Replace the external V4 address octets (in reverse order) 349 preceding the string "IN-ADDR.ARPA" with the corresponding 350 private V4 address, if such an address binding exists 351 already. However, if a binding does not exist, the DNS_ALG 352 would simply respond (as a name server would) with a 353 response code (RCODE) of 5 (REFUSED to respond due to policy 354 reasons) and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the 355 header section of the response. 357 In the opposite direction, as DNS response traverses from the 358 DNS server in private network, DNS_ALG would once again intercept 359 the packet and modify as follows. 361 a) For a host name to host address query requests, replace the 362 private address sent by DMZ name server with a public 363 address internally assigned by the NAT router. If a public 364 address is not previously assigned to the host's private 365 address, NAT would assign one at this time. 367 b) For host address to host name queries, replace the private 368 address octets preceding the string "IN-ADDR.ARPA" in 369 response RRs with their external address assignments. 370 There is a chance here that by the time the DMZ name server 371 replies, the bind-holdout timer in NAT for the address in 372 question has expired. In such a case, DNS_ALG would simply 373 drop the reply. The sender will have to resend the query 374 (as would happen when a router enroute drops the response). 376 For static address assignments, the TTL value supplied in the 377 original RR will be left unchanged. For dynamic address assignments, 378 DNS_ALG would modify the TTL value on DNS resource records (RRs) to 379 be 1, implying that the RRs should only be used for transaction in 380 progress, and not be cached. Note, TTL of 1 instead of 0 is 381 selected to indicate non-caching because, some older DNS 382 implementations interpret 0 to mean "forever", instead of 383 "no caching". 385 In addition, NAT would be requested to initiate a bind-holdout timer 386 following the assignment. If no session is initiated to the private 387 host within the Bind-holdout time period, NAT would terminate the 388 temporary binding. 390 3.3. Outgoing Queries 392 For Basic and bi-directional NATs, there is no need to distinguish 393 between temporary and committed bindings for outgoing queries. This 394 is because, DNS_ALG does not modify the DNS packets directed to or 395 from external name servers (used during outbound sessions), unlike 396 the inbound DNS sessions. 398 Say, a private host needs to communicate with an external host. 399 The DNS query goes to the internal name server (if there 400 exists one) and from there to the appropriate authoritative/cache 401 name server outside the private domain. The reply follows the 402 same route but neither the query nor the response are subject to 403 DNS_ALG translations. 405 This however will not be the case with address isolated twice NAT 406 private and external domains. In such a case, NAT would intercept 407 all DNS packets and make address modifications to payload as 408 discussed in the previous section. Temporary Private to external 409 address bindings are created when responses are sent by private DNS 410 servers and temporary external to private address bindings are 411 created when responses are sent by external DNS servers. 413 4. DNS payload modifications by DNS-ALG 415 Typically, UDP is employed as the transport mechanism for DNS 416 queries and responses and TCP for Zone refresh activities. In 417 either case, name servers are accessed using a well-known DNS 418 server port 53 (decimal) and all DNS payloads have the following 419 format of data [Ref 4]. The header section is always present and 420 includes fields specifying which of the remaining sections are 421 present. The header identifies if the message is a query or a 422 response. No changes are required to be made by NATs to the 423 Header section. DNS_ALG would parse only the DNS payloads whose 424 QCLASS is set to IN (IP class). 426 +---------------------+ 427 | Header | 428 +---------------------+ 429 | Question | the question for the name server 430 +---------------------+ 431 | Answer | RRs answering the question 432 +---------------------+ 433 | Authority | RRs pointing toward an authority 434 +---------------------+ 435 | Additional | RRs holding additional information 436 +---------------------+ 438 4.1. Question section 440 The question section contains QDCOUNT (usually 1) entries, as 441 specified in Header section, with each of the entries in the 442 following format: 444 1 1 1 1 1 1 445 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 446 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 447 | | 448 / QNAME / 449 / / 450 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 451 | QTYPE | 452 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 453 | QCLASS | 454 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 456 4.1.1. PTR type Queries 458 DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified 459 Domain Names) fall within IN-ADDR.ARPA domain and replace the 460 address octets (in reverse order) preceding the string 461 "IN-ADDR.ARPA" with the corresponding assigned address octets 462 in reverse order, only if the address binding is active on 463 the NAT router. If the address preceding the string 464 "IN-ADDR.ARPA" falls within the NAT address map, but does not 465 have at least a temporary address binding, DNS_ALG would simply 466 simply respond back (as a DNS name server would) with a response 467 code (RCODE) of 5 (REFUSED to respond due to policy reasons) 468 and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section 469 of the response. 471 Note that the above form of host address to host name type queries 472 will likely yield different results at different times, depending 473 upon address bind status in NAT at a given time. 475 For example, a resolver that wanted to find out the hostname 476 corresponding to address 198.76.29.1 (externally) would pursue a 477 query of the form: 478 QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA. 480 DNS_ALG would intervene and if the address 198.76.29.1 is 481 internally mapped to a private address of 10.0.0.1, modify the 482 query as below and forward to DMZ name server within private 483 network. 485 QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA 487 Presumably, the DMZ name server is the authoritative name server 488 for 10.IN-ADDR.ARPA zone and will respond with an RR of the 489 following form in answer section. DNS_ALG translations of the 490 response RRs will be considered in a following section. 492 1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_domain 494 Inverse translation is a fairly popular technique used by e-mail 495 programs to trace e-mail originating hosts and prevent spam. 496 ex: verify if the address from which the e-mail was sent does 497 indeed belong to the same domain name the sender claims as 498 sender ID. There may be other applications. 500 Query modifications of this nature will likely change the length 501 of DNS payload. As a result, the corresponding IP and TCP/UDP 502 header checksums must be updated. In case of TCP based queries, 503 the sequence number deltas must be tracked by NAT so that the 504 delta can be applied to subsequent sequence numbers in datagrams 505 in the same direction and acknowledgement numbers in datagrams in 506 the opposite direction. In case of UDP based queries, message 507 sizes are restricted to 512 bytes (not counting the IP or UDP 508 headers). Longer messages must be truncated and the TC bit should 509 be set in the header. 511 Lastly, any compressed domain names using pointers to represent 512 common domain denominations must be updated to reflect new 513 pointers with the right offset, if the original domain name had 514 to be translated by NAT. 516 4.1.2. A, MX, NS and SOA type Queries 518 For these queries, DNS_ALG would not modify any of the fields in 519 the query section, not even the name field. 521 4.1.3. AXFR type Queries 522 AXFR is a special zone transfer type query. Zone transfers from 523 private routing realm must be avoided for address assignments 524 that are not static. Typically, TCP is used for AXFR requests. 526 When changes are made to a zone, they must be distributed to all 527 name servers. The general model of automatic zone transfer or 528 refreshing is that one of the name servers is the master or 529 primary for the zone. Changes are coordinated at the primary, 530 typically by editing a master file for the zone. After editing, 531 the administrator signals the master server to load the new zone. 532 The other non-master or secondary servers for the zone 533 periodically check the SERIAL field of the SOA for the zone for 534 changes (at some polling intervals) and obtain new zone copies 535 when changes have been made. 537 Zone transfer is usually from primary to backup name servers. In 538 the case of NAT supported private networks, both primary and 539 backup servers will likely be in the same private domain. 540 In such a case, zone transfer does not cross the realm and 541 DNS_ALG support for zone transfer is not an issue. In the case a 542 secondary name server is located outside the premisis of private 543 network, zone transfers must not be permitted for non-static 544 address assignments. 546 During zone transfers, DNS_ALG must examine all A type records 547 and replace the original address octets with their statically 548 assigned address octets. DNS_ALG could also examine if there is 549 an attempt to transfer records for hosts that are not assigned 550 static addresses and drop those records alone or drop the whole 551 transfer. This would minimize misconfiguration and human errors. 553 4.2. Resource records in all other sections 555 The answer, authority, and additional sections all share the same 556 format, with a variable number of resource records. The number of 557 RRs specific to each of the sections may be found in the 558 corresponding count fields in DNS header. Each resource record 559 has the following format: 561 1 1 1 1 1 1 562 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 563 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 564 | | 565 / / 566 / NAME / 567 | | 568 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 569 | TYPE | 570 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 571 | CLASS | 572 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 573 | TTL | 574 | | 575 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 576 | RDLENGTH | 577 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 578 / RDATA / 579 / / 580 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 582 The TTL value supplied in the original RRs is left unchanged For 583 static address assignments. For dynamic address assignments, 584 DNS_ALG would modify the TTL to be 0, so the RRs are used just 585 for the transaction in progress, and not cached. Note, TTL of 1 586 instead of 0 is selected to indicate non-caching because, some 587 older DNS implementations interpret 0 to mean "forever", instead 588 of "no caching". 590 4.2.1. PTR type RRs 592 The considerations specified in the Question section 593 is equally valid with names for PTR type RRs. Private address 594 preceding the string "IN-ADDR.ARPA" (in reverse order of 595 octets) must be replaced by its external address assignment 596 (in reverse order), if a binding exists. The remaining fields 597 for this RR remain unchanged. 599 4.2.2. A type RRs 601 The RDATA for A records is a 4-byte IP address. DNS_ALG would 602 simply replace the original address in RDATA with its externally 603 assigned IP address, if it succeeded in finding an address 604 binding. Successful address translation should cause no 605 changes to payload length. Only the transport header checksum 606 would need updating. In case of failure to find an address 607 binding, DNS_ALG would have to drop the record and decrement 608 the corresponding COUNT field in the header section. 610 4.2.3. CNAME, MX, NS and SOA type RRs 612 No changes required to be made by DNS_ALG for these RRs, as the 613 RDATA does not contain any IP addresses. The host names within 614 the RDATA remain unchanged between realms. 616 5. Illustration of DNS_ALG in conjunction with Bi-directional NAT 618 The following diagram illustrates the operation of DNS_ALG in a 619 a bi-directional NAT router. We will illustrate by walking 620 through how name lookup and reverse name lookup queries are 621 processed. 623 . 624 ________________ . External.com 625 ( ) . 626 ( ) . +-------------+ 627 +--+ ( Internet )-.---|Border Router| 628 |__|------ ( ) . +-------------+ 629 /____\ (________________) . | 630 Root | . | 631 DNS Server | . --------------- 632 +---------------+ . | | 633 |Provider Router| . +--+ +--+ 634 +---------------+ . |__| |__| 635 | . /____\ /____\ 636 | . DNS Server Host X 637 External domain | . 171.68.1.1 171.68.10.1 638 ............................|............................... 639 Private domain | 640 | Private.com 641 | 642 +--------------------------------------+ 643 |Bi-Directional NAT router with DNS_ALG| 644 | | 645 | Private addresses: 172.19/16 | 646 | External addresses: 131.108.1/24 | 647 +--------------------------------------+ 648 | | 649 ---------- ---------- 650 | | DNS Server 651 +--+ +--+ Authoritative 652 |__| |__| for private.com 653 /____\ /____\ 654 Host A DNS Server 655 172.19.1.10 172.19.2.1 656 (Mapped to 131.108.1.8) 658 Figure 3: DNS-ALG operation in Bi-Directional NAT setup 660 The above diagram depicts a scenario where a company private.com 661 using private address space 172.19/16 connects to the Internet 662 using bi-directional NAT. DNS_ALG is embedded in the NAT device 663 to make necessary DNS payload changes. NAT is configured to 664 translate the private addresses space into an external address 665 block of 131.108.1/24. NAT is also configured with a static 666 translation for private.com's DNS server, so it can be referred 667 in the external domain by a valid address. 669 The company external.com is located in the external domain, using 670 a registered address block of 171.68/16. Also shown in the 671 topology is a root DNS server. 673 Following simplifications are made to the above configuration: 675 * private.com is not multihomed and all traffic to the external 676 space transits a single NAT. 678 * The DNS server for private.com is authoritative for the 679 private.com domain and points to the root server for all 680 other DNS resolutions. The same is true for the DNS server 681 in external.com. 683 * The internal name servers for private.com and external.com 684 are same as their DMZ name servers. The DNS servers for these 685 domains are configured with addresses private to the 686 organization. 688 * The name resolvers on host nodes do not have recursion 689 available on them and desire recursive service from servers. 690 All name servers are assumed to be able to provide 691 recursive service. 693 5.1. Outgoing Name-lookup queries 695 Say, Host A in private.com needs to perform a name lookup for 696 host X in external.com to initiate a session with X. This would 697 proceed as follows. 699 1. Host A sends a UDP based name lookup query (A record) for 700 "X.External.Com" to its local DNS server. 702 2. Local DNS server sends the query to the root server enroute 703 NAT. NAT would change the IP and UDP headers to reflect DNS 704 server's statically assigned external address. DNS_ALG will 705 make no changes to the payload. 707 3. The root server, in turn, refers the local DNS server to query 708 the DNS server for External.com. This referal transits the NAT 709 enroute to the local DNS server. NAT would simply translate 710 the IP and UDP headers of the incoming packet to reflect DNS 711 server's private address. No changes to the payload by DNS_ALG. 713 4. Private.com DNS server will now send the query to the DNS server 714 for external.com, once again, enroute NAT. Just as with the query 715 to root, The NAT router would change the IP and UDP headers to 716 reflect the DNS server's statically assigned external address. 717 And, DNS_ALG will make no changes to the payload. 719 5. The DNS server for external.com replies with the IP address 720 171.68.10.1. This reply also transits the NAT. NAT would 721 translate the IP and UDP headers of the incoming packet to 722 reflect DNS server's private address. Once again, no changes 723 to the payload by DNS_ALG. 725 6. The DNS server in Private.com replies to host A. 727 When Host A finds the address of Host X, A initiates a session with 728 host X, using a destination IP address of 171.68.10.1. This datagram 729 and any others that follow in this session will be translated as 730 usual by NAT. 732 Note, DNS_ALG does not change the payload for DNS packets in 733 either direction. 735 5.2. Reverse name lookups originated from private domain 737 This scenario builds on the previous case by having host A in 738 Private.com perform a reverse name lookup on 171.68.10.1, which 739 is host X's global address. Following is a sequence of events. 741 1. Host A sends a UDP based inverse name lookup query (PTR record) 742 for "1.10.68.171.IN-ADDR.ARPA." to its local DNS server. 744 2. Local DNS server sends the query to the root server enroute 745 NAT. As before, NAT would change the IP and UDP headers to 746 reflect DNS server's statically assigned external address. 747 DNS_ALG will make no changes to the payload. 749 3. The root server, in turn, refers the local DNS server to query 750 the DNS server for External.com. This referal transits the NAT 751 enroute to the local DNS server. NAT would simply translate 752 the IP and UDP headers of the incoming packet to reflect DNS 753 server's private address. No changes to the payload by DNS_ALG. 755 4. Private.com DNS server will now send the query to the DNS server 756 for external.com, once again, enroute NAT. Just as with the query 757 to root, The NAT router would change the IP and UDP headers to 758 reflect the DNS server's statically assigned external address. 760 And, DNS_ALG will make no changes to the payload. 762 5. The DNS server for external.com replies with the host name 763 of "X.External.Com.". This reply also transits the NAT. NAT would 764 translate the IP and UDP headers of the incoming packet to 765 reflect DNS server's private address. Once again, no changes 766 to the payload by DNS_ALG. 768 6. The DNS server in Private.com replies to host A. 770 Note, DNS_ALG does not change the payload in either direction. 772 5.3. Incoming Name-lookup queries 774 This time, host X in external.com wishes to initiate a session with 775 host A in Private.com. Below are the sequence of events that take 776 place. 778 1. Host X sends a UDP based name lookup query (A record) for 779 "A.Private.com" to its local DNS server. 781 2. Local DNS server in External.com sends the query to root server. 783 3. The root server, in turn, refers the DNS server in External.com 784 to query the DNS server for private.com, 786 4. External.com DNS server will now send the query to the DNS server 787 for Private.com. This query traverses the NAT router. NAT would 788 change the IP and UDP headers of the packet to reflect the DNS 789 server's private address. DNS_ALG will make no changes to the 790 payload. 792 5. The DNS server for Private.com replies with the IP address 793 172.19.1.10 for host A. This reply also transits the NAT. NAT 794 would translate the IP and UDP headers of the outgoing packet 795 from the DNS server. 797 DNS_ALG will request NAT to (a) setup a temporary binding for i 798 Host A (172.19.1.10) with an external address and (b) initiate 799 Bind-holdout timer. When NAT successfully sets up a temporary 800 binding with an external address (say, 131.108.1.12), DNS_ALG 801 would modify the payload to replace A's private address with 802 its external assigned address and set the Cache timeout to 0. 804 6. The server in External.com replies to host X 806 When Host X finds the address of Host A, X initiates a session with 807 A, using a destination IP address of 131.108.1.12. This datagram and 808 any others that follow in this session will be translated as usual 809 by the NAT. 811 Note, DNS_ALG changes only the response packets from the DNS server 812 for Private domain. 814 5.4. Reverse name lookups originated from external domain 816 This scenario builds on the previous case (section 5.3) by having 817 host X in External.com perform a reverse name lookup on 131.108.1.12, 818 which is host A's assigned external address. The following sequence 819 of events take place. 821 1. Host X sends a UDP based inverse name lookup query (PTR record) 822 for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server. 824 2. Local DNS server in External.com sends the query to the root 825 server. 827 3. The root server, in turn, refers the local DNS server to query 828 the DNS server for Private.com. 830 4. External.com DNS server will now send the query to the DNS server 831 for Private.com. This query traverses the NAT router. NAT would 832 change the IP and UDP headers to reflect the DNS server's private 833 address. 835 DNS_ALG will enquire NAT for the private address associated 836 with the external address of 131.108.1.12 and modify the payload, 837 replacing 131.108.1.12 with the private address of 172.19.1.10. 839 5. The DNS server for Private.com replies with the host name 840 of "A.Private.Com.". This reply also transits the NAT. NAT would 841 translate the IP and UDP headers of the incoming packet to 842 reflect DNS server's private address. 844 Once again, DNS_ALG will enquire NAT for the assigned external 845 address associated with the private address of 172.19.1.10 and 846 modify the payload, replacing 172.19.1.10 with the assigned 847 external address of 131.108.1.12. 849 6. The DNS server in External.com replies to host X. 851 Note, DNS_ALG changes the query as well as response packets from DNS 852 server for Private domain. 854 6. Illustration of DNS_ALG in conjunction with Twice-NAT 856 The following diagram illustrates the operation of DNS_ALG in a 857 Twice NAT router. As before, we will illustrate by walking through 858 how name lookup and reverse name lookup queries are processed. 860 . 861 ________________ . External.com 862 ( ) . 863 ( ) . +-------------+ 864 +--+ ( Internet )-.---|Border Router| 865 |__|------ ( ) . +-------------+ 866 /____\ (________________) . | 867 Root | . | 868 DNS Server | . --------------- 869 +---------------+ . | | 870 |Provider Router| . +--+ +--+ 871 +---------------+ . |__| |__| 872 | . /____\ /____\ 873 | . DNS Server Host X 874 External domain | . 171.68.1.1 171.68.10.1 875 ............................|............................... 876 Private domain | 877 | Private.com 878 | 879 +-------------------------------------------+ 880 | Twice-NAT router with DNS_ALG | 881 | | 882 | Private addresses: 171.68/16 | 883 | Assigned External addresses: 131.108.1/24 | 884 | | 885 | External addresses: 171.68/16 | 886 | Assigned Private addresses: 10/8 | 887 +-------------------------------------------+ 888 | | 889 ---------- ---------- 890 | | DNS Server 891 +--+ +--+ Authoritative 892 |__| |__| for private.com 893 /____\ /____\ 894 Host A DNS Server 895 171.68.1.10 171.68.2.1 896 (Mapped to 131.108.1.8) 898 Figure 4: DNS-ALG operation in Twice-NAT setup 900 In this scenario, hosts in private.com were not numbered from the 901 RFC1918 reserved 172.19/16 space, but rather were numbered with the 902 globally-routable 171.68/16 network, the same as external.com. Not 903 only does private.com need translation service for its own host 904 addresses, but it also needs translation service if any of those 905 hosts are to be able to exchange datagrams with hosts in 906 external.com. Twice-NAT accommodates the transition by translating 907 the overlapping address space used in external.com with a unique 908 address block (10/8) from RFC1918 address space. Routes are set up 909 within the private domain to direct datagrams destined for the 910 address block 10/8 through Twice-NAT device to the external global 911 network space. 913 Simplifications and assumptions made in section 5.0 will be valid 914 here as well. 916 6.1. Outgoing Name-lookup queries 918 Say, Host A in private.com needs to perform a name lookup for 919 host X in external.com (host X has a FQDN of X.external.com), 920 to find its address. This would would proceed as follows. 922 1. Host A sends a UDP based name lookup query (A record) for 923 "X.External.Com" to its local DNS server. 925 2. Local DNS server sends the query to the root server enroute 926 NAT. NAT would change the IP and UDP headers to reflect DNS 927 server's statically assigned external address. DNS_ALG will 928 make no changes to the payload. 930 3. The root server, in turn, refers the local DNS server to query 931 the DNS server for External.com. This referal transits the NAT 932 enroute to the local DNS server. NAT would simply translate 933 the IP and UDP headers of the incoming packet to reflect DNS 934 server's private address. 936 DNS_ALG will request NAT for an assigned private address for 937 the referral server and replace the external address with its 938 assigned private address in the payload. 940 4. Private.com DNS server will now send the query to the DNS server 941 for external.com, using its assigned private address, via NAT. 942 This time, NAT would change the IP and UDP headers to reflect the 943 External addresses of the DNS servers. I.e., Private.com DNS 944 server's IP address is changed to its assigned external address 945 and External.Com DNS server's assigned Private address is 946 changed to its external address. 948 DNS_ALG will make no changes to the payload. 950 5. The DNS server for external.com replies with the IP address 951 171.68.10.1. This reply also transits the NAT. NAT would 952 once again translate the IP and UDP headers of the incoming 953 to reflect the private addresses of the DNS servers. 954 I.e., Private.com DNS server's IP address is changed to its 955 private address and External.Com DNS server's external 956 address is changed to its assigned Private address. 958 DNS_ALG will request NAT to (a) set up a temporary binding for 959 Host X (171.68.10.1) with a private address and (b) initiate 960 Bind-holdout timer. When NAT successfully sets up temporary 961 binding with a private address (say, 10.0.0.254), DNS_ALG would 962 modify the payload to replace X's external address with its 963 assigned private address and set the Cache timeout to 0. 965 6. The DNS server in Private.com replies to host A. 967 When Host A finds the address of Host X, A initiates a session with 968 host X, using a destination IP address of 10.0.0.254. This datagram 969 and any others that follow in this session will be translated as 970 usual by Twice NAT. 972 Note, the DNS_ALG has had to change payload in both directions. 974 6.2. Reverse name lookups originated from private domain 976 This scenario builds on the previous case by having host A in 977 Private.com perform a reverse name lookup on 10.0.0.254, which 978 is host X's assigned private address. Following is a sequence 979 of events. 981 1. Host A sends a UDP based inverse name lookup query (PTR record) 982 for "254.0.0.10.IN-ADDR.ARPA." to its local DNS server. 984 2. Local DNS server sends the query to the root server enroute 985 NAT. As before, NAT would change the IP and UDP headers to 986 reflect DNS server's statically assigned external address. 988 DNS_ALG will translate the private assigned address 10.0.0.254 989 with its external address 171.68.10.1. 991 3. The root server, in turn, refers the local DNS server to query 992 the DNS server for External.com. This referal transits the NAT 993 enroute to the local DNS server. NAT would simply translate 994 the IP and UDP headers of the incoming packet to reflect DNS 995 server's private address. 997 As with the original query, DNS_ALG will translate the private 998 assigned address 10.0.0.254 with its external address 999 171.68.10.1. In addition, DNS_ALG will replace the external 1000 address of the referal server (i.e., the DNS server for 1001 External.com) with its assigned private address in the payload. 1003 4. Private.com DNS server will now send the query to the DNS server 1004 for external.com, using its statically assigned private address, 1005 via NAT. This time, NAT would change the IP and UDP headers to 1006 reflect the External addresses of the DNS servers. I.e., 1007 Private.com DNS server's IP address is changed to its assigned 1008 external address and External.Com DNS server's assigned Private 1009 address is changed to its external address. 1011 As with the original query, DNS_ALG will translate the private 1012 assigned address 10.0.0.254 with its external address 1013 171.68.10.1. 1015 5. The DNS server for external.com replies with the FQDN of 1016 "X.External.Com.". This reply also transits the NAT. NAT would 1017 once again translate the IP and UDP headers of the incoming 1018 to reflect the private addresses of the DNS servers. 1019 I.e., Private.com DNS server's IP address is changed to its 1020 private address and External.Com DNS server's external 1021 address is changed to its assigned Private address. 1023 Once again, DNS_ALG will translate the query section, replacing 1024 the external address 171.68.10.1 with its assigned private 1025 address of 10.0.0.254 1027 6. The DNS server in Private.com replies to host A. 1029 Note, the DNS_ALG has had to change payload in both directions. 1031 6.3. Incoming Name-lookup queries 1033 This time, host X in external.com wishes to initiate a session with 1034 host A in Private.com. Below are the sequence of events that take 1035 place. 1037 1. Host X sends a UDP based name lookup query (A record) for 1038 "A.Private.com" to its local DNS server. 1040 2. Local DNS server in External.com sends the query to root server. 1042 3. The root server, in turn, refers the DNS server in External.com 1043 to query the DNS server for private.com, 1045 4. External.com DNS server will now send the query to the DNS server 1046 for Private.com. This query traverses the NAT router. NAT would 1047 change the IP and UDP headers to reflect the private addresses of 1048 the DNS servers. I.e., Private.com DNS server's IP address is 1049 changed to its private address and External.Com DNS server's 1050 external address is changed to assigned Private address. 1052 DNS_ALG will make no changes to the payload. 1054 5. The DNS server for Private.com replies with the IP address 1055 171.68.1.10 for host A. This reply also transits the NAT. NAT 1056 would once again translate the IP and UDP headers of the incoming 1057 to reflect the external addresses of the DNS servers. I.e., 1058 Private.com DNS server's IP address is changed to its 1059 assigned external address and External.Com DNS server's 1060 assigned private address is changed to its external address. 1062 DNS_ALG will request NAT to (a) set up temporary binding for 1063 Host A (171.68.1.10) with an external address and (b) initiate 1064 Bind-holdout timer. When NAT succeeds in finding an external 1065 address (say, 131.108.1.12) to temporarily bind to host A, 1066 DNS_ALG would modify the payload to replace A's private address 1067 with its external assigned address and set the Cache timeout to 0. 1069 6. The server in External.com replies to host X 1071 When Host X finds the address of Host A, X initiates a session with 1072 A, using a destination IP address of 131.108.1.12. This datagram and 1073 any others that follow in this session will be translated as usual 1074 by the NAT. 1076 Note, DNS_ALG changes only the response packets from the DNS server 1077 for Private domain. 1079 6.4. Reverse name lookups originated from external domain 1081 This scenario builds on the previous case (section 6.3) by having 1082 host X in External.com perform a reverse name lookup on 131.108.1.12, 1083 which is host A's assigned external address. The following sequence 1084 of events take place. 1086 1. Host X sends a UDP based inverse name lookup query (PTR record) 1087 for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server. 1089 2. Local DNS server in External.com sends the query to the root 1090 server. 1092 3. The root server, in turn, refers the local DNS server to query 1093 the DNS server for Private.com. 1095 4. External.com DNS server will now send the query to the DNS server 1096 for Private.com. This query traverses the NAT router. NAT would 1097 change the IP and UDP headers to reflect the private addresses of 1098 the DNS servers. I.e., Private.com DNS server's IP address is 1099 changed to its private address and External.Com DNS server's 1100 external address is changed to assigned Private address. 1102 DNS_ALG will enquire NAT for the private address associated 1103 with the external address of 131.108.1.12 and modify the payload, 1104 replacing 131.108.1.12 with the private address of 171.68.1.10. 1106 5. The DNS server for Private.com replies with the host name 1107 of "A.Private.Com.". This reply also transits the NAT. NAT would 1108 once again translate the IP and UDP headers of the incoming 1109 to reflect the external addresses of the DNS servers. I.e., 1110 Private.com DNS server's IP address is changed to its 1111 assigned external address and External.Com DNS server's 1112 assigned private address is changed to its external address. 1114 Once again, DNS_ALG will enquire NAT for the assigned external 1115 address associated with the private address of 172.19.1.10 and 1116 modify the payload, replacing 171.68.1.10 with the assigned 1117 external address of 131.108.1.12. 1119 6. The DNS server in External.com replies to host X. 1121 Note, DNS_ALG changes the query as well as response packets from DNS 1122 server for Private domain. 1124 7. DNS-ALG limitations and Future Work 1126 NAT increases the probability of mis-addressing. For example, 1127 same local address may be bound to different public address at 1128 different times and vice versa. As a result, hosts that cache 1129 the name to address mapping for longer periods than the NAT 1130 router is configured to hold the map are likely to misaddress 1131 their sessions. Note, this is mainly an issue with bad host 1132 implementations and is not directly attributable to the 1133 mechanism described here. 1135 DNS_ALG cannot support secure DNS name servers in the private 1136 domain. I.e., an authoritative DNS name server in the DMZ cannot 1137 sign replies to queries that originate from the external world. 1138 Since the DNS server does not have a way to find where the queries 1139 come from (i.e., internal or external), it will most likely have 1140 to resort to the common denomination of today's "insecure" DNS. 1141 Secondly, an end-node that demands DNS replies to be signed will 1142 reject replies that have been tampered with by DNS_ALG. Both are 1143 serious limitations to DNS_ALG. Zone transfers between DNS-SEC 1144 servers is also impacted the same way, if the transfer crosses 1145 routing realms. 1147 The good news, however, is that only end-nodes in DMZ pay the 1148 price for the above limitation in a traditional NAT (or, a 1149 bi-directional NAT), as external end-nodes may not access internal 1150 hosts due to DNS replies not being secure. However, for outgoing 1151 sessions (from private network) in a bi-directional NAT setup, 1152 the DNS queries can be signed and securely accepted by DMZ and 1153 other internal hosts since DNS_ALG does not intercept outgoing 1154 DNS queries and incoming replies. Lastly, zone transfers between 1155 DNS-SEC servers within the same private network are not impacted. 1157 Clearly, if DNS-SEC were to become the norm in DNS servers and 1158 end-host resolvers, the scheme suggested in this document will 1159 not work. 1161 8. Security considerations. 1163 DNS packets must not be encrypted in order for DNS_ALG to be able 1164 to perform payload modifications. Alternately, if packets must be 1165 encrypted in a routing realm, DNS_ALG will need to hold the 1166 secret key to decrypt payload before forwarding packets to a 1167 different realm. The preceding section, "DNS-ALG limitations and 1168 Future Work" has coverage on DNS_ALG security considerations. 1170 REFERENCES 1172 [1] P. Srisuresh, M. Holdrege, "The IP Network Address 1173 Translator (NAT) terminology and considerations", 1174 - Work in progress, 1175 October 1998 1177 [2] K. Egevang, P. Francis, "The IP Network Address Translator 1178 (NAT)", RFC 1631. 1180 [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, 1181 Lear, E. "Address Allocation for Private Internets", RFC 1918 1183 [4] P. Mockapetris, "Domain Names - Concepts and facilities", 1184 RFC 1034. 1186 [5] P. Mockapetris, "Domain Names - Implementation and 1187 Specification", RFC 1035. 1189 [6] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700. 1191 [7] R. Braden, "Requirements for Internet Hosts -- Communication 1192 Layers", RFC 1122. 1194 [8] R. Braden, "Requirements for Internet Hosts -- Application 1195 and Support", RFC 1123. 1197 [9] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812. 1199 [10] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address 1200 Behaviour Today", RFC 2101. 1202 [11] Donald E. Eastlake 3rd, Charles W. Kaufman, "Domain Name 1203 System Security Extensions", RFC 2065. 1205 Authors' Addresses 1207 Pyda Srisuresh 1208 Lucent technologies 1209 Pleasanton, CA 94588-8519 1210 U.S.A. 1212 Phone: +1 (925) 737-2153 1213 Fax: +1 (925) 737-2110 1214 e-mail: suresh@ra.lucent.com 1216 George Tsirtsis 1217 Internet Transport Group 1218 B29 Room 129 1219 BT Laboratories 1220 Martlesham Heath 1221 IPSWICH 1222 Suffolk IP5 3RE 1223 England 1225 Phone: +44 1473 640756 1226 Fax: +44 1473 640709 1227 e-mail: george@gideon.bt.co.uk 1229 Praveen Akkiraju 1230 cisco Systems 1231 170 West Tasman Drive 1232 San Jose, CA 95134 USA 1234 Phone: +1 (408) 526-5066 1235 e-mail: spa@cisco.com 1237 Andy Heffernan 1238 Juniper Networks, Inc. 1239 385 Ravensdale Drive. 1240 Mountain View, CA 94043 USA 1242 Phone: +1 (650) 526-8037 1243 Fax: +1 (650) 526-8001 1244 e-mail: ahh@juniper.net