Split Domain Name System (DNS) allows DNS queries for certain domain
names to be resolved to internal DNS servers over the VPN tunnel, while all the
other DNS queries are resolved to the Internet Service Provider's (ISP) DNS
servers. A list of internal domain names is "pushed" to the VPN Client during
initial tunnel negotiation. The VPN Client then determines whether DNS queries
should be sent over the encrypted tunnel or sent unencrypted to the ISP. Split
DNS is only used in split-tunneling environments, since traffic is sent both
over the encrypted tunnel and unencrypted to the Internet.
Dynamic DNS (DDNS) allows automatic registration of VPN Client host
names into a DNS server upon successful negotiation of the VPN connection. When
a VPN Client initiates a connection, the local host name is sent to the
concentrator, which in turn forwards this onto the centrally located Dynamic
Host Configuration Protocol (DHCP) server for the address allocation. If the
DHCP server supports DDNS, then the allocated address and host name are entered
automatically. DHCP address allocation is a requirement for DDNS to function,
but does not work with local address pools.
There are no specific requirements for this document.
Both split DNS and DDNS were introduced in version 3.6 of both
concentrator and client code. You must run at least these versions to enable
and configure this feature. All the configurations in this document were
developed and tested using these software and hardware versions.
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
This document uses this network setup:
For more information on document conventions, refer to the
Cisco Technical Tips
In this section, you are presented with the information to configure
the features described in this document. Split DNS parameters are configured
under the group parameters on the Cisco VPN 3000 Concentrator. Therefore, no
configuration on the client is necessary.
Under the User Management >
Groups section of the GUI, select the appropriate group, and
select Modify Group.
Under the General tab, enter up to two internal DNS servers to be
passed down to the client.
Under the Client Config tab, configure split tunneling, the
default domain name, and the split DNS domain list.
After the tunnel is successfully negotiated using the above
parameters, any reference to hosts with fully qualified domain names in the
Cisco.com or Test.com domains results in a DNS query being sent over the tunnel
to 192.168.1.1. DNS queries for hosts in any other domain are sent unencrypted
to the DNS servers provided by DHCP at the initial PC boot up time.
Note: The split tunnel list called "192.168 Network" contains the
192.168.0.0/16 network. This is necessary so that the DNS requests to the
internal DNS server of 192.168.1.1 will be encrypted.
DDNS requires that the DHCP address assignment is configured on the VPN
Concentrator. Therefore, no configuration on the client is necessary. During
the initial tunnel negotiation, the client sends its host name to the
concentrator, and the concentrator uses this in its DHCP request packet when
requesting an address for the client. It is up to the DHCP server to
dynamically add this host name into the DDNS server. Windows 2000 DHCP servers
support this functionality.
To configure DHCP address allocation for VPN Clients on the VPN
Concentrator, under Configuration > System
> Servers > DHCP, add the DHCP
servers IP address. Ensure that DHCP is enabled globally on the
concentrator under Configuration > System
> IP Routing > DHCP Parameters.
Note: This is enabled by default.
Under Configuration > System
> Address Management > Assignment,
check the option to allocate addresses from a DHCP server.
The Log Viewer included with the VPN Client can be used to ensure the
correct parameters are being sent down from the VPN Concentrator. Under
Options > Filters, set the Internet Key
Exchange (IKE) log class to High. After the tunnel is
successfully negotiated, the following messages (or your network-specific
equivalent) should be present in the log.
34 11:43:38.069 03/07/03 Sev=Info/5 IKE/0x63000010
MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_ADDRESS: , value = 192.168.1.50
35 11:43:38.069 03/07/03 Sev=Info/5 IKE/0x63000010
MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_DNS(1): , value = 192.168.1.1
38 11:43:38.069 03/07/03 Sev=Info/5 IKE/0x6300000D
MODE_CFG_REPLY: Attribute = MODECFG_UNITY_SPLIT_INCLUDE (# of split_nets), value = 0x00000001
39 11:43:38.069 03/07/03 Sev=Info/5 IKE/0x6300000F
subnet = 192.168.0.0
mask = 255.255.0.0
protocol = 0
src port = 0
40 11:43:38.069 03/07/03 Sev=Info/5 IKE/0x6300000E
MODE_CFG_REPLY: Attribute = MODECFG_UNITY_DEFDOMAIN: , value = cisco.com
41 11:43:38.069 03/07/03 Sev=Info/5 IKE/0x6300000E
MODE_CFG_REPLY: Attribute = MODECFG_UNITY_SPLITDNS_NAME: , value = cisco.com,test.com
The above parameters are defined as follows:
INTERNAL_IPV4_ADDRESS - IP address allocated to VPN
INTERNAL_IPV4_DNS(1) - Internal DNS server
MODECFG_UNITY_SPLIT_INCLUDE - Number of networks in
the split tunnel list
SPLIT_NET #n - Details of each split tunnel network
passed down to client
MODECFG_UNITY_DEFDOMAIN - Default domain name
MODECFG_UNITY_SPLITDNS_NAME - List of internal
domains to be sent to
There is currently no specific troubleshooting information available
for this configuration. For additional troubleshooting information, refer to
Problems on the VPN 3000 Concentrator.