Whispers & Screams
And Other Things

Spread Spectrum Modulation Techniques

As an ex military satellite communications engineer I certainly remember working with spread spectrum modulation and also frequency hopping technology in the 1980's. Wireless Local Area Networking technology today exploits a technology which was thitherto mostly hidden inside this shadowy domain of military communications and radar. This technology comprises a collection of ideas which are termed Spread Spectrum Techniques (SST). Spread Spectrum techniques have some powerful properties which make them an excellent candidate for networking applications. To better understand why, we will take a closer look at this fascinating area, and its implications for networking.

Continue reading
2262 Hits
0 Comments

Isn't Satellite Communication Old School Now

Space travel has and continues to fascinate us. As humans it will always be our intrinsic instinct to explore and discover whatever lies over the next horizon. Such was the motivation for the space race which ultimately provided the world with satellite communications amongst many other things. When we look back at the grainy pictures from that febrile time in history however what we see is a world which looks very different to that of today. Indeed most of the sci-fi of the 1960's was set around about now. As people of their future looking back it all seems rather quaint to us but the benefits we have enjoyed from satellite communications have been many and varied. Since the launch of Telstar, satellite communications has enabled us to beam the finger of mass communications to every corner of the planet

The above notwithstanding, our world today is criss-crossed by undersea cables between every continent and across every sea. Satellite communication (or SATCOM as we will refer to it moving forward) would seem to no longer be necessary... or is it? Lets take a look at the benefits it brought to us at its genesis.

Satcom is the ultimate mobile technology. It provides us with the possibility for cable free communications across the whole footprint of a beam. For some types of spacecraft such a footprint can cover many hundreds of thousands of square miles from only one beam. A single spacecraft can support many beams. That we can utilise this technology anywhere within the beam is such an enormous asset that it completely revolutionises our activity in the remotest areas of the planet. It is now possible to call your mum from a rowing boat in the middle of the atlantic ocean on mothers day, or indeed on any day. Such is the ease of use that is possible using technology no more byzantine than a satellite phone. 

Satellite comms is also relatively cheap although the person who owns the satellite phone may ask you to keep it brief whilst calling your mum. Mobile terminals are however cheap and cheerful when examined in the context of global communication methods. They can also be quite easily adapted to support voice, video or data or indeed all three at once. It is being used extensively as a medium through which to deliver broadband internet services to difficult to reach areas within developed countries not to mention those with a less ubiquitous infrastructure. The frequencies used for satcom are selected specifically because of their ability to resist absorption enabling them to cover the enormous distances required. On top of this it is impossible to ignore the enormous usage of satellite for broadcast media such as television broadcasting where the system is set up primarily for one way communication. In summary then satellite communications has and continues to deliver enormous benefits and has a number of key unique selling points.

 

The premise of this post however does not seek to confirm the obsolescence of Satcom but rather to examine its place in the ever changing telecommunications landscape. In today's world of wireless communications, high definition television and global access to the Internet, many people are unclear about the inherent advantages of satellite communications but they persist and are many. 

 

Cost Effective - The cost of satellite capacity doesn't increase with the number of users/receive sites, or with the distance between communication points. Whether crossing continents or staying local, satellite connection cost is distance insensitive. 

Global Availability - Communications satellites cover all land masses and there is growing capacity to serve maritime and even aeronautical markets. Customers in rural and remote regions around the world who cannot obtain high speed Internet access from a terrestrial provider are increasingly relying on satellite communications.

Superior Reliability - Satellite communications can operate independently from terrestrial infrastructure. When terrestrial outages occur from man-made and natural events, satellite connections remain operational.

Superior Performance - Satellite is unmatched for broadcast applications like television. For two-way IP networks, the speed, uniformity and end-to-end control of today's advanced satellite solutions are resulting in greater use of satellite by corporations, governments and consumers.

Immediacy and Scalability - Additional receive sites, or nodes on a network, can readily be added, sometimes within hours. All it takes is ground-based equipment. Satellite has proven its value as a provider of "instant infrastructure" for commercial, government and emergency relief communications.

Versatility and More - Satellites effectively support on a global basis all forms of communications ranging from simple point-of-sale validation to bandwidth intensive multimedia applications. Satellite solutions are highly flexible and can operate independently or as part of a larger network.

 

As we move froward and the need for ubiquitous communications becomes ever more embedded into the fabric of our lives, satellite communication will move into a golden age. Techniques and mechanisms with which to leverage the spacecraft as a communications platform are continually evolving and it is this swathe of new and exciting use cases that will take the communications satellite into the rest of the 21st century and beyond. 

Ingenious new techniques such as that envisioned by companies like Leosat and OneWeb demonstrate that the traditional paradigm of teleport-satellite-teleport communications is no longer de rigeur. As new business models seek to create optical meshed networks in the sky, new uses continue to emerge. Such networks will ultimately become the fastest communication links for distances over 10,000 miles because light travels faster through a vacuum than it does through glass. For applications which need to shave every possible fraction of a second from network delays (and there are many) these new networks will surpass the existing terrestrial networks no matter how few routed hops are required. The high speed world of financial algo trading, where microseconds cost millions will quickly move to these types of networks once they reach production.

As we move slowly away from the turn of the 21st century some may have expected that satellite communication may have been headed for its swansong given the ubiquity and reach of terrestrial networks. I'd appreciate your thoughts in the comments section below as to what the future may hold for satellite communication or indeed perhaps more broadly for spacecraft communication. I think its fair to say that reports of its demise have been greatly exaggerated.

Continue reading
2385 Hits
0 Comments

The Rise Of The Machines

One of the hot topics of the twenty teenies that was totally expected is the examination surrounding the ways in which AI or artificial intelligence will affect our lives and most specifically how AI will affect our jobs. For decades now, celebrated authors from Asimov to Zelazny have used robotics and AI as a key thread around which to weave a story.

That it is prominent in the public consciousness is in no doubt but in recent years as science fiction has slowly begun to become science fact, it is how this technology threatens to directly affect us that has become the core of the discussion. Unsurprisingly the kernel of that discussion has been how it will affect our bank balance and it is here that the real story lies in terms of how the fragile and unweildy human psyche copes against the agile and indefatigable machine.

To properly begin to understand this subject it is important to establish a rather obvious but sometimes surprising baseline. Ever since man discovered the flint and invented the wheel, technology has been changing our lives irrevocably. Its a track we have been travelling for millennia and, as the changes have affected our societies, we've adapted accordingly. Sure there's some tech we'd probably like to have not invented such as the nuke but even that thought is surrounded by controversy as it's by no means certain that we wouldn't still be embroiled in the Second World War if it hadn't been made. Its important therefore to accept that all of the tech in our world today has made the world what it is today and very few of us would seek to go back to a subsistence agrarian and feudal societal model with all its attendant drudgery and disease. Yes we have unemployment in modern society but it is rarely helpless unemployment and by learning new skills, the individual can once again find a foothold in the employment market.

This, in my opinion, is the key fact regarding AI and robots. It's manifest human nature to believe that everything that has gone before was somehow different but the crisis yet to come will change everything because of its uniqueness. The laughable fact that the British during the reign of Queen Victoria believed that they had invented everything testifies to that sentiment.

Looking at more contemporary disruption such as the invention of the tractor and the factory robot, its clear to see that whilst jobs have obviously disappeared, others have emerged. It is probably fair to expect that this model which has been the reality for millennia will continue to apply. As our economies develop increasingly technological foundations the need for unskilled human labour will continue to diminish however will not necessarily end. The slightly disturbing concept of meatware which is used to describe humans doing menial tasks that are not able to be done more economically by robots has come into the dictionary. Notwithstanding this unfortunate niche, society will continue to develop as its technology does. 

The key in all of this is the adaptability and indeed the ability of the individual to adapt and learn new and increasingly complex skills. This, if anywhere is where the drawbridge may be pulled up on certain sections of society. AI may well have already arrived. Of that there is no doubt however autonomous AI which can continue to operate with no intervention from humans for decades or indeed indefinitely is still a long way off. This is where the future human workforce will ply its trade and it was ever thus. 

Another interesting area which opens up as a result of this discussion topic is that of human robotic augmentation. It may well be the destiny of the human race to slowly mechanise using increasingly powerful technological assistance which will gradually find social acceptance in its integration into our bodies. This may present us with enough of an edge that we can continue to compete with advancing technology or to some it may be the thin end of a terrible wedge which will find us all as barely conscious semi automata, trapped in a body that is not really ours and connected to the hive mind forever. 

The future is coming whether we like it or not and we cannot uninvent that which we have invented. Even the heavily regulated field of human embryonic manipulation is never at a standstill but rather is always creeping forward as taboos slowly dissipate over time. The ratchet of progress can go only one way and it never really stops. As a species we are masters of this planet because of our enormous ability to adapt and overcome the most difficult of environments and it is this core human skill which will be our greatest asset in the decades to come. If we cannot then the social upheaval may well become the biggest influencer regarding our future. Discrepancies of wealth and opportunity in societies are rarely allowed to exist for long and usually end explosively and it may well be therefore that the surest way for humanity to survive is to assure a certain minimum living standard for all as we pivot to a new model where ones ability to earn a living becomes less important. There are many possible futures out there and, as has always been the case, many are terrible and many are not. The future's not ours to see. Que sera sera...

Continue reading
2551 Hits
0 Comments

Set up BIND as a DNS Server on Ubuntu

Introduction

 



DNS is important. The Domain Name Service is perhaps the most overlooked component of routine Internet services. When it becomes compromised or fails, the consequences can be far reaching and even catastrophic. To control DNS is to potentially control everything since modifying DNS services can redirect any user anywhere. It doesnt take a rocket scientist to understand the dramatic consequences of redirecting paypal.com to hackedpaypal.com and have all users innocently punching in their login details for collection in a nasty database somewhere.

DNS is also convenient. Setting your browser to use the bbc.co.uk website wouldnt be quite so easy if you had to refer to it as 212.58.246.104. Using fully qualified domain names (FQDNs), instead of IP addresses, to specify network addresses eases the configuration of services and applications, and increases the maintainability of configuration files.

As I am currently setting up some of my own internal nameservers, I decide to create a guide for my blog. In this post, I will go over how to set up an internal DNS server, using the BIND name server software (BIND9), that can be used by your own private network in the home or business to resolve host names and IP addresses. This provides a central way to manage your own hostnames and IP addresses, which is indispensable when your environment expands to more than a few hosts.

DNS Hosts


We will be setting up the new DNS servers in our office in London serving the technofatty domain. With this assumption, we decide that it makes sense to use a naming scheme that uses "ldn1.technofatty.com" to refer to our private subnet or zone. Therefore, host1's private Fully-Qualified Domain Name (FQDN) will be "pc1.ldn1.technofatty.com". Refer to the following table the relevant details:
Host Role Private FQDN Private IP Address
host1 User PC 1 pc1.ldn1.technofatty.com 192.168.1.101
host2 DVR 1 dvr1.ldn1.technofatty.com 192.168.1.102

Note: Your own setup will be different, but the example names and IP addresses given will be used to demonstrate how to configure a DNS server to provide a functioning internal DNS. You should be able to adapt this setup to your own environment fairly simply by replacing the host names and private IP addresses with your own. It is not necessary to use the region name of the site in your naming scheme, but we use it here to denote that these hosts belong to a particular sites private network. If you have multiple sites, you can set up an internal DNS within each respective site.
 

Our Goal


By the end of this tutorial, we will have a primary DNS server, ns1, as well as a secondary DNS server,ns2, which will operate as a backup.

Here is a table with example names and IP addresses:
Host Role Private FQDN Private IP Address
ns1 Pri DNS Server ns1.ldn1.technofatty.com 192.168.1.1
ns2 Sec DNS Server ns2.ldn1.technofatty.com 192.168.1.2

Let's get started by installing our Primary DNS server, ns1.
 

Install BIND on Primary Server


On both DNS servers, ns1 and ns2, carry out apt-get update
sudo apt-get update

Next install BIND:
sudo apt-get install bind9 bind9utils bind9-doc

IPv4 Mode


Next we need to set BIND to IPv4 mode. On both servers, edit the bind9 startup options file:
sudo nano /etc/default/bind9

Add "-4" to the OPTIONS variable. It should look like the following:
OPTIONS="-4 -u bind"

Save and exit.

OK onwards to configure the primary DNS server.
 

Configure Primary DNS Server


BIND's configuration consists of multiple files, which are included from the main configuration file, named.conf. These filenames begin with "named" because that is the name of the process that BIND runs. We will start with configuring the options file. The default contents of this file are shown below:

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Configure Options File


As you can see from the above, the first file that is included is named.conf.options. On ns1, open the named.conf.options file for editing:
sudo nano /etc/bind/named.conf.options

Above the existing options block, create a new ACL block called "trusted". This is where we will define list of clients that we will allow recursive DNS queries from (i.e. your servers that are in the same datacenter as ns1). Using our example private IP addresses, we will add ns1, ns2, host1, and host2 to our list of trusted clients:
acl "trusted" {
192.168.1.1; # ns1 - can be set to localhost
192.168.1.2; # ns2
192.168.1.101; # pc1
192.168.2.102; # dvr1
};

Having set up the list of trusted DNS clients, we now need to edit the options block. Currently, the start of the block looks like the following:
options {
directory "/var/cache/bind";
...
}

Below the directory directive, add the highlighted configuration lines (and substitute in the proper ns1 IP address) so it looks something like this:
options {
directory "/var/cache/bind";

recursion yes; # enables resursive queries
allow-recursion { trusted; }; # allows recursive queries from "trusted" clients
listen-on { 192.168.1.1; }; # ns1 private IP address - listen on private network only
allow-transfer { none; }; # disable zone transfers by default

forwarders {
8.8.8.8;
8.8.4.4;
};
...
};

Now save and exit named.conf.options. The above configuration specifies that only your own servers (the "trusted" ones) will be able to query your DNS server.

Next, we will configure the local file, to specify our DNS zones.

Configure Local File


On ns1, open the named.conf.local file using nano:
sudo nano /etc/bind/named.conf.local

Apart from some commented lines, the default file will be empty. This is where, we specify our forward and reverse zones.

Add the forward zone with the following lines (substituting the zone name as appropriate):
zone "ldn1.technofatty.com" {
type master;
file "/etc/bind/zones/db.ldn1.technofatty.com"; # zone file path
allow-transfer { 192.168.1.2; }; # ns2 address - secondary
};

Assuming that our private subnet is 192.168.1.0/24, add the reverse zone by with the following lines (note that our reverse zone name starts with "168.192" which is the octet reversal of "192.168"):
zone "168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.168.192"; # 192.168.1.0/24 subnet
allow-transfer { 192.168.1.2; }; # ns2 address - secondary
};

If your servers span more than one subnet but are on the same site, dont forget to specify an additional zone and zone file for each seperate subnet.

Once finished adding all of your required zones, save and exit the named.conf.local file.

Now that our zones are specified in BIND, we need to create the corresponding forward and reverse zone files.

Create Forward Zone File


The forward zone file is where we define DNS records for forward DNS lookups. That is, when the DNS receives a name query, "host1.nyc2.example.com" for example, it will look in the forward zone file to resolve host1's corresponding private IP address.

Let's create the directory where our zone files will reside. According to our named.conf.local configuration, that location should be /etc/bind/zones:
sudo mkdir /etc/bind/zones

It is simplest to base our forward zone file on the sample db.local zone file which is installed by default. Copy it to the proper location with the following commands:
cd /etc/bind/zones
sudo cp ../db.local ./db.ldn1.technofatty.com

Now let's edit our forward zone file:
sudo nano /etc/bind/zones/db.ldn1.technofatty.com

Initially, it will look something like the following:
$TTL    604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line

First, you will want to edit the SOA record. Replace the first "localhost" with ns1's FQDN, then replace "root.localhost" with "admin.ldn1.technofatty.com". Also, every time you edit a zone file, you should increment the serial value before you restart the named process--we will increment it to "3". It should look something like this:
@       IN      SOA     ns1.ldn1.technofatty.com. admin.ldn1.technofatty.com. (
3 ; Serial

Now delete the three records at the end of the file (after the SOA record). If you're not sure which lines to delete, they are marked with a "delete this line" comment above.

At the end of the file, add your nameserver records with the following lines (replace the names with your own). Note that the second column specifies that these are "NS" records:
; name servers - NS records
IN NS ns1.ldn1.technofatty.com.
IN NS ns2.ldn1.technofatty.com.

Then add the A records for your hosts that belong in this zone. This includes any server whose name we want to end with ".ldn1.technofatty.com" (substitute the names and private IP addresses). Using our example names and private IP addresses, we will add A records for ns1, ns2, pc1, and dvr1 like so:
; name servers - A records
ns1.ldn1.technofatty.com. IN A 192.168.1.1
ns2.ldn1.technofatty.com. IN A 192.168.1.2

; 192.168.1.0/24 - A records
pc1.ldn1.technofatty.com. IN A 192.168.1.101
dvr1.ldn1.technofatty.com. IN A 192.168.1.102

Save and exit the db.ldn1.technofatty.com file.

Our final example forward zone file looks like the following:
$TTL    604800
@ IN SOA ns1.ldn1.technofatty.com. admin.ldn1.technofatty.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; name servers - NS records
IN NS ns1.ldn1.technofatty.com.
IN NS ns2.ldn1.technofatty.com.

; name servers - A records
ns1.ldn1.technofatty.com. IN A 192.168.1.1
ns2.ldn1.technofatty.com. IN A 192.168.1.2

; 192.168.1.0/24 - A records
pc1.ldn1.technofatty.com. IN A 192.168.1.101
dvr1.ldn1.technofatty.com. IN A 192.168.1.102

Next we move on to the reverse zone file(s).

Create Reverse Zone File(s)


Reverse zone file are where we define DNS PTR (pointer) records for reverse DNS lookups. That is, when the DNS receives a query by IP address, "192.168.1.101" for example, it will look in the reverse zone file(s) to resolve the corresponding FQDN, "pc1.ldn1.technofatty.com" in this case.

On ns1, for each reverse zone specified in the named.conf.local file, create a reverse zone file. We will base our reverse zone file(s) on the sample db.127 zone file. Copy it to the proper location with the following commands (substituting the destination filename so it matches your reverse zone definition):
cd /etc/bind/zones
sudo cp ../db.127 ./
db.168.192

Edit the reverse zone file that corresponds to the reverse zone(s) defined in named.conf.local:
sudo nano /etc/bind/zones/db.168.192

Initially, it will look something like the following:
$TTL    604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
1.0.0 IN PTR localhost. ; delete this line

In the same manner as the forward zone file, you will want to edit the SOA record and increment the serial value. It should look something like this:
@       IN      SOA     ns1.ldn1.technofatty.com. admin.ldn1.technofatty.com. (
3 ; Serial

Now delete the two records at the end of the file (after the SOA record). If you're not sure which lines to delete, they are marked with a "delete this line" comment above.

At the end of the file, add your nameserver records with the following lines (replace the names with your own). Note that the second column specifies that these are "NS" records:
; name servers - NS records
IN NS ns1.ldn1.technofatty.com.
IN NS ns2.ldn1.technofatty.com.

Then add PTR records for all of your servers whose IP addresses are on the subnet of the zone file that you are editing. In our example, this includes all of our hosts because they are all on the 10.128.0.0/16 subnet. Note that the first column consists of the last two octets of your servers' private IP addresses in reversed order. Be sure to substitute names and private IP addresses to match your servers:
; PTR Records
1.1 IN PTR ns1.ldn1.technofatty.com. ; 192.168.1.1
2.1 IN PTR ns2.ldn1.technofatty.com. ; 192.168.1.2
101.1 IN PTR pc1.ldn1.technofatty.com. ; 192.168.1.101
102.1 IN PTR dvr1.ldn1.technofatty.com. ; 192.168.1.102

Save and exit the reverse zone file (repeat this section if you need to add more reverse zone files).

Our final example reverse zone file looks like the following:
$TTL    604800
@ IN SOA ns1.ldn1.technofatty.com. admin.ldn1.technofatty.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

; name servers - NS records
IN NS ns1.ldn1.technofatty.com.
IN NS ns2.ldn1.technofatty.com.

; PTR Records
1.1 IN PTR ns1.ldn1.technofatty.com. ; 192.168.1.1
2.1 IN PTR ns2.ldn1.technofatty.com. ; 192.168.1.2
101.1 IN PTR pc1.ldn1.technofatty.com. ; 192.168.1.101
102.1 IN PTR dvr1.ldn1.technofatty.com. ; 192.168.1.102


Check BIND Configuration Syntax


Run the following command to check the syntax of the named.conf* files:
sudo named-checkconf

If your named configuration files have no syntax errors, you will return to your shell prompt and see no error messages. If there are problems with your configuration files, review the error messages then re-try named-checkconf .

The named-checkzone command can be used to check the correctness of your zone files. Its first argument specifies a zone name, and the second argument specifies the corresponding zone file, which are both defined in named.conf.local.

For example, to check the "ldn1.technofatty.com" forward zone configuration, run the following command (change the names to match your forward zone and file):
sudo named-checkzone ldn1.technofatty.com db.ldn1.technofatty.com

And to check the "168.192.in-addr.arpa" reverse zone configuration, run the following command (change the numbers to match your reverse zone and file):
sudo named-checkzone 168.192.in-addr.arpa /etc/bind/zones/db.168.192

When all of your configuration and zone files have no errors in them, you should be ready to restart the BIND service.

Restart BIND


Restart BIND:
sudo service bind9 restart

Your primary DNS server is now setup and ready to respond to DNS queries. Let's move on to creating the secondary DNS server.
 

Configure Secondary DNS Server


In most environments, it is a good idea to set up a secondary DNS server that will respond to requests if the primary becomes unavailable. Luckily, the secondary DNS server is much easier to configure.

On ns2, edit the named.conf.options file:
sudo nano /etc/bind/named.conf.options

At the top of the file, add the ACL with the private IP addresses of all of your trusted servers:
acl "trusted" {
192.168.1.1; # ns1 - can be set to localhost
192.168.1.2; # ns2
192.168.1.101; # pc1
192.168.2.102; # dvr1
};

Below the directory directive, add the following lines:
        recursion yes;
allow-recursion { trusted; };
listen-on { 192.168.1.2; }; # ns2 private IP address
allow-transfer { none; }; # disable zone transfers by default

forwarders {
8.8.8.8;
8.8.4.4;
};

Save and exit named.conf.options. This file should look exactly like ns1's named.conf.options file except it should be configured to listen on ns2's private IP address.

Now edit the named.conf.local file:
sudo nano /etc/bind/named.conf.local

Define slave zones that correspond to the master zones on the primary DNS server. Note that the type is "slave", the file does not contain a path, and there is a masters directive which should be set to the primary DNS server's private IP. If you defined multiple reverse zones in the primary DNS server, make sure to add them all here:
zone "ldn1.technofatty.com" {
type slave;
file "db.ldn1.technofatty.com";
masters { 192.168.1.1; }; # ns1 private IP
};

zone "168.192.in-addr.arpa" {
type slave;
file "db.168.192";
masters { 192.168.1.1; }; # ns1 private IP
};

Now save and exit named.conf.local.

Run the following command to check the validity of your configuration files:
sudo named-checkconf

Once that checks out, restart bind
sudo service bind9 restart

Now you have primary and secondary DNS servers for private network name and IP address resolution. Now you must configure your servers to use your private DNS servers.
 

Configure DNS Clients


Before all of your servers in the "trusted" ACL can query your DNS servers, you must configure each of them to use ns1 and ns2 as nameservers. This process varies depending on OS, but for most Linux distributions it involves adding your name servers to the /etc/resolv.conf file.

Ubuntu Clients


On Ubuntu and Debian Linux VPS, you can edit the head file, which is prepended to resolv.conf on boot:
sudo nano /etc/resolvconf/resolv.conf.d/head

Add the following lines to the file (substitute your private domain, and ns1 and ns2 private IP addresses):
search ldn1.technofatty.com     # your private domain
nameserver 192.168.1.1 # ns1 private IP address
nameserver 192.168.1.2 # ns2 private IP address

Now run resolvconf to generate a new resolv.conf file:
sudo resolvconf -u

Your client is now configured to use your DNS servers.

CentOS Clients


On CentOS, RedHat, and Fedora Linux VPS, simply edit the resolv.conf file:
sudo nano /etc/resolv.conf

Then add the following lines to the TOP of the file (substitute your private domain, and ns1 and ns2 private IP addresses):
search ldn1.technofatty.com  # your private domain
nameserver 192.168.1.1 # ns1 private IP address
nameserver 192.168.1.2 # ns2 private IP address

Now save and exit. Your client is now configured to use your DNS servers.

Test Clients


Use nslookup to test if your clients can query your name servers. You should be able to do this on all of the clients that you have configured and are in the "trusted" ACL.

Forward Lookup


For example, we can perform a forward lookup to retrieve the IP address of pc1.ldn1.technofatty.com by running the following command:
nslookup pc1

Querying "pc1" expands to "pc1.ldn1.technofatty.com because the search option is set to your private subdomain, and DNS queries will attempt to look on that subdomain before looking for the host elsewhere. The output of the command above would look like the following:
paula@ns2:~$ nslookup pc1
Server: 192.168.1.1
Address: 192.168.1.1#53

Name: host1.nyc2.example.com
Address: 192.168.1.101

Reverse Lookup


To test the reverse lookup, query the DNS server with pc1's private IP address:
nslookup 192.168.1.101

You should see output that looks like the following:
Server:     192.168.1.1
Address: 192.168.1.1#53

101.1.168.192.in-addr.arpa name = pc1.ldn1.technofatty.com.

If all of the names and IP addresses resolve to the correct values, that means that your zone files are configured properly. If you receive unexpected values, be sure to review the zone files on your primary DNS server (e.g. db.ldn1.technofatty.com and db.168.192).

Congratulations! Your internal DNS servers are now set up properly! Now we will cover maintaining your zone records.

 

Maintaining DNS Records


Now that you have a working internal DNS, you need to maintain your DNS records so they accurately reflect your server environment.

Adding Host to DNS


Whenever you add a host to your environment (in the same datacenter), you will want to add it to DNS. Here is a list of steps that you need to take:

Primary Nameserver



    • Forward zone file: Add an "A" record for the new host, increment the value of "Serial"

    • Reverse zone file: Add a "PTR" record for the new host, increment the value of "Serial"

    • Add your new host's private IP address to the "trusted" ACL (named.conf.options)


Then reload BIND:
sudo service bind9 reload

Secondary Nameserver



    • Add your new host's private IP address to the "trusted" ACL (named.conf.options)


Then reload BIND:
sudo service bind9 reload

Configure New Host to Use Your DNS



    • Configure resolv.conf to use your DNS servers

    • Test using nslookup


Removing Host from DNS


If you remove a host from your environment or want to just take it out of DNS, just remove all the things that were added when you added the server to DNS (i.e. the reverse of the steps above).
 

Conclusion


Now you may refer to your servers' private network interfaces by name, rather than by IP address. This makes configuration of services and applications easier because you no longer have to remember the private IP addresses, and the files will be easier to read and understand. Also, now you can change your configurations to point to a new servers in a single place, your primary DNS server, instead of having to edit a variety of distributed configuration files, which eases maintenance.

Once you have your internal DNS set up, and your configuration files are using private FQDNs to specify network connections, it is critical that your DNS servers are properly maintained. If they both become unavailable, your services and applications that rely on them will cease to function properly. This is why it is recommended to set up your DNS with at least one secondary server, and to maintain working backups of all of them.
Continue reading
359 Hits
0 Comments

OSPF DR and BDR Election

Participating routers in an OSPF network have varying roles to play in ensuring that the processes which route the data around the network maintain a true and accurate picture of the network topology. The two primary roles in this structure are the Designated Router (DR) and the Backup Designated Router (BDR). Their roles, whilst primarily aimed at maintaining network function from a routing perspective, are equally focused on ensuring that network bandwidth used to accomplish this is used judiciously.

An Election


Consider a multi-access environment (such as LAN or MAN), where three or more routers are connected together. If all the routers in the OSPF network had to form adjacencies with every other OSPF router present, forming a fully meshed OSPF adjacency network, the resultant conceptualised routing mesh would be overly chatty flooding Link State Advertisements (LSAs) with each and every other OSPF router. As a direct result, router CPU load and network bandwidth would be consumed wastefully. OSPF is designed to be far more efficient in its use of these resources, and, in order to prevent this from happening, OSPF holds an election process to determine and fill roles named Designated Router (DR) and a Backup Designated Router (BDR) so that the workload of propagating routing information around the network is more effectively managed. Election for the DR and BDR is determined primarily on the Router Priority (which by default is 1) and the Router ID. If the value of the router interface priority is changed to 0, it prevents that router from becoming the DR or the BDR.

Router priority can be adjusted on Cisco routers on a per interface basis. The Router ID however is a 32-bit number that uniquely identifies the router in the Autonomous System. One algorithm for Router ID assignment is to choose the largest or smallest IP address assigned to the router. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting in order to change its Router ID, the router should flush its self-originated LSAs from the routing domain or they will persist for up to MaxAge minutes. Cisco uses a method that some other vendors choose to follow, but it is not a requirement. If you have a loopback interface, since that's the most stable interface on your router, that will be used. If there is no loopback interface, the highest IP address on the router is used. If there is more than one loopback then the highest of them is used. In many elections in OSPF, the higher RID wins. this is the logic for choosing higher over lower. It should be noted however that you can manually specify an RID that isn't even a valid ip address such as 224.1.1.1.

Drothers


The DR is the router which receives LSAs and other updates when there is a change in the inter-neighbor communications. These LSAs are sent out by the DROTHERS routers (all non-DR/BDR routers), and consequently, any further updates are propagated by the DR to the rest of the DROTHERS routers. The show ip ospf neighbor command, when executed, indicates the non-DR/BDR routers as DROTHERS. Every network segment in OSPF has a DR and a BDR.

The Process


What actually happens is that whenever there is a change in network routing status, instead of flooding each and every path with LSAs advertising new information about network topology, the update is only sent to the DR. The DR then takes on this job and floods the routers in its network segment with the update. If the DR fails or is not functioning, the BDR takes over. When this happens, the BDR replaces the existing DR as the new Designated Router, and a new BDR is elected.

Continue reading
386 Hits
0 Comments