Slashdot Mirror
Mirror Listings Though TXT DNS Records?
mackman asks: "I was wondering if anyone has ever though about using their DNS servers to provide mirror information? A specially formated TXT-record could easily provide a DNS-cache-friendly mirror listing. A TXT-record would just need a list of servers and paths, or perhaps a more complicated mapping for servers which only mirror a subset of the original site. This would allow for much more flexibility than a basic round-robin A-record scheme. For example, instead of pounding the Red Hat web server to get a mirror listing (or relying on Slashdot posts for that matter), why not do a 'dig -t txt mirrors.redhat.com'? Of course we could build this into download managers like wget."
This is a very nice idea.
But for more usability the record should include the location (country and continent) of each mirror, so your favourite download manager can try the nearest mirrors first.
Another question is how quick such lists would be replicated/cached by your ISP's DNS server...
-- I love the smell of Blue Screens in the morning.
Instead of shoehorning in functionality into a free-form field (or so I assume, by its name), why not use something more appropriate? Why not write an I-D about how DNS should include "MIRROR" records? I'll leave it to the mailing lists to debate whether DNS should know so much about a name, and the specifics of what exactly is meant by "mirror" (what content, what protocols, etc.).
The IETF has some great things cooking. RSerPool, e.g. -- though it's not designed primarily for load-distribution (rather uptime, AFAIK). Perhaps I'm suggesting you use a hammer to crack a nut, but this might abate the need for posting mirrors, like you said.
Open Source is such a beautiful thing. It's unfortunate that so much of its energy is spent writing competing implementations of various similar protocols. But I digress.
http://www.ietf.org/rfc/rfc2052.txt Doesn't do everything, but it definately accomplishes more advanced mirroring & balancing anyways. Combined with a little virtual-hosting on the mirror's side, all that's really missing is partial mirrors, as far as I can see.
"You know, Hobbes, some days even my lucky rocketship underpants don't help" -- Calvin
I really don't think that kind of functionality belongs in a DNS
Exactly.
DNS is supposed to provide nameIP mappings, in an application-neutral fashion.
By trying to make it provide "mirror" information, you're moving into the realm of the application - which doesn't really map properly to the concept of IP address.
The question (of course) is "mirror for what?"
HTTP content? Why only HTTP? FTP sites are commonly mirrored as well. How do you distinguish between the two? If you do a lookup for the example provided - "mirrors.redhat.com" - which service is mirrored, the HTTP, or the FTP? How do you know if they have different content? How do you know if they have the same content? And what happens if you have multiple HTTP servers on the same machine? (Say, one running on port 80, and one running on port 8080.)
Which one gets mirrored? Since you can't do a DNS lookup for "www.redhat.com:8080", this makes it impossible to provide a mirror for anything that doesn't use the WK port.
Then what are these mx records being used to relay mail. That's not exactly application neutral. You can place any random text you want to in a dns record. If you do a host -a you will occasionally come across people who have thrown completely random shit into their dns record. The A record is what is used to resolve a hostname to an ip address. Here is a list of other record types from nslookup(1):
A the host's Internet address.
CNAME the canonical name for an alias.
HINFO the host CPU and operating system type.
MX the mail exchanger.
NS the name server for the named zone.
SOA the domain's ``start-of-authority'' information.
TXT the text information.
WKS the supported well-known services.
Other types (ANY, AXFR, MB, MD, MF, NULL) are described in the RFC-1035 document.
I seem to recall something about jabber using a dns record similar to mx. A quick google search comes up with this page that claims both ldap and jabber use srv records and that jabber formerly used the mx record.
So yeah, dns, more than just ip addresses and hostnames.
DNS is designed to be an extensible, flexible, distributed, and massively scaleable lookup database. It is quite suited to what you propose, and has certainly been used for much lamer ideas already.
I wouldn't use TXT records, though. SRV records might be more appropriate, but people are apparently using SRV for LDAP nowadays so you're probably better off just defining a new type. Use the procedure laid out in the RFCs for designating a new type of "experimental" DNS record, so that everyone will be compatible with you (well, everyone that follows the RFCs, anyway, which might leave out MS and DJB) or figure out how to use one of the obsolete record types.
You can look at some of the other types of records in RFCs 1035, 1183, 1706, 1886, 2672, 2782, and 2874. Most of the important ones (well, other than IPv6 stuff) are in RFC1035.
Incidentally, you're going to get dozens (if not hundreds) of posts here that will say "You shouldn't do that with DNS!". Pretty much any question you ask around here that even mentions DNS will get the same result, so just ignore them. I think these people are a lot more interested in shooting down ideas than in actually testing them, which is the only real way to find out if they will work.