What is Caching Name Server ?

Caching Name Servers

A Caching Server obtains information from another server (a Zone Master) in response to a host query and then saves (caches) the data locally. On a second or subsequent request for the same data the Caching Server will respond with its locally stored data (the cache) until the time-to-live (TTL) value of the response expires at which time the server will refresh the data from the zone master.
If the caching server obtains its data directly from a zone master it will respond as 'authoritative', if the data is supplied from its cache the response is 'non-authoritative'.
The default BIND behaviour is to cache and this is associated with the recursion parameter (the default is 'recursion yes'). There are many configuration examples which show caching behaviour being defined using a type hint statement in a zone declaration. These configurations confuse two distinct but related functions. If a server is going to provide caching services then it must provide recursive queries and recursive queries need access to the root servers which is provided via the 'type hint' statement. A caching server will typically have a named.conf file which includes the following fragment:

// options section fragment of named.conf
// recursion yes is the default and may be omitted
options {
directory "/var/named";
version "not currently available";
recursion yes;
};
// zone section
....
// the DOT indicates the root domain = all domains
zone "." IN {
type hint;
file "root.servers";
};

---

Note

1. BIND defaults to recursive queries which by definition provides caching behaviour. The named.conf recursion parameter controls this behaviour.
   
2. The zone '.' is shorthand for the root domain which translates to 'any domain not defined as either a master or slave in this named.conf file'.
   
3. cache data is discarded when BIND is restarted.
   

The most common DNS server caching configurations are:

1. A DNS server acting as master or slave for one or more zones (domains) and as cache server for all other requests. A general purpose DNS server.
   
2. A caching only local server - typically used to minimise external access or to compensate for slow external links. This is sometimes called a Proxy server though we prefer to associate the term with a Forwarding server.
   

To cache or not is a crucial question in the world of DNS. BIND is regarded as the reference implementation of the DNS specification. As such it provides excellent - if complex to configure - functionality. The down side of generality is suboptimal performance on any single function - in particular caching involves a non-trivial performance overhead.
For general usage the breadth of BIND functionality typically offsets any performance concerns. However if the DNS is being 'hit' thousands of times per second performance is a major factor. There are now a number of alternate Open Source DNS servers some of which stress performance. These servers typically do NOT provide caching services (they are said to be'Authoritative only' servers).
Example configuration files for a caching DNS are provided.
Note The response to a query is Authoritative under three conditions:

1. The response is received from a Zone master.
   
2. The response is received from a Zone slave with non time-expired zone data.
   
3. The response is received by a caching server directly from either a Zone master or slave. If the response is read from the cache directly it is not authoritative.
   

[ Read More ]

How to update zone files ?

Update Zone files

The initial design of DNS allowed for changes to be propagated using Zone Transfer (AXFR) but the world of the Internet was simpler and more sedate in those days (1987). The desire to speed up the process of zone update propagation while minimising resources used has resulted in a mumber of changes to this aspect of DNS design and implementation from simple - but effective - tinkering such as Incremental Zone Transfer (IXFR) and Notify messages to the concept of Dynamic Updates which have significant security consequences if not properly implemented.
Warning: While zone transfers are generally essential for the operation of DNS systems they are also a source of threat. A slave DNS can become poisoned if it accepts zone updates from a malicious source. Care should be taken during configuration to ensure that, as a minimum, the 'slave' will only accept transfers from known sources. The example configurations provide these minimum precautions. Security Overview outlines some of the potential threats involved.

---

Full Zone Update (AXFR)
The original DNS specifications (RFC 1034 & RFC 1035) envisaged that slave (or secondary) DNS servers would 'poll' the 'master'. The time between such 'polling' is determined by the REFRESH value on the domain's SOA Resource Record.
The polling process is accomplished by the 'slave' sending a query to the 'master' and requesting the latest SOA record. If the SERIAL number of this record is different from the current one maintained by the 'slave' a zone transfer (AXFR) is requested. This is why it is vital to very disciplined about updating the SOA serial number every time anything changes in ANY of the zone records.
Zone transfers are always carried out using TCP on port 53 whereas normal DNS query operations use UDP on port 53.

Incremental Zone Update (IXFR)

Transferring very large zone files can take a long time and waste bandwidth and other resources. This is especially wasteful if only a single record has been changed! RFC 1995 introduced Incremental Zone Transfers (IXFR) which as the name suggests allows the 'slave' and 'master' to transfer only those records that have changed.
The process works as for AXFR. The 'slave' sends a query for the domain's SOA Resource Record every REFRESH interval. If the SERIAL value of the SOA record has changed the 'slave' requests a Zone Transfer and indicates whether or not it is capable of accepting an Incremental Transfer (IXFR). If both 'master' and 'slave' support the feature an Incremental Transfer (IXFR) takes place otherwise a Full Zone Transfer (AXFR) takes place. Incremental Zone transfers use TCP on port 53 whereas normal DNS queries operations use UDP on port 53.
The default mode for BIND when acting as a 'slave' is to use IXFR unless it is configured not to using the request-ixfr parameter in the server or options section of the named.conf file.
The default mode for BIND when acting as a 'master' is to use IXFR only when the zone is dynamic.The use of IXFR is controlled using the provide-ixfr parameter in the server or options section of the named.conf file.

Notify (NOTIFY)

RFC 1912 recommends a REFRESH interval of up to 12 hours on the REFRESH interval of an SOA Resource Record. This means that changes to the 'master' DNS may not be visible at the 'slave' DNS for up to 12 hours. In a dynamic environment this may be unacceptable.
RFC 1996 introduced a scheme whereby the master will send a NOTIFY message to the slave DNS systems that a change MAY have occurred in the domain records. The 'slave' on receipt of the NOTIFY will request the latest SOA Resource Record and if the SERIAL value is different will attempt a Zone Transfer using either a full Zone Transfer (AXFR) or an Incremental Transfer (IXFR).
NOTIFY behaviour in BIND is controlled by notify, also-notify and notify-source parameters in the zone or options statements of the named.conf file.

Dynamic Update

The classic method of updating Zone Resource Records is to manually edit the zone file and then stop and start the name server to propagate the changes. When the volume of changes reaches a certain level this can become operationally unacceptable - especially considering that in organisations which handle large numbers of Zone Files, such as service providers, BIND itself can take a long time to restart at it plows through very large numbers of zone statements.
The 'holy grail' of DNS is to provide a method of dynamically changing the DNS records while DNS continues to service requests.
There are two architectural approaches to solving this problem:

1. Allow 'run-time' updating of the Zone Records from an external source/application.
   
2. Directly feed the DNS from a database which can be dynamically updated. BIND provides two APIs to enable this, other DNS implemenations provide embedded database access.
   

RFC 2136 takes the first approach and defines a process where zone records can be updated from an external source. The key limitation in this specification is that a new domain cannot be added dynamically. All other records within an existing zone can be added, changed or deleted. This limitation is also true for both of BIND's APIs as well.
As part of RFC 2136 the term Primary Master was coined to describe the Name Server defined in the SOA Resource Record for the zone. The significance of this term is that when dynamically updating records it is essential to update only one server even though there may be multiple master servers for the zone. In order to solve this problem a 'boss' server must be selected, this 'boss' server (the Primary Master) has no special characteristics other than it is defined as the Name Server in the SOA record and may appear in an allow-update clause to control the update process.
DDNS is normally associated with Secure DNS features such as TSIG – RFC 2845 & TKEY – RFC 2930. Dynamic DNS (DDNS) does not REQUIRE TSIG/TKEY. However by enabling Dynamic DNS you are also opening up the possibility of master zone file corruption or poisoning. Simple IP address protection (acl) can be configured into BIND but this provides - at best - limited protection. For that reason, serious users of Dynamic DNS will always use TSIG/TKEY procedures to authenticate incoming update requests.
In BIND DDNS is defaulted to deny from all hosts. Control of Dynamic Update is provided by the BIND allow-update usable with and without TSIG/TKEY) and update-policy (only usable with TSIG/TKEY) clauses in the zone or options statements of the named.conf file.
There are a number of Open Source tools which will initiate Dynamic DNS updates these include dnsupdate (not the same as DNSUpdate) and nsupdate which is distributed with bind-utils.

Alternative Dynamic DNS Approaches

As noted above the major limitation in the standard Dynamic DNS (RFC 2136) approach is that new domains cannot be created dynamically.
BIND-DLZ takes a much more radical approach and, using a serious patch to BIND, allows replacement of all zone files with a single zone file which defines a database entry. The database support, which includes most of the major databases (MySQL, PostgreSQL, BDB and LDAP among others) allows the addition of new domains as well as changes to pre-existing domains without the need to stop and start BIND. As with all things in life there is a trade-off and performance can drop precipitously. Current work being carried (early 2004) out with a High performance Berkeley DB (BDB) is showing excellent results approaching raw BIND performance.
PowerDNS an authoritative only name server takes a similar approach with its own (non-BIND) code base by referring all queries to the database back-end and thereby allow new domains to be added dynamically.

[ Read More ]

How to configure Slave Name Server

Slave (Secondary) Name Servers

A Slave DNS gets its zone data using a zone transfer operation (typically from a zone master) and it will respond as authoritative for those zones for which it is defined to be a 'slave' and for which it has a currently valid zone configuration. It is impossible to determine from a query result that it came from a zone master or slave.
The term 'slave' was introduced in BIND 8.x and replaced the term 'secondary'.
There can be any number of slave DNS's for any given zone.
Slave status is defined in BIND by including 'type slave' in the zone declaration section of the named.conf file as shown by the following fragment.

// example.com fragment from named.conf
// defines this server as a zone slave
zone "example.com" in{
type slave;
file "sec/sec.example.com";
masters {192.168.23.17;};
};

---

Notes

1. The master DNS for each zone is defined in the 'masters' statement of the zone clause and allows slaves to refresh their zone record when the 'expiry' parameter of the SOA Record is reached. If a slave cannot reach the master DNS when the 'expiry' time has been reached it will stop responding to requests for the zone. It will NOT use time-expired data.
   
2. The file parameter is optional and allows the slave to write the transferred zone to disc and hence if BIND is restarted before the 'expiry' time the server will use the saved data. In large DNS systems this can save a considerable amount of network traffic.
   

Assuming NOTIFY is allowed in the master DNS for the zone (the default behaviour) then zone changes are propagated to all the servers defined with NS Records in the zone file. Other acceptable NOTIFY sources can be defined using the allow-notify parameter in named.conf.
Example configuration files for a slave DNS are proviided.

• But Slaves can also be Masters

Oh, stop this pain. This section can get a bit confusing. Read it only when accompanied by your favorite keep-me-awake-cos-I-can't-take-anymore-of-this-stuff beverage.
The definition of a slave server is simply that it gets its zone data via zone transfer whereas a master gets its zone data from a local file system. The source of the zone transfer could just as easily be another slave as a master.
So what sane human would want to do that?

1. Assume you want to hide your master servers in, say, a stealth configuration then at least one slave server will sit on the public side of a firewall, or similar configuration, providing perimeter defence. To provide resilience you would need two or more such public slaves. The second slave can be updated from the same master as the first or it could be updated from the slave server - we'll call it the 'boss' slave to avoid getting into tortuous terminology (is it a master-slave or a slave-master?). To configure this miracle the second slave server would define the 'boss' slave's IP in its masters statement. When the 'boss' slave has sucessfully transfered a zone file (from the master) it will send out NOTIFY messages (the default) unless configured not to do so. This type of configuration will marginally increase latency for updating the zone on the second slave - but that may be more than offset by increased stealth.
   
2. In a DNSSEC environment the master will likely have all kinds of whizzo dodads concerned with keeping keys secure. Whereas DNSSEC slaves simply send the data in the zone file in response to queries and have no requirements for secure key maintenance. Hidden master configurations will become increasingly the norm in this environment.
   

[ Read More ]

How to configure Master Name Server

Master(Primary)NameServers

A Master DNS defines one or more zone files for which this DNS is Authoritative ('type master'). The zone has been delegated (via an NS Resource Record) to this DNS.
The term 'master' was introduced in BIND 8.x and replaced the term 'primary'.
Master status is defined in BIND by including 'type master' in the zone declaration section of the name.conf file as shown by the following fragment.

// example.com fragment from named.conf
// defines this server as a zone master
zone "example.com" in{
type master;
file "pri.example.com";
};

---

Notes

1. The terms Primary and Secondary DNS entries in Windows TCP/IP network properties mean nothing, they may reflect the 'master' and 'slave' name-server or they may not - you decide this based on operational need, not BIND configuration.
   
2. It is important to understand that a zone 'master' is a server which gets its zone data from a local source as opposed to a 'slave' which gets its zone data from an external (networked) source (typically the 'master' but not always). This apparently trivial point means that you can have any number of 'master' servers for any zone if it makes operational sense. You have to ensure (by a manual or other process) that the zone files are synchronised but apart from this there is nothing to prevent it.
   
3. Just to confuse things still further you may run across the term 'Primary Master' this has a special meaning in the context of dynamic DNS updates and is defined to be the name server that appears in the SOA RR record.
   

When a master DNS receives Queries for a zone for which it is authoritative then it will respond as 'Authoritative' (AA bit is set in a query response).
If a DNS server receives a query for a zone for which it is neither a Master nor a Slave then it will act as configured (in BIND this behaviour is defined in the named.conf file :

1. If caching behaviour is permitted and recursive queries are allowed the server will completely answer the request or return an error.
   
2. If caching behaviour is permitted and Iterative (non-recursive) queries are allowed the server can respond with the complete answer (if it is already in the cache because of another request), a referral or return an error.
   
3. If caching behaviour is NOT permitted (an 'Authoritative Only' DNS server) the server will return a referral or an error.
   

A master DNS server can NOTIFY zone changes to defined (typically slave) servers - this is the default behaviour. NOTIFY messages ensure zone changes are rapidly propagated to the slaves (interrupt driven) rather than rely on the slave server periodically polling for changes. The BIND default is to notify the servers defined in NS records for the zone - except itself, obviously.
A zone master can be 'hidden' (only one or more of the slaves know of its existence). There is no requirement in such a configuration for the master server to appear in an NS RR for the domain. The only requirement is that two (or more) name servers support the zone. Both servers could be any combination of master-slave, slave-slave or even master-master.
If you are running Stealth Servers and wish them to be notified you will have to add an also-notify parameter as shown in the BIND named.conffile fragment below:

// example.com fragment from named.conf
// defines this server as a zone master
// 192.168.0.2 is a stealth server NOT listed in a NS record
zone "example.com" in{
type master;
also-notify {192.168.0.2;};
file "pri/pri.example.com";
};

You can turn off all NOTIFY operations by specifying 'notify no' in the zone declaration.
Example configuration files for a master DNS Are provided.

[ Read More ]

How many way to Query to DNS ?

Way to Query to DNS ?

The major task carried out by a DNS server is to respond to queries (questions) from a local or remote resolver or other DNS acting on behalf of a resolver. A query would be something like 'what is the IP address of fourm.infoporch.com'.
A DNS server may receive such a query for any domain. DNS servers may be configured to be authoritative for some domains, slaves for others, forward queries or other combinations.
Most of the queries that a DNS server will receive will be for domains for which it has no knowledge, that is, for which it has no local zone files. DNS software typically allows the name server to respond in different ways to queries about which it has no knowledge.
There are three types of queries defined for DNS:

1. A recursive query - the complete answer to the question is always returned. DNS servers are not required to support recursive queries.
   
2. An Iterative (or non-recursive) query - where the complete answer MAY be returned or a referral provided to another DNS. All DNS servers must support Iterative queries.
   
3. An Inverse query - where the user wants to know the domain name given a resource record. Reverse queries were poorly syupported, very infrequent and are now obsolete (RFC 3425).
   

Note: The process called Reverse Mapping (returns a host name given an IP address) does not use Inverse queries but instead uses Recursive and Iterative (non-recursive) queries using the special domain name IN-ADDR.ARPA.
Historically reverse IPv4 mapping was not mandatory. Many systems however now use reverse mapping for security and simple authentication schemes (especially mail servers) so proper implementation and maintenance is now practically essential. Further IPv6 mandates reverese mapping.

---

Recursive Queries

A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries and both the resolver (or another DNS acting recursively on behalf of another resolver) negotiate use of recursive service using bits in the query headers.
There are three possible responses to a recursive query:

1. The answer to the query accompanied by any CNAME records (aliases) that may be useful. The response will indicate whether the data is authoritative or cached.
   
2. An error indicating the domain or host does not exist (NXDOMAIN). This response may also contain CNAME records that pointed to the non-existing host.
   
3. An temporary error indication - for instance, can't access other DNS's due to network error etc..
   

In a recursive query a DNS server will, on behalf of the client (resolver), chase the trail of DNS across the universe to get the real answer to the question. The journey of a simple query such as 'what is the IP address of fourm.infoporch.com' to a DNS server which supports recursive queries but is not authoritative for infoporch.com could look something like this:

1. Resolver on a host sends query 'what is the IP address of fourm.infoporch.com' to locally configured DNS server.
   
2. DNS server looks up fourm.infoporch.com in local tables (its cache) - not found
   
3. DNS sends query to a root-server for the IP of fourm.infoporch.com.
   
4. The root-server replies with a referral to the TLD servers for .com
   
5. The DNS server sends query 'what is the IP address fourm.infoporch.com' to one of the .com TLD servers.
   
6. The TLD server replies with a referral to the name servers for infoporch.com.
   
7. The DNS server sends query 'what is the IP address fourm.infoporch.com' to name server for infoporch.com.
   
8. Zone file defines a CNAME record CNAME record which shows fourm is aliased to joe. DNS returns both the CNAME for fourm and the A record for joe.
   
9. send response joe=x.x.x.x (with CNAME record fourm=joe) to original client resolver. Transaction complete.
   

Iterative (non-recursive) Queries

A Iterative (or non-recursive) query is one where the DNS server may provide a partial answer to the query (or give an error). DNS servers must support non-recursive queries.
There are four possible responses to a non-recursive query:

1. The answer to the query accompanied by any CNAME records (aliases) that may be useful. The response will indicate whether the data is authoritative or cached.
   
2. An error indicating the domain or host does not exist (NXDOMAIN). This response may also contain CNAME records that pointed to the non-existing host.
   
3. An temporary error indication, for instance, can't access other DNS's due to network error etc..
   
4. A referral: the name and IP addess(es) or one or more name server(s) that are closer to the requested domain name. This may, or may not be, the authoritative name server for the target domain.
   

The journey of a simple query such as 'what is the IP address of fourm.infoporch.com' to a DNS server which supports Iterative (non-recursive) queries but is not authoritative for example.com could look something like this:

1. Resolver on a host sends query 'what is the IP address fourm.infoporch.com' to locally configured DNS server.
   
2. DNS server looks up fourm.infoporch.com in local tables (its cache) - not found
   
3. The DNS replies with a referral containing the root-servers
   
4. Resolver sends query to a root-server for the IP of fourm.infoporch.com
   
5. The root-server replies with a referral to the TLD servers for .com
   
6. The Resolver sends query 'what is the IP address fourm.infoporch.com' to .com TLD server.
   
7. The TLD server replies with a referral to the name servers for infoporch.com
   
8. The Resolver sends query 'what is the IP address fourm.infoporch.com' to name server for infoporch.com.
   
9. Zone file defines a CNAME record which shows fourm is aliased to joe. DNS returns both the CNAME and the A record for joe.
   
10. Transaction complete.
    

Note: The above sequence is highly artificial since the resolver on Windows and most *nix systems is a stub resolver - which is defined in the standards to be a minimal resolver which cannot follow referrals. If you reconfigure your local PC or Workstation to point to a DNS server that only supports Iterative queries - it will not work. Period.

Inverse Queries

Historically an Inverse query maps a resource record to a domain. An example Inverse query would be 'what is the domain name for this MX record'. Inverse query support is optional and it is permitted for the DNS server to return a response Not Implemented.
Inverse queries are NOT used to find a host name given an IP address. This process is called Reverse Mapping (Look-up) uses recursive and Iterative (non-recursive) queries with the special domain name IN-ADDR.ARPA. Inverse queries went the way of all "seemed like a good idea at the time" concepts when they were finally obsoleted by RFC 3425.

[ Read More ]

How many type of DNS Server

DNS Configuration Types

Most DNS servers are schizophrenic - they may be masters (authoritative) for some zones, slaves for others and provide caching or forwarding for all others. Many observers object to the concept of DNS types partly because of the schizophrenic behaviour of most DNS servers and partly to avoid confusion with the name.conf zone parameter 'type' which only allows master, slave, stub, forward, hint). Nevertheless, the following terms are commonly used to describe the primary function or requirement of DNS servers.

Notes

• Running any DNS server that does not need to support recursive queries for external users (an Open DNS) is a bad idea. While it may look like a friendly and neighbourly thing to do it carries with it a possible threat that it may be used in DDoS attacks as well as an increased risk of cache poisoning. The various configurations have been modified to ensure that the DNS stays Closed to non-permitted users.
• One of the basic rules of security is that only the minimum services necessary to meet the objectives should be deployed. This means that a secure DNS server should provide only a single function, for instance, authoritative only, or caching only, not both capabilities in the same server. This is a correct but idealistic position, generally possible only in larger organizations. In practice many of us run mixed mode DNS servers. While much can be done to mitigate any security implications it must always be accepted that, in mixed configurations, increased risk is the downside of flexibility.

Contents

1. Master (a. k. a. Primary) DNS Server
   
2. Slave (a. k. a. Secondary) DNS Server
   

• But Slaves can also be Masters

3. Caching (a. k. a. Hint) DNS Server
   
4. Forwarding (a. k. A Proxy, Client, Remote) DNS Server
   
5. Stealth (a. k. a. DMZ, Split or Hidden Master) DNS Server
   
6. Authoritative only DNS Server
   
7. Split Horizon DNS Server
   

[ Read More ]

DNS system Components

What is DNS System Components

A Domain Name System (DNS) as defined by RFC 1034 includes three parts:

1. Data which describes the domain(s)
   
2. One or more Name Server programs.
   
3. A resolver program or library.
   

A single DNS server may support many domains. The data for each domain describes global properties of the domain and its hosts (or services). This data is defined in the form of textual Resource Records organized in Zone Files. The format of Zone files is defined in RFC 1035 and is supported by most DNS software.
The Name Server program typically does three things:

1. It will read a configuration file which defines the zones for which it is responsible.
   
2. Depending on the Name Servers functionality a configuration file may describe various behaviours, for instance, to cache or not. Some DNS servers are very specialized and do not provide this level of control.
   
3. Respond to questions (queries) from local or remote hosts.

---

The resolver program or libraryis located on each host and provides a means of translating a users request for, say, www.inforporch.com into one or more queries to DNS servers using UDP (or TCP) protocols.
Note: The resolver on all Windows systems and the majority of *nix systems is actually a stub resolver - a minimal resolver that can only work with a DNS that supports recursive queries. The caching resolver on MS Windows 2K and XP is a stub resolver with a cache to speed up responses and reduce network usage.
While BIND is the best known of the DNS servers and much of this guide documents BIND features, it is by no means the only solution or for that matter the only Open Source solution.

Zones and Zone Files

Zone files contain Resource Records that describe a domain or sub-domain. The format of zone files is an IETF standard defined by RFC 1035. Almost any sensible DNS software should be able to read zone files. A zone file will consist of the following types of data:

1. Data that indicates the top of the zone and some of its general properties (a SOA Record.
   
2. Authoritative data for all nodes or hosts within the zone (typically A (IPv4) or AAA (IPv6) Records).
   
3. Data that describes global information for the zone (including mail MX Records and Name Server NS Records).
   
4. In the case of sub-domain delegation the name servers responsible for this sub-domain (one or more NS Records).
   
5. In the case of sub-domain delegation one or more glue records that allows a name server to reach the sub-domain (typically one or more A or AAA Records) for the sub-domain name servers.
   

The individual Resource Records are described and numerous sample configuration files are provided and documented.

[ Read More ]

Concept of DNS Server

What is Technical Defination of DNS ?

The DNS translates Internet domain and host names to IP adresses. DNS automatically converts the names we type in our Web browser address bar to the IP addresses of Web servers hosting those sites.

---

What is DNS Concepts & How to Implementation

The Internet's Domain Name Service (DNS) is just a specific implementation of the Name Server concept optimized for the prevailing conditions on the Internet.

DNS Overview

From our brief history of Name Servers we saw how three needs emerged:

1. The need for a hierarchy of names
   
2. The need to spread the operational loads on our name servers
   
3. The need to delegate the administration of our Name servers
   

The Internet Domain Name System elegantly solves all these problems at the single stroke of a pen (well actually the whole of RFC 1034 to be precise).
Domains and Delegation
The Domain Name System uses a tree (or hierarchical) name structure. At the top of the tree is the root followed by the Top Level Domains (TLDs) then the domain-name and any number of lower levels each separated with a dot.
NOTE: The root of the tree is represented most of the time as a silent dot ('.') but there are times as we shall see later when it VERY important.
Top Level Domains (TLDs) are split into two types:

1. Generic Top Level Domains (gTLD) .com, .edu, .net, .org, .mil etc.
   
2. Country Code Top Level Domain (ccTLD) e.g. .us, .ca, .tv , .uk etc.
   

Country Code TLDs (ccTLDs) use a standard two letter sequence defined by ISO 3166. Since 2004 gTLDs now have a sub-category known as sTLDs (Sponsored TLDs) which implies they have limited registration, examples of sTLDs include .aero, .museum, .travel, and .jobs whereas the normal gTLDs typically have open registration requirements.

[ Read More ]