| BEP: | XX |
|---|---|
| Title: | DNS Tracker Lookup with FQDNs |
| Version: | |
| Last-Modified: | |
| Author: | Sam Whited <[email protected]> |
| Status: | Draft |
| Type: | Standards Track |
| Created: | 27-December-2012 |
| Post-History: |
Sometimes when users create torrents they mistakingly add hosts to the trackers list that point to other services such as websites. Alternatively, the location of a tracker changes and the old port is repurposed for something else. This results in those hosts getting flooded with unwanted traffic, or the torrent failing because there are no longer any valid trackers.
To prevent these scenarios, the Fully Qualified Domain Name of one or more trackers can be looked up using the Domain Name System (DNS). The prefered process for doing so is to use DNS SRV [1] records.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119 [2].
If a torrent contains a tracker target that cannot be contacted, or contains a URL that does not specify a protocol or port, the client SHOULD attempt to resolve the trackers FQDN using DNS SRV records.
The process is as follows:
- The client queries for DNS SRV records using the domain provided in the torrent, the desired transport protocol (udp or tcp), and the service name "bittorrent-tracker".
- If a response is received containing a single resource record with a target of "." then the client MUST abort processing of trackers at this domain.
- If a response is received that contains one or more combinations of a port and FQDN then the client uses the priorities and weights as described in RFC 2782 to choose at least one of the FQDNs on which to perform an "A" or "AAAA" lookup.
- The IPv4 or IPv6 address along with the corresponding port from the SRV lookup, is used by the client as the address for the tracker.
- If the "A" or "AAAA" lookup returned multiple IP addresses and the first is not reachable, the next is tried.
- If the client fails to connect to any of the IP addresses for a given FQDN, then it repeats the process from step 3 with the next FQDN returned by the SRV lookup.
- If the client receives a response to its SRV query but is not able to establish a connection to any trackers using the data received in the response, it SHOULD NOT attempt to resolve trackers for the given domain using any fallback process.
- If the client does not receive a response to its SRV query it SHOULD attempt the fallback process described in the next section.
If a fallback is required as defined above in "SRV Lookup" alternative lookup methods should be used such as that described in BEP 34.
Without using origin authentication technologies such as DNSSEC, this method of finding trackers could potentially allow a malicious party to prevent trackers from operating by injecting entries into DNS records. It is RECOMMENDED that torrent clients implementing this BEP suport DNSSEC.
It is also possible for an SRV record to redirect the client to a tracker outside of the current domain. While this isn't a problem for most users, it could be an issue for clients who only want to connect to specific trusted trackers. To mitigate this risk, torrent clients implementing this BEP SHOULD provide a security setting to alert the user when the SRV lookup returns a tracker on a different domain than the one queried.
Other security considerations not directly related to Bittorrent are described in RFC 2782.
Example SRV Query:
_bittorrent-tracker._udp.example.net _bittorrent-tracker._tcp.example.net
This will search for all UDP or TCP trackers running at "example.net" which might return a result like the following:
Tracker SRV Records:
_bittorrent-tracker._udp SRV 0 0 6881 tracker.example.net. _bittorrent-tracker._udp SRV 0 5 6881 tracker2.example.net. _bittorrent-tracker._tcp SRV 0 0 0 .
Assuming these records are present at example.net (which is listed in a torrents metadata) a client should use UDP tracker tracker.example.net:6881 with UDP tracker tracker2.example.net:6882 as a backup. They can also see that there are no TCP trackers running on example.net.
| [1] | RFC-2782. (https://www.ietf.org/rfc/rfc2782.txt) |
| [2] | RFC-2119. (https://www.ietf.org/rfc/rfc2119.txt) |
This document has been placed in the public domain.