TCPware FAQ: DNS
Can I have newly edited host file entries take effect immediately?
Yes. The resolver (the TCPware_DNS process) checks the host file periodically for changes and reloads it if it has been modified. You can force it to reload the file by stopping and starting the resolver with the following commands:
$ NETCU STOP/DNS $ @TCPWARE:STARTUP_RESOLVER DETACH
How often is the DDNS zone information checkpointed to the zone file, and is this configurable?
The zone goes into maintenance on an hourly basis, and it is not a configurable time interval. The changes are written temporarily to a log file, and then re-applied if something happens to the server. When the server starts up, it looks for the log file and applies any changes if the file is there.
When changes are made to the NAMED files on the primary DNS server the files are not transferred to the secondary DNS servers.
The zone transfers must not be taking place. Make sure that when the NAMED files on the primary are edited that the serial number in the SOA record is being incremented. Also after making changes on the primary DNS server you have to restart DNS (@TCPWARE:RESTART DNS) in order for the changes to become live. The secondary servers will compare the serial numbers every refresh period and start a zone transfer to get the updated file.
How often is the host file reloaded?
The TCPware resolver, TCPWARE_DNS, checks the HOSTS. file every 10 minutes for changes. If there are any changes, the file is reloaded.
How can an MX record be added for a domain of univ.edu which will point to a specific host?
Edit the host file for that domain, i.e. TCPWARE_NAMED_ROOT:NAMED.HOSTS.
After the SOA record and NS records for the domain add one or more MX records for the domain. For example to have all mail addressed to user@univ.edu be delivered to the host mail1.univ.edu the NAMED.HOSTS file would contain the following:
@ IN SOA univ.edu. sysmgr.univ.edu. (
1 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS univ.edu.
IN A 192.168.0.1
;
univ.edu. IN MX 1 mail1.univ.edu
mail1 IN A 192.168.0.2
;
The MX record above says that any mail addressed to a univ.edu should be sent to the gateway mail1.univ.edu. The 1 in the MX record is the preference. The preference is the order of delivery when one host has multiple MX records. A host can have multiple MX records so that if an attempt to reach one of the gateways is unsuccessful another can be tried. An example of this would be if the above NAMED.HOSTS was changed to be as follows:
@ IN SOA univ.edu. sysmgr.univ.edu. (
1 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS univ.edu.
IN A 192.168.0.1
;
univ.edu. IN MX 1 mail1.univ.edu
univ.edu. IN MX 2 mail2.univ.edu
mail1 IN A 192.168.0.2
mail2 IN A 192.168.0.3
;
In the example above mail addressed to univ.edu would be sent to the gateway with the lowest preference value, mail1.univ.edu, and if that was unsuccessful it would then be sent to mail2.univ.edu.
Why does my TCPware system not get the correct IP address changed in DNS, even after rebooting to make sure it was not in the DNS cache?
TCPware will, by default, resolve names from the TCPWARE:HOSTS file before DNS. Edit TCPWARE:HOSTS. to change the entry to reflect the new IP address. Then restart the DNS resolver:
$ NETCU STOP/DNS $ @TCPWARE:STARTUP_RESOLVER DETACH
Why can some DNS clients not resolve names when they are configured to use the secondary address as their nameserver?
If your DNS client checks to ensure that the response it gets to a DNS query comes from the same address that the query was sent to, then they will not be able to use the secondary address as their nameserver. This is due to the way secondary addresses work on TCPware. If the client can be configured to accept responses from addresses other than the one the query was sent to, this will workaround the problem.
You can also configure pseudo devices instead of using secondary addresses. DNS queries sent to a name server running on pseudo devices will get answered from the address they were sent to and will correct the problem.
There is a secondary address configured on a TCPware system that is also running as a DNS nameserver. Some DNS clients can not resolve names when they are configured to use the secondary address as their DNS nameserver. Why?
If a DNS client checks to ensure that the response it gets from a DNS query comes from the same address that the query was sent to, then it will not be able to use the secondary address as its nameserver. This is due to the way secondary addresses work on TCPware.
There are two possible solutions:
- If the client can be configured to accept responses from addresses other than the one the query was sent to, the problem will be eliminated.
- Pseudo devices can be used instead of secondary addresses. DNS queries sent to a name server running on a pseudo device will be answered from the address they were sent to and will correct this problem.
Why is the secondary nameservers not picking up the change to a DNS zone file on the primary nameserver?
When making a change to a DNS zone file, the Serial # field MUST be incremented in order for the secondary nameservers to realize that a change has been made and to request a zone transfer. The serial number is located in the SOA record that is generally at the top of a zone file. The following is an example of an SOA record:
@ IN SOA host.domain. sysmgr. host.domain. ( 25; Serial 3600; Refresh 600; Retry 3600000; Expire 86400); Minimum
In this case the serial number of 25 would be incremented to 26 if you were to make a change to this file.
Can this behavior be changed? When TCPware does a lookup on a host name and the host name is available in DNS and the hosts. file, it gives the answer found in the hosts. file and not in DNS.
By default the TCPware resolver looks in the hosts. file first (local) and then in DNS (bind). The order is determined by the logical TCPWARE_SVCORDER. You can redefine this logical when TCPware starts by adding the symbol TCPIP_SVCORDER to the file TCPWARE:TCPWARE_CONFIGURE.COM. Adding the following line to the file would change the lookup order form the default of "local,bind" to "bind,local".
$ TCPIP_SVCORDER == "bind,local"
Is there a way to make new hosts entered in the hosts. file immediately available?
When TCPware starts, the information from the hosts. file is read by the TCPware_DNS process (DNS_CLIENT) and cached. Then, when a host name or address is looked up, the DNS_CLIENT is able to look in cache for the information instead of having to look in the hosts. file. This improves the performance of the lookups. TCPware checks for changes in the hosts. file every 10 minutes and if there are changes, reloads the information from the hosts. file into cache. Use the following command to stop and start the DNS_CLIENT to force changes to the hosts. file to be read into cache:
$ NETCU STOP/DNS $ @TCPWARE:STARTUP_RESOLVER DETACH
DNS: Tips on configuring
When configuring DNS you should do the following at a minimum:
- Make sure that the
NETCU_DOMAIN(inTCPWARE:TCPWARE_CONFIGURE.COM) is set to your fully qualified hostname. i.e. VAXA.COMPANY.COM. - Run @TCPWARE:CNFNET DNS. This will create the default NAMED files for you.
- Edit the NAMED database file,
NAMED.BOOT,NAMED.LOCAL,NAMED.HOSTSandNAMED.REV, located inTCPWARE_SPECIFIC:[TCPWARE.NAMED]
The TCPware Management Guide has a complete chapter describing how DNS works and how the database files should look.