Questions concerning future slave DNS zones
I've seen the DNS manager, and the fact that you offer this service free to existing customers makes me incredibly happy with my choice in Linode. I'd like to thank you for your work ahead of time, in short :).
I do, however, have a few questions.
1) For primary zones, only certain types of records can be created. This is to be expected, as it's a tad bit unrealistic to expect you to support all the different types of RRs out there, especially when 99% of your users will only be using A, MX, NS, and maybe TXT records. SRV records are probably less often seen than TXT records.
However, I will only be using the DNS service as a slave zone. Will the slave zones support every RR available to you in BIND? I would fit into that 1% of people: I use SSHFP, RP, multiple SRV records, and may be adding more types of RRs in the furture. If these records were truncated, well, the slave zone feature would suddenly not be as useful to me.
2a) Will the slave zones support NOTIFY? I've been known to update my zones several times a minute - usually when I'm debugging SPF records, but still. It's not a common thing that I do, but having my DNS servers being consistent while debugging is invaluable.
2b) If NOTIFY will not be enabled, at what interval will the slave zones be transfered? Will the Linode NSs transfer them at the interval specified in the SOA record, or at an internal value?
3) I don't want to start a holy war of BIND vs. djbdns, but what are the chances of allowing the slave zones to authenticate with the standard HMAC-MD5 keys? For example, in my named.conf of my (current) slave server, I have:
> key linode-key {
algorithm hmac-md5;
secret "KeyGoesHere-ThisIsQuiteClearlyNotMyActualKey$==";
};
server 64.22.124.36 {
keys { linode-key; };
};
On the server side, I have an identical config, only with the slave IP specified. In the /var/log/messages of the slave, whenever I update the zone, I see:
> Sep 20 22:14:34 router named[5001]: client 64.22.124.36#37572: received notify for zone 'averageurl.com': TSIG 'linode-key'
Sep 20 22:14:35 router named[5001]: zone averageurl.com/IN: transferred serial 33: TSIG 'linode-key'
The only advantage to using TSIG keys over regular IP-based transfer ACLs? Authenticity. Which is important to me. I'd classify this as work which you would typically not need to do, as it'll only be used with maybe 1% of your customers, but I'm just asking :).
4) Is there any ETA on slave zones? If you'd like testing of this feature, I'd gladly volunteer my zones to the cause.
(edit:)
5) Will there be any limit to the number of zones (be it primary or slave) we can host? I've got 3, soon to be 4 zones hosted on my linode, and while they are small, that's also more than I'd expect is average.
(/edit)
–A happy customer, even if he can't use slave zone transfers with TSIG when all is said and done.
2 Replies
caker
Linode Staff
I'm digging into the slave support stuff now..
1) All record types will be supported. It'll just be an AXFR of your entire zone. The DNS manager won't display the records, just the zone name and the list of master, so supporting the more uncommon RR types in the UI won't be necessary.
2 & 2a) Notify support will be enabled, from the masters only. I don't think I'm going to override the defaults for intervals here. Still reading up..
3) Slim. I'll get the slave stuff done first and then have a look at the key mojo
4) Within the next few days of this posting
5) No limits, within reason
-Chris
@caker:
Hey – thanks for your comments.
I'm digging into the slave support stuff now..
1) All record types will be supported. It'll just be an AXFR of your entire zone. The DNS manager won't display the records, just the zone name and the list of master, so supporting the more uncommon RR types in the UI won't be necessary.
That's what I thought. Good to hear. :)
@caker:
3) Slim. I'll get the slave stuff done first and then have a look at the key mojo
It's actually simpler than I make it out. ns1.linode.com is running bind 9.3.4, which is good to go.
They key associations are broad: they are not zone specific, they are IP specific. Likewise, they'd also be very easy to add, I realized. When (if?) you specify the IP address to AXFR the zone from, you'd simply provide a TSIG key along with that. The obvious problem comes with multiple people on one linode - but even then, a key that allows just transfer can be setup among the people on that host, and the plugged into the linode control panel. It's literally that easy as my provided config example. Just keep in mind that it's there to authenticate IPs and not zones.
@caker:
4) Within the next few days of this posting
I need to check the forums more often :)
@caker:
5) No limits, within reason
That's what I was expecting. Perfect.
Thanks!