Essentials of DNS: understand the basics well

DNS stands for “Domain Name Service”.  It is the mechanism in which the internet is able to map a name (eg to an IP address (eg

This writeup is not designed to be 100% technically accurate.  Rather, it is designed to give a layman understanding of relevant parts of the DNS system.
Much more comprehensive information can be found here:

A bit on IP Addresses and Routing

Packets of data to move to and fro across the internet based entirely on IP Address.  At every “network meeting point” on the internet, there is a router which examines all traffic to find out where it is headed, and then sends it to the next step.  This process is repeated at each “network meeting point” until the traffic arrives at the destination.
There is a popular utility called “Trace Route”, which will demonstrate all of the routers that a packet of data must go through to get from where you are to where it is headed.  In the following example, I ran a traceroute to
Notice the first step was a DNS lookup, converting to
Tracing route to []
over a maximum of 30 hops:
  1    <1 ms    <1 ms    <1 ms   (our office router/gateway))
  2     1 ms    <1 ms    <1 ms     (our cable modem (another router/gateway)
  3    15 ms    13 ms    12 ms
  4     9 ms     9 ms    10 ms []
  5    14 ms    10 ms     9 ms []
  6    10 ms    55 ms    30 ms []
  7    12 ms    18 ms    19 ms []
  8    21 ms    63 ms    53 ms []
  9    28 ms    29 ms    27 ms []
 10    25 ms    28 ms    25 ms []
 11    43 ms    44 ms    44 ms []
 12    48 ms    52 ms    58 ms
 13    37 ms    39 ms    39 ms
 14    36 ms    43 ms    41 ms
 15    42 ms    39 ms    39 ms []
Trace complete.
In true geek fashion, after 15 hops, our packet reached  Google was derived from the word Googol, which is a number with 1 and 100 zeros.  Henceforth, stands for something to that effect.

Why does this matter?

It is important to understand that computers are binary, and therefore require input to be ultimately converted to binary.  An IPv4 address is simply 32 bits, but rather than presenting it as 11000000.10101000.00000000.00000001, humans find it more convenient to look at it like  However, that is still a far cry from a human readable name like
This is where DNS comes into play.  DNS is a system which allows people to use names, while still providing for computers to use the numbers.  Of the many benefits of DNS, it allows you to move a domain to another IP address while keeping the domain name the same. 

Common Types of DNS Records

DNS records come in several types:
A record
Points to a specific IP address.  “A” stands for “Address”.

This means that should resolve to            70755   IN      A
CNAME record
Points to another record.  “CNAME” stands for “Canonical Name Record”
This means that should resolve to and in turn resolve to        86400   IN      CNAME
MX record
Specifies a domain which will handle incoming email for the domain.
This means that mail sent to will be handled by, and if that does not work, send it to and so on.  The weight indicates which server should be tried first — the lower the weight, the better.            86400   IN      MX      40            86400   IN      MX      10            86400   IN      MX      20            86400   IN      MX      30
NS record
Delegates a DNS zone to use the given authoritative name servers.  “NS” stands for “Name Server”.
This means that DNS for is to be handled by either or            57957   IN      NS            57957   IN      NS
TXT record
Specifies arbitrary text associated with a name.  “TXT” stands for “Text”
The provides a mechanism for the DNS system to be extended with different bits of text about a domain name.  The following TXT record stores SPF information, used to specify what servers are allowed to send mail on behalf of            86400   IN      TXT     "v=spf1 ip4: ip4: ip4:  ~all"

DNS Propagation

DNS is a distributed system.  This means that there are thousands of DNS servers scattered around the globe.  Most internet providers will have their own DNS servers.  Most hosting providers will have their own DNS servers.  Etc…
How do they all stay in sync?  They do and they don’t!
Every DNS entry has a corresponding TTL value associated with it.  TTL means “time to live”.  This value, expressed in seconds, states how long a given DNS entry is valid before it must be refreshed from the “authoritative” DNS server for the given domain.  Typically, the TTL is set to 86,400 seconds, or 1 day.
With a TTL of 1 day, any changes to authoritative DNS records may take up to a full day (or more) to propagate around the internet.  This is worth keeping in mind before you engage in any important DNS changes.
The proper way to change DNS is to first, at least 48 hours prior to the transition period, change the TTL to a very low value (like 5 minutes).  It will still take at least a day for this to fully propagate to all relevant DNS servers.   However, once they are all aware that the TTL is 5 minutes, they will frequently check your authoritative server for updates every 5 minutes or each time a new request comes in for one of your DNS records, whichever is longer.
In other words, DNS servers only look up what they are asked to look up.  Then they retain it for the TTL period, and finally discard it (only to repeat if needed).
Authoritative DNS
Every domain must be registered with a registrar.  Part of this registration information for every domain, is the DNS servers to use as “authoritative dns information” for that domain.   These NS records are transmitted to the root nameserver system. 
Every top level domain (com, net, edu, org, us, gb, br, uk, au, etc…) all have their own authoritative DNS servers.  This information is kept in the world’s root name servers, which are currently:     117655  IN      A     196594  IN      AAAA    2001:503:ba3e::2:30     113829  IN      A     120655  IN      A     113757  IN      A     115554  IN      A     121256  IN      A     280321  IN      AAAA    2001:500:2f::f     113755  IN      A     116456  IN      A     206320  IN      AAAA    2001:500:1::803f:235     115856  IN      A     337685  IN      AAAA    2001:7fe::53     119155  IN      A
If you lookup the NS record for com at one of the above root servers, you will be told this:     16131   IN      A     74653   IN      A     111162  IN      A     33590   IN      A     171076  IN      A     2665    IN      A     8352    IN      AAAA    2001:503:a83e::2:30     78083   IN      A     14957   IN      A     127812  IN      A     168301  IN      AAAA    2001:503:231d::2:30     29652   IN      A     47519   IN      A     41990   IN      A     42456   IN      A
If you lookup the NS record for at one of the above “com” servers, you will be told this:            172800  IN      NS            172800  IN      NS
Finally, we have the authoritative DNS servers for  Now, if you lookup the record for at, you will be told this:        86400   IN      CNAME
Finally, if you lookup at it’s authoritative server, you will be told this:            86400   IN      A

How to force-drop a postgresql database by killing off connection processes

Ever need to drop a postgresql database, but it would not let you because there are open connections to it (from a webapp or whatever)?

Quite annoying.  If on a production server, and other databases are being used, restarting postgresql is a last resort, because it generates downtime for your site (even if small).

I finally took the time to scratch around and find the answer.

As a super user, to list all of the open connections to a given database:

select * from pg_stat_activity where datname='YourDatabase';

As a superuser, to drop all of the open connections to a given database:

select pg_terminate_backend(procpid) from pg_stat_activity where datname=’YourDatabase’;

Or for 9.x, change `procpid` to `pid`

select pg_terminate_backend(pid) from pg_stat_activity where datname='YourDatabase';

Here are some references to the functions:

Ubuntu Post-Install tips…

I received this from a friend, and thought I would post it here in case anyone would find it useful.

After Installing Ubuntu, basically I do this:

Go to:
System -> Administration -> Software Sources -> Other Sofware, and enable partner repository.

After that, we can this on a Terminal:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install ubuntu-restricted-extras
sudo /usr/share/doc/libdvdread4/

PostgreSQL Dump and Restore Notes

The pg_dump and pg_restore commands provide excellent flexibility in storing a compressed dump file, and selectively restoring any part of it.

I’ve found that dropping and re-creating the target database is the cleanest way to restore a dumpfile — no stray relations left to cause trouble.

Unless you own all of the objects being restored, you may need to be SUPERUSER in order to have a successful restore.

The custom dump format is quite useful.  Unlike the normal sequence of SQL statements you may be used to from mysqldump (and pg_dump as well), the –format=custom option will create a compressed archive file (internally a tar file) that can be selectivly read with pg_restore.  That flexibility could come in handy if you *just* need the schema from 1 table, or *just* the data from another table.

pg_dump –format=custom -U jason_super MyDatabase > MyDatabase.pgdump

pg_restore –exit-on-error –clean –dbname=MyDatabase MyDatabase.pgdump

Get all of the SQL
pg_restore TMTManage_2.pgdump | more

Get some of the SQL
pg_restore –schema=ACRM –table=Admin TMTManage_2.pgdump | more

nginx restart error

Was playing around with nginx on Centos 5 (EPEL package).

Most of the time I ran:

service nginx restart

I would get this message in the /var/log/nginx/error.log file:

panic: MUTEX_LOCK (22) [op.c:352].

After some hunting around, it appears to be a known bug in nginx (perhaps perl in nginx?)… Anyway, a simple workaround is to do this:

service nginx stop
service nginx start

Or, simply edit /etc/init.d/nginx, and add the sleep 1 line:

51 restart() {
52     configtest || return $?
53     stop
54     sleep 1
55     start
56 }

Nice workround!

Example Automated MySQL Backup Script

Rather than use --all-databases, which will prevent you from being able to selectively restore any single database, consider the following:

Ideally, you should have a daily backup, with some history. It should be bulletproof (--force), it should be logged (>> ...log), it should be compressed (| gzip), it should keep separate copies of each database, and it should automatically pick up any databases that are added.

Consider, rather, a shell script like this:


Dump="/usr/bin/mysqldump --skip-extended-insert --force"

Today=$(date "+%a")

# Get a list of all databases
Databases=$(echo "SHOW DATABASES" | $MySQL -h $Host)

for db in $Databases; do
        echo "Backing up '$db' from '$Host' on '$date' to: "
        echo "   $file"
        $Dump -h $Host $db | gzip > $file

Which is assuming that you have a file ~/.my.cnf (chmod 600), that has:

user = "BACKUP"
password = "SOMEPASS8342783492"

Make sure that whatever user you are using for BACKUP has this grant statement:

  TO BACKUP@localhost

So simply add this to a nightly cronjob, and you have a daily backup that rotates each 7 days week.

0 3 * * *   backup-mysql >> backup-mysql.log 2>> backup-mysql.log

The backup directory then contains:

-rw-r--r-- 1 backup backup 2217482184 Sep  3 13:35
-rw-rw-r-- 1 backup backup 2505876287 Dec 25 00:48
-rw-r--r-- 1 backup backup 2500384029 Dec 21 00:48
-rw-r--r-- 1 backup backup 2506849331 Dec 26 00:48
-rw-r--r-- 1 backup backup 2499859469 Dec 20 00:48
-rw-rw-r-- 1 backup backup 2505046147 Dec 24 00:48
-rw-rw-r-- 1 backup backup 2502277743 Dec 22 00:48
-rw-r--r-- 1 backup backup 2504169910 Dec 23 00:48
-rw-r--r-- 1 backup backup   76983829 Dec 25 00:49
-rw-r--r-- 1 backup backup   76983829 Dec 21 00:49
-rw-r--r-- 1 backup backup   76983829 Dec 26 00:49
-rw-r--r-- 1 backup backup   76983829 Dec 20 00:48
-rw-rw-r-- 1 backup backup   76983829 Dec 24 00:49
-rw-rw-r-- 1 backup backup   76983829 Dec 22 00:49
-rw-r--r-- 1 backup backup   76983829 Dec 23 00:49
-rw-r--r-- 1 backup backup  304803726 Dec 25 00:49
-rw-r--r-- 1 backup backup  303480087 Dec 21 00:49
-rw-r--r-- 1 backup backup  304710121 Dec 26 00:49
-rw-r--r-- 1 backup backup  303791294 Dec 20 00:49
-rw-rw-r-- 1 backup backup  305315415 Dec 24 00:49
-rw-rw-r-- 1 backup backup  302516217 Dec 22 00:49
-rw-r--r-- 1 backup backup  303314217 Dec 23 00:49
-rw-r--r-- 1 backup backup     135301 Dec 25 00:30
-rw-r--r-- 1 backup backup     135301 Dec 21 00:30
-rw-r--r-- 1 backup backup     135301 Dec 26 00:30
-rw-r--r-- 1 backup backup     135301 Dec 20 00:30
-rw-rw-r-- 1 backup backup     135301 Dec 24 00:30
-rw-rw-r-- 1 backup backup     135301 Dec 22 00:30
-rw-r--r-- 1 backup backup     135301 Dec 23 00:30

Freeky Bug

Ever have one of those bugs that customers complain about, but you just cannot reproduce it? Here is a good one…

Customers were complaining about being logged out when clicking a download link.

This particular setup is a Cisco CSS 11501 series load balancer with 2 Dell Poweredge web servers sitting behind it.  Each webserver is running apache, as well as an application server (python) which handles authentication and processing for THAT server.

For weeks, I could not reproduce this bug.  So tonight when I finally got bit by it (at home), I was clueless for a while.  The code is so simple.  A simple key lookup in a simple dictionary, yet it just was not making sense.

Here is the story:

A while ago, we were having problems with Internet Explorer downloading content over SSL.  This turns out to be a common problem with IE, so to fix it, I caused the downloads to not use SSL, which is more efficient anyway.

We use a cisco hardware load balancer which balances incoming requests to different backend servers.  It has a feature called STICKY SOURCE IP, which means that any connections routed from the same IP to the same site will be delivered to the same backend server.  This is nice, because you are always visiting the same server.

So as it turns out, by turning the download SSL off, the load balancer was using another “site” definition to handle the DOWNLOAD request.  STICKY SOURCE IP was out the window, and the request was being passed back to a “random” webserver.

About 50% of the time, users (like me tonight) were tossed to the other server, which knew nothing about the user login. That is why it was complaining about the “WB4_App::$DSEG and/or WB4_App::$AuthToken must be set in order to contact the     applications server.” error message, which is not one that should normally be shown.

To make matters worse, our IP address at work was apparently always using the same server, so I could not reproduce the problem.  I’m lucky that it happened to me at home, or I would still be banging my head against the desk…