Blog post: Submitting trackers to newTrackon

[josecelano]

Blog post: Submitting trackers to newTrackon

Summary

A blog post explaining how to submit BitTorrent trackers to newTrackon, a popular third-party tracker uptime monitoring service. The post covers the prerequisites, the "one tracker per IP" constraint, how we solved it for the Torrust demo environment using floating IPs and BEP34-compliant DNS configuration, and a troubleshooting section based on real issues we encountered.

---

Outline

Introduction

• What is newTrackon and why use it?
• Why a third-party uptime monitor is valuable: independent, trustworthy uptime data.

Prerequisites (from the newTrackon FAQ)

1. Tracker must not already be in the list (checked by URL and IP).
2. Tracker must be working at submission time.
3. Tracker must not deny connections per BEP34.
4. Tracker must resolve to globally routable IP addresses (no private/loopback IPs).
5. Announce interval must be between 5 minutes (300 s) and 3 hours (10800 s).

Constraint: One tracker per URL and IP

newTrackon rejects any tracker whose IP is already registered — even if the URL or domain is different.

Example of what does NOT work:

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

If both are hosted on the same server with the same IP, only the first submission will be accepted.

Why this matters for Torrust:

• The Torrust Tracker can run multiple tracker protocols (UDP + HTTP) from a single process and config file.
• In the demo environment we run both protocols and want to monitor uptime of each independently.
• Hosting both on the same IP means newTrackon treats them as duplicates.

Solution: Floating IPs

Use separate IPs for each tracker endpoint, even if they run on the same physical server.

For the new Torrust tracker demo:

Endpoint	Domain	IP
HTTP/S tracker	http1.torrust-tracker-demo.com	116.202.176.169
UDP tracker	udp1.torrust-tracker-demo.com	116.202.177.184

Both domains point to different Hetzner floating IPs, but route to the same server and the same Torrust Tracker process. Similar mechanisms exist with other providers (static IPs, reserved IPs, etc.).

BEP34: DNS-based tracker policy

BEP34 defines a DNS TXT record convention that declares which ports (and protocols) a host is running trackers on. newTrackon checks this and will reject trackers that deny connections according to this BEP.

Torrust demo DNS TXT records:

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

Submitting to newTrackon

Step-by-step walkthrough of the submission process on https://newtrackon.com/.

Troubleshooting: Tracker Shows as Down

Real issues we encountered after listing our trackers:

• IPv6 routing with Docker and floating IPs — Docker wiping ip6tables rules on restart; Docker bridge network being IPv4-only; SNAT/DNAT configuration required for correct reply routing.
• Using newtrackon.com/raw — how to read the raw probe output to identify error strings (UDP timeout, HTTP connection failed, etc.).
• Running a local copy of newTrackon — for deeper inspection without waiting for the probe rotation.
• Using the Torrust Tracker console client — console/tracker-client for sending announce/scrape requests directly to the tracker.

---

References

• https://newtrackon.com/faq
• https://newtrackon.com/submitted
• https://www.bittorrent.org/beps/bep_0034.html
• https://github.com/CorralPeltzer/newTrackon
• https://github.com/torrust/torrust-tracker/tree/develop/console/tracker-client
• fix: UDP tracker down on newTrackon after nightly restart torrust-tracker-demo#2
• fix: enable IPv6 on Docker proxy_network for native IPv6 UDP support torrust-tracker-demo#4