1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627
|
Network Working Group P. Srisuresh
Request for Comments: 2694 Consultant
Category: Informational G. Tsirtsis
BT Laboratories
P. Akkiraju
Cisco Systems
A. Heffernan
Juniper Networks
September 1999
DNS extensions to Network Address Translators (DNS_ALG)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
Domain Name Service (DNS) provides name to address mapping within a
routing class (ex: IP). Network Address Translators (NATs) attempt to
provide transparent routing between hosts in disparate address realms
of the same routing class. Typically, NATs exist at the border of a
stub domain, hiding private addresses from external addresses. This
document identifies the need for DNS extensions to NATs and outlines
how a DNS Application Level Gateway (DNS_ALG) can meet the need.
DNS_ALG modifies payload transparently to alter address mapping of
hosts as DNS packets cross one address realm into another. The
document also illustrates the operation of DNS_ALG with specific
examples.
1. Introduction
Network Address Translators (NATs) are often used when network's
internal IP addresses cannot be used outside the network either for
privacy reasons or because they are invalid for use outside the
network.
Ideally speaking, a host name uniquely identifies a host and its
address is used to locate routes to the host. However, host name and
address are often not distinguished and used interchangeably by
applications. Applications embed IP address instead of host name in
Srisuresh, et al. Informational [Page 1]
RFC 2694 DNS extensions to NAT September 1999
payload. Examples would be e-mails that specify their MX server
address (ex: user@666.42.7.11) instead of server name (ex:
user@private.com) as sender ID; HTML files that include IP address
instead of names in URLs, etc. Use of IP address in place of host
name in payload represents a problem as the packet traverses a NAT
device because NATs alter network and transport headers to suit an
address realm, but not payload.
DNS provides Name to address mapping. Whereas, NAT performs address
translation (in network and transport headers) in datagrams
traversing between private and external address realms. DNS
Application Level Gateway (DNS_ALG) outlined in this document helps
translate Name-to-Private-Address mapping in DNS payloads into Name-
to-external-address mapping and vice versa using state information
available on NAT.
A Network Address Port Translator (NAPT) performs address and
Transport level port translations (i.e, TCP, UDP ports and ICMP query
IDs). DNS name mapping granularity, however, is limited to IP
addresses and does not extend to transport level identifiers. As a
result, the DNS_ALG processing for an NAPT configuration is
simplified in that all host addresses in private network are bound to
a single external address. The DNS name lookup for private hosts
(from external hosts) do not mandate fresh private-external address
binding, as all private hosts are bound to a single pre-defined
external address. However, reverse name lookups for the NAPT external
address will not map to any of the private hosts and will simply map
to the NAPT router. Suffices to say, the processing requirements for
a DNS_ALG supporting NAPT configuration are a mere subset of Basic
NAT. Hence, the discussion in the remainder of the document will
focus mainly on Basic NAT, Bi-directional NAT and Twice NAT
configurations, with no specific reference to NAPT setup.
Definitions for DNS and related terms may be found in [Ref 3] and
[Ref 4]. Definitions for NAT related terms may be found in [Ref 1].
2. Requirement for DNS extensions
There are many ways to ensure that a host name is mapped to an
address relevant within an address realm. In the following sections,
we will identify where DNS extensions would be needed.
Typically, organizations have two types of authoritative name
servers. Internal authoritative name servers identify all (or
majority of) corporate resources within the organization. Only a
portion of these hosts are allowed to be accessed by the external
world. The remaining hosts and their names are unique to the private
network. Hosts visible to the external world and the authoritative
Srisuresh, et al. Informational [Page 2]
RFC 2694 DNS extensions to NAT September 1999
name server that maps their names to network addresses are often
configured within a DMZ (De-Militarized Zone) in front of a firewall.
We will refer the hosts and name servers within DMZ as DMZ hosts and
DMZ name servers respectively. DMZ host names are end-to-end unique
in that their FQDNs do not overlap with any end node that
communicates with it.
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
Stub A .........|\|....
|
+-----------------+
|Stub Router w/NAT|
+-----------------+
|
| DMZ - Network
------------------------------------------------------------
| | | | |
+--+ +--+ +--+ +--+ +----------+
|__| |__| |__| |__| | Firewall |
/____\ /____\ /____\ /____\ +----------+
DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web |
Server Server etc. |
|
Internal hosts (Private IP network) |
------------------------------------------------------------
| | | |
+--+ +--+ +--+ +--+
|__| |__| |__| |__|
/____\ /____\ /____\ /____\
Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server
Figure 1: DMZ network configuration of a private Network.
Figure 1 above illustrates configuration of a private network which
includes a DMZ. Actual configurations may vary. Internal name servers
are accessed by users within the private network only. Internal DNS
queries and responses do not cross the private network boundary. DMZ
name servers and DMZ hosts on the other hand are end-to-end unique
and could be accessed by external as well as internal hosts.
Throughout this document, our focus will be limited to DMZ hosts and
DMZ name servers and will not include internal hosts and internal
name servers, unless they happen to be same.
Srisuresh, et al. Informational [Page 3]
RFC 2694 DNS extensions to NAT September 1999
2.1. DMZ hosts assigned static external addresses on NAT
Take the case where DMZ hosts are assigned static external addresses
on the NAT device. Note, all hosts within private domain, including
the DMZ hosts are identified by their private addresses. Static
mapping on the NAT device allows the DMZ hosts to be identified by
their public addresses in the external domain.
2.1.1. Private networks with no DMZ name servers
Take the case where a private network has no DMZ name server for
itself. If the private network is connected to a single service
provider for external connectivity, the DMZ hosts may be listed by
their external addresses in the authoritative name servers of the
service provider within their forward and in-add.arpa reverse zones.
If the network is connected to multiple service providers, the DMZ
host names may be listed by their external address(es) within the
authoritative name servers of each of the service providers. This is
particularly significant in the case of in-addr.arpa reverse zones,
as the private network may be assigned different address prefixes by
the service providers.
In both cases, externally generated DNS lookups will not reach the
private network. A large number of NAT based private domains pursue
this option to have their DMZ hosts listed by their external
addresses on service provider's name servers.
2.1.2. Private networks with DMZ name servers
Take the case where a private network opts to keep an authoritative
DMZ name server for the zone within the network itself. If the
network is connected to a single service provider, the DMZ name
server may be configured to obviate DNS payload interceptions as
follows. The hosts in DMZ name server must be mapped to their
statically assigned external addresses and the internal name server
must be configured to bypass the DMZ name server for queries
concerning external hosts. This scheme ensures that DMZ name servers
are set for exclusive access to external hosts alone (not even to the
DMZ hosts) and hence can be configured with external addresses only.
The above scheme requires careful administrative planning to ensure
that DMZ name servers are not contacted by the private hosts directly
or indirectly (through the internal name servers). Using DNS-ALG
would obviate the administrative ordeals with this approach.
Srisuresh, et al. Informational [Page 4]
RFC 2694 DNS extensions to NAT September 1999
2.2. DMZ hosts assigned external addresses dynamically on NAT
Take the case where DMZ hosts in a private network are assigned
external addresses dynamically by NAT. While the addresses issued to
these hosts are fixed within the private network, their externally
known addresses are ephemeral, as determined by NAT. In such a
scenario, it is mandatory for the private organization to have a DMZ
name server in order to allow access to DMZ hosts by their name.
The DMZ name server would be configured with private addresses for
DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing on NAT
device will intercept the DNS packets directed to or from the DMZ
name server(s) and perform transparent payload translations so that a
DMZ host name has the right address mapping within each address realm
(i.e., private or external).
3. Interactions between NAT and DNS_ALG
This document operates on the paradigm that interconnecting address
realms may have overlapping address space. But, names of hosts within
interconnected realms must be end-to-end unique in order for them to
be accessed by all hosts. In other words, there cannot be an overlap
of FQDNs between end nodes communicating with each other. The
following diagram illustrates how a DNS packet traversing a NAT
device (with DNS_ALG) is subject to header and payload translations.
A DNS packet can be a TCP or UDP packet with the source or
destination port set to 53. NAT would translate the IP and TCP/UDP
headers of the DNS packet and notify DNS-ALG to perform DNS payload
changes. DNS-ALG would interact with NAT and use NAT state
information to modify payload, as necessary.
Srisuresh, et al. Informational [Page 5]
RFC 2694 DNS extensions to NAT September 1999
Original-IP
packet
||
||
vv
+---------------------------------+ +-----------------------+
| | |DNS Appl. Level Gateway|
|Network Address Translation (NAT)|--->| (DNS_ALG) |
| *IP & Transport header mods |<---| *DNS payload mods |
| | | |
+---------------------------------+ +-----------------------+
||
||
vv
Translated-IP
packet
Figure 2: NAT & DNS-ALG in the translation path of DNS packets
3.1. Address Binding considerations
We will make a distinction between "Temporary Address Binding" and
"Committed Address Binding" in NATs. This distinction becomes
necessary because the DNS_ALG will allow external users to create
state on NAT, and thus the potential for denial-of-service attacks.
Temporary address binding is the phase in which an address binding is
reserved without any NAT sessions using the binding. Committed
address binding is the phase in which there exists at least one NAT
session using the binding between the external and private addresses.
Both types of bindings are used by DNS_ALG to modify DNS payloads.
NAT uses only the committed address bindings to modify the IP and
Transport headers of datagrams pertaining to NAT sessions.
For statically mapped addresses, the above distinction is not
relevant. For dynamically mapped addresses, temporary address binding
often precedes committed binding. Temporary binding occurs when DMZ
name server is queried for a name lookup. Name query is likely a
pre-cursor to a real session between query originator and the queried
host. The temporary binding becomes committed only when NAT sees the
first packet of a session between query initiator and queried host.
A configurable parameter, "Bind-holdout time" may be defined for
dynamic address assignments as the maximum period of time for which a
temporary address binding is held active without transitioning into a
committed binding. With each use of temporary binding by DNS_ALG (to
modify DNS payload), this Bind-holdout period is renewed. A default
Bind-holdout time of a couple of minutes might suffice for most DNS-
ALG implementations. Note, it is possible for a committed address
Srisuresh, et al. Informational [Page 6]
RFC 2694 DNS extensions to NAT September 1999
binding to occur without ever having to be preceded by a temporary
binding. Lastly, when NAT is ready to unbind a committed address
binding, the binding is transitioned into a temporary binding and
kept in that phase for an additional Bind-holdout period. The binding
is freed only upon expiry of Bind-holdout time. The Bind-holdout time
preceding the committed-address-binding and the address-unbinding are
required to ensure that end hosts have sufficient time in which to
initiate a data session subsequent to a name lookup.
For example, say a private network with address prefix 10/8 is mapped
to 198.76.29/24. When an external hosts makes a DNS query to host7,
bearing address 10.0.0.7, the DMZ name server within private network
responds with an A type RR for host7 as:
host7 A 10.0.0.7
DNS_ALG would intercept the response packet and if 10.0.0.7 is not
assigned an external address already, it would request NAT to create
a temporary address binding with an external address and start Bind-
holdout timer to age the binding. Say, the assigned external address
is 198.76.29.1. DNS-ALG would use this temporary binding to modify
the RR in DNS response, replacing 10.0.0.7 with its external address
and reply with:
host7 A 198.76.29.1
When query initiator receives DNS response, only the assigned
external address is seen. Within a short period (presumably before
the bind-holdout time expires), the query initiator would initiate a
session with host7. When NAT notices the start of new session
directed to 198.76.29.1, NAT would terminate Bind-holdout timer and
transition the temporary binding between 198.76.29.1 and 10.0.0.7
into a committed binding.
To minimize denial of service attacks, where a malicious user keeps
attempting name resolutions, without ever initiating a connection,
NAT would have to monitor temporary address bindings that have not
transitioned into committed bindings. There could be a limit on the
number of temporary bindings and attempts to generate additional
temporary bindings could be simply rejected. There may be other
heuristic solutions to counter this type of malicious attacks.
We will consider bi-directional NAT to illustrate the use of
temporary binding by DNS_ALG in the following sub-sections, even
though the concept is applicable to other flavors of NATs as well.
Srisuresh, et al. Informational [Page 7]
RFC 2694 DNS extensions to NAT September 1999
3.2. Incoming queries
In order to initiate incoming sessions, an external host obtains the
V4 address of the DMZ-host it is trying to connect to by making a DNS
request. This request constitutes prelude to the start of a
potential new session.
The external host resolver makes a name lookup for the DMZ host
through its DNS server. When the DNS server does not have a record
of IPv4 address attached to this name, the lookup query is redirected
at some point to the Primary/Backup DNS server (i.e., in DMZ) of the
private stub domain.
Enroute to DMZ name server, DNS_ALG would intercept the datagram and
modify the query as follows.
a) For Host name to Host address query requests:
Make no change to the DNS payload.
b) For Host address to Host name queries: Replace the external V4
address octets (in reverse order) preceding the string "IN-
ADDR.ARPA" with the corresponding private V4 address, if such
an address binding exists already. However, if a binding does
not exist, the DNS_ALG would simply respond (as a name server
would) with a response code (RCODE) of 5 (REFUSED to respond
due to policy reasons) and set ANCOUNT, NSCOUNT and ARCOUT to 0
in the header section of the response.
In the opposite direction, as DNS response traverses from the DNS
server in private network, DNS_ALG would once again intercept the
packet and modify as follows.
a) For a host name to host address query requests, replace the
private address sent by DMZ name server with a public address
internally assigned by the NAT router. If a public address is
not previously assigned to the host's private address, NAT
would assign one at this time.
b) For host address to host name queries, replace the private
address octets preceding the string "IN-ADDR.ARPA" in response
RRs with their external address assignments. There is a chance
here that by the time the DMZ name server replies, the bind-
holdout timer in NAT for the address in question has expired.
In such a case, DNS_ALG would simply drop the reply. The sender
will have to resend the query (as would happen when a router
enroute drops the response).
Srisuresh, et al. Informational [Page 8]
RFC 2694 DNS extensions to NAT September 1999
For static address assignments, the TTL value supplied in the
original RR will be left unchanged. For dynamic address assignments,
DNS_ALG would modify the TTL value on DNS resource records (RRs) to
be 0, implying that the RRs should only be used for transaction in
progress, and not be cached. For compatibility with broken
implementations, TTL of 1 might in practice work better.
Clearly, setting TTL to be 0 will create more traffic than if the
addresses were static, because name-to-address mapping is not cached.
Specifically, network based applications will be required to use
names rather than addresses for identifying peer nodes and must use
DNS for every name resolution, as name-to-address mapping cannot be
shared from the previously run applications.
In addition, NAT would be requested to initiate a bind-holdout timer
following the assignment. If no session is initiated to the private
host within the Bind-holdout time period, NAT would terminate the
temporary binding.
3.3. Outgoing Queries
For Basic and bi-directional NATs, there is no need to distinguish
between temporary and committed bindings for outgoing queries. This
is because, DNS_ALG does not modify the DNS packets directed to or
from external name servers (used during outbound sessions), unlike
the inbound DNS sessions.
Say, a private host needs to communicate with an external host. The
DNS query goes to the internal name server (if there exists one)
and from there to the appropriate authoritative/cache name server
outside the private domain. The reply follows the same route but
neither the query nor the response are subject to DNS_ALG
translations.
This however will not be the case with address isolated twice NAT
private and external domains. In such a case, NAT would intercept all
DNS packets and make address modifications to payload as discussed in
the previous section. Temporary Private to external address bindings
are created when responses are sent by private DNS servers and
temporary external to private address bindings are created when
responses are sent by external DNS servers.
4. DNS payload modifications by DNS-ALG
Typically, UDP is employed as the transport mechanism for DNS queries
and responses and TCP for Zone refresh activities. In either case,
name servers are accessed using a well-known DNS server port 53
(decimal) and all DNS payloads have the following format of data [Ref
Srisuresh, et al. Informational [Page 9]
RFC 2694 DNS extensions to NAT September 1999
4]. While NAT is responsible for the translation of IP and TCP/UDP
headers of a DNS packet, DNS-ALG is responsible for updating the DNS
payload.
The header section within the DNS payload is always present and
includes fields specifying which of the remaining sections are
present. The header identifies if the message is a query or a
response. No changes are required to be made by DNS-ALG to the Header
section. DNS_ALG would parse only the DNS payloads whose QCLASS is
set to IN (IP class).
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+
4.1. Question section
The question section contains QDCOUNT (usually 1) entries, as
specified in Header section, with each of the entries in the
following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4.1.1. PTR type Queries
DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified
Domain Names) fall within IN-ADDR.ARPA domain and replace the address
octets (in reverse order) preceding the string "IN-ADDR.ARPA" with
the corresponding assigned address octets in reverse order, only if
the address binding is active on the NAT router. If the address
Srisuresh, et al. Informational [Page 10]
RFC 2694 DNS extensions to NAT September 1999
preceding the string "IN-ADDR.ARPA" falls within the NAT address map,
but does not have at least a temporary address binding, DNS_ALG would
simply simply respond back (as a DNS name server would) with a
response code (RCODE) of 5 (REFUSED to respond due to policy reasons)
and set ANCOUNT, NSCOUNT and ARCOUT to 0 in the header section of the
response.
Note that the above form of host address to host name type queries
will likely yield different results at different times, depending
upon address bind status in NAT at a given time.
For example, a resolver that wanted to find out the hostname
corresponding to address 198.76.29.1 (externally) would pursue a
query of the form:
QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA.
DNS_ALG would intervene and if the address 198.76.29.1 is internally
mapped to a private address of 10.0.0.1, modify the query as below
and forward to DMZ name server within private network.
QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA
Presumably, the DMZ name server is the authoritative name server for
10.IN-ADDR.ARPA zone and will respond with an RR of the following
form in answer section. DNS_ALG translations of the response RRs will
be considered in a following section.
1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_domain
An example of Inverse translation is e-mail programs using inverse
translation to trace e-mail originating hosts for spam prevention.
Verify if the address from which the e-mail was sent does indeed
belong to the same domain name the sender claims in sender ID.
Query modifications of this nature will likely change the length of
DNS payload. As a result, the corresponding IP and TCP/UDP header
checksums must be updated. In case of TCP based queries, the sequence
number deltas must be tracked by NAT so that the delta can be applied
to subsequent sequence numbers in datagrams in the same direction and
acknowledgement numbers in datagrams in the opposite direction. In
case of UDP based queries, message sizes are restricted to 512 bytes
(not counting the IP or UDP headers). Longer messages must be
truncated and the TC bit should be set in the header.
Srisuresh, et al. Informational [Page 11]
RFC 2694 DNS extensions to NAT September 1999
Lastly, any compressed domain names using pointers to represent
common domain denominations must be updated to reflect new pointers
with the right offset, if the original domain name had to be
translated by NAT.
4.1.2. A, MX, NS and SOA type Queries
For these queries, DNS_ALG would not modify any of the fields in the
query section, not even the name field.
4.1.3. AXFR type Queries
AXFR is a special zone transfer type query. Zone transfers from
private address realm must be avoided for address assignments that
are not static. Typically, TCP is used for AXFR requests.
When changes are made to a zone, they must be distributed to all name
servers. The general model of automatic zone transfer or refreshing
is that one of the name servers is the master or primary for the
zone. Changes are coordinated at the primary, typically by editing a
master file for the zone. After editing, the administrator signals
the master server to load the new zone. The other non-master or
secondary servers for the zone periodically check the SERIAL field of
the SOA for the zone for changes (at some polling intervals) and
obtain new zone copies when changes have been made.
Zone transfer is usually from primary to backup name servers. In the
case of NAT supported private networks, primary and backup servers
are advised to be located in the same private domain (say,
private.zone) so zone transfer is not across the domain and DNS_ALG
support for zone transfer is not an issue. In the case a secondary
name server is located outside the private domain, zone transfers
must not be permitted for non-static address assignments. Primary and
secondary servers are required to be within the same private domain
because all references to data in the zone had to be captured. With
dynamic address assignments and bindings, it is impossible to
translate the axfr data to be up-to-date. Hence, if a secondary
server for private.zone were to be located external to the domain, it
would contain bad data. Note, however, the requirement outlined here
is not in confirmence with RFC 2182, which recommends primary and
secondary servers to be placed at topologically and geographically
dispersed locations on the Internet.
During zone transfers, DNS_ALG must examine all A type records and
replace the original address octets with their statically assigned
address octets. DNS_ALG could also examine if there is an attempt to
Srisuresh, et al. Informational [Page 12]
RFC 2694 DNS extensions to NAT September 1999
transfer records for hosts that are not assigned static addresses and
drop those records alone or drop the whole transfer. This would
minimize misconfiguration and human errors.
4.1.4. Dynamic Updates to the DNS.
An authoritative name server can have dynamic updates from the nodes
within the zone without intervention from NAT and DNS-ALG, so long as
one avoids spreading a DNS zone across address realms. We recommend
keeping a DNS zone within the same realm it is responsible for. By
doing this, DNS update traffic will not cross address realms and
hence will not be subject to consideration by DNS-ALG.
Further, if dynamic updates do cross address realms, and the updates
must always be secured via DNSSEC, then such updates are clearly out
of scope for DNS-ALG (as described in section 7).
4.2. Resource records in all other sections
The answer, authority, and additional sections all share the same
format, with a variable number of resource records. The number of RRs
specific to each of the sections may be found in the corresponding
count fields in DNS header. Each resource record has the following
format:
The TTL value supplied in the original RRs will be left unchanged for
static address assignments. For dynamic address assignments, DNS_ALG
will modify the TTL to be 0, so the RRs are used just for the
transaction in progress, and not cached. RFC 2181 requires all RRs
in an RRset (RRs with the same name, class and type, but with
different RDATA) to have the same TTL. So if the TTL of an RR is set
to 0, all other RRs within the same RRset will also be adjusted by
the DNS-ALG to be 0.
Srisuresh, et al. Informational [Page 13]
RFC 2694 DNS extensions to NAT September 1999
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4.2.1. PTR type RRs
The considerations specified in the Question section is equally valid
with names for PTR type RRs. Private address preceding the string
"IN-ADDR.ARPA" (in reverse order of octets) must be replaced by its
external address assignment (in reverse order), if a binding exists.
The remaining fields for this RR remain unchanged.
4.2.2. A type RRs
The RDATA for A records is a 4-byte IP address. DNS_ALG would simply
replace the original address in RDATA with its externally assigned IP
address, if it succeeded in finding an address binding. Successful
address translation should cause no changes to payload length. Only
the transport header checksum would need updating. In case of failure
to find an address binding, DNS_ALG would have to drop the record and
decrement the corresponding COUNT field in the header section.
4.2.3. CNAME, MX, NS and SOA type RRs
No changes required to be made by DNS_ALG for these RRs, as the RDATA
does not contain any IP addresses. The host names within the RDATA
remain unchanged between realms.
Srisuresh, et al. Informational [Page 14]
RFC 2694 DNS extensions to NAT September 1999
5. Illustration of DNS_ALG in conjunction with Bi-directional NAT
The following diagram illustrates the operation of DNS_ALG in a a
bi-directional NAT router. We will illustrate by walking through how
name lookup and reverse name lookup queries are processed.
.
________________ . External.com
( ) .
( ) . +-------------+
+--+ ( Internet )-.---|Border Router|
|__|------ ( ) . +-------------+
/____\ (________________) . |
Root | . |
DNS Server | . ---------------
+---------------+ . | |
|Provider Router| . +--+ +--+
+---------------+ . |__| |__|
| . /____\ /____\
| . DNS Server Host X
External domain | . 171.68.1.1 171.68.10.1
............................|...............................
Private domain |
| Private.com
|
+--------------------------------------+
|Bi-Directional NAT router with DNS_ALG|
| |
| Private addresses: 172.19/16 |
| External addresses: 131.108.1/24 |
+--------------------------------------+
| |
---------- ----------
| | DNS Server
+--+ +--+ Authoritative
|__| |__| for private.com
/____\ /____\
Host A DNS Server
172.19.1.10 172.19.2.1
(Mapped to 131.108.1.8)
Figure 3: DNS-ALG operation in Bi-Directional NAT setup
The above diagram depicts a scenario where a company private.com
using private address space 172.19/16 connects to the Internet using
bi-directional NAT. DNS_ALG is embedded in the NAT device to make
necessary DNS payload changes. NAT is configured to translate the
private addresses space into an external address block of
Srisuresh, et al. Informational [Page 15]
RFC 2694 DNS extensions to NAT September 1999
131.108.1/24. NAT is also configured with a static translation for
private.com's DNS server, so it can be referred in the external
domain by a valid address.
The company external.com is located in the external domain, using a
registered address block of 171.68/16. Also shown in the topology is
a root DNS server.
Following simplifications are made to the above configuration:
* private.com is not multihomed and all traffic to the external
space transits a single NAT.
* The DNS server for private.com is authoritative for the
private.com domain and points to the root server for all other
DNS resolutions. The same is true for the DNS server in
external.com.
* The internal name servers for private.com and external.com are
same as their DMZ name servers. The DNS servers for these
domains are configured with addresses private to the
organization.
* The name resolvers on host nodes do not have recursion
available on them and desire recursive service from servers.
All name servers are assumed to be able to provide recursive
service.
5.1. Outgoing Name-lookup queries
Say, Host A in private.com needs to perform a name lookup for host X
in external.com to initiate a session with X. This would proceed as
follows.
1. Host A sends a UDP based name lookup query (A record) for
"X.External.Com" to its local DNS server.
2. Local DNS server sends the query to the root server enroute NAT.
NAT would change the IP and UDP headers to reflect DNS server's
statically assigned external address. DNS_ALG will make no
changes to the payload.
3. The root server, in turn, refers the local DNS server to query the
DNS server for External.com. This referal transits the NAT enroute
to the local DNS server. NAT would simply translate the IP and
UDP headers of the incoming packet to reflect DNS server's private
address. No changes to the payload by DNS_ALG.
Srisuresh, et al. Informational [Page 16]
RFC 2694 DNS extensions to NAT September 1999
4. Private.com DNS server will now send the query to the DNS server
for external.com, once again, enroute NAT. Just as with the query
to root, The NAT router would change the IP and UDP headers to
reflect the DNS server's statically assigned external address.
And, DNS_ALG will make no changes to the payload.
5. The DNS server for external.com replies with the IP address
171.68.10.1. This reply also transits the NAT. NAT would
translate the IP and UDP headers of the incoming packet to reflect
DNS server's private address. Once again, no changes to the
payload by DNS_ALG.
6. The DNS server in Private.com replies to host A.
When Host A finds the address of Host X, A initiates a session with
host X, using a destination IP address of 171.68.10.1. This datagram
and any others that follow in this session will be translated as
usual by NAT.
Note, DNS_ALG does not change the payload for DNS packets in either
direction.
5.2. Reverse name lookups originated from private domain
This scenario builds on the previous case by having host A in
Private.com perform a reverse name lookup on 171.68.10.1, which is
host X's global address. Following is a sequence of events.
1. Host A sends a UDP based inverse name lookup query (PTR record)
for "1.10.68.171.IN-ADDR.ARPA." to its local DNS server.
2. Local DNS server sends the query to the root server enroute NAT.
As before, NAT would change the IP and UDP headers to reflect DNS
server's statically assigned external address. DNS_ALG will make
no changes to the payload.
3. The root server, in turn, refers the local DNS server to query the
DNS server for External.com. This referal transits the NAT enroute
to the local DNS server. NAT would simply translate the IP and
UDP headers of the incoming packet to reflect DNS server's private
address. No changes to the payload by DNS_ALG.
4. Private.com DNS server will now send the query to the DNS server
for external.com, once again, enroute NAT. Just as with the query
to root, The NAT router would change the IP and UDP headers to
reflect the DNS server's statically assigned external address.
And, DNS_ALG will make no changes to the payload.
Srisuresh, et al. Informational [Page 17]
RFC 2694 DNS extensions to NAT September 1999
5. The DNS server for external.com replies with the host name of
"X.External.Com.". This reply also transits the NAT. NAT would
translate the IP and UDP headers of the incoming packet to reflect
DNS server's private address. Once again, no changes to the
payload by DNS_ALG.
6. The DNS server in Private.com replies to host A.
Note, DNS_ALG does not change the payload in either direction.
5.3. Incoming Name-lookup queries
This time, host X in external.com wishes to initiate a session with
host A in Private.com. Below are the sequence of events that take
place.
1. Host X sends a UDP based name lookup query (A record) for
"A.Private.com" to its local DNS server.
2. Local DNS server in External.com sends the query to root server.
3. The root server, in turn, refers the DNS server in External.com to
query the DNS server for private.com,
4. External.com DNS server will now send the query to the DNS server
for Private.com. This query traverses the NAT router. NAT would
change the IP and UDP headers of the packet to reflect the DNS
server's private address. DNS_ALG will make no changes to the
payload.
5. The DNS server for Private.com replies with the IP address
172.19.1.10 for host A. This reply also transits the NAT. NAT
would translate the IP and UDP headers of the outgoing packet from
the DNS server.
DNS_ALG will request NAT to (a) setup a temporary binding for Host
A (172.19.1.10) with an external address and (b) initiate Bind-
holdout timer. When NAT successfully sets up a temporary binding
with an external address (say, 131.108.1.12), DNS_ALG would modify
the payload to replace A's private address with its external
assigned address and set the Cache timeout to 0.
6. The server in External.com replies to host X
When Host X finds the address of Host A, X initiates a session with
A, using a destination IP address of 131.108.1.12. This datagram and
any others that follow in this session will be translated as usual by
the NAT.
Srisuresh, et al. Informational [Page 18]
RFC 2694 DNS extensions to NAT September 1999
Note, DNS_ALG changes only the response packets from the DNS server
for Private domain.
5.4. Reverse name lookups originated from external domain
This scenario builds on the previous case (section 5.3) by having
host X in External.com perform a reverse name lookup on 131.108.1.12,
which is host A's assigned external address. The following sequence
of events take place.
1. Host X sends a UDP based inverse name lookup query (PTR record)
for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.
2. Local DNS server in External.com sends the query to the root
server.
3. The root server, in turn, refers the local DNS server to query the
DNS server for Private.com.
4. External.com DNS server will now send the query to the DNS server
for Private.com. This query traverses the NAT router. NAT would
change the IP and UDP headers to reflect the DNS server's private
address.
DNS_ALG will enquire NAT for the private address associated with
the external address of 131.108.1.12 and modify the payload,
replacing 131.108.1.12 with the private address of 172.19.1.10.
5. The DNS server for Private.com replies with the host name of
"A.Private.Com.". This reply also transits the NAT. NAT would
translate the IP and UDP headers of the incoming packet to reflect
DNS server's private address.
Once again, DNS_ALG will enquire NAT for the assigned external
address associated with the private address of 172.19.1.10 and
modify the payload, replacing 172.19.1.10 with the assigned
external address of 131.108.1.12.
6. The DNS server in External.com replies to host X.
Note, DNS_ALG changes the query as well as response packets from DNS
server for Private domain.
6. Illustration of DNS_ALG in conjunction with Twice-NAT
The following diagram illustrates the operation of DNS_ALG in a Twice
NAT router. As before, we will illustrate by walking through how name
lookup and reverse name lookup queries are processed.
Srisuresh, et al. Informational [Page 19]
RFC 2694 DNS extensions to NAT September 1999
.
________________ . External.com
( ) .
( ) . +-------------+
+--+ ( Internet )-.---|Border Router|
|__|------ ( ) . +-------------+
/____\ (________________) . |
Root | . |
DNS Server | . ---------------
+---------------+ . | |
|Provider Router| . +--+ +--+
+---------------+ . |__| |__|
| . /____\ /____\
| . DNS Server Host X
External domain | . 171.68.1.1 171.68.10.1
............................|...............................
Private domain |
| Private.com
|
+-------------------------------------------+
| Twice-NAT router with DNS_ALG |
| |
| Private addresses: 171.68/16 |
| Assigned External addresses: 131.108.1/24 |
| |
| External addresses: 171.68/16 |
| Assigned Private addresses: 10/8 |
+-------------------------------------------+
| |
---------- ----------
| | DNS Server
+--+ +--+ Authoritative
|__| |__| for private.com
/____\ /____\
Host A DNS Server
171.68.1.10 171.68.2.1
(Mapped to 131.108.1.8)
Figure 4: DNS-ALG operation in Twice-NAT setup
In this scenario, hosts in private.com were not numbered from the RFC
1918 reserved 172.19/16 space, but rather were numbered with the
globally-routable 171.68/16 network, the same as external.com. Not
only does private.com need translation service for its own host
addresses, but it also needs translation service if any of those
hosts are to be able to exchange datagrams with hosts in
external.com. Twice-NAT accommodates the transition by translating
the overlapping address space used in external.com with a unique
Srisuresh, et al. Informational [Page 20]
RFC 2694 DNS extensions to NAT September 1999
address block (10/8) from RFC 1918 address space. Routes are set up
within the private domain to direct datagrams destined for the
address block 10/8 through Twice-NAT device to the external global
network space.
Simplifications and assumptions made in section 5.0 will be valid
here as well.
6.1. Outgoing Name-lookup queries
Say, Host A in private.com needs to perform a name lookup for host X
in external.com (host X has a FQDN of X.external.com), to find its
address. This would would proceed as follows.
1. Host A sends a UDP based name lookup query (A record) for
"X.External.Com" to its local DNS server.
2. Local DNS server sends the query to the root server enroute NAT.
NAT would change the IP and UDP headers to reflect DNS server's
statically assigned external address. DNS_ALG will make no
changes to the payload.
3. The root server, in turn, refers the local DNS server to query the
DNS server for External.com. This referal transits the NAT enroute
to the local DNS server. NAT would simply translate the IP and
UDP headers of the incoming packet to reflect DNS server's private
address.
DNS_ALG will request NAT for an assigned private address for the
referral server and replace the external address with its assigned
private address in the payload.
4. Private.com DNS server will now send the query to the DNS server
for external.com, using its assigned private address, via NAT.
This time, NAT would change the IP and UDP headers to reflect the
External addresses of the DNS servers. I.e., Private.com DNS
server's IP address is changed to its assigned external address
and External.Com DNS server's assigned Private address is changed
to its external address.
DNS_ALG will make no changes to the payload.
5. The DNS server for external.com replies with the IP address
171.68.10.1. This reply also transits the NAT. NAT would once
again translate the IP and UDP headers of the incoming to reflect
the private addresses of the DNS servers. I.e., Private.com DNS
Srisuresh, et al. Informational [Page 21]
RFC 2694 DNS extensions to NAT September 1999
server's IP address is changed to its private address and
External.Com DNS server's external address is changed to its
assigned Private address.
DNS_ALG will request NAT to (a) set up a temporary binding for
Host X (171.68.10.1) with a private address and (b) initiate
Bind-holdout timer. When NAT successfully sets up temporary
binding with a private address (say, 10.0.0.254), DNS_ALG would
modify the payload to replace X's external address with its
assigned private address and set the Cache timeout to 0.
6. The DNS server in Private.com replies to host A.
When Host A finds the address of Host X, A initiates a session with
host X, using a destination IP address of 10.0.0.254. This datagram
and any others that follow in this session will be translated as
usual by Twice NAT.
Note, the DNS_ALG has had to change payload in both directions.
6.2. Reverse name lookups originated from private domain
This scenario builds on the previous case by having host A in
Private.com perform a reverse name lookup on 10.0.0.254, which is
host X's assigned private address. Following is a sequence of events.
1. Host A sends a UDP based inverse name lookup query (PTR record)
for "254.0.0.10.IN-ADDR.ARPA." to its local DNS server.
2. Local DNS server sends the query to the root server enroute NAT.
As before, NAT would change the IP and UDP headers to reflect DNS
server's statically assigned external address.
DNS_ALG will translate the private assigned address 10.0.0.254
with its external address 171.68.10.1.
3. The root server, in turn, refers the local DNS server to query the
DNS server for External.com. This referal transits the NAT enroute
to the local DNS server. NAT would simply translate the IP and
UDP headers of the incoming packet to reflect DNS server's private
address.
As with the original query, DNS_ALG will translate the private
assigned address 10.0.0.254 with its external address 171.68.10.1.
In addition, DNS_ALG will replace the external address of the
referal server (i.e., the DNS server for External.com) with its
assigned private address in the payload.
Srisuresh, et al. Informational [Page 22]
RFC 2694 DNS extensions to NAT September 1999
4. Private.com DNS server will now send the query to the DNS server
for external.com, using its statically assigned private address,
via NAT. This time, NAT would change the IP and UDP headers to
reflect the External addresses of the DNS servers. I.e.,
Private.com DNS server's IP address is changed to its assigned
external address and External.Com DNS server's assigned Private
address is changed to its external address.
As with the original query, DNS_ALG will translate the private
assigned address 10.0.0.254 with its external address 171.68.10.1.
5. The DNS server for external.com replies with the FQDN of
"X.External.Com.". This reply also transits the NAT. NAT would
once again translate the IP and UDP headers of the incoming to
reflect the private addresses of the DNS servers. I.e.,
Private.com DNS server's IP address is changed to its private
address and External.Com DNS server's external address is changed
to its assigned Private address.
Once again, DNS_ALG will translate the query section, replacing
the external address 171.68.10.1 with its assigned private address
of 10.0.0.254
6. The DNS server in Private.com replies to host A.
Note, the DNS_ALG has had to change payload in both directions.
6.3. Incoming Name-lookup queries
This time, host X in external.com wishes to initiate a session with
host A in Private.com. Below are the sequence of events that take
place.
1. Host X sends a UDP based name lookup query (A record) for
"A.Private.com" to its local DNS server.
2. Local DNS server in External.com sends the query to root server.
3. The root server, in turn, refers the DNS server in External.com to
query the DNS server for private.com,
4. External.com DNS server will now send the query to the DNS server
for Private.com. This query traverses the NAT router. NAT would
change the IP and UDP headers to reflect the private addresses of
the DNS servers. I.e., Private.com DNS server's IP address is
changed to its private address and External.Com DNS server's
external address is changed to assigned Private address.
Srisuresh, et al. Informational [Page 23]
RFC 2694 DNS extensions to NAT September 1999
DNS_ALG will make no changes to the payload.
5. The DNS server for Private.com replies with the IP address
171.68.1.10 for host A. This reply also transits the NAT. NAT
would once again translate the IP and UDP headers of the incoming
to reflect the external addresses of the DNS servers. I.e.,
Private.com DNS server's IP address is changed to its assigned
external address and External.Com DNS server's assigned private
address is changed to its external address.
DNS_ALG will request NAT to (a) set up temporary binding for Host
A (171.68.1.10) with an external address and (b) initiate Bind-
holdout timer. When NAT succeeds in finding an external address
(say, 131.108.1.12) to temporarily bind to host A, DNS_ALG would
modify the payload to replace A's private address with its
external assigned address and set the Cache timeout to 0.
6. The server in External.com replies to host X
When Host X finds the address of Host A, X initiates a session with
A, using a destination IP address of 131.108.1.12. This datagram and
any others that follow in this session will be translated as usual by
the NAT.
Note, DNS_ALG changes only the response packets from the DNS server
for Private domain.
6.4. Reverse name lookups originated from external domain
This scenario builds on the previous case (section 6.3) by having
host X in External.com perform a reverse name lookup on 131.108.1.12,
which is host A's assigned external address. The following sequence
of events take place.
1. Host X sends a UDP based inverse name lookup query (PTR record)
for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.
2. Local DNS server in External.com sends the query to the root
server.
3. The root server, in turn, refers the local DNS server to query the
DNS server for Private.com.
Srisuresh, et al. Informational [Page 24]
RFC 2694 DNS extensions to NAT September 1999
4. External.com DNS server will now send the query to the DNS server
for Private.com. This query traverses the NAT router. NAT would
change the IP and UDP headers to reflect the private addresses of
the DNS servers. I.e., Private.com DNS server's IP address is
changed to its private address and External.Com DNS server's
external address is changed to assigned Private address.
DNS_ALG will enquire NAT for the private address associated with
the external address of 131.108.1.12 and modify the payload,
replacing 131.108.1.12 with the private address of 171.68.1.10.
5. The DNS server for Private.com replies with the host name of
"A.Private.Com.". This reply also transits the NAT. NAT would once
again translate the IP and UDP headers of the incoming to reflect
the external addresses of the DNS servers. I.e., Private.com DNS
server's IP address is changed to its assigned external address
and External.Com DNS server's assigned private address is changed
to its external address.
Once again, DNS_ALG will enquire NAT for the assigned external
address associated with the private address of 172.19.1.10 and
modify the payload, replacing 171.68.1.10 with the assigned
external address of 131.108.1.12.
6. The DNS server in External.com replies to host X.
Note, DNS_ALG changes the query as well as response packets from DNS
server for Private domain.
7. DNS-ALG limitations and Future Work
NAT increases the probability of mis-addressing. For example, same
local address may be bound to different public address at different
times and vice versa. As a result, hosts that cache the name to
address mapping for longer periods than the NAT router is configured
to hold the map are likely to misaddress their sessions. Note, this
is mainly an issue with bad host implementations that hold DNS
records longer than the TTL in them allows and is not directly
attributable to the mechanism described here.
DNS_ALG cannot support secure DNS name servers in the private domain.
I.e., Signed replies from an authoritative DNS name server in the DMZ
to queries originating from the external world will be broken by the
DNS-ALG. At best, DNS-ALG would be able to transform secure dnssec
data into unprotected data. End-node demanding DNS replies to be
signed may reject replies that have been tampered with by DNS_ALG.
Since, the DNS server does not have a way to find where the queries
come from (i.e., internal or external), it will most likely have to
Srisuresh, et al. Informational [Page 25]
RFC 2694 DNS extensions to NAT September 1999
resort to the common denomination of today's insecure DNS. Both are
serious limitations to DNS_ALG. Zone transfers between DNS-SEC
servers is also impacted the same way, if the transfer crosses
address realms.
The good news, however, is that only end-nodes in DMZ pay the price
for the above limitation in a traditional NAT (or, a bi-directional
NAT), as external end-nodes may not access internal hosts due to DNS
replies not being secure. However, for outgoing sessions (from
private network) in a bi-directional NAT setup, the DNS queries can
be signed and securely accepted by DMZ and other internal hosts since
DNS_ALG does not intercept outgoing DNS queries and incoming replies.
Lastly, zone transfers between DNS-SEC servers within the same
private network are not impacted.
Clearly, with DNS SEC deployment in DNS servers and end-host
resolvers, the scheme suggested in this document will not work.
8. Security Considerations
If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG
will fail because it won't be able to perform payload modifications.
Alternately, if packets must be preserved in an address realm,
DNS_ALG will need to hold the secret key to decrypt/verify payload
before forwarding packets to a different realm. For example, if DNS-
ALG, NAT and IPsec gateway (providing secure tunneling service) are
resident on the same device, DNS-ALG will have access to the IPsec
security association keys. The preceding section, "DNS-ALG
limitations and Future Work" has coverage on DNS_ALG security
considerations.
Further, with DNS-ALG, there is a possibility of denial of service
attack from a malicious user, as outlined in section 3.1. Section
3.1 suggests some ways to counter this attack.
REFERENCES
[1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[2] Egevang, K. and P. Francis, "The IP Network Address Translator
(NAT)", RFC 1631, May 1994.
[3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
Srisuresh, et al. Informational [Page 26]
RFC 2694 DNS extensions to NAT September 1999
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[5] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[6] Reynolds J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[7] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, October 1989.
[8] Braden, R., "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC 1123, October 1989.
[9] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[10] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
[11] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[12] Vixie, P., Thompson, S., Rekhter Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997.
[13] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
2137, April 1997.
[14] Elz R. and R. Bush, "Clarifications to the DNS specification",
RFC 2181, July 1997.
[15] Elz, R., R. Bush, Bradner S. and M. Patton, "Selection and
Operation of Secondary DNS Servers", RFC 2182, July 1997.
Srisuresh, et al. Informational [Page 27]
RFC 2694 DNS extensions to NAT September 1999
Authors' Addresses
Pyda Srisuresh
849 Erie Circle
Milpitas, CA 95035
U.S.A.
Phone: +1 (408) 263-7527
EMail: srisuresh@yahoo.com
George Tsirtsis
Internet Transport Group
B29 Room 129
BT Laboratories
Martlesham Heath
IPSWICH
Suffolk IP5 3RE
England
Phone: +44 1473 640756
Fax: +44 1473 640709
EMail: george@gideon.bt.co.uk
Praveen Akkiraju
cisco Systems
170 West Tasman Drive
San Jose, CA 95134 USA
Phone: +1 (408) 526-5066
EMail: spa@cisco.com
Andy Heffernan
Juniper Networks, Inc.
385 Ravensdale Drive.
Mountain View, CA 94043 USA
Phone: +1 (650) 526-8037
Fax: +1 (650) 526-8001
EMail: ahh@juniper.net
Srisuresh, et al. Informational [Page 28]
RFC 2694 DNS extensions to NAT September 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Srisuresh, et al. Informational [Page 29]
|