While we saw here how to setup a Cisco Router as a Caching/Forwarding DNS Server. We can now look at how to make your Cisco Router as an Authoritative DNS server. When configured as an authoritative name server for its own local host table, the router listens on port 53 for DNS queries and then answers DNS queries using the permanent and cached entries in its own host table.

Careful consideration has to be given as this can consume considerable amount of resources like CPU cycles on the Cisco Router. If you are a small network and realise your Cisco ROuter is under utilised then there is a good business case to turn your router into a DNS server.

Enable DNS Server

From the Global configuration mode, enable the DNS server on your Cisco Router

ciscorouter# conf term

ciscorouter(config)# ip dns server

Configure as Primary DNS Server

Configures the router as the primary DNS name server for a domain (zone) and as the start of authority (SOA) record source. Unless Distributed Director is enabled, the TTL on locally defined resource records will always be ten seconds.

ciscorouter(config)# ip dns primary test.com soa ns.test.com postmaster.test.com

The above command configures the Cisco Router as a Authoritative Primary DNS server for the domain "test.com" where

ns.test.com is the Primary DNS Server and

postmaster.test.com is the email account for the postmaster (read as postmaster@test.com)

Create NS Records

Create NS resource record to be returned when the DNS server is queried for the associated domain. This configuration is needed only if the zone for which the system is authoritative will also be served by other name servers

ciscorouter(config)# ip host test.com ns ns.test.com

Optionally, you can also use the Caching DNS server settings along with this so the Cisc Router can act as an Authoritative DNS server for its zone and for everything else as a caching DNS server. For caching DNS Server on Cisco Router, click here

A Cisco Router running Cisco IOS can function as a Caching or Forwarding DNS Server which answers to DNS queries from clients either from its host table or cache or forward it to a DNS server which can respond to the query.

This feature can come in handy in small network environments where the router can act as a Caching DNS server forwarding queries to the ISPs DNS servers or infact any external DNS servers. Also, makes sense using on under utilized DNS servers.

NOTE: This feature can have an impact on the available resource on the Cisco Router and hence plan according to the network size and ofcourse the router itself.

Enable DNS Translations

From the global Configuration mode, enable the DNS server.

ciscrouter# conf term

ciscorouter(config)# ip domain lookup

Add the Name Servers

Add the name servers to which the Cisco Router will forward the queries, if it can't answer from its host table or cache. You can specify upto 6 Namservers in a single command (seperated by a "SPACE") or specifiy one Name-server per command for legibility.

ciscorouter(config)# ip name-server 192.168.1.1 192.168.2.1

Add Hosts (optional)

Add host entries to the host table manually, if required

ciscorouter(config)# ip host webserver 10.1.1.100

In the above, the IP address 10.1.1.100 is mapped to the hostname "webserver"

Set Default Domain Name(s)

Optionally, add a domain name or a list of domain names that the Cisco Router can use to append to a unqualified hostname. Using a list is useful where the router tries to try one domain name at a time until it finds a match.

To set a single domain name

ciscorouter(config)# ip domain name example.com

To set a list of Domain names

ciscorouter(config)# ip domain list example.com

ciscorouter(config)# ip domain list test.com

ciscorouter(config)# ip domain list myowndomain.com

Set Domain Lookup Timeout (optional)

Optionally, you can set the timeout in seconds for the Cisco router to wait for a resonse to a DNS query. The default is 3 seconds

ciscorouter(config)# ip domain timeout 5

Set Domain Lookup Retry (optional)

Again optional, you can set the number of retry attempts for the DNS queries. Default is "2" times

ciscorouter(config)# ip domain retry 5

Enable DNS Round Robin (optional)

If there are hosts with load balancing enabled and having more than 1 host (example, 10.1.1.101, 10.1.1.102,10.1.1.103 are all pointing to a host, "dbserver") it makes sense to enable the DNS RoundRobin feature to rotate among the hosts else the 1st cached hosts will only be picked up causing load issues on that particular hosts

ciscorouter(config)# ip host dbserver 10.1.1.101 10.1.1.102 10.1.1.103

ciscorouter(config) ip domain round-robin

Dnsmasq is an opensource light-weight,easy to configure and administer DNS and a DHCP Server. Dnsmasq is ideally suitable for smaller networks like Small Office and Home Office networks (SOHO) and branch office networks. Dnsmasq can be run on old PC and is very easy to configure and administer. Dnsmasq is seen to support upto 1000 nodes on a network.

In essence, Dnsmasq is a Caching nameserver and a DNS forwarder with DHCP enabled on it. Dnsmasq can provide nameservice for local hosts while forwarding the queries for global public resources to a Public DNS Server (like an ISP DNS server). So, small networks which are behind a DSL/ADSL router or even a modem link and share a single internet connection can make the best use of Dnsmasq.

Dnsmasq is included in most of the opensource firewalls and opensource router firmware and in the most common Linux distributions. Some of them include:

Opensource Firewalls:

IPCop / Smoothwall / floppyfw / Firebox / LEAF / m0n0wall / PfSense / Endian Firewall / ClarkConnect

Opensource router firmware:

dd-wrt / openwrt / stock firmware / fli4l

Linux Distributions:

Debian / Gentoo / Slackware / Suse / Fedora / Coyote Linux

*BSD

FreeBSD / OpenBSD / NetBSD

Some of the highlighting features of Dnsmasq are as follows:

• Automatically update the Public DNS Servers through PPP or DHCP connections. So, change in a Public DNS server of an ISP that the network is connected to will be picked up by Dnsmasq
• Caching Nameserver to reduce network traffic and improve performance
• Forwarding to Private DNS servers for specific Domains can be configured
• Nameservice for the localhosts using the /etc/hosts file and for DHCP Client hosts
• Static and Dynamic client leases on DHCP
• Multiple Network and IP Ranges on the DHCP server
• BOOTP support for network booting using a secure read-only TFTP server
• Simple global configuration using the /etc/dnsmasq.conf file
• Supports BOOTP and DHCP Relays
• Caches A records for IPv4 and AAAA records for IPv6 and PTR records
• Supports IPv4 and IPv6 protocols and even can act as a IPv4 toIPv6 and IPv6 to IPv4 forwarder
• Support MX records and SRV records for local machines
• Block DNS redirect websites (like some websites which forward to a link for a website that doesn't exist)

Dnsmasq does the name lookup from its /etc/hosts file and hence its all about maintaining a /etc/hosts file on one computer as against multiple PCs on the LAN. If the host is a DHCP client then even if there isn't an entry for the host in the "hosts" file it can still provide name resolution for the host.

Effectively, all hosts in the LAN will have the dnsmasq server as the nameserver in /etc/resolv.conf file (In windows under network connection) and you dont have to worry about the "hosts" file on the local system.

The /etc/hosts file on the Dnsmasq server can have only the hostname without the domain name (example: host1 instead of host1.mynetwork.com) as the domain name can be appended globally using configurations in the /etc/dnsmasq.conf file.

It's got .deb and rpm packages for Debian, Fedora and other distributions and also can be built from the Source files. For more information and download, click here for dnsmasq home page.

Domain Name Service (DNS) is a system which translates the meaningful Hostnames and Domain Names into valid IP Addresses. A DNS Client or a Resolver is a host or a network device which queries the DNS servers for various resource records like the IP Address for a host like a Mail Server.

If you configure your Solaris Server as a DNS client then you need to add the DNS servers which the resolver on the server query for various DNS records in the file

/etc/resolv.conf

The following is an example of a sample /etc/resolv.conf

$ cat /etc/resolv.conf

domain example.com
nameserver 10.10.10.1
nameserver 10.10.10.2
nameserver 10.10.10.3

search example.com example.co.uk example.net

where

domain – specifies the local domain. A search for a host in the domain can simply be done with the hostname without the Domain suffix.

nameserver – specifies the IP Address to it as a DNS server. There can be more than one DNS server specified by the nameserver keyword (one per line) listed in the file.

search – specifies a list of local domains to search for the hosts. This process is slow and generates a lot of traffic.

This is the most commonly found configuration on DNS clients or Resolvers. More advanced configurations include

sortlist – Sort the IP Addresses returned to the resolver
options -  Allows additional configurations to modify resolver variables.

For a detailed man page, click here

PTR Records are called as the Pointer Records. These are called as the Reverse DNS Records as it is used for reverse DNS lookups. The DNS best practices suggest that every host on the Internet that has a A record assigned should have a PTR record assigned to its IP address.

As long as there is an A record is available for the host, it should be reacheable on the internet. But, systems like an email or a webserver checks for a PTR record and might refuse connections as a measure of security and or against SPAM. For example, a mail server for example.com can refuse connection to a SMTP sending server for mail.test.com if the either the server did not have a PTR record or if the Reverse DNS lookup did not match the hostname and the IP Address

Syntax:

1.1.168.192.IN-ADDR.ARPA IN PTR www.itsyourip.com

Where,

The first 4 fields seperated by decimal (.) symbols refer to the IP address of the host in reverse order.

IN-ADDR.ARPA is a special Internet domain like a .com domain assigned by IANA specifically for Internet Address to Hostname mapping lookups as per RFC 1035.

The reason for reversing the IP Address on the record is to facilitate the delegation of zones based on the class (Class A or Class B or Class C) of the IP. For example, 10.IN-ADDR.ARPA can be the zone for ARPANET.

PTR records are hosted by the Network Owner. In other words, if you own a whole Class C address space then you are authoritative. However, if you have a few IP addresses from your Internet Service Provider (ISP) then it is very likely that your ISP is authoritative and hence they need to host your PTR records. You would obviously host your internet private network PTR records

The following is an excert from the RFC 1035 (Section 3.5) about the IN-ADDR.ARPA domain (ARPA is Address Routing Parameter Area):

The Internet uses a special domain to support gateway location and Internet address to host mapping.  Other classes may employ a similar strategy in other domains.  The intent of this domain is to provide a guaranteed method to perform host address to host name mapping, and to facilitate queries to locate all gateways on a particular network in the Internet.

Note that both of these services are similar to functions that could be performed by inverse queries; the difference is that this part of the domain name space is structured according to address, and hence can guarantee that the appropriate data can be located without an exhaustive search of the domain space.

The domain begins at IN-ADDR.ARPA and has a substructure which follows the Internet addressing structure.

Domain names in the IN-ADDR.ARPA domain are defined to have up to four labels in addition to the IN-ADDR.ARPA suffix.  Each label represents one octet of an Internet address, and is expressed as a character string for a decimal value in the range 0-255 (with leading zeros omitted except in the case of a zero octet which is represented by a single zero).

Host addresses are represented by domain names that have all four labels specified.  Thus data for Internet address 10.2.0.52 is located at domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to read, allows zones to be delegated which are exactly one network of address space.  For example, 10.IN-ADDR.ARPA can be a zone containing data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for MILNET.  Address nodes are used to hold pointers to primary host names in the normal domain space.

Network numbers correspond to some non-terminal nodes at various depths in the IN-ADDR.ARPA domain, since Internet network numbers are either 1, 2, or 3 octets.  Network nodes are used to hold pointers to the primary host names of gateways attached to that network.  Since a gateway is, by definition, on more than one network, it will typically have two or more network nodes which point at it.  Gateways will also have host level pointers at their fully qualified addresses.

Both the gateway pointers at network nodes and the normal host pointers at full address nodes use the PTR RR to point back to the primary domain names of the corresponding hosts.

For example, the IN-ADDR.ARPA domain will contain information about the ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's

From the 1st November, the IP address for the L Root servers (L.ROOR-SERVERS.NET) for DNS lookups has changed. The new IP Address will be

199.7.83.42

and replaces the old IP address 198.32.64.12 which is expected to be decomiisioned in 6 months time.

DNS servers hosting various domains need to update the reference to the old IP addresses.

The new hints files are available for download from here:

ftp://rs.internic.net/domain/db.cache

ftp://rs.internic.net/domain/named.cache

ftp://rs.internic.net/domain/named.root

ftp://ftp.internic.net/domain/db.cache

ftp://ftp.internic.net/domain/named.cache

ftp://ftp.internic.net/domain/named.root

The Sender ID Framework is a new authentication protocol that can be used to counter spoofing by people who send unsolicited commercial e-mail messages (spam). Spoofing is the practice of forging a sender's address on e-mail messages. Spoofing misleads e-mail recipients and makes them read and respond to deceptive e-mail messages. To safeguard Internet domain names, and to help e-mail recipients identify junk e-mail messages and phishing scams more effectively, administrators can publish SPF records in the public DNS.

For more information and syntax on SPF, click here.

To configure SPF records in the Windows Server 2003 DNS, follow these steps:

SPF record is a Sender Policy Framework resource record. This is defined as a regular TXT record type.

The SPF record are used to avoid spam emails. SPF record validates the mail server that delivers the email for a domain to check if it is actually an authorised server before accepting any email from it.

For example, When Server X receives an email for a user in the domain xyz.com from a Server Y claiming to be sending an email from the domain abc.com

The receiving Server X checks the SPF records for the domain abc.com and if the Server Y is an authorised sender for this domain then it accepts the email, if it is not an authorised server then rejects the email. This way, the receiving server which checks for the SPF records can reduce the amount of SPAM without even passing them onto various spam checkers and other extensions to the email servers.

The SPF records are simple TXT records although some of the newer version of the DNS servers (BIND 9.4.0) does support a SPF record type. The RFC 4408 for the Sender Policy Framework recommends using a TXT record type or add a duplicate TXT record (if using a SPF record type) as the older version of the Nameserver software do not support the SPF record type.

The record format is as for a TXT record.

<Name> TTL class TXT <text with SPF arguements>

<Name> TTL class SPF <text with SPF arguements>

The text field contains the SPF data.

The SPF data is of the following format.

v=spf1 [<Qualifier><Mechanism>] [<Qualifier><Mechanism>] <optional Modifiers>

where,

v=spf1 defines the version of the SPF format. As of now there is just one version.
 
<qualifier><Mechanism> One of more pair of Qualifier:Mechanism pairs that describes the mailing hosts for the domain.

<modifiers> There can be only one modifer in a SPF record.

Qualifiers

The qualifiers are the paramters that define the action to perform on a match to a Mechanism. There are four Qualifiers:

+ Pass (default)
– Fail
~ SoftFail
? Neutral

Mechanism

The following are the mechanisms that describes the host that sends email for the domains:

all     – Match all
ipv4    – IPv4 Host or Network
ipv6    – IPv6 or Network
a       – Match A records
mx      – Match A records for the MX records
ptr     – Check PTR records
exist   – Check if the Domain checked resolves
include – Check for the SPF record for the domain checked

all

Always matches anything that is compared. Usually comes at the end of the record.

ip4

ip4:<ip4-address>
ip4:<ip4-network>/<prefix>

Checks the IPv4 host or the network range. If no prefix is given then it is assumed as a Host(/32).

ip6

ip6:<ip6-address>
ip6:<ip6-network>/<prefix>

Checks the IPv6 network range. If no prefix is given then it is assumed as a Host (/128).

a

a/<prefix>
a:<domain>
a:<domain>/<prefix>

All the A records for domain are tested and if the client IP is one of them then  this mechanism matches. If domain is not specified, the current-domain is used.

The A records have to match the client IP exactly, unless a "prefix" is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.

mx

mx
mx/<prefix>
mx:<domain>
mx:<domain>/<prefix>

The A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches. If domain is not specified, the current-domain is used.

The A records have to match the client IP exactly, unless a prefix is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that network range.

ptr

ptr
ptr:<domain>

The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.

If domain is not specified, the current-domain is used.

exists

exists:<domain>

Perform an A query on the provided domain. If a result is found, this constitutes a match.

include

include:<domain>

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

Modifiers

Modifiers are optional. A modifier may appear only once per record.

The "redirect" modifier

redirect=<domain>

The SPF record for domain replace the current record.

The "exp" modifier

exp=<domain>

If a receiving receiver rejects a message, it can include an explanation. The SPF record can specify the explanation string that senders can see.

The domain is expanded; a TXT lookup is performed. The result of the TXT query is then macro-expanded and shown to the sender. Other macros can be used to provide an customized explanation.

Examples for SPF Resource Records:

v=spf1 ip4:192.168.0.1/16 -all

Allows any host from 192.168.0.0/16 network

v=spf1 mx -all

Allows only mx servers for the domain and discards anything else (-all)

v=spf1 ptr:example.com -all

Allows any host whose hostname ends as example.com

v=spf1 exists:example.com -all

Matches if the example.com domain resolves

v=spf1 include:example.com -all

Checks the SPF records for the example.com domain and follows the matches for that domain. Fails if there is no SPF record for example.com

To quickly generate a SPF record, plese use the wizard here

To check the SPF record for your domain, click here

SRV records, also known as Service records in DNS helps clients find services in the domain. A best example of this is with the Windows Active Directory where the SRV records are used to locate the Domain Controllers.

SRV records can also help Load Balancing between multiple resources providing the same service. For example, if there are more than one web servers in the Domain then they can be load balanced using the SRV records.

Let's for example there are four servers in the Domains serving the website and the records look like the following:

_http._tcp.itsyourip.com. 86400 IN SRV 10 50 80 web1.itsyourip.com. _http._tcp.itsyourip.com. 86400 IN SRV 10 30 80 web2.itsyourip.com. _http._tcp.itsyourip.com. 86400 IN SRV 10 20 80 web3.itsyourip.com. _http._tcp.itsyourip.com. 86400 IN SRV 20 60 0 backup.itsyourip.com.

Here, the SRV records for web1,web2,web3 all have the priority set the same at "10" while backup has the priority set as 20. This means the web1,web2,web3 all have the least priority number and hence will be forwarded with the web requets. The backup server with priority 20 means that it will get the requests forwarded only when all the servers with the priority "10" went down or are not responding. This is exactly how it works with the MX records as well.

Now, the priority "10" servers have weight set as follows:

web1 = 50

web2 = 30

web3 = 20

Here, of the 100% of the requests, 50% of it will be served as to web1 based on the weight while web2 will be served 30% of the time while 20% of the requests will be served by web3.

If all the priority "10" servers fail then the backup server with priority "20" will become the sole server which be served all the time.

Although not the very best way to provide Load Balancing solutions, it still can be used as one way of doing it.

A SRV record called as a Service record provides information on available services.

The SRV record has four fields. The naming convention of the SRV record is unique. Following is the naming syntax:

_<SERVICENAME>._<PROTOCOL>.<DOMAINNAME>

Where,

SERVICENAME is the name of the service

PROTOCOL is the name of the protocol ex: TCP

DOMAINNAME is the name of the domain.

An example would be,

_ftp._tcp.itsyourip.com.

The record itself has four fields in it namely,

1. Priority

2. Weight

3. Port

4. Hostname

An example record would look like the following:

_ftp._tcp.itsyourip.com. 86400 IN SRV 10 10 21 ftp.itsyourip.com.