Caching Torrent files in DNS

bodin writes "This is a proof of concept version of BitTorrent where the torrent files are transported over DNS. This will of course bog down BIND servers all over the planet. Everyone should be thankful that the files are not sent over DNS."

Comments

This was bound to happen

[color of static]

Some of us have been using DNS to get through some really draconian firewalls for ages. It was just a matter of time before we saw someone distribute files this way. What is unique is that they will be cached. This in and of itself is an amazing idea. DNS is well designed to cache for well defined amounts of time.

The load on large DNS servers can grow quickly. I wouldn't be surprised if we see a set of patches coming out for DNS servers to combat this. the question is can we find a TTL that reduces the abuse and still makes it useful.

Standing up for fun/useless hacks!

[iamdrscience]

There are already a number of posts on Slashdot talking about how this is a really bad idea. I disagree (with a big but). It would almost certainly be a Bad Idea (TM) if this were enacted and people tried to make it the main way of distributing torrents. However, I don't think the idea was meant to do that, I think it was more just to show that it could be done. It's akin to people who get put on the mainpage of Slashdot for hacking their Apple IIe's so that they have ethernet and then writing a simple graphical operating system for them so they can browse the web. Impractical and largely useless? Probably. Interesting and fun hack? Definitely.

Missing the point are we?

[pomac]

If someone adds TXT records to their dnses and in turn to their dns slaves it's their buissnies, how the hell will this affect all dnses available in the world? You generally ask the "owner dns" but yes, if you ask your "ips's dns" or someone elses dns then they might cache the result.

But how bad is that really? How large is a .torrent file? And wouldn't linux distrobutiors enjoy this?

$large_isp has several users who wants to download $linux_dist. The first user gets the TXT record and is off downloading. And the rest of em uses the cached record (if it is cached) in either case $linux_dist's webserver dosn't suffer as hard and they can always add more slave dnses to handle the load. Perhaps users even starts slave servers for that zone to help the dist.

(Is there really a rule that says "you have to cache and store TXT for $TTL time".)

And whats this with spelling? I mean you totally miss the point and... complain about spelling? is that the end of the world? =) /me is also a typical Swedish geek =)

We have the technology!

[DrZaius]

DNS is a resource locating service. For example, SRV records are a nicer way of autoconfiging your network.

With SRV records, you say service.domain = port at host. You could do a dig for ldap.slashdot.org and findout that the ldap server is on port 389 at directory.slashdot.org.

This is a slight extension of this. I don't know the exact implementation, but you could have a zone file that looks like:

'file being served'.bt.slashdot.org SRV 0 0 PORT 'seed host'

You can have multiple SRV's per resource and load balance between them.

DNS is currently used for stuff like this all over the place. We already have the technology. IXFR means we can transfer just the changes in the zones when there are updates.

Last time I checked, DNS is not over loaded and will scale to handle this. Even it 50% of the internet uses BT over DNS, 100% of the internet uses DNS for email, web and so forth. Every time an email is delivered, there are at least 6-10 DNS queries.

DNS will not be bogged down.

I don't think it's such a bad idea.

[0x0d0a]

I don't see what the issue is, exactly. DNS data is propagated lazily. The only issues is that you'd have maybe three machines storing the data instead of one.

Unless .torrent files are particularly big -- I happened to have one on my hard drive, which was under 512 bytes.

I'm not sure that there's much point in using DNS to propagate .torrent files -- it seems that USENET or similar would be a better choice, given that they tend to only be useful for a short period of time, that announcements of new torrents is a useful characteristic of a .torrent propagation system, and that archiving torrents is useful -- but I also don't really see the harm in this.

Given the kind of load that nameservers happily handle today when you hit a webpage with a number of entries (especially for those annoying little "badges") (and the nameserver potentially gets twenty or more lookup requests all at once), there can't be a huge processing hit.

There *might* be a storage hit...but suppose there are 10,000 torrent files out there, and each is 1K. That's just 10MB of data, and I doubt anyone is interested in storing all available torrents.

Finally, I suppose that bandwidth might be an issue, but I suspect that given the frequency of DNS lookups and the infrequency of someone needing a new .torrent file, the bandwidth will not be an issue.

I have done plenty of fun things with DNS and run a small DNS server, but I will freely admit that I am not a DNS wizard, and leave it to the folks on NANOG to debate the merits of this.

For my money, though, this is cute and not harmful at all, though it might not be particularly useful.