No ticket, no passport, just an address!  

Statistics
General
  Users: 16271
Stargates
  Connections: 0
  Total: 430
  Milkyway: 167
  Pegasus: 92
  Forerunner: 81
  Tollan: 90
Teleporters
  Total: 3
Miscellaneous
  AFVIs: 7
 

News

     
Avatar Ash Qin

April Updates

Posted by Ash Qin on 12 May 2025, 5:15:26 pm

Table of Contents

Stargates Standards of Placement

We're excited to announce the Stargate Standards of Placement (SSoP) updates, reflecting community feedback and our commitment to improving the user experience. The revised SSoP guidelines incorporate changes to make Stargate navigation smoother and more inclusive. These updates are not set in stone. We welcome ongoing feedback to refine the rules further and address any concerns or suggestions.

The checklist was updated to include the Stargate for entry and exit without requiring IDC/GDO systems.

We've also introduced a new section on Access Control Systems ℹ️ to address challenges with random dialling. To prevent negative experiences, stargates using IDC/GDO systems that require user authorisation will no longer be allowed to appear on the random dial list. Operators are welcome to re-enable random dialling after disabling access controls, and we strongly encourage IDC/GDO server developers to use the in-world API to automate this process. To ensure fairness, a radio hint must be provided for puzzle-based gates requiring access.

DNS Woes

We recently had some issues with Stargates going offline, and we didn't have sufficient information to explain why. Eventually, we figured out it was caused by a DNS issue. We use DNS to validate connections from Amazon's data centre as part of many checks to verify that the connection is authentic from Second Life.

DNS stands for Domain Name System, often likened to the Internet's "phone book". Instead of remembering numeric IP addresses (for example, 54.200.222.248), users type friendly names such as alpha-fox.com. DNS translates these names into the corresponding IP addresses so your computer knows where to send requests.

  • Forward DNS lookup: You start with a hostname (like ec2-54-200-150-143.us-west-2.compute.amazonaws.com) and ask DNS, "What IP address goes with this name?"
  • Reverse DNS lookup: You start with an IP address (for example, 54.200.222.248) and ask DNS, "Which hostname corresponds to this IP?"

We perform a reverse and forward DNS lookup on every connection we receive. The results for forward and reverse lookups are cached independently on our server, so we don't hammer external DNS servers for every request.

When we receive a message from a Stargate, the simulator sends a connection through a pool of forwarding proxies. For example, we might receive a connection from 54.200.222.248. We perform a reverse lookup to confirm that the IP maps to an AWS hostname in the expected region (does it end with .us-west-2.compute.amazonaws.com?). The problem with reverse lookups is that they can be spoofed to any hostname, so to properly ensure this isn't spoofed, we perform a forward lookup to ensure that the hostname resolves back to the same IP.

Previously, when that lookup failed, meaning the IP address didn't match any known hostname, we weren't recording those failures anywhere. That gap in our failure logging meant that during a brief outage earlier this month, we had no record of why those connections were rejected. We've now implemented proper error logging for reverse DNS failures, so if the lookup fails again, we'll immediately see an entry in our logs and be able to diagnose and resolve the issue better.

Authentic Object Validation

This is unrelated to DNS. Our backend performs rigorous checks to ensure that every incoming request hitting the application server for the Stargates really comes from a Second Life simulator; we have added more validations this month. We are not aware of this being abused previously.

Notifications

In Alpha-Fox, we have started aggressively using Discord webhooks. A Discord webhook is a simple yet powerful tool that allows external applications or services to send messages directly into a specific Discord channel. It acts as a one-way communication bridge, enabling automated notifications, updates, or alerts from various sources to be posted in Discord without manual effort.

We originally sent our Discord alerts using a "blocking" approach ℹ️, which meant that as soon as we triggered a notification via a Discord webhook, our system would pause and wait until Discord confirmed receipt before carrying on. That pause could hold up the code immediately afterwards. We've now switched to a "non-blocking" (asynchronous) method to send notifications to Discord. At the same time, our system keeps running without waiting for the webhook to finish.

HSTS Extended

Last month, we mentioned the implementation of the HTTP Strict Transport Security (HSTS) ℹ️ header to ensure that your web browser always connects to our site using a secure connection, known as HTTPS.

We've been running a month-long trial of the HTTP Strict Transport Security (HSTS) header. After confirming that it works flawlessly, we've extended its duration. Previously, the header only instructed browsers to enforce HTTPS for five minutes; now, it does so for 30 days. In practice, once you visit our site, your browser will automatically use the secure HTTPS connection for the next month, helping to keep your data safe from any accidental unencrypted requests.

Directory-Listing Defence

We carried out some routine maintenance on our servers. During that process, we noticed that a particular path on the site (the specific URLs or "addresses" you type after our domain) could accidentally trigger a directory listing (where the server shows you every file in a folder). Exposing those listings when unintended can reveal sensitive or irrelevant files. We've now tightened the configuration by disabling directory listings.

Legacy API script SQL Injection

Discord Providers Updates

To improve signal‑to‑noise in our community server, we have migrated status and provider announcements from the general chat into a dedicated provider-updates channel. This separation helps users subscribe more selectively to updates and reduces the risk of missing essential messages in busy conversations.

Final Thoughts

The SSoP has been revised based on community feedback to improve the ASN's usability. Security has been strengthened with improved DNS failure logging to address previous outages, extended HSTS for secure connections over 30 days, and a fixed SQL injection vulnerability in the Legacy API. Communication improvements include optimised, non-blocking Discord webhook notifications and a dedicated provider-updates channel for clearer announcements.

You may have noticed we've had fewer updates over the past month, and we want to be upfront about why. The reality is that Alpha-Fox, as much as we love it, isn't something that pays the bills. Some of us on the team have been caught up in work and other demands, pulling our focus away from this project. We expect this reduced pace to continue through the summer as life's priorities take the front seat.

This is the nature of passion projects; they often have to fit around the edges of our day-to-day responsibilities. We're still deeply committed to Alpha-Fox and will keep pushing it forward. We're incredibly grateful to all of you for sticking with us through this journey. Your support means the world, and we hope you'll stay with us as we progress. Thanks for being patient and cheering us on!

--Ash Qin

Permalink

     

Navigation
 
Login

Username:

Password:

Remember Me?

Register an Account

Reset your Password