Anycast DNS - Part 2, Using Static Routes

This second article in our series "Anycast DNS" is a recipe for deploying Anycast DNS using static routes. In this article we'll show our recipe for configuring Anycast using static routes, and provide an explanation as to why this is the least optimal way of building an Anycast DNS environment.

Recipe - Single Anycast IP Address

The goal of this recipe is to configure Anycast DNS on two (2) Linux caching only DNS servers. While this solution can accommodate additional servers, we'll only deal with two servers in our scenario. Our fictitious company, ABC Corporation, uses RIPv2 as its IGP routing routing protocol. NOTE: for this solution there is no requirement for any host-based routing software.


The figure above shows two name servers, Server A & B, deployed on two different subnets and respectively. Both servers are shown configured with a virtual loopback interface of Each of these systems has an upstream router that will be responsible for originating a static route to the Anycast DNS address of The upstream router's job is not only to originate the route, but to redistribute it into the IGP cloud.

Read more ...

Anycast DNS - Part 1, Overview

This is the first article in series on the topic of deploying Anycast DNS. The purpose of this series of articles is to share some ideas, recipes, and information on how to deploy Anycast in your environment.  The first thing we need to do is explain what Anycast is.  Anycast is the use of routing and addressing policies to affect the most efficient path between a single source and several geographically dispersed targets that "listen" to a service within a receiver group.  In Anycast, the same IP address space is used to address each of the listening targets (DNS servers in our case).  Layer 3 routing dynamically handles the calculation and transmission of packets from our source (DNS Client) to its most appropriate (DNS Server) target. 

The diagram below shows an example of Anycast DNS.  A single DNS client workstation, configured with the Anycast DNS IP address of, is shown performing DNS resolution against its "closest" of three DNS name servers deployed using the same Anycast IP address.


Read more ...

Issues with Multi-Master DNS Servers in VitalQIP

multi-master-dnsThis article is a continuation of our discussion on Multi-master DNS Servers in VitalQIP, and highlights some of the problems, issues, and concerns with Multi-master DNS using VitalQIP.

Issue #1 - Dynamic DNS

A BIND DNS server does not use the same replication mechanism for Dynamic DNS (DDNS) updates as a Microsoft Active Directory-integrated DNS servers do. We could write an entire article on DDNS, but that is outside the scope of this article.

There are mainly two different strategies for implementing Dynamic DNS updates when using VitalQIP:

  • qip-dnsupdated - allow the VitalQIP product to propagate DDNS Updates to all authoritative servers (master(s) and slaves)
  • notify - allow the VitalQIP product to propagate DDNS Updates to a single authoritative master and rely on BIND DNS Notify and ixfr from the master to its slaves

    Read more ...

Multi-master DNS Servers in VitalQIP

multi-master-dnsThe purpose of this article is to demonstrate how multi-master DNS is configured and supported in VitalQIP 7.x for static DNS environments. A multi-master DNS configuration using BIND DNS software is defined as having two different name servers configured as master for the same zone.  In this article we configure two name servers and to be master name servers for a static zone called Our zone has dynamic DNS updates disabled and is statically managed.  Essentially, our two name servers become identical peer name servers or do they?!

Read more ...

IPAM Product Approaches

There are three basic IPAM product approaches that have been taken by the industry leaders, the Software Model, Appliance Model, and the Hybrid Model.  Each model has it's strengths and weaknesses, and different costs.  Netlinx can help you choose which model best suits your environment by taking into account compliance policies, staffing models, cost considerations, support infrastructure, and technical standards.

Read more ...

Get $Id$ keywords working in Subclipse

Subversion and Subclipse keywords are not enabled by default.  To get $Id$ to be automatically picked up, you must make a change to the Subclipse configuration file.  On Vista / Windows Server 2008, edit the file <drive>:\Users\<user>\Application Data\Subversion\config.  NOTE: with UAC enabled, you will need to open your command prompt with the "Run As Administrator" option to provide the requisite permissions.

  1. uncomment the line that contains 'enable-auto-props' and make sure it is set to 'yes'
  2. add file types and keyword support in the section [auto-props]

For example:

enable-auto-props = yes
*.pl = svn:eol-style=native;svn:keywords=Id Author Date Revision
*.php = svn:eol-style=native;svn:keywords=Id Author Date Revision
*.txt = svn:eol-style=native;svn:keywords=Id Author Date Revision
*.ini = svn:eol-style=native;svn:keywords=Id Author Date Revision

On UNIX, this can be done by editing the file ~/.subversion/config and making the same edits.