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

Comments

Good idea!

[root 66]

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

Who will impliment it?

[jasonrocks]

This idea wouldn't work because people would not implement it. It would take time to set up mirrors in a DNS and then to update them. If you are talking about FTP, some downloaders already search for and accept multiple sites. They also check for proximity of downloads.
If you are talking about websites like the slashdot effect, good luck on getting anyone to implement and maintain the table. A viable option for slashdot effect would be to mirror it in your journal. Or you could use kazaa.

Re:Interesting... but no

[schon]

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.

Re:Interesting... but no

[The Clockwork Troll]

DNS is supposed to provide nameIP mappings, in an application-neutral fashion.

Yes, and the Internet was intended to be a means for scientists and military personnel to exchange information, and HTML was intended to link cross-referenced scientific documents.

My point is, you can nitpick details about the existing protocols/DNS record types and for what they were originally intended but that doesn't mean it's the wrong type of architecture.

If you were building a system from the ground up to be a mirror directory for various well-known services it would probably end up looking a bit like DNS in its hierarchy (and probably, semantics).

That being said, I think the parent post's idea is problematic in more significant regard in that it tries to assign a standard meaning to an unstandardized record type which could only wreak chaos with DNS servers that did not support it.

I think a more "correct" approach could involve adding an additional record type to DNS that enumerated available mirrors for a host's well-known services that were listed in its WKS records. It could return results similar to an MX query (service [e.g. ftp], host name, priority) along with port and country information.

xml or text format?

[Midnight Thunder]

Since most mirror sites are usually discovered by going through the original site, then maybe if sites were to host a text or xml file at the root of the server listing the mirrors. This file would be in a universal format and could be automatically checked by browsers aware of this service. This would have the added advantage of being cachable by any proxy service.

The sort of information the file would contain would include (5 second analysis):

• name of sites being mirrored
  
• list of the mirror, which would URL, geographic location, country name
  

If the browser sees that the current server's address is not the same as the listed orginal then it knows than it is a mirror. Also, the mirror file would have the ability to list all the sites that are mirrored on the server.

This file could then be be read by a search Engine and then when it shows the site in the search results it could list the associated mirrors. The file would probably be called mirrors.txt or mirrors.xml, depending on the format used.

This is my 5c worth. If you like the idea, then consider it free for the taking :)