Wild card DNS is used in DNS record for domains, where anything.domainname will show the domain name page, it is also said that the wild card character used to search for text, and may represent any character (or any character in a set). A wild-card character is like a wild card in a card game, which may represent any other card in the deck. Wildcard DNS allows us to set up a host to respond to any particular hostname in the domain.

For eg : abc.domainname will show domainname page
To set up Wild Card, please follow the below steps ::
—————————————————————–
Enter the entry in Zone file ::

For eg :

#vi /var/named/domainname.db

; Modified by Web Host Manager
; Zone File for domainname
$TTL 14400
@ 86400 IN SOA ns1.eukhost.com. cpanel.eukhost.com. (
2006062906
86400
7200
3600000
86400
)

domainname. 86400 IN NS ns1.eukhost.com.
domainname. 86400 IN NS ns2.eukhost.com.

domainname. 14400 IN A IP
localhost.domainname. 14400 IN A 127.0.0.1
domainname. 14400 IN MX 0 domainname.

mail 14400 IN CNAME domainname.
www 14400 IN CNAME domainname.
ftp 14400 IN A IP
*.domainname. 14400 IN A IP

Due to clustering, this entry should be present on the all the Servers from where the DNS for the domain is resolving.

After entering this entry restart named on the Server.

Also, the entry has to be made in the virtual host on the server:
——————————————————————————
For eg :

#vi /usr/local/apache/conf/httpd.conf

ServerAlias www.domain.com domain.com *.domain.com
ServerAdmin webmaster@domain.com
DocumentRoot /home/user/public_html
BytesLog domlogs/domain.com-bytes_log
ServerName www.domain.com
User user
Group user
CustomLog /usr/local/apache/domlogs/domain.com combined
ScriptAlias /cgi-bin/ /home/user/public_html/cgi-bin/

After entering this entry, restart Apache server.

To an Administrator, there is nothing more peaceful than a stable and optimized DNS server. The moment something goes wrong, such as a mis-configuration, the server wakes up and starts crying; both sites and email systems goes down. An important way of creating a stable DNS environment is to use SOA records.

What are DNS Records? DNS records or Zone files are used for mapping URLs to IPs. Located on servers called the DNS servers, these records are typically the connection of your website with the outside world. Requests for your website are forwarded to your DNS servers and then get pointed to the web servers that serve the website or to Email servers that handle the incoming email.

This is how a typical Zone file (containing many common DNS records) looks like.

; Zone file for eukhost.com.
@ 86400 IN SOA ns1.eukhost.com. root.manou.eukhost.com. (
2006061904

86000

7200

3600000

86400 )

eukhost.com. NS IN 86400 ns1.eukhost.com.

eukhost.com. NS IN 86400 ns2.eukhost.com.

eukhost.com. 14400 IN A 69.20.54.201

localhost. eukhost.com. 14400 IN A 127.0.0.1

eukhost.com. 14400 IN MX 0 eukhost.com.

mail 14400 IN CNAME eukhost.com.

www 14400 IN CNAME eukhost.com.

ftp 14400 IN CNAME eukhost.com.

SOA Records

An SOA (State of Authority) Record is the most essential part of a Zone file. The SOA record is a way for the Domain Administrator to give out simple information about the domain, like how often it is updated when it was last updated, when to check back for more info, what the administrators email address is and so on. A Zone file can contain only one SOA Record.

A properly optimized and updated SOA record can reduce bandwidth between nameservers, increase the speed of website access and ensure the site is alive even when the primary DNS server is down.

Here is the SOA record. Notice the starting bracket “(“. This has to be on the same line, otherwise the record gets broken.

; name TTL class rr Nameserver email-address

@ 86400 IN SOA ns1.eukhost.com. root.linux5.nettoolz.net. (

2006061904 ; Serial number

86000 ; Refresh rate in seconds

7200 ; Update Retry in seconds

3600000 ; Expiry in seconds

86400 ; minimum in seconds )

• name - mydomain.com is the main name in this zone.

• TTL - 86400 - TTL defines the duration in seconds that the record may be cached by client side programs. If it is set as 0, it indicates that the record should not be cached. The range is defined to be between 0 to 2147483647 (close to 68 years !)

• Class - IN - The class shows the type of record. IN equates to Internet. Other options are all historic. So as long as your DNS is on the Internet or Intranet, you must use IN.

• Nameserver - ns.nameserver.com. -The nameserver is the server which holds the zone files. It can be either an external server in which case, the entire domain name must be specified followed by a dot. In case it is defined in this zone file, then it can be written as “ns’’ .

• Email address – root.linux5.nettoolz.net. -This is the email of the domain name administrator. Now, this is really confusing, because people expect an @ to be in an email address. However in this case, email is sent to [EMAIL=”root@ns.nameserver.com”] root@ns.nameserver.com[/EMAIL], but written as root.ns.nameserver.com . And yes, remember to put the dot behind the domain name.

• Serial number - 2006061904 - This is a sort of a revision numbering system to show the changes made to the DNS Zone. This number has to increment, whenever any change is made to the Zone file. The standard convention is to use the date of update YYYYMMDDnn, where nn is a revision number in case more than one updates are done in a day. So if the first update done today would be 2006061904 and second update would be 2006061905.

• Refresh - 86000 - This is time(in seconds) when the slave DNS server will refresh from the master. This value represents how often a secondary will poll the primary server to see if the serial number for the zone has increased (so it knows to request a new copy of the data for the zone). It can be written as “23h88M’’ indicating 23 hours and 88 minutes. If you have a regular Internet server, you can keep it between 6 to 24 hours.

• Retry - 7200 - Now assume that a slave tried to contact the master server and failed to contact it because it was down. The Retry value (time in seconds) will tell it when to get back. This value is not very important and can be a fraction of the refresh value.

• Expiry - 3600000 - This is the time (in seconds) that a slave server will keep a cached zone file as valid, if it can’t contact the primary server. If this value were set to say 2 weeks ( in seconds), what it means is that a slave would still be able to give out domain information from its cached zone file for 2 weeks, without anyone knowing the difference. The recommended value is between 2 to 4 weeks.

• Minimum - 86400 - This is the default time(in seconds) that the slave servers should cache the Zone file. This is the most important time field in the SOA Record. If your DNS information keeps changing, keep it down to a day or less. Otherwise if your DNS record doesn’t change regularly, step it up between 1 to 5 days. The benefit of keeping this value high, is that your website speeds increase drastically as a result of reduced lookups. Caching servers around the globe would cache your records and this improves site performance.

Increasing site speed

The time it takes to access a website on a browser includes the time it takes to look it up on the domain name server. By increasing the “Minimum’’ value, we’re telling the contacting clients to keep their copies of the zone file for a longer time. In effect, reducing the lookups to the nameserver. By reducing the number of times a client has to lookup, we’re increasing the site speed.

However, this also means that if you make changes to the DNS record, it will take longer to propagate. If you require to make frequent updates to your DNS records, make sure your Minimum value is lesser than 1 day. That means longer lookup times, but accurate information for the clients

If you are planning a major update on the DNS zone file(say moving to another server or hosting service), reduce the Minimum value a couple of days prior to the change. Then make the change and then jack up the minimum value again. This way the caching clients all over the world will pick up the changes quicker and yet you do not need to sacrifice on site speed thereafter.

How to improve backup

Always keep a secondary DNS server and keep a higher Expiry value. This will mean that even if the Primary server goes down, the secondary will have the cached copy(for as long as the Expiry value stands) and it will keep serving lookups. Keeping a secondary server but a low expiry value defeats the purpose of a Backup.

How to test SOA records

You have set the new SOA values, and you want to know whether the update has taken place. “Dig’’ is a good tool to troubleshoot and check for DNS information.

For example to check out the SOA records of yahoo.com from all the nameservers, primary and secondary, all you need to do is

# dig google.com nssearch

SOA ns1.eukhost.com. root.manou.eukhost.com. 2006072101 28800 7200 3600 86400 from server ns2.eukhost.com in 1 ms.

SOA ns1.eukhost.com. root.manou.eukhost.com. 2006072101 28800 7200 3600 86400 from server ns1.eukhost.com in 28 ms.

A Static URL connects to a destination without calling a script. No programming scripts are generated when a static URL is selected. Therefore the destination URL is identical to the starting point URL. A static URL is always a starting point URL. A static URL would read like http://www.mydomain.com/products/productname/

A Dynamic URL processes a script to connect to a destination. Dynamic URLs are becoming increasingly common with vendors and should be analyzed carefully. A dynamic URl would read like http://www.mydomain.com/link.asp?id=100408. Most dynamic URLs become transformed at the destination.
For eg. http://www.mydomain.com/link.asp?id=100408
becomes transformed to this
http://www.mydomain.com/app/home/journal.asp?wasp=3d1xhxwvup7tng64qwtm&referrer=parent&backto=linkingpublicationresults,1,1

In this case, the destination URL is not persistent and therefore should not be used as a starting point URL.

It is believed that the search engines do not like dynamic URLs because of the difficulties they have had indexing and reading them in the past and the users are also not in love with URLs like http://domain.com/product.php?cid=1&pid=5  because such URLs do not tell much about the contents of the page.

Static URLs score better than dynamic URLs for a few other reasons too. Dynamic URLs are not always there i.e. the page is generated on request after the user performs a specific action like filling a form and submit it or performing a search using the site’s search engine. Which indirectly means that such pages are nonexistent for search engines, because they index the Web by crawling it, not by filling in forms.

Even if a dynamic page has already been generated by a previous user request and is stored on the server, search engines might just skip it if it has too many question marks and other special symbols in it. Earlier the search engines did not index dynamic pages at all, while today they do index them but generally slower than they index static pages.

One of the solutions of the dynamic URLs problem is called URL rewrite. There are various tools which are different for different platforms and servers that rewrite URLs in a friendlier format, so they appear in the browser like normal HTML pages.