@IntuititveNipple:

It's better to have your own DNS server as SOA for your zones and set the Linode DNS servers as slaves,

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.

@SteveG:

@IntuititveNipple:

It's better to have your own DNS server as SOA for your zones and set the Linode DNS servers as slaves,
Why?
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.

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.

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.

@redboy:

Where did you get the IPs 69.93.127.10 and 65.19.178.10?
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.

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?

@tonycpsu:

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.

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.

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.

@tonycpsu:

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.

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.

@tonycpsu:

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…

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

@SteveG:

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.

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.

@SteveG:

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

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.

'Tasaro' responded to the support ticket: > This is in our queue - we're not sure on an ETA at this time.

IntuitiveNipple:

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

@SteveG:

BIND in particular is a big beast, easy to break, and running it to support 3 entries seems like overkill to me.

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 ===

ipv4bindaddresses = "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"

zonetransferacl = "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.

I configured my host as described above:

• maradns on my vps, configured more or less as above,

• linode configured (in DNS manager) as slave for my domain

• two linode nameservers (plus some other secondary DNS my colleague serves for me) configured as servers for my domain

Everything seems to be working properly

The system seems to work pretty well. I recently moved everything over to ns{1,2,3,4}.linode.com, with my Linode as the master.

I've noticed a few quirks:

-ns{3,4} seem to take a few minutes to pick up changes sometimes.

-Subdomains don't work. I assume this is to prevent a malicious user from setting up www.mydomain.com on top of mydomain.com as a DNS poisoning attack.

I haven't seen any major issues, and it's one of my favorite features of Linode. Just getting name servers for the domain is trivial with most registrars, if you're looking to host at Linode at all you probably need more. Unfortunately a good DNS setup isn't something a single VPS can host by itself. Getting an infrastructure to do that is a great addition.
@SteveG:

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 security impact isn't that large, it's mostly an image thing to be honest. Whether or not the practice is important, it's preferable to be seen to follow it.

Someone jogged my memory about this post and I thought I'd update the bind acl list - I now have four Linode servers in /etc/bind/named.conf:

acl slaves {
        69.93.127.10;
        65.19.178.10;
        75.127.96.10;
        207.192.70.10;
        };

@ArbitraryConstant:

-Subdomains don't work. I assume this is to prevent a malicious user from setting up www.mydomain.com on top of mydomain.com as a DNS poisoning attack.
Delegated sub-domains should work the same as any other. On the master server delegate the sub-domain in the domain zone file, create the zone-file for the sub-domain, and add the sub-domain to Linode DNS Manager.

@IntuititveNipple:

Someone jogged my memory about this post and I thought I'd update the bind acl list - I now have four Linode servers in /etc/bind/named.conf:

acl slaves {
        69.93.127.10;
        65.19.178.10;
        75.127.96.10;
        207.192.70.10;
        };

Are you sure that's right? I have a couple of domains slaved to the Linode servers, but only the first two servers respond when I query them - the last two return ESERVFAIL.

EDIT: Oh wait, sorry, my bad - got confused with the nameservers. Yes, I have to add these to the Bind config before ns3 and ns4 will work… :oops: