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

Don't mess with DNS

[Anonymous Coward]

I don't think it is a bad idea but I think we must start making "prime directives" ala RoboCop. ....
Prime Directives
1. Get DSL/Cable Modem
2. Install Linux/BSD/OpenSource OS.
3. Do not mess with DNS

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.

What can we do next?

[Limburgher]

Also coming soon:

Freenet over DHCP;

Gnutella over BOOTP;

And last, but not least, KaZaa over WINS!!! :)

Re:Idiot

[dtdns]

If you read the article and know anything about DNS, you can see that he is splitting the file into 126 byte segments and storing the parts in TXT records of individual hosts. The host naming scheme is quite clever, I might add.

The goal is to offload the duty of serving up the files from the download servers to an existing distributed network. He even mentions that the DNS servers caching these records would consume massive amounts of memory, and then (like a spammer) blows it off as "its [memory] not that expensive today anyway."

If this is actually implemented on a wide scale, DNS administrators will simply stop caching TXT records, putting the load right back on the original download server where it belongs. Or worse, they may stop caching records altogether, which could only lead us all down the path of chaos, death and destruction.

I agree that it's clever, but like a deadly virus, not something that should leave the lab on a large scale.

Re:Idiot

[hattmoward]

He's just talking about the .torrent file, which points to a torrent tracker, not the torrent data itself; and DNS works over TCP also.

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.

What's the Problem?

[Abjifyicious]

If people start using this extensively, and the DNS servers start getting clogged up by this, we'll just have to come up with a way to send DNS information over BitTorrent! That way, everything will balance out, right?

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.

Re:We have the technology!

[Anonymous Coward]

They are not talking about transfering data directly through the DNS channels. They are talking about using the DNS system to replace the tracker server. In reality they are both doing basically the same thing -- they are both mearly creating an abstration that points to the actual electronic address where are resource is located.

While I am not really to hot about tracking through BIND I do think that the two protocols can learn from each other. What makes DNS so great is that it is a distributed system which balances the load more or less evenly among connected nodes but the system is useless in dealing with dynamic IP, NAT, intermittent connections, etc. that effect most work stations at the fringe of the Internet. This is were P2P technologies like bittorent are starting to excel. Taken together these technologies could create a new hybridized standard that will once again allow workstations to be a presence on the Internet by creating a new Universal Resource Locator (URL) that will transend the barriors of DHCP, NAT, etc. and reinforce the advantage of distributed hierchies to peer to peer.

-1, Wrong

[Wesley Felter]

The tracker does not allocate bandwidth, it just introduces peers to each other.

Re:Not THAT small.

[Zocalo]

Actually, DNS is designed to handle considerably more than just the few bytes of data that would typically be required for an A or PTR record. One reason for DNS supporting TCP was to enable queries of more than 64kB, which are quite often seen on zone transfers, and should be able to cope with the majority of .torrent files.

Plus, I don't see how this is going to put the huge strain on the DNS infrastructure that is implied, apart from the server hosting the torrent's TXT record anyway. Assuming no cached DNS information, I need to perform exactly the same number of DNS queries to resolve foo.domain.com to get a TXT record as I do get pull a tracker file from it. Judging by some of the posts here already some seem to think that the root DNS servers are going to have to handle terabytes of movies files or something, and that just isn't that case.

Re:Not THAT small.

[CowboyMeal]

Not only that, but DNS was designed to handle a lot of tiny requests, and a few huge requests. For the many many tiny requests, it uses UDP, and doesnt have to go through the overhead of a full-blown TCP connection. This is what makes it so scalable. If it has to send back more than 512 bytes (for a zone transfer or torrent file), it sets up a TCP connection, but in the case of a zone transfer, it doesnt have to do this very often.

For a typical name query, only two UDP segments are involved, one for the request and one for the response. If you were to request a torrent file, you would need the first three TCP handshaking segments, one to send the request, and then 1 or 2( depending on the machine setup) to send back the torrent file.

Normal DNS query: 2 segments
Torrent file DNS query: 5 or 6 segments

So that takes 2.5-3 times more processing time per request on the DNS server, and that doesnt even take into account the TCP session state.

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.