pantz.org banner
DNS SRV records now!
Posted on 05-05-2008 21:55:17 UTC | Updated on 05-14-2008 02:56:56 UTC
Section: /software/bind/ | Permanent Link

When I started my first real sysadmin job back in 1999 I had the simple job of setting up a backup web server. It was going to live in our data center and the primary was going to live at the main office. After setting up the backup web server I thought about how I was going to have it fail over in case the primary died. Thinking about it for a while I thought about how it's done with NS and MX records. MX for e-mail and NS for the DNS servers themselves. Both work by providing a list of servers that can be contacted for that particular service. Not knowing a ton about DNS my reasoning went that there must be one for http. Reading the O'Reilly DNS and BIND book I found out that this was not the case. There was no equivalent www (for example) record in DNS for HTTP like there was for e-mail. You just had to setup an A record and that was that.

Upon reading further into the DNS and BIND book I found out about DNS SRV records. After reading about the SRV record type it sounded exactly like what I needed. It was a cheap and simple way to have multiple servers running a service and failing over when one server was down. Like I said above there are only 2 records that can provide fail over if one of those services goes down. For any other service your running you have to have some other software doing the checking of the server to see if it's down or up. If one if the servers in the list goes down then the software you setup can take the machine out of the pool of servers you have. This can be done with a front end proxy (like pound, Apache, or hoststated on OpenBSD) for web servers. The thing is setting up front end watchers and traffic balancers is a bit complicated and a pain. If you just want simple a setup and don't really have the money to setup anything else SRV records would be the way to go. Let me explain a little more about what SRV records are and why they are so useful.

The SRV resource record was introduced in RFC 2052 (superseeded by RFC 2782). The RFC describes it best so I'll just quote it "The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups". What does this mean? It means we can take any service like http or ftp and spread them across as many servers as you want. Then you can designate which server takes priority over others, distribute load, and provide backup services if a service fails.

An example of what an SRV record structure looks like is the in the following example:


#  Service.Proto.Name    Class SRV Priority Weight Port Target

_http._tcp.www.pantz.org.  IN  SRV  0         2     80  www.pantz.org.
                           IN  SRV  0         1     80  www2.pantz.org.
                           IN  SRV  1         1    8080 www3.pantz.org.

In the record above requests for the website www.pantz.org will go to port 80 on www.pantz.org and www2.pantz.org. The host www.pantz.org will get twice the queries that www2.pantz.org gets. If both hosts go down, the queries will go to www3.pantz.org on port 8080. For a better detailed explanation of SRV records see RFC 2782.

How fantastically simple is that! All in a DNS record. This is a record almost all DNS servers support right now. You can put in a record for any service you want to run (FTP,IMAP,POP,etc) and you get all that great stuff. So what's the problem? The problem is (as I found out back in 1999 when first learning about SRV records) almost no one uses them. Can you f'ing believe that!

For SRV records to be useful the client software (web browser,ftp client, etc) has to be able to read the record from DNS and use the information the DNS server gives it. All client software queries DNS for A records. Why the hell can't it ask for an SRV record also? All it would take is a little code on the client side to parse the SRV info and little logic to figure out which server to contact.

Almost 10 years from when I first read about SRV records to now and most people still don't use SRV records. No web browser supports it. Mozilla has had a bug filed to get one since 1999. How sad is that? Someone has written a patch but they don't know what to do with it. No email client uses them either. How great would that be for backup POP or IMAP servers? With SRV records you could almost get rid of the MX record. The only things that use SRV records now are SIP,LDAP,XMPP,KERBEROS, and a few others. That is not much.

So why don't people want to use them? I my opinion we have a catch-22 going on here. DNS admins won't put in the records because the clients won't use them. The clients won't write the code to use the SRV records because the DNS admins won't put in records. Someone has to step up here.

Some will try to argue that this is one more query to the DNS server and it will take more time to do the lookup. I'm here to tell you the the small amount of time it takes to do this look up is outweighed by the advantages these records provide. I would rather endure waiting a little longer (we are talking low 100's of milliseconds here) for a web page to load because it had to look up the SRV records than for the website not to load because the person running the site did not have any easy way of setting up a fail over server. Just like what happened to me in my first sys admin job back in 1999. Because I found out that no one was using SRV records I had to setup the backup server and just changed the A record by hand when the machine went down. So inefficient.

SRV records also provide a way to run a service on an alternate port. This would be a godsend for people who try to run services on their home machines. Many ISP's block popular incoming ports but leave open many others. So an ISP that blocks port 80 in (I'm looking at you Verizon FIOS) could easily be worked around with SRV records. Just specify an alternate port in your SRV record like in the example above and your done. Same goes for any service that they block in. If we started using SRV records instead of MX records for mail then we could run SMTP on any port we wanted. It's all spelled out in the record.

I have to practice what I preach so I put in SRV records for the web and mail servers for pantz.org. If you want to see what an SRV record looks like you can check for the entry using the host program found on most UNIX systems. I'll use my domains as an example.

host -t SRV _smtp._tcp.pantz.org
host -t SRV _http._tcp.www.pantz.org

The first command above will show the 2 mail servers that service pantz.org. The primary and the backup. The priority levels are set to reflect this. The second command shows just the one web server for now. These entries took only a few minutes to setup. They really are an easy way to get some very basic fail over and balancing for your servers. Now, if we can just get some clients than would use these SRV records the internet would be a much better place.

Reddit!

Related stories

Setup of BIND 9 name server on OpenBSD
Posted on 01-02-2007 23:13:00 UTC | Updated on 01-02-2007 23:13:00 UTC
Section: /software/bind/ | Permanent Link

This setup was done on OpenBSD 4.1. BIND is installed on OpenBSD 4.1 by default. The files shown below have the paths mentioned at the top. The named dir (/var/named/) has dir's in it that have the config files. Make sure all files and directories are owned by root:named. Check the /var/log/messages for errors on startup. If you dont have any localy resolvable hostnames just take out the last few lines in named.conf.

To start the server use the command argument "-4" for ipv4 only in /etc/rc.local file. The named server should start on boot.

The config below is very simple and has only one domain (domain.lan). It uses the ip block 192.168.0. It uses comcast's name servers for forwarding queries it can't answer. Run only on your internal interface. Change the ip addresses to the internal ip addresses you want to use.

The first file below is /var/named/etc/named.conf. This is the main Bind config file.


options {
        allow-query { 127.0.0.1; 192.168.0/24; };
        allow-recursion { 127.0.0.1; 192.168.0/24; };
        forwarders { 68.87.73.242; 68.87.71.226; };
        listen-on { 192.168.0.1; };
        listen-on-v6 { none; };
        version "gateway dns server";
};

controls { };

logging {
        category lame-servers { null; };
};

zone "." {
        type hint;
        file "standard/root.hint";
};

zone "localhost" {
        type master;
        file "standard/localhost";
        allow-transfer { localhost; };
};

zone "127.in-addr.arpa" {
        type master;
        file "standard/loopback";
        allow-transfer { localhost; };
};

zone "com" {
        type delegation-only;
};

zone "net" {
        type delegation-only;
};

zone "org" {
        type delegation-only;
};

zone "domain.lan" {
        type master;
        file "master/db.domain.lan";
        allow-update { none; };
};

zone "0.168.192.in-addr.arpa" {
        type master;
        file "master/db.0.168.192";
        allow-update { none; };
};

The next file below is the /var/named/standard/root.hint file. This file has the root dns servers in it.

;       $OpenBSD: root.hint,v 1.2 2004/01/30 18:59:41 jakob Exp $
;
;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
;
;       last update:    Jan 29, 2004
;       related version of root zone:   2004012900
;
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
;
; formerly C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; formerly NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;
; formerly NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;
; operated by VeriSign, Inc.
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
;
; operated by RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
;
; operated by ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
;
; operated by WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
; End of File

The next file below is the localhost zone file /var/named/standard/localhost.

; $OpenBSD: db.localhost,v 1.2 2005/02/07 06:08:10 david Exp $

$ORIGIN localhost.
$TTL 6h

@       IN      SOA     localhost. root.localhost. (
                        1       ; serial
                        1h      ; refresh
                        30m     ; retry
                        7d      ; expiration
                        1h )    ; minimum

                NS      localhost.
                A       127.0.0.1
                AAAA    ::1

The next file below is the file for our only zone the domain.lan zone. The path for it is /var/named/master/db.domain.lan.

domain.lan.     86400   IN SOA  gateway.domain.lan. root.gateway.domain.lan. ( 1 10800 3600 6044800 86400 )
                86400   IN NS   gateway.domain.lan.

gateway.domain.lan. 	86400   IN   A    192.168.0.1
machine1.domain.lan.   	86400   IN   A    192.168.0.2
machine2.domain.lan.  	86400   IN   A    192.168.0.3
dhcp4.domain.lan.   	86400   IN   A    192.168.0.4
dhcp5.domain.lan.   	86400   IN   A    192.168.0.5
dhcp6.domain.lan.   	86400   IN   A    192.168.0.6

The next file below is the file for the in-addr.arpa domain. Inverse (reverse) dns records. The path for it is /var/named/master/db.0.168.192.

0.168.192.in-addr.arpa. 86400   IN SOA  gateway.domain.lan. root.gateway.domain.lan. ( 1 10800 3600 6044800 86400 )
                86400   IN NS   gateway.domain.lan.

1.0.168.192.in-addr.arpa.   86400   IN   PTR   gateway.domain.sys.
2.0.168.192.in-addr.arpa.   86400   IN   PTR   machine1.domain.sys.
3.0.168.192.in-addr.arpa.   86400   IN   PTR   machine2.domain.sys.
4.0.168.192.in-addr.arpa.   86400   IN   PTR   dhcp4.domain.sys.
5.0.168.192.in-addr.arpa.   86400   IN   PTR   dhcp5.domain.sys.
6.0.168.192.in-addr.arpa.   86400   IN   PTR   dhcp6.domain.sys.

Reboot after all your files are in place and configured. Bind should start on boot.

Notes: "rndc reload" will force a zone transfer in bind9.

Reddit!

Related stories


RSS Feed RSS feed logo

About


3com

3ware

alsa

alsactl

alsamixer

amd

android

apache

areca

arm

ati

auditd

awk

badblocks

bash

bind

bios

bonnie

cable

carp

cat5

cdrom

cellphone

centos

chart

chrome

chromebook

cifs

cisco

cloudera

comcast

commands

comodo

compiz-fusion

corsair

cpufreq

cpufrequtils

cpuspeed

cron

crontab

crossover

cu

cups

cvs

database

dbus

dd

dd_rescue

ddclient

debian

decimal

dhclient

dhcp

diagnostic

diskexplorer

disks

dkim

dns

dos

dovecot

drac

dsniff

dvdauthor

e-mail

echo

editor

emerald

encryption

ethernet

expect

ext3

ext4

fat32

fedora

fetchmail

fiber

filesystems

firefox

firewall

flac

flexlm

floppy

flowtools

fonts

format

freebsd

ftp

gdm

gmail

gnome

google

gpg

greasemonkey

greylisting

growisofs

grub

hacking

hadoop

harddrive

hba

hex

hfsc

html

html5

http

https

hulu

idl

ie

ilo

intel

ios

iperf

ipmi

iptables

ipv6

irix

javascript

kde

kernel

kickstart

kmail

kprinter

krecord

kubuntu

kvm

lame

ldap

linux

logfile

lp

lpq

lpr

maradns

matlab

memory

mencoder

mhdd

mkinitrd

mkisofs

moinmoin

motherboard

mouse

movemail

mplayer

multitail

mutt

myodbc

mysql

mythtv

nagios

nameserver

netflix

netflow

nginx

nic

ntfs

ntp

nvidia

odbc

openbsd

openntpd

openoffice

openssh

openssl

openvpn

opteron

parted

partimage

patch

perl

pf

pfflowd

pfsync

photorec

php

pop3

pop3s

ports

postfix

power

procmail

proftpd

proxy

pulseaudio

putty

pxe

python

qemu

r-studio

raid

recovery

redhat

router

rpc

rsync

ruby

saltstack

samba

schedule

screen

scsi

seagate

seatools

sed

sendmail

sgi

shell

siw

smtp

snort

solaris

soundcard

sox

spam

spamd

spf

spotify

sql

sqlite

squid

srs

ssh

ssh.com

ssl

su

subnet

subversion

sudo

sun

supermicro

switches

symbols

syslinux

syslog

systemd

systemrescuecd

t1

tcpip

tcpwrappers

telnet

terminal

testdisk

tftp

thttpd

thunderbird

timezone

ting

tls

tools

tr

trac

tuning

tunnel

ubuntu

unbound

vi

vpn

wget

wiki

windows

windowsxp

wireless

wpa_supplicant

x

xauth

xfree86

xfs

xinearama

xmms

youtube

zdump

zeromq

zic

zlib