It's better to have your own DNS server as SOA for your zones and set the Linode DNS servers as slaves, so that whenever you make a change to a zone file (and increment the serial # field of the SOA) the slave servers automatically get notified and fetch the updated zone.

1. configure an ACL at the top of your /etc/bind/named.conf

acl slaves {
        69.93.127.10;
        65.19.178.10;
};

2. For each zone that you want to use Linode as slaves, add to /etc/bind/named.conf:

        notify yes;
        allow-transfer {
                slaves;
        };

so, a complete zone entry will look like this:

zone "intuitivenipple.net" {
        type master;
        file "/etc/bind/intuitivenipple.net.hosts";
        notify yes;
        allow-transfer {
                slaves;
        };
};

3. Add the domain-name as a Slave to Linode DNS manager, and put your DNS server's IP address in the Masters field.

4. Make sure your firewall allows inbound/outbound TCP on port 53, possibly restricted to those Linode DNS server IP addresses in the ACL.

5. In each zone file ensure the Linode servers are listed as NS, so, in addition to your own DNS server's NS entry, add:

@               IN      NS      dns1.intuitivenipple.net.
@               IN      NS      dns2.intuitivenipple.net.
dns1            IN      A       69.93.127.10
dns2            IN      A       65.19.178.10

obviously, change the names to match your domain, or else use the linode.com names and don't use A records:

@               IN      NS     ns1.linode.com.
@               IN      NS     ns2.linode.com.

6. At the registry for the domain, add the 2 slave servers to the list of NS servers

_________________
TJ.
IntuitiveNipple
The only intuitive interface is the nipple; everything else is learned.

Why?

I run my own mail server, because there are policy issues that I really don't want anyone else making decisions about. OTOH, DNS either works or it doesn't, and unless you are managing a large zone, or have some pretty special requirements, I really don't see the value of running your own DNS server. BIND in particular is a big beast, easy to break, and running it to support 3 entries seems like overkill to me.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.
-- seen on the net

Especially when using automated management tools such as Webmin, VirtualMin, UserMin, Plesk, CPanel etc., this configuration ensures that any changes to the DNS zones are automatically reflected in all the DNS servers and that domain DNS is resilient to temporary interruptions.

If the server is being used to host more than a trivial number of personal domains, and especially if the operator offers hosting to others, it keeps management of the domains simple and ensures things don't get out of step.

_________________
TJ.
IntuitiveNipple

The only intuitive interface is the nipple; everything else is learned.

Ah, I think I misread your original post. I thought you were asserting a general statement that running one's own DNS server was "better". Instead, I think you were asserting that if you need to run your own DNS server, setting up automatic updates of the secondaries via the slaves system is a Good Thing, which I'd agree with completely.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.

-- seen on the net

Where did you get the IPs 69.93.127.10 and 65.19.178.10? When I was poking around trying to use Linode as a secondary DNS service, I got a host starting 68. that had a PTR to webhost.linode.com, but there was no corresponding A record. I've tried all 3, but when I query the servers looking for my slave records, I get NXDOMAIN.

They are the IP addresses of ns1.linode.com and ns2.linode.com. If you want to have the hostnames of the nameservers use the same domain-name as your domain then you need the A records as I showed (dns1 and dns2).

If you're okay with your domain reporting the NS records as the linode hostnames then just use the second example I gave.

_________________
TJ.
IntuitiveNipple

The only intuitive interface is the nipple; everything else is learned.

Great tip, IntuititveNipple. I just got this going and it seems to be working well so far. Thanks for posting it!

The one thing I did notice that bothers me a bit is that anyone is allowed to do a zone transfer of any zone from the linode.com DNS servers. I found this thread in which this was brought up a while back, but it still looks like an issue. If any admins are reading, is this something you guys are still planning on fixing in the future?

So? It's public information. That's why it's in the DNS. If you don't want people to find your hosts, don't put them in the system.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.

-- seen on the net

Of course it's public information, but just because you allow people inside an art museum doesn't mean you should furnish them with building plans showing all of the entrances.

Attackers go for the easiest targets. Having a lax policy toward zone transfers is a sign of lax security, even if it's a reasonably small amount of actual exposure.

Not to mention, think of all the wasted bandwidth and CPU resources on the DNS servers as they fulfill transfer requests for no good reason...

It's not the biggest deal in the world, but I'd definitely put it on the list of things to fix in the future if I was running things.

Because, of course, it's impossible for the attacker to find them otherwise. If releasing the building plan affects your museum security, then your security is flawed.



That *is* a good reason to disallow zone transfers, but that's caker's problem (and choice).

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.

-- seen on the net

Again, my points were (1) there's no need to make it *easy* for them, and (2) a seemingly innocuous oversight like this is a sign that there may be bigger vulnerabilities elsewhere. But, whatever, you disagree.



I wasn't aware it was a conscious choice rather than an oversight, or maybe something that might have fallen to the bottom of the stack. Just throwin' it out there...

Best practice for non-authoritative DNS servers (such as the Linode servers) is that they should not allow unrestricted zone transfers.

Amongst varied reasons is that the zone file when seen in total can give clues as to the domain's organisation and structure, possibly making it easier for an attacker to deduce and exploit 'psuedo-private' servers or services.

See also Sans Institute "Why is securing DNS zone transfer necessary ?"

I've opened a support ticket and will report back on what Chris thinks.

_________________
TJ.
IntuitiveNipple

The only intuitive interface is the nipple; everything else is learned.

'Tasaro' responded to the support ticket:

_________________
TJ.
IntuitiveNipple

The only intuitive interface is the nipple; everything else is learned.

IntuitiveNipple:

Thanks for the response, I appreciate it. As long as they know about the problem, I'm happy.

maradns is tiny and does the same

I am yet to configure it on linode, but I used maradns for years on some 96MB RAM VPS. It takes a few kB of RAM and here is my whole configuration:

=== /etc/maradns/mararc ===

ipv4_bind_addresses = "1.2.3.4,127.0.0.1"
# replace 1.2.3.4 with machine IP

chroot_dir = "/etc/maradns"
csv2 = {}
csv2["my.domain.name."] = "db.my.domain.name"
# replace my.domain.name with true domain name

# Allow hosts below to transfer
recursive_acl = "11.12.13.14,21.22.23.24"
zone_transfer_acl = "11.12.13.14,21.22.23.24"

hide_disclaimer = "YES"

# Suit to "id maradns"
maradns_uid=108
maradns_gid=114

=== /etc/maradns/db.my.domain.name ====

my.domain.name. 1.2.3.4
www.my.domain.name. 1.2.3.4
mail.my.domain.name. 1.2.3.4
my.domain.name. MX 10 mail.my.domain.name.