How to set up a home DNS server

Ubuntu Documentation > Ubuntu 8.04 LTS > Ubuntu Server Guide > Domain Name Service (DNS) > Configuration

Configuration

There a many ways to configure BIND9. Some of the most common configurations are a caching nameserver, primary master, and a as a secondary master.

• When configured as a caching nameserver BIND9 will find the answer to name queries and remember the answer when the domain is queried again.
• As a primary master server BIND9 reads the data for a zone from a file on it's host and is authoritative for that zone.
• In a secondary master configuration BIND9 gets the zone data from another nameserver authoritative for the zone.

Overview

The DNS configuration files are stored in the /etc/bind directory. The primary configuration file is /etc/bind/named.conf.

The include line specifies the filename which contains the DNS options. The directory line in the /etc/bind/named.conf.options file tells DNS where to look for files. All files BIND uses will be relative to this directory.

The file named /etc/bind/db.root describes the root nameservers in the world. The servers change over time, so the /etc/bind/db.root file must be maintained now and then. This is usually done as updates to the bind9 package. The zone section defines a master server, and it is stored in a file mentioned in the file option.

It is possible to configure the same server to be a caching name server, primary master, and secondary master. A server and be the Start of Authority (SOA) for one zone, while providing secondary service for another zone. All the while providing caching services for hosts on the local LAN.

Caching Nameserver

The default configuration is setup to act as a caching server. All that is required is simply adding the IP Addresses of your ISP's DNS servers. Simply uncomment and edit the following in /etc/bind/named.conf.options:

forwarders {
                1.2.3.4;
                5.6.7.8;
           };

Now restart the DNS server, to enable the new configuration. From a terminal prompt:

sudo /etc/init.d/bind9 restart

See the section called “dig” for information on testing a caching DNS server.

Primary Master

In this section BIND9 will be configured as the Primary Master for the domain example.com. Simply replace example.com with your FQDN (Fully Qualified Domain Name).

Forward Zone File

To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, the first step is to edit /etc/bind/named.conf.local:

zone "example.com" {
	type master;
        file "/etc/bind/db.example.com";
};

Now use an existing zone file as a template to create the /etc/bind/db.example.com file:

sudo cp /etc/bind/db.local /etc/bind/db.example.com

Edit the new zone file /etc/bind/db.example.com change localhost. to the FQDN of your server, leaving the additional "." at the end. Change 127.0.0.1 to the nameserver's IP Address and root.localhost to a valid email address, but with a "." instead of the usual "@" symbol, again leaving the "." at the end.

Also, create an A record for ns.example.com. The name server in this example:

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.example.com.
@       IN      A       192.168.1.10
ns      IN      A       192.168.1.10

You must increment the Serial Number every time you make changes to the zone file. If you make multiple changes before restarting BIND9, simply increment the Serial once.

Now, you can add DNS records to the bottom of the zone file. See the section called “Common Record Types” for details.

Once you have made a change to the zone file BIND9 will need to be restarted for the changes to take affect:

sudo /etc/init.d/bind9 restart

Reverse Zone File

Now that the zone is setup and resolving names to IP Adresses a Reverse zone is also required. A Reverse zone allows DNS to resolve an address to a name.

Edit /etc/bind/named.conf.local and add the following:

zone "1.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "/etc/bind/db.192";
};

Now create the /etc/bind/db.192 file:

sudo cp /etc/bind/db.127 /etc/bind/db.192

Next edit /etc/bind/db.192 changing the basically the same options as /etc/bind/db.example.com:

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.
10      IN      PTR     ns.example.com.

The Serial Number in the Reverse zone needs to be incremented on each changes as well. For each A record you configure in /etc/bind/db.example.com you need to create a PTR record in /etc/bind/db.192.

After creating the reverse zone file restart BIND9:

sudo /etc/init.d/bind9 restart

Secondary Master

Once a Primary Master has been configured a Secondary Master is needed in order to maintain the availability of the domain should the Primary become unavailable.

First, on the Primary Master server, the zone transfer needs to be allowed. Add the allow-transfer option to the example Forward and Reverse zone definitions in /etc/bind/named.conf.local:

zone "example.com" {
        type master;
	file "/etc/bind/db.example.com";
        allow-transfer { 192.168.1.11; };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "/etc/bind/db.192";
	allow-transfer { 192.168.1.11; };
};

Next, on the Secondary Master, install the bind9 package the same way as on the Primary. Then edit the /etc/bind/named.conf.local and add the following declarations for the Forward and Reverse zones:

zone "example.com" {
	type slave;
        file "db.example.com";
        masters { 192.168.1.10; };
};        
      
zone "1.168.192.in-addr.arpa" {
	type slave;
        file "db.192";
        masters { 192.168.1.10; };
};

Restart BIND9 on the Secondary Master:

sudo /etc/init.d/bind9 restart

In /var/log/syslog you should see something similar to:

slave zone "example.com" (IN) loaded (serial 6)
slave zone "100.18.172.in-addr.arpa" (IN) loaded (serial 3)

NEWS CONTENTS

• 20200508 : Configuring Unbound as a simple forwarding DNS server Enable Sysadmin ( May 08, 2020 , www.redhat.com )
• 20191201 : How to Find DNS (Domain Name Server) Records On Linux Using the Dig Command 2daygeek.com ( Dec 01, 2019 , www.2daygeek.com )
• 20190126 : How and why i run my own dns servers ( zwischenzugs )
• 20190108 : Bind DNS threw a (network unreachable) error CentOS ( Jan 08, 2019 , www.reddit.com )
• 20151207 : Localhost DNS Cache by Kyle Rankin ( Feb 23, 2015 , Linux Journal )
• 20130805 : How to set up a home DNS server by Shannon Hughes ( Red Hat Magazine )
• 20130805 : Speeding up the internet with squid ( Speeding up the internet with squid, )

Old News ;-)

[May 08, 2020] Configuring Unbound as a simple forwarding DNS server Enable Sysadmin

May 08, 2020 | www.redhat.com

In part 1 of this article, I introduced you to Unbound , a great name resolution option for home labs and small network environments. We looked at what Unbound is, and we discussed how to install it. In this section, we'll work on the basic configuration of Unbound.

Basic configuration

First find and uncomment these two entries in unbound.conf :

interface: 0.0.0.0
interface: ::0

Here, the 0 entry indicates that we'll be accepting DNS queries on all interfaces. If you have more than one interface in your server and need to manage where DNS is available, you would put the address of the interface here.

Next, we may want to control who is allowed to use our DNS server. We're going to limit access to the local subnets we're using. It's a good basic practice to be specific when we can:

Access-control: 127.0.0.0/8 allow  # (allow queries from the local host)
access-control: 192.168.0.0/24 allow
access-control: 192.168.1.0/24 allow

We also want to add an exception for local, unsecured domains that aren't using DNSSEC validation:

domain-insecure: "forest.local"

Now I'm going to add my local authoritative BIND server as a stub-zone:

stub-zone:
        name: "forest"
        stub-addr: 192.168.0.220
        stub-first: yes

If you want or need to use your Unbound server as an authoritative server, you can add a set of local-zone entries that look like this:

local-zone:  "forest.local." static

local-data: "jupiter.forest"         IN       A        192.168.0.200
local-data: "callisto.forest"        IN       A        192.168.0.222

These can be any type of record you need locally but note again that since these are all in the main configuration file, you might want to configure them as stub zones if you need authoritative records for more than a few hosts (see above).

If you were going to use this Unbound server as an authoritative DNS server, you would also want to make sure you have a root hints file, which is the zone file for the root DNS servers.

Get the file from InterNIC . It is easiest to download it directly where you want it. My preference is usually to go ahead and put it where the other unbound related files are in /etc/unbound :

wget https://www.internic.net/domain/named.root -O /etc/unbound/root.hints

Then add an entry to your unbound.conf file to let Unbound know where the hints file goes:

# file to read root hints from.
        root-hints: "/etc/unbound/root.hints"

Finally, we want to add at least one entry that tells Unbound where to forward requests to for recursion. Note that we could forward specific domains to specific DNS servers. In this example, I'm just going to forward everything out to a couple of DNS servers on the Internet:

forward-zone:
        name: "."
        forward-addr: 1.1.1.1
        forward-addr: 8.8.8.8

Now, as a sanity check, we want to run the unbound-checkconf command, which checks the syntax of our configuration file. We then resolve any errors we find.

[root@callisto ~]# unbound-checkconf
/etc/unbound/unbound_server.key: No such file or directory
[1584658345] unbound-checkconf[7553:0] fatal error: server-key-file: "/etc/unbound/unbound_server.key" does not exist

This error indicates that a key file which is generated at startup does not exist yet, so let's start Unbound and see what happens:

[root@callisto ~]# systemctl start unbound

With no fatal errors found, we can go ahead and make it start by default at server startup:

[root@callisto ~]# systemctl enable unbound
Created symlink from /etc/systemd/system/multi-user.target.wants/unbound.service to /usr/lib/systemd/system/unbound.service.

And you should be all set. Next, let's apply some of our DNS troubleshooting skills to see if it's working correctly.

First, we need to set our DNS resolver to use the new server:

[root@showme1 ~]# nmcli con mod ext ipv4.dns 192.168.0.222
[root@showme1 ~]# systemctl restart NetworkManager
[root@showme1 ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.0.222
[root@showme1 ~]#

Let's run dig and see who we can see:

root@showme1 ~]# dig; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36486
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       508693  IN      NS      i.root-servers.net.
<snip>

Excellent! We are getting a response from the new server, and it's recursing us to the root domains. We don't see any errors so far. Now to check on a local host:

;; ANSWER SECTION:
jupiter.forest.         5190    IN      A       192.168.0.200

Great! We are getting the A record from the authoritative server back, and the IP address is correct. What about external domains?

;; ANSWER SECTION:
redhat.com.             3600    IN      A       209.132.183.105

Perfect! If we rerun it, will we get it from the cache?

;; ANSWER SECTION:
redhat.com.             3531    IN      A       209.132.183.105

;; Query time: 0 msec
;; SERVER: 192.168.0.222#53(192.168.0.222)

Note the Query time of 0 seconds- this indicates that the answer lives on the caching server, so it wasn't necessary to go ask elsewhere. This is the main benefit of a local caching server, as we discussed earlier.

Wrapping up

While we did not discuss some of the more advanced features that are available in Unbound, one thing that deserves mention is DNSSEC. DNSSEC is becoming a standard for DNS servers, as it provides an additional layer of protection for DNS transactions. DNSSEC establishes a trust relationship that helps prevent things like spoofing and injection attacks. It's worth looking into a bit if you are using a DNS server that faces the public even though It's beyond the scope of this article.

[ Getting started with networking? Check out the Linux networking cheat sheet . ]

[Dec 01, 2019] How to Find DNS (Domain Name Server) Records On Linux Using the Dig Command 2daygeek.com

Dec 01, 2019 | www.2daygeek.com

The common syntax for dig command as follows:

dig [Options] [TYPE] [Domain_Name.com]

1) How to Lookup a Domain "A" Record (IP Address) on Linux Using the dig Command

Use the dig command followed by the domain name to find the given domain "A" record (IP address).

$ dig 2daygeek.com

; <<>> DiG 9.14.7 <<>> 2daygeek.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7777
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;2daygeek.com.                  IN      A

;; ANSWER SECTION:
2daygeek.com.           299     IN      A       104.27.157.177
2daygeek.com.           299     IN      A       104.27.156.177

;; Query time: 29 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Nov 07 16:10:56 IST 2019
;; MSG SIZE  rcvd: 73

It used the local DNS cache server to obtain the given domain information from via port number 53.

2) How to Only Lookup a Domain "A" Record (IP Address) on Linux Using the dig Command

Use the dig command followed by the domain name with additional query options to filter only the required values of the domain name.

In this example, we are only going to filter the Domain A record (IP address).

$ dig 2daygeek.com +nocomments +noquestion +noauthority +noadditional +nostats

; <<>> DiG 9.14.7 <<>> 2daygeek.com +nocomments +noquestion +noauthority +noadditional +nostats
;; global options: +cmd
2daygeek.com.           299     IN      A       104.27.157.177
2daygeek.com.           299     IN      A       104.27.156.177

3) How to Only Lookup a Domain "A" Record (IP Address) on Linux Using the +answer Option

Alternatively, only the "A" record (IP address) can be obtained using the "+answer" option.

$ dig 2daygeek.com +noall +answer

2daygeek.com.           299     IN      A       104.27.156.177
2daygeek.com.           299     IN      A       104.27.157.177

4) How Can I Only View a Domain "A" Record (IP address) on Linux Using the "+short" Option?

This is similar to the output above, but it only shows the IP address.

$ dig 2daygeek.com +short
     
104.27.157.177
104.27.156.177

5) How to Lookup a Domain "MX" Record on Linux Using the dig Command

Add the MX query type in the dig command to get the MX record of the domain.

# dig 2daygeek.com MX +noall +answer
or
# dig -t MX 2daygeek.com +noall +answer

2daygeek.com.           299     IN      MX      0 dc-7dba4d3ea8cd.2daygeek.com.

According to the above output, it only has one MX record and the priority is 0.

6) How to Lookup a Domain "NS" Record on Linux Using the dig Command

Add the NS query type in the dig command to get the Name Server (NS) record of the domain.

# dig 2daygeek.com NS +noall +answer
or
# dig -t NS 2daygeek.com +noall +answer

2daygeek.com.           21588   IN      NS      jean.ns.cloudflare.com.
2daygeek.com.           21588   IN      NS      vin.ns.cloudflare.com.

7) How to Lookup a Domain "TXT (SPF)" Record on Linux Using the dig Command

Add the TXT query type in the dig command to get the TXT (SPF) record of the domain.

# dig 2daygeek.com TXT +noall +answer
or
# dig -t TXT 2daygeek.com +noall +answer

2daygeek.com.           288     IN      TXT     "ca3-8edd8a413f634266ac71f4ca6ddffcea"

8) How to Lookup a Domain "SOA" Record on Linux Using the dig Command

Add the SOA query type in the dig command to get the SOA record of the domain.

me width=

me width=

# dig 2daygeek.com SOA +noall +answer
or
# dig -t SOA 2daygeek.com +noall +answer

2daygeek.com.           3599    IN      SOA     jean.ns.cloudflare.com. dns.cloudflare.com. 2032249144 10000 2400 604800 3600

9) How to Lookup a Domain Reverse DNS "PTR" Record on Linux Using the dig Command

Enter the domain's IP address with the host command to find the domain's reverse DNS (PTR) record.

# dig -x 182.71.233.70 +noall +answer

70.233.71.182.in-addr.arpa. 21599 IN    PTR     nsg-static-070.233.71.182.airtel.in.

10) How to Find All Possible Records for a Domain on Linux Using the dig Command

Input the domain name followed by the dig command to find all possible records for a domain (A, NS, PTR, MX, SPF, TXT).

# dig 2daygeek.com ANY +noall +answer

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> 2daygeek.com ANY +noall +answer
;; global options: +cmd
2daygeek.com.           12922   IN      TXT     "v=spf1 ip4:182.71.233.70 +a +mx +ip4:49.50.66.31 ?all"
2daygeek.com.           12693   IN      MX      0 2daygeek.com.
2daygeek.com.           12670   IN      A       182.71.233.70
2daygeek.com.           84670   IN      NS      ns2.2daygeek.in.
2daygeek.com.           84670   IN      NS      ns1.2daygeek.in.

11) How to Lookup a Particular Name Server for a Domain Name

Also, you can look up a specific name server for a domain name using the dig command.

# dig jean.ns.cloudflare.com 2daygeek.com

; <<>> DiG 9.14.7 <<>> jean.ns.cloudflare.com 2daygeek.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10718
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;jean.ns.cloudflare.com.                IN      A

;; ANSWER SECTION:
jean.ns.cloudflare.com. 21599   IN      A       173.245.58.121

;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Nov 12 11:22:50 IST 2019
;; MSG SIZE  rcvd: 67

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45300
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;2daygeek.com.                  IN      A

;; ANSWER SECTION:
2daygeek.com.           299     IN      A       104.27.156.177
2daygeek.com.           299     IN      A       104.27.157.177

;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Nov 12 11:22:50 IST 2019
;; MSG SIZE  rcvd: 73

12) How To Query Multiple Domains DNS Information Using the dig Command

You can query DNS information for multiple domains at once using the dig command.

# dig 2daygeek.com NS +noall +answer linuxtechnews.com TXT +noall +answer magesh.co.in SOA +noall +answer

2daygeek.com.           21578   IN      NS      jean.ns.cloudflare.com.
2daygeek.com.           21578   IN      NS      vin.ns.cloudflare.com.
linuxtechnews.com.      299     IN      TXT     "ca3-e9556bfcccf1456aa9008dbad23367e6"
linuxtechnews.com.      299     IN      TXT     "google-site-verification=a34OylEd_vQ7A_hIYWQ4wJ2jGrMgT0pRdu_CcvgSp4w"
magesh.co.in.           3599    IN      SOA     jean.ns.cloudflare.com. dns.cloudflare.com. 2032053532 10000 2400 604800 3600

13) How To Query DNS Information for Multiple Domains Using the dig Command from a text File

To do so, first create a file and add it to the list of domains you want to check for DNS records.

In my case, I've created a file named dig-demo.txt and added some domains to it.

# vi dig-demo.txt

2daygeek.com
linuxtechnews.com
magesh.co.in

Once you have done the above operation, run the dig command to view DNS information.

# dig -f /home/daygeek/shell-script/dig-test.txt NS +noall +answer

2daygeek.com.           21599   IN      NS      jean.ns.cloudflare.com.
2daygeek.com.           21599   IN      NS      vin.ns.cloudflare.com.
linuxtechnews.com.      21599   IN      NS      jean.ns.cloudflare.com.
linuxtechnews.com.      21599   IN      NS      vin.ns.cloudflare.com.
magesh.co.in.           21599   IN      NS      jean.ns.cloudflare.com.
magesh.co.in.           21599   IN      NS      vin.ns.cloudflare.com.

14) How to use the .digrc File

You can control the behavior of the dig command by adding the ".digrc" file to the user's home directory.

If you want to perform dig command with only answer section. Create the .digrc file in the user's home directory and save the default options +noall and +answer .

# vi ~/.digrc

+noall +answer

Once you done the above step. Simple run the dig command and see a magic.

# dig 2daygeek.com NS

2daygeek.com.           21478   IN      NS      jean.ns.cloudflare.com.
2daygeek.com.           21478   IN      NS      vin.ns.cloudflare.com.

[Jan 26, 2019] How and why i run my own dns servers

Notable quotes:

"... Learn Bash the Hard Way ..."

"... Learn Bash the Hard Way ..."

zwischenzugs

Introduction Despite my woeful knowledge of networking, I run my own DNS servers on my own websites run from home. I achieved this through trial and error and now it requires almost zero maintenance, even though I don't have a static IP at home.

Here I share how (and why) I persist in this endeavour.

Overview This is an overview of the setup:

This is how I set up my DNS. I:

• got a domain from an authority (a .tk domain in my case)
• set up glue records to defer DNS queries to my nameservers
• set up nameservers with static IPs
• set up a dynamic DNS updater from home

How? Walking through step-by-step how I did it: 1) Set up two Virtual Private Servers (VPSes) You will need two stable machines with static IP addresses. If you're not lucky enough to have these in your possession, then you can set one up on the cloud. I used this site , but there are plenty out there. NB I asked them, and their IPs are static per VPS. I use the cheapest cloud VPS (1$/month) and set up debian on there. NOTE: Replace any mention of DNSIP1 and DNSIP2 below with the first and second static IP addresses you are given. Log on and set up root password SSH to the servers and set up a strong root password. 2) Set up domains You will need two domains: one for your dns servers, and one for the application running on your host. I use dot.tk to get free throwaway domains. In this case, I might setup a myuniquedns.tk DNS domain and a myuniquesite.tk site domain. Whatever you choose, replace your DNS domain when you see YOURDNSDOMAIN below. Similarly, replace your app domain when you see YOURSITEDOMAIN below. 3) Set up a 'glue' record If you use dot.tk as above, then to allow you to manage the YOURDNSDOMAIN domain you will need to set up a 'glue' record. What this does is tell the current domain authority (dot.tk) to defer to your nameservers (the two servers you've set up) for this specific domain. Otherwise it keeps referring back to the .tk domain for the IP. See here for a fuller explanation. Another good explanation is here . To do this you need to check with the authority responsible how this is done, or become the authority yourself. dot.tk has a web interface for setting up a glue record, so I used that. There, you need to go to 'Manage Domains' => 'Manage Domain' => 'Management Tools' => 'Register Glue Records' and fill out the form. Your two hosts will be called ns1.YOURDNSDOMAIN and ns2.YOURDNSDOMAIN , and the glue records will point to either IP address. Note, you may need to wait a few hours (or longer) for this to take effect. If really unsure, give it a day.

---

If you like this post, you might be interested in my book Learn Bash the Hard Way , available here for just $5.

---

4) Install bind on the DNS Servers On a Debian machine (for example), and as root, type: apt install bind9 bind is the domain name server software you will be running. 5) Configure bind on the DNS Servers Now, this is the hairy bit. There are two parts this with two files involved: named.conf.local , and the db.YOURDNSDOMAIN file. They are both in the /etc/bind folder. Navigate there and edit these files. Part 1 – named.conf.local This file lists the 'zone's (domains) served by your DNS servers. It also defines whether this bind instance is the 'master' or the 'slave'. I'll assume ns1.YOURDNSDOMAIN is the 'master' and ns2.YOURDNSDOMAIN is the 'slave.

Part 1a – the master

On the master/ ns1.YOURNDSDOMAIN , the named.conf.local should be changed to look like this:

zone "YOURDNSDOMAIN" {
 type master;
 file "/etc/bind/db.YOURDNSDOMAIN";
 allow-transfer { DNSIP2; };
};
zone "YOURSITEDOMAIN" {
 type master;
 file "/etc/bind/YOURDNSDOMAIN";
 allow-transfer { DNSIP2; };
};

zone "14.127.75.in-addr.arpa" {
 type master;
 notify no;
 file "/etc/bind/db.75";
 allow-transfer { DNSIP2; };
};

logging {
 channel query.log {
 file "/var/log/query.log";
 // Set the severity to dynamic to see all the debug messages.
 severity debug 3;
 };
category queries { query.log; };
};

The logging at the bottom is optional (I think). I added it a while ago, and I leave it in here for interest. I don't know what the 14.127 zone stanza is about.

Part 1b – the slave

Jan 26, 2019 | zwischenzugs.com

On the slave/ ns2.YOURNDSDOMAIN , the named.conf.local should be changed to look like this:

zone "YOURDNSDOMAIN" {
 type slave;
 file "/var/cache/bind/db.YOURDNSDOMAIN";
 masters { DNSIP1; };
};

zone "YOURSITEDOMAIN" {
 type slave;
 file "/var/cache/bind/db.YOURSITEDOMAIN";
 masters { DNSIP1; };
};

zone "14.127.75.in-addr.arpa" {
 type slave;
 file "/var/cache/bind/db.75";
 masters { DNSIP1; };
};

Part 2 – db.YOURDNSDOMAIN

Now we get to the meat – your DNS database is stored in this file.

On the master/ ns1.YOURDNSDOMAIN the db.YOURDNSDOMAIN file looks like this :

$TTL 4800
@ IN SOA ns1.YOURDNSDOMAIN. YOUREMAIL.YOUREMAILDOMAIN. (
  2018011615 ; Serial
  604800 ; Refresh
  86400 ; Retry
  2419200 ; Expire
  604800 ) ; Negative Cache TTL
;
@ IN NS ns1.YOURDNSDOMAIN.
@ IN NS ns2.YOURDNSDOMAIN.
ns1 IN A DNSIP1
ns2 IN A DNSIP2
YOURSITEDOMAIN. IN A YOURDYNAMICIP

On the slave/ ns2.YOURDNSDOMAIN it's very similar, but has ns1 in the SOA line, and the IN NS lines reversed. I can't remember if this reversal is needed or not :

$TTL 4800 @ IN SOA ns1.YOURDNSDOMAIN. YOUREMAIL.YOUREMAILDOMAIN. (
  2018011615 ; Serial
 604800 ; Refresh
 86400 ; Retry
 2419200 ; Expire
 604800 ) ; Negative Cache TTL
;
@ IN NS ns1.YOURDNSDOMAIN.
@ IN NS ns2.YOURDNSDOMAIN.
ns1 IN A DNSIP1
ns2IN A DNSIP2
YOURSITEDOMAIN. IN A YOURDYNAMICIP

A few notes on the above:

• The dots at the end of lines are not typos – this is how domains are written in bind files. So google.com is written google.com.
• The YOUREMAIL.YOUREMAILDOMAIN. part must be replaced by your own email. For example, my email address: [email protected] becomes ianmiell.gmail.com. . Note also that the dot between first and last name is dropped. email ignores those anyway!
• YOURDYNAMICIP is the IP address your domain should be pointed to (ie the IP address returned by the DNS server). It doesn't matter what it is at this point, because .

the next step is to dynamically update the DNS server with your dynamic IP address whenever it changes.

6) Copy ssh keys

Before setting up your dynamic DNS you need to set up your ssh keys so that your home server can access the DNS servers.

NOTE: This is not security advice. Use at your own risk.

First, check whether you already have an ssh key generated:

ls ~/.ssh/id_rsa

If that returns a file, you're all set up. Otherwise, type:

ssh-keygen

and accept the defaults.

Then, once you have a key set up, copy your ssh ID to the nameservers:

ssh-copy-id root@DNSIP1
ssh-copy-id root@DNSIP2

Inputting your root password on each command.

7) Create an IP updater script

Now ssh to both servers and place this script in /root/update_ip.sh :

#!/bin/bash
set -o nounset
sed -i "s/^(.*) IN A (.*)$/1 IN A $1/" /etc/bind/db.YOURDNSDOMAIN
sed -i "s/.*Serial$/ $(date +%Y%m%d%H) ; Serial/" /etc/bind/db.YOURDNSDOMAIN
/etc/init.d/bind9 restart

Make it executable by running:

chmod +x /root/update_ip.sh

Going through it line by line:

• set -o nounset

This line throws an error if the IP is not passed in as the argument to the script.

• sed -i "s/^(.*) IN A (.*)$/1 IN A $1/" /etc/bind/db.YOURDNSDOMAIN

Replaces the IP address with the contents of the first argument to the script.

• ​​​sed -i "s/.*Serial$/ $(date +%Y%m%d%H) ; Serial/" /etc/bind/db.YOURDNSDOMAIN

Ups the 'serial number'

• /etc/init.d/bind9 restart

Restart the bind service on the host.

8) Cron Your Dynamic DNS

At this point you've got access to update the IP when your dynamic IP changes, and the script to do the update.

Here's the raw cron entry:

* * * * * curl ifconfig.co 2>/dev/null > /tmp/ip.tmp && (diff /tmp/ip.tmp /tmp/ip || (mv /tmp/ip.tmp /tmp/ip && ssh root@DNSIP1 "/root/update_ip.sh $(cat /tmp/ip)")); curl ifconfig.co 2>/dev/null > /tmp/ip.tmp2 && (diff /tmp/ip.tmp2 /tmp/ip2 || (mv /tmp/ip.tmp2 /tmp/ip2 && ssh [email protected] "/root/update_ip.sh $(cat /tmp/ip2)"))

Breaking this command down step by step:

curl ifconfig.co 2>/dev/null > /tmp/ip.tmp

This curls a 'what is my IP address' site, and deposits the output to /tmp/ip.tmp

diff /tmp/ip.tmp /tmp/ip || (mv /tmp/ip.tmp /tmp/ip && ssh root@DNSIP1 "/root/update_ip.sh $(cat /tmp/ip)"))

This diffs the contents of /tmp/ip.tmp with /tmp/ip (which is yet to be created, and holds the last-updated ip address). If there is an error (ie there is a new IP address to update on the DNS server), then the subshell is run. This overwrites the ip address, and then ssh'es onto the

The same process is then repeated for DNSIP2 using separate files ( /tmp/ip.tmp2 and /tmp/ip2 ).

Why!?

You may be wondering why I do this in the age of cloud services and outsourcing. There's a few reasons.

It's Cheap

The cost of running this stays at the cost of the two nameservers (24$/year) no matter how many domains I manage and whatever I want to do with them.

Learning

I've learned a lot by doing this, probably far more than any course would have taught me.

More Control

I can do what I like with these domains: set up any number of subdomains, try my hand at secure mail techniques, experiment with obscure DNS records and so on.

I could extend this into a service. If you're interested, my rates are very low :)

---

If you like this post, you might be interested in my book Learn Bash the Hard Way , available here for just $5.

[Jan 08, 2019] Bind DNS threw a (network unreachable) error CentOS

Jan 08, 2019 | www.reddit.com

submitted 11 days ago by

---

mr-bope

Bind 9 on my CentOS 7.6 machine threw this error:

error (network unreachable) resolving './DNSKEY/IN': 2001:7fe::53#53
error (network unreachable) resolving './NS/IN': 2001:7fe::53#53
error (network unreachable) resolving './DNSKEY/IN': 2001:500:a8::e#53
error (network unreachable) resolving './NS/IN': 2001:500:a8::e#53
error (FORMERR) resolving './NS/IN': 198.97.190.53#53
error (network unreachable) resolving './DNSKEY/IN': 2001:dc3::35#53
error (network unreachable) resolving './NS/IN': 2001:dc3::35#53
error (network unreachable) resolving './DNSKEY/IN': 2001:500:2d::d#53
error (network unreachable) resolving './NS/IN': 2001:500:2d::d#53
managed-keys-zone: Unable to fetch DNSKEY set '.': failure

​

What does it mean? Can it be fixed?

And is it at all related with DNSSEC cause I cannot seem to get it working whatsoever.

​

cryan7755 1 point 2 points 3 points 11 days ago (1 child)

Looks like failure to reach ipv6 addressed NS servers. If you don't utilize ipv6 on your network then this should be expected.

knobbysideup 1 point 2 points 3 points 11 days ago (0 children)

Can be dealt with by adding

#/etc/sysconfig/named
OPTIONS="-4"

[Dec 07, 2015] Localhost DNS Cache By Kyle Rankin

Feb 23, 2015 | Linux Journal

... ... ...

There are a number of different ways to implement DNS caching. In the past, I've used systems like nscd that intercept DNS queries before they would go to name servers in /etc/resolv.conf and see if they already are present in the cache. Although it works, I always found nscd more difficult to troubleshoot than DNS when something went wrong. What I really wanted was just a local DNS server that honored TTL but would forward all requests to my real name servers. That way, I would get the speed and load benefits of a local cache, while also being able to troubleshoot any errors with standard DNS tools.

The solution I found was dnsmasq. Normally I am not a big advocate for dnsmasq, because it's often touted as an easy-to-configure full DNS and DHCP server solution, and I prefer going with standalone services for that. Dnsmasq often will be configured to read /etc/resolv.conf for a list of upstream name servers to forward to and use /etc/hosts for zone configuration. I wanted something completely different. I had full-featured DNS servers already in place, and if I liked relying on /etc/hosts instead of DNS for hostname resolution, I'd hop in my DeLorean and go back to the early 1980s. Instead, the bulk of my dnsmasq configuration will be focused on disabling a lot of the default features.

The first step is to install dnsmasq. This software is widely available for most distributions, so just use your standard package manager to install the dnsmasq package. In my case, I'm installing this on Debian, so there are a few Debianisms to deal with that you might not have to consider if you use a different distribution. First is the fact that there are some rather important settings placed in /etc/default/dnsmasq. The file is fully commented, so I won't paste it here. Instead, I list two variables I made sure to set:

ENABLED=1
IGNORE_RESOLVCONF=yes

The first variable makes sure the service starts, and the second will tell dnsmasq to ignore any input from the resolvconf service (if it's installed) when determining what name servers to use. I will be specifying those manually anyway.

The next step is to configure dnsmasq itself. The default configuration file can be found at /etc/dnsmasq.conf, and you can edit it directly if you want, but in my case, Debian automatically sets up an /etc/dnsmasq.d directory and will load the configuration from any file you find in there. As a heavy user of configuration management systems, I prefer the servicename.d configuration model, as it makes it easy to push different configurations for different uses. If your distribution doesn't set up this directory for you, you can just edit /etc/dnsmasq.conf directly or look into adding an option like this to dnsmasq.conf:

conf-dir=/etc/dnsmasq.d

In my case, I created a new file called /etc/dnsmasq.d/dnscache.conf with the following settings:

no-hosts
no-resolv
listen-address=127.0.0.1
bind-interfaces
server=/dev.example.com/10.0.0.5
server=/10.in-addr.arpa/10.0.0.5
server=/dev.example.com/10.0.0.6
server=/10.in-addr.arpa/10.0.0.6
server=/dev.example.com/10.0.0.7
server=/10.in-addr.arpa/10.0.0.7

Let's go over each setting. The first, no-hosts, tells dnsmasq to ignore /etc/hosts and not use it as a source of DNS records. You want dnsmasq to use your upstream name servers only. The no-resolv setting tells dnsmasq not to use /etc/resolv.conf for the list of name servers to use. This is important, as later on, you will add dnsmasq's own IP to the top of /etc/resolv.conf, and you don't want it to end up in some loop. The next two settings, listen-address and bind-interfaces ensure that dnsmasq binds to and listens on only the localhost interface (127.0.0.1). You don't want to risk outsiders using your service as an open DNS relay.

The server configuration lines are where you add the upstream name servers you want dnsmasq to use. In my case, I added three different upstream name servers in my preferred order. The syntax for this line is server=/domain_to_use/nameserver_ip. So in the above example, it would use those name servers for dev.example.com resolution. In my case, I also wanted dnsmasq to use those name servers for IP-to-name resolution (PTR records), so since all the internal IPs are in the 10.x.x.x network, I added 10.in-addr.arpa as the domain.

Once this configuration file is in place, restart dnsmasq so the settings take effect. Then you can use dig pointed to localhost to test whether dnsmasq works:

$ dig ns1.dev.example.com @localhost

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ns1.dev.example.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4208
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.dev.example.com.                   IN      A

;; ANSWER SECTION:
ns1.dev.example.com.    265     IN      A       10.0.0.5

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 18 00:59:18 2014
;; MSG SIZE  rcvd: 56

Here, I tested ns1.dev.example.com and saw that it correctly resolved to 10.0.0.5. If you inspect the dig output, you can see near the bottom of the output that SERVER: 127.0.0.1#53(127.0.0.1) confirms that I was indeed talking to 127.0.0.1 to get my answer. If you run this command again shortly afterward, you should notice that the TTL setting in the output (in the above example it was set to 265) will decrement. Dnsmasq is caching the response, and once the TTL gets to 0, dnsmasq will query a remote name server again.

After you have validated that dnsmasq functions, the final step is to edit /etc/resolv.conf and make sure that you have nameserver 127.0.0.1 listed above all other nameserver lines. Note that you can leave all of the existing name servers in place. In fact, that provides a means of safety in case dnsmasq ever were to crash. If you use DHCP to get an IP or otherwise have these values set from a different file (such as is the case when resolvconf is installed), you'll need to track down what files to modify instead; otherwise, the next time you get a DHCP lease, it will overwrite this with your new settings.

I deployed this simple change to around 100 servers in a particular environment, and it was amazing to see the dramatic drop in DNS traffic, load and log entries on my internal name servers. What's more, with this in place, the environment is even more tolerant in the case there ever were a real problem with downstream DNS servers-existing cached entries still would resolve for the host until TTL expired. So if you find your internal name

[Aug 05, 2013] How to set up a home DNS server by Shannon Hughes

Red Hat Magazine

The Domain Name System (DNS) is the crucial glue that keeps computer networks in harmony by converting human-friendly hostnames to the numerical IP addresses computers require to communicate with each other. DNS is one of the largest and most important distributed databases the world depends on by serving billions of DNS requests daily for public IP addresses. Most public DNS servers today are run by larger ISPs and commercial companies but private DNS servers can also be useful for private home networks. This article will explore some advantages of setting up various types of DNS servers in the home network.

Why set up a private DNS server?

This question is valid and the answer may vary depending on your home network environment. Maintaining a host file on each client with IP/hostname mappings in a home network that contains a router and a few machines may be sufficient for most users. If your network contains more than a few machines, then adding a private DNS server may be more attractive and worth the setup effort. Some advantages may include:

• Maintenance: keeping track of the host file for every client in your network can be tedious. In fact, it may not even be feasible for roaming DHCP laptops or your occasional LAN party guests. Maintaining host information in one central area and allowing DNS to manage host names is more efficient.

• Cache performance: DNS servers can cache DNS information, allowing your clients to acquire DNS information internally without the need to access public nameservers. This performance improvement can add up for tasks such as web browsing.

• Prototyping: A private internal DNS server is an excellent first step to eventually setting up a public accessible DNS server to access a web server or other services hosted on your internal network. Learning from mistakes on an internal network can help prevent duplicate errors on a public DNS server that could result in loss of service for external users. Note: Some ISPs require customers to have a static IP or business subscription when hosting services in a home network environment.

• Cool factor: Ok, I may be stretching it, but the "cool" factor did have some influence when I set up my first home network DNS server. Creating an internal domain that reflects an individual's personality without paying a domain registrar and issuing hostnames to your clients is cool. The cool factor doubles when your customized hostname glows from your friend's laptop screen.

Let's start out simply by setting up a caching-only nameserver to handle client DNS requests. A caching-only nameserver won't allow references to internal clients by hostname, but it does allow clients to take advantage of frequently requested domains that are cached.

Caching nameserver

Fortunately, setting up a caching nameserver is easy using RHEL (Red Hat Enterprise Linux) or Fedora RPMs. The following RPMs need to be installed on the machine acting as the nameserver (use rpm -q to determine if these packages are installed):

• bind (includes DNS server, named)

• bind-utils (utilities for querying DNS servers about host information)

• bind-libs (libraries used by the bind server and utils package)

• bind-chroot (tree of files which can be used as a chroot jail for bind)

• caching-nameserver (config files for a simple caching nameserver)

A caching nameserver forwards queries to an upstream nameserver and caches the results. Open the file /var/named/chroot/etc/named.conf and add the following lines to the global options section:

     forwarders { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; }; #IP of upstream ISP nameserver(s)
     forward only; #rely completely on our upstream nameservers

The block above will cause the caching name server to forward DNS requests it can't resolve to your ISP nameserver. Save the named.conf file and then assign 644 permissions:
chmod 644 named.conf
Check the syntax using the named-checkconf utility provided by the bind RPM:
named-checkconf named.conf
Correct any syntax errors (watch those semicolons) named-checkconf reports. Monitoring the /var/log/messages file may also be helpful in debugging any errors.
We now need to set the local resolver to point to itself for DNS resolution. Modify the /etc/resolv.conf file to the following:
nameserver 127.0.0.1
If you are running a DHCP server on your router make sure your /etc/resolv.conf file does not get overwritten whenever your DHCP lease is renewed. To prevent this from happening, modify /etc/sysconfig/network-scripts/ifcfg-eth0 (replace eth0 with your network interface if different) and make sure the following settings are set:

BOOTPROTO=dhcp
PEERDNS=no
TYPE=Ethernet

Go ahead and start the nameserver as root and configure to start in runlevels 2-5:
service named start
chkconfig named on

Testing

The bind-utils RPM contains tools we can use to test our caching nameserver. Test your nameserver using host or dig and querying redhat.com:

dig redhat.com
.
.
;; Query time: 42 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

From the above dig query you can see it took 42 msec to receive the DNS request. Now test out the caching ability of your nameserver by running dig again on the redhat.com domain:

dig redhat.com
.
.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

We dropped from 42 msec to 1 msec after the previous DNS query was cached. Caching is working! Let's now put the cache to work by configuring the clients to use the new caching nameserver.

Client Configuration

For Linux and Windows clients you may have a couple of options for your resolver configuration depending on your network environment:

1. If you have a router and your client's IP address is assigned via DHCP from the router, then you can use the router to assign the primary nameserver during the DHCP lease requested from the client. Log in to your router and make sure your primary nameserver points to your caching nameserver IP address in the router DHCP settings.

2. For Linux clients, you can set up the resolver in the same procedure as the nameserver by modifying the /etc/resolv.conf file. For Windows clients you will need to set the nameserver IP address in the Control Panel -> Network Connections -> TCP/IP -> Properties -> Use the DNS Server Address option. NOTE: The Windows DNS server option may vary depending on your version.

Test your new client configuration(s) using dig. You can use the nslookup command for Windows clients. Your DNS requests should have similar response times as we saw earlier when testing the nameserver directly.

NOTE: If you are running a firewall on the nameserver system, make sure clients have access to port 53. An example iptables rule for the 192.168.15.0/24 subnet would be:

iptables -A INPUT -s 192.168.15.0/24 -p udp --dport 53 -j ACCEPT
service iptables save

Summary

Your new caching nameserver offers a performance improvement with a minimal amount of set up effort. Clients can now ask the caching nameserver for DNS information, and it only needs to ask the upstream ISP nameserver for cache misses. In the next issue we will setup a master nameserver that is responsible for the authoritative information for our internal client hostnames. An authoritative nameserver also caches by default but additionally allows managing both static and DHCP clients using personalized hostnames set up in zone files. In the meantime, enjoy your new caching nameserver and be thinking about a creative domain and hostname theme for your future authoritative nameserver.

About the author

Shannon Hughes is a Red Hat Network (RHN) engineer who enjoys using open source software to solve the most demanding software projects. When he is not cranking out code, tweaking servers, or coming up with new RHN projects, you can find him trying to squeeze in yet another plant in the yard/garden with his wife, watching Scooby Doo reruns with his two kids and dog, or incorporating the latest open source projects for his church.

Speeding up the internet with squid

Living, as I do, in rural France, I suffer from rather slow internet connectivity. My normal line speed is only 512Kbs and sometimes I struggle to achieve even this. My solution is to use an Internet Acceleration Appliance, the building and configuration of which is detailed at….

www.InternetAccelerationAppliance.com

Now, whilst that works very well, the server that it runs on needs an upgrade (I'm going to add some more memory and another couple of SCSI disks) and will then be used for a number crunching/data processing project that I am about to embark on.

Now, I was resigned to losing the speed increase that the server gave me but today, over a cup of coffee in a little bar in the nearest village, I wondered to myself whether I could just install the functionality of the server onto my local PC.

I couldn't see any reason why not and, less than an hour later, it was done.

Caching DNS Proxy Server

I started off by installing PDNSD as a local caching DNS server.

The instructions and reasons for doing this are detailed at www.internetaccelerationappliance.com – installing pdnsd so I'll just offer a brief recap here….

What is DNS?

Imagine, if you will, that you want to send a letter to your friend Joe Bloggs. If you were just to address that letter to Joe Bloggs, it would almost certainly never arrive.

If, however, you were to address that letter to Joe's address… 24 Staunton Court, Streatham, London, England then, sooner or later, it will be delivered.

The internet is similar. We know sites by their names (i.e. www.google.com) but the delivery service needs the address (in this case the IP address – 74.125.77.104)

When we type www.google.com into our browser, that information goes up the line to our Service Provider (in my case Orange.fr)

Now, the server(s) at Orange don't know who Google.com is so they have to look up an address for it. For this, they request the information from their DNS servers. These are basically just servers that contain lists of names and their associated IP addresses. A bit like telephone directories except there can only be one Google.com whereas in a telephone directory there may be many entries for Joe Bloggs.

If the local DNS servers at Orange.fr don't have an address, then the request is forwarded to the national DNS servers and then, finally, the root DNS servers (which, for .COM addresses are in Singapore.)

All this can take time. What we are going to do here is make this process local so that every time we get an IP address from the Service Provider, it is going to be noted here in a local caching DNS server so that the next time we want to visit Google.com we don't have to wait for Orange.fr to supply the address – we'll already have it.

Hopefully this will speed up my effective internet speed.

pdnsd installation

1). On my Debian system the installation was simple….

apt-get install pdnsd dnsutils

2). Once this is complete we need to edit one file…

nano /etc/default/pdnsd and press Enter. This will load the file in the nano text editor.

Change line 2 so that it reads… START_DAEMON=yes

Ctrl & O – to save file and press Enter

3). Now we need to edit the pdnsd configuration file (/etc/psdnd.conf)

My /etc/pdnsd.conf now looks like this….

global {
perm_cache=1024;
cache_dir="/var/cache/pdnsd";
run_as="pdnsd";
server_ip = 127.0.0.1;
server_port=53;
status_ctl = on;
paranoid=on;
query_method=udp_tcp;
max_ttl=1w; # One week.
timeout=10;
}
server {
label=OpenDNS;
ip=208.67.222.222;
ip=208.67.220.220;
timeout=30;
uptest=ping;
interval=30;
ping_timeout=300;
purge_cache=off;
caching=on;
preset=off;
}
source {
owner=localhost;
serve_aliases=on;
file="/etc/hosts";
}
rr {
name=localhost;
reverse=on;
a=127.0.0.1;
owner=localhost;
soa=localhost,root.localhost,42,86400,900,86400,86400;
}
global {perm_cache=1024;cache_dir="/var/cache/pdnsd";run_as="pdnsd"; server_ip = 127.0.0.1; server_port=53;status_ctl = on;paranoid=on; query_method=udp_tcp;max_ttl=1w; # One week.timeout=10; }server {label=OpenDNS;ip=208.67.222.222;ip=208.67.220.220;timeout=30;uptest=ping;interval=30; ping_timeout=300;purge_cache=off;caching=on;preset=off;}
source {owner=localhost;serve_aliases=on;file="/etc/hosts";}
rr {name=localhost;reverse=on;a=127.0.0.1;owner=localhost; soa=localhost,root.localhost,42,86400,900,86400,86400;}

4). Now we must resolv.conf - nano /etc/resolv.conf and press Enter

Change the file so that it contains just one line which reads exactly as follows….. nameserver 127.0.0.1

5). Because my machine already used a fixed IP address I didn't have to do the following, you may have to if you use DHCP…

Edit dhclient.conf - nano /etc/dhcp3/dhclient.conf and press Enter

Find the line that starts #prepend domain-name-servers (about 20 lines down) and remove the # so that the line reads as follows… prepend domain-name-servers 127.0.0.1;

Ctrl & O – to save file and press Enter

Ctrl & X – to quit nano

6). Finally, Edit interfaces - nano /etc/network/interfaces

Edit the line that starts… dns-nameservers so that it reads….. dns-nameservers 192.168.1.2

Ctrl & O – to save file and press Enter

Ctrl & X – to quit nano

Reboot the machine.

7). Log into the rebooted machine, open a terminal and type in the command…

dig Google.com

Note the Query time: (this is the time spent to retrieve Google's IP address from the OpenDNS servers) – on my machine it was 316 msec.

Now run the same command again (arrow up will redisplay the last command.)

Note the Query time: (the address should be resolved locally by pdnsd) – it should now be about 3 msec.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

• Quick HOWTO Ch18 Configuring DNS - Linux Home Networking
• Linux DNS Server - How To Set Up Static or Dynamic DNS for Your Internet Servers
• Setting up a Linux DNS server, part 2: Ongoing maintenance
• Setup DNS Server step by step in CentOS 6.3 / RHEL 6.3 / Scientific Linux 6.3 January 25, 2013 ~ SK

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: May, 10, 2020