Submitting Trackers to newTrackon

Introduction

When you run a public BitTorrent tracker, you want people to be able to trust its reliability. One of the best ways to demonstrate that trust is to list your tracker on newTrackon, a popular third-party service that continuously monitors the uptime of public trackers and publishes the results.

For the Torrust project we run demo trackers to showcase the software. We wanted to list them on newTrackon so anyone can verify the uptime independently — without having to take our word for it. Getting there required understanding a few prerequisites and solving a specific constraint, which is what this post is about.

What is newTrackon?

newTrackon is a community-driven service that maintains a curated list of working public BitTorrent trackers. It periodically probes each tracker and calculates an uptime percentage based on the last 1000 attempts. Tracker lists from newTrackon are widely used by torrent clients and torrent creators to populate the announce URLs in .torrent files.

Because it is an independent third party, its uptime data is more credible than anything a tracker operator could self-report. If your tracker is listed there and shows high uptime, that is a meaningful signal to the BitTorrent community.

Prerequisites

Before you can submit a tracker, newTrackon checks several conditions. These are documented in the newTrackon FAQ:

1. Not already listed by URL or IP. newTrackon checks both the tracker URL and the IP address it resolves to. If either is already in the list, the submission is rejected as a duplicate.
2. Tracker must be working at submission time. newTrackon performs a live probe when you submit. If the tracker does not respond correctly, it will not be added.
3. Must not deny connections per BEP34. newTrackon respects the DNS-based tracker policy described in BEP34. If your DNS TXT record indicates the tracker is not available on the submitted port and protocol, the submission will be rejected.
4. Must resolve to a globally routable IP. Private addresses (e.g. 192.168.x.x, 10.x.x.x), loopback (127.0.0.1), and other non-routable addresses are rejected.
5. Announce interval must be between 5 minutes and 3 hours. newTrackon checks the interval value returned in the tracker's announce response. If it is shorter than 5 minutes (300 seconds) or longer than 3 hours (10800 seconds), the tracker is rejected. This requirement is described on the submitted trackers page. In Torrust Tracker, set the interval in your config:

[core.announce_policy]
interval = 300
interval_min = 300

Points 2, 4, and 5 are straightforward. Points 1 and 3 require a bit more planning, which is what the rest of this post covers.

Constraint: One Tracker per IP

The first prerequisite has an important implication that is easy to miss: newTrackon deduplicates by IP address, not just by URL.

This is exactly what happened with our old demo tracker. Both the UDP and HTTP endpoints share the same domain and the same IP (144.126.245.19):

udp://tracker.torrust-demo.com:6969/announce
https://tracker.torrust-demo.com:7070/announce

Even though the URLs are different (different protocol, different port), both resolve to the same IP address. Only the first submission was accepted by newTrackon; the second was rejected as a duplicate IP. The HTTP tracker at https://tracker.torrust-demo.com:7070/announce is therefore not listed — not because it is broken, but because newTrackon already has that IP registered from the UDP tracker.

Why This Matters for Torrust

The Torrust Tracker supports running multiple tracker protocols — UDP and HTTP/S — from a single process using a single configuration file. This is very convenient operationally, but it means both protocols run on the same server and therefore share the same IP address.

In our demo environment we run both a UDP and an HTTP/S tracker because we want to demonstrate both protocols and monitor the uptime of each independently on newTrackon. With a single IP, that is not possible.

Solution: Floating IPs

The solution is to assign a separate IP address to each tracker endpoint you want to list, even if they all run on the same physical server.

For our new Torrust tracker demo we use Hetzner Floating IPs: additional IP addresses that can be attached to a server and routed independently. The Torrust Tracker process listens on both IPs, but from newTrackon's perspective each tracker has its own unique IP.

The two domains resolve to two different floating IPs, so newTrackon treats them as independent trackers. DNS verification:

$ dig http1.torrust-tracker-demo.com
http1.torrust-tracker-demo.com.  IN  A  116.202.176.169

$ dig udp1.torrust-tracker-demo.com
udp1.torrust-tracker-demo.com.   IN  A  116.202.177.184

BEP34: DNS-Based Tracker Policy

BEP34 (DNS Tracker Preferences) defines a convention for declaring, via a DNS TXT record, which ports and protocols a host is running trackers on. BitTorrent clients and services like newTrackon can read this record to validate tracker URLs or discover the correct ports.

newTrackon checks this record and will reject a tracker if the BEP34 TXT record explicitly excludes the submitted protocol or port.

TXT Record Syntax

The TXT record lives on the tracker's hostname and starts with the keyword BITTORRENT, followed by one or more protocol/port declarations:

• "BITTORRENT" — the host runs no trackers (deny all).
• "BITTORRENT DENY ALL" — same as above, more readable.
• "BITTORRENT UDP:6969" — UDP tracker on port 6969.
• "BITTORRENT TCP:443" — HTTP/S tracker on port 443.
• "BITTORRENT UDP:6969 TCP:443" — both, UDP preferred.

Trackers are listed in order of preference, with the preferred protocol first. Unknown words are silently ignored for forward compatibility.

Our DNS Configuration

We configured TXT records on each tracker domain to match the protocols and ports each one handles:

$ dig TXT http1.torrust-tracker-demo.com
→ "BITTORRENT TCP:443"

$ dig TXT udp1.torrust-tracker-demo.com
→ "BITTORRENT UDP:6969"

$ dig TXT tracker.torrust-demo.com
→ "BITTORRENT UDP:6969 TCP:443"

http1.torrust-tracker-demo.com declares only TCP:443 because it is an HTTP/S-only endpoint. udp1.torrust-tracker-demo.com declares only UDP:6969. The older tracker.torrust-demo.com domain runs both protocols and declares both.

Submitting to newTrackon

Once your tracker is running, has a globally routable IP, and has the correct BEP34 TXT record, submission is straightforward:

1. Go to https://newtrackon.com/ and open the Add section.
2. Paste your full announce URL (e.g. https://http1.torrust-tracker-demo.com:443/announce).
3. Submit the form.
4. newTrackon performs a live probe. If all checks pass, the tracker is added to the list within a few minutes.
5. Repeat for each tracker URL you want to list (e.g. your UDP endpoint separately).

Troubleshooting: Tracker Shows as Down

Even after a successful submission you may find your tracker showing as down on newTrackon. Here is the first case we encountered and how we resolved it.

IPv6 Routing with Floating IPs and Docker

Shortly after we listed udp://udp1.torrust-tracker-demo.com:6969/announce, the tracker appeared as ❌ down on newTrackon — even though manual UDP announces from external clients worked fine (see issue #2 and the fix PR #4).

The key difference from the old demo is that the new demo is dual-stack: the server has both IPv4 and IPv6 addresses. The old demo was IPv4-only. When we tested the tracker from our development machines, everything worked — but our dev machines have IPv4 public addresses. newTrackon, however, resolved udp1.torrust-tracker-demo.com to the floating IPv6 address (2a01:4f8:1c0c:828e::1) and sent its probe over IPv6. That probe got no response.

Two root causes were found:

Root Cause A: Docker wiping ip6tables rules on restart

By default, Docker sets ip6tables: false. This means Docker does not manage its own ip6tables chains. However, every time Docker restarts a container it rewrites its iptables/ip6tables chains — and in doing so it can flush the live rules that ufw had applied to allow IPv6 UDP port 6969 through to the container. After a nightly restart, IPv6 UDP packets were silently dropped even though ufw still showed the rule as active.

Fix: add /etc/docker/daemon.json with {"ip6tables": true}. Docker then manages ip6tables rules itself for all published ports, mirroring its IPv4 behaviour and surviving container restarts.

Root Cause B: Docker bridge network was IPv4-only

The Docker bridge network had no IPv6 subnet, so containers had no IPv6 address. When an IPv6 packet arrived at the floating IP, Docker's proxy tried to relay it to the container's IPv4 address — a cross-address-family relay that silently drops UDP packets.

Even after giving the container an IPv6 address, there was a second problem: when the container replied, Docker's MASQUERADE rule rewrote the source address to the server's primary IPv6 (2a01:4f8:1c19:620b::1) rather than the floating IPv6 (2a01:4f8:1c0c:828e::1) that the client connected to. From the client's point of view the reply came from an unexpected address and looked like a timeout.

The packet flow after the fix looks like this:

Client → floating IPv6 2a01:4f8:1c0c:828e::1:6969
       → ip6tables DNAT → container fd01:db8:1::3:6969
       → container replies
       → ip6tables SNAT → source rewritten to 2a01:4f8:1c0c:828e::1
       → client receives reply from the correct address ✅

Two config changes were required:

1. Enable IPv6 on the Docker network (enable_ipv6: true + a ULA subnet in docker-compose.yml). Docker then creates proper ip6tables DNAT rules so packets reach the container natively.
2. Add a SNAT rule in /etc/ufw/before6.rules to rewrite the source address of replies back to the floating IPv6, so the client always receives the response from the address it originally connected to.

Using the Raw Output to Debug

newTrackon exposes a public page at newtrackon.com/raw that lists the latest connection attempt results for every tracked tracker. It is updated in near-real-time as the monitoring system probes each tracker in rotation.

After submitting your tracker, open this page and keep refreshing — your tracker's announce URL will appear once newTrackon has completed its first probe. The table columns you care about are:

• Result — either Working or Down.
• Response / Error — the raw response dictionary for a working tracker, or a short error string for a failing one.

Common error strings you may encounter:

• UDP timeout — the probe sent a UDP connect request but received no reply. This is what we saw when the IPv6 routing was misconfigured (see above).
• UDP connection failed — the connection was actively refused.
• HTTP timeout / HTTP connection failed — equivalent issues for HTTP/S trackers.
• Can't resolve IP — DNS lookup failed for the tracker's hostname.

Running a Local Copy of newTrackon

For deeper inspection, you can run your own instance of newTrackon from its source code. The project is open source and available at github.com/CorralPeltzer/newTrackon.

When running locally, the probe output is printed directly to the console — similar to what the public /raw endpoint exposes, but without needing to wait for your tracker's turn in the full rotation. You can also modify the source code to add extra logging or change behavior if you need to dig deeper into a problem.

Using the Torrust Tracker Client

The Torrust project includes a console tracker client inside the main tracker repository at console/tracker-client. It lets you send announce and scrape requests directly to a tracker from the command line, making it easy to verify that your tracker responds correctly to the same kind of requests that newTrackon sends.

Because you have access to the full Rust source code, you can also instrument the client to print additional protocol-level details that would not normally be visible, which can help narrow down subtle routing or response issues.

Conclusion

Getting a tracker listed on newTrackon requires satisfying a handful of prerequisites. The one that catches most operators by surprise is the per-IP deduplication rule: if you want multiple tracker endpoints listed independently (e.g. UDP and HTTP/S), each must have its own unique IP address.

For the Torrust demo we solved this with Hetzner floating IPs — one per protocol endpoint — along with BEP34-compliant DNS TXT records on each domain. The result is two independently monitored tracker entries on newTrackon, providing trustworthy public uptime data for both the UDP and HTTP/S endpoints.

If you are running a Torrust Tracker instance and want to list it, the same approach applies: assign a unique IP per endpoint, configure the BEP34 TXT records, and submit each announce URL separately.