In some cases you may be allocated a block of IP addresses smaller than a /24. This is referred to as a Classless Delegation and is explained in technical detail in RFC 2317.
For example, if your ISP allocated the block 192.168.5.224/27 (the 32 IP addresses from 192.168.5.224 to 192.168.5.255), the reverse DNS for this zone would be served out of a zone named
224-27.5.168.192.in-addr.arpa
Once the zone is created, you'll be able to create PTR entries within this zone for each individual IP address. As an example, to map the IP address 192.168.5.226 to mail.example.com, you would enter:
Host:
226
TTL:
86400
Type:
PTR
Data:
mail.example.com
Once you have setup the Custom DNS zone for this block, you need to have the block delegated to us. Contact your ISP and have them create NS records for the zone:
224-27.5.168.192.in-addr.arpa. 86400 IN NS ns1.mydyndns.org. 224-27.5.168.192.in-addr.arpa. 86400 IN NS ns2.mydyndns.org. 224-27.5.168.192.in-addr.arpa. 86400 IN NS ns3.mydyndns.org. 224-27.5.168.192.in-addr.arpa. 86400 IN NS ns4.mydyndns.org. 224-27.5.168.192.in-addr.arpa. 86400 IN NS ns5.mydyndns.org.
Your ISP will ALSO need to create individual CNAME records for each IP address they have delegated to you. These CNAME records map the IP addresses into the new name space that has been defined via the 224-27.5.168.192.in-addr.arpa zone.
224.5.168.192.in-addr.arpa. 86400 IN CNAME 224.224-27.5.168.192.in-addr.arpa. 225.5.168.192.in-addr.arpa. 86400 IN CNAME 225.224-27.5.168.192.in-addr.arpa. 226.5.168.192.in-addr.arpa. 86400 IN CNAME 226.224-27.5.168.192.in-addr.arpa. etc...
Until those changes are made, DNS queries for those IP addresses won't come to us, so it is not enough to simply create the zone. You MUST get it delegated to us and have the CNAME entries created in order for the reverse DNS to function.
All records in DNS have a Time to Live (TTL) value. This value dictates how long a record should be stored locally before a new copy of the record must be retrieved from DNS. The record storage is known as the DNS cache, and the act of storing records is called caching.
There are many different places where DNS caches exist: on your local computer, with your ISP's recursive DNS servers, and even the root servers at the core of the Domain Name System. These caches reduce the number of queries that need to be resolved by nameservers.
Sometimes the information in DNS changes, but the old information is still stored in the DNS caches at varying levels. When the cached record is different from the newest information in DNS, it is called a caching error.
How do I fix a caching error?
Depending on your operating system, there are different methods of clearing your local DNS cache. Removing all of your stored DNS information is known as cache flushing. Please see the following list for instructions on how to flush your DNS cache in most common operating systems. (Before flushing the DNS cache, clear out your web browser's temporary files and close all browser windows.)
Windows
In Windows 98/2000/ME/XP, open a command prompt and type the following to clear the Windows DNS Resolver:
ipconfig /flushdns
Unix
In most *nix operating systems (Unix, Linux, FreeBSD, etc.), type the following to restart the nscd daemon:
/etc/rc.d/init.d/nscd restart
Mac OSX
In Mac OSX, open a command prompt and type the following to clear the DNS resolver cache:
dscacheutil -flushcache
In older versions, the command is:
lookupd -flushcache
Some records are cached by your ISP's recursive DNS servers, which are servers that do the 'legwork' of lookups on behalf of subscribers. If a caching error occurs at this level, clearing your local cache will not solve the issue, as your ISP will keep returning the old, incorrect records to your queries. If this happens, you will need to wait for the records to expire naturally.
Common TTL Values
The default or recommended value for the DNS record types in our Dynamic DNS and Custom DNS services are:
In the Expert interface, you can modify the TTL value for any record type. If you do change the default TTLs, values lower than 20 have no noticeable impact on propagation time, and TTL values higher than 86400 (twenty four hours) are likewise unnecessary and can lead to problems if the record needs to be changed.
Caching Issues
When a client attempts to access a domain before it exists, a "does not exist" record will be saved. The TTL for these records varies from server to server, but the average TTL is about 2 hours. During this time period, domain name resolution may not be possible.
Why do some records have such high TTLs?
As discussed earlier, the TTL values of records exist to ease the query load on nameservers. Many records, such as MX or CNAME records, are expected to change very rarely, so they are usually given high TTL to prevent unnecessary extra lookups. Other records, such as hosts assigned to dynamic IP addresses, are given very low TTLs, as they are expected to change at a moment's notice. Unnecessarily low TTLs will also slow clients as they will be forced to perform extra DNS queries.
Reverse DNS records (PTR) are generally served out of a reverse zone. For instance, if you have been assigned the block of addresses 192.168.5/24 (the 256 IP addresses from 192.168.5.0 to 192.168.5.255), the reverse DNS for this zone would be served out of a zone named
5.168.192.in-addr.arpa
In such a case, you would setup Custom DNS for that zone, selecting the Expert interface option (PTR records can only be added in this interface). Once the zone is created, you'll be able to create PTR entries within this zone for each individual IP address. As an example, to map the IP address 192.168.5.12 to mail.example.com, you would enter:
Host:
12
TTL:
86400
Type:
PTR
Data:
mail.example.com
Note that is you have multiple /24 blocks, you will need a separate zone for each block.
Once you have setup the Custom DNS zone for this block, you need to have the block delegated to us. Contact your ISP (or whomever is assigning this block of addresses to you) and have them create NS records for the zone:
5.168.192.in-addr.arpa. 86400 IN NS ns1.mydyndns.org. 5.168.192.in-addr.arpa. 86400 IN NS ns2.mydyndns.org. 5.168.192.in-addr.arpa. 86400 IN NS ns3.mydyndns.org. 5.168.192.in-addr.arpa. 86400 IN NS ns4.mydyndns.org. 5.168.192.in-addr.arpa. 86400 IN NS ns5.mydyndns.org.
Until that delegation is made, DNS queries for those IP addresses won't come to us, so it is not enough to simply create the zone. You MUST get it delegated to us in order for the DNS to function.
In some cases your ISP may not want to create NS records for your allocation, especially if the ISP has assigned a large number of very small blocks to individual customers. In such a case, they can still allow you to control the reverse by using the method discussed in section 5.2 "Alternative naming conventions" of RFC 2317.
Let's say, for example that your ISP has provided you with 4 IP addresses, 192.168.5.27 - 192.168.5.30. Not only is this a very small block, but it doesn't fall on an octet boundary. Thus it is actually not possible to use the above described method.
In such a case, instead of having the ISP create NS records for Classless delegation, you would have them create CNAME records within the 5.168.192.in-addr.arpa zone like this:
27.5.168.192.in-addr.arpa 86400 IN CNAME 27.rev.example.com 28.5.168.192.in-addr.arpa 86400 IN CNAME 28.rev.example.com 29.5.168.192.in-addr.arpa 86400 IN CNAME 29.rev.example.com 30.5.168.192.in-addr.arpa 86400 IN CNAME 30.rev.example.com
Then, in the Custom DNS zone for example.com you would create PTR records like this:
Host:
27.rev
TTL:
86400
Type:
PTR
Data:
mail.example.com
Important: Just as with the earlier example, unless your ISP does their part and create the necessary CNAME records, DNS queries to resolve the IP addresses won't come to us and those PTR records will be useless. Not all ISPs are willing to do this, even for customers who have static IP addresses (if you have a dynamic IP address, they almost certainly won't create these for you).
Reverse DNS provide mappings from IP addresses to host names. For more info on this, see the Reverse DNS KB article.
Reverse DNS should not be created in Custom DNS. Instead, it is usually best to contact your ISP and request DNS records to be created for your IP. Also, only in rare circumstances is it necessary to delegate individual or few amounts of IP addresses to DynDNS.com.