[auton-users] Changes to Auton Lab DNS

[Michael J. Baysek]

Hi Lab,


We have long had a problem which I will refer to as "DNS duality" where 
if accessed interally, *.autonlab.org addresses resolve to different IP 
addresses than they would if accessed externally.  This is a carryover 
from the legacy infrastructure from days of yore.  This DNS duality 
creates a number of problems for standardizing configurations.


What follows is a description and brief rational for some changes that 
are underway regarding DNS.  You may or may not care to read it, but I 
prefer to broadcast information instead of secretly making changes and 
causing problems that seem to have no explanation.  I admit that this 
changeover may cause some issues, though I will do my best to minimize 
them.  This is the first in a series of changes that are going to make 
things less trouble-prone in the future.


The nature of the change revolves around the fact that we have two (even 
three) networks we can access our central servers from, the internal 192 
network, CMU's network, and the world.  Depending on which mode of 
access, a machine could be using either the internal Auton DNS servers, 
or honest authoritative Internet DNS servers.


When the central servers talk to each other, they are doing so over a 
private (192.168) network.  When DNS queries were made for 
*.autonlab.org hosts, the internal DNS servers dished up the internal 
192.168.x.x. address of the server in question.  These addresses do not 
match the "real" or external public IP addresses that Internet DNS 
servers return for these hosts.  In effect, DNS duality.


To make matters more convoluted, On VPN connected workstations, 
depending on how the domain servers and search paths were set, some 
machines were getting the internal addresses when they queried for 
*.autonlab.org hosts, and some were getting the public 128.2 addresses.  
Traffic going to the 192 addresses are transferred over the VPN, 
incurring overhead for the encryption of the VPN connection, and adding 
load to the primary firewall machine in our server rack.


Depending on whether a machine was using internal DNS or external DNS 
also affected which hostnames would even resolve.  Also, requests coming 
from inside (192) vs. outside IP addresses are treated differently by 
the firewall, webservers, etc, sometimes leading one group of users to 
not be able to access a resource when they should.


To solve this (and other problems related to DNS duality of the 
autonlab.org DNS), I am introducing the int.autonlab.org domain.  When 
machines are supposed to access internal IP's by default, they will be 
configured with the int.autonlab.org search suffix.  The search suffix 
is what allows you to say "ssh lop1" instead of "ssh lop1.auton. etc.) 


Fixing the DNS duality is one step in fixing "once and for all" some 
nagging issues that has caused lots of wasted sysadmin time over the years.


Your comments appreciated,


Mike