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

6 of 32 comments (clear)

  1. Re:Already done, of a sort by drudd · · Score: 2, Informative

    I do the same with my webservers (only two) to balance the load, but it's not really a complete solution...

    It provides reasonable load balancing, but isn't fault tolerant (i.e. a server goes down, requests aren't redirected).

    Works well enough for me though...

    Doug

    --
    Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
  2. Re:Interesting... but no by glitchvern · · Score: 3, Informative
    DNS is supposed to provide nameIP mappings, in an application-neutral fashion.

    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.
  3. Go for it! (but don't use TXT) by Ashurbanipal · · Score: 4, Informative

    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.

  4. Akamai by sql*kitten · · Score: 2, Informative

    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.

    Akamai already do something like this, and they didn't need to extend the DNS protocol in any way. They even provide the mirrors for you, if you use their service, and take care of ensuring that users get redirected to the nearest mirror. Sure beats having to scroll through a long list like you have to on sites that mirror the old-fashioned way, particularly since a site physically close to you might actually have less bandwidth than a faraway one.

  5. Re:How about ENRP? by torpor · · Score: 2, Informative

    TXT is intended for such things as this. I seem to recall it was originally proposed for 'additional information about the domain'.

    Seems more than appropriate for mirror information to me ...

    --
    ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
  6. Re:Interesting... but no by schon · · Score: 2, Informative

    I think it's interesting that you didn't comment at all on any of my real arguments against this, and instead just chose one line to bitch about.

    I said that DNS isn't the proper way to do this, and here's why - and you completely ignored all of the "why"..

    Then what are these mx records being used to relay mail.

    They're used to find the MX for a domain. - To find an IP address, just like I said.

    That's not exactly application neutral.

    Yes, it is. MX records don't include information on where the mail aliases to, or where to find the administrator for a domain (for example). It's used to provide a record for a Domain. (You know, the "D" in DNS.)

    You can place any random text you want to in a dns record

    Just because you can do something, that all of a sudden makes it a good idea to do it?

    By that logic, I bet you can jump off a cliff.

    Here is a list of other record types from nslookup(1)

    What's your point? In every case, the records provide information about the domain, or about a host in that domain. In no case do they provide information about pathnames, mirrors, the name and address of the administrator of the domain, or anything that's handled by an application-specific protocol.