I’ve organized my thoughts a bit and want to share with everyone the latest updates on the platform, the technical challenges encountered, and the future operational plans.
First, a brief introduction: this platform is built on @james’s open-source project and aims to provide free domain names and DDNS services. Since the launch, thanks to everyone’s support, I’ve been working hard to keep the service stable and open.
Below are my recent progress and explorations:
- PowerDNS Maintenance:
To ensure reliable and low-latency resolution services, I’ve built a multi-node, high-availability PowerDNS setup.
Master Node: Handles core database write and management.
Slave Nodes: Deployed domestic nodes and high-protection nodes to achieve fast response and disaster recovery, both globally and across China.
Node Layout Significance:
Domestic Nodes: Optimized for users in mainland China, greatly reducing resolution latency and improving access speed.
High-Protection Nodes: Defend against DDoS attacks, ensuring the service remains stable and online even under malicious traffic, and guaranteeing normal users’ resolution requests.
Root Domain @ CNAME Attempt: ALIAS
Some folks are using cf pages or GitHub Pages to deploy and host their projects, but have hit a key pain point: root domains (@ or so-called bare domains) cannot use CNAME records, as DNS standards (RFC 1034 / RFC 1035) explicitly prohibit this. So I tried the following (which didn’t fully succeed, but wasn’t a complete failure either…)
Enabled ALIAS records in PowerDNS—a mechanism similar to CNAME, aimed at allowing users to set a CNAME directly on the root domain. However, reality bites. Testing showed that most external providers do not recognize this mechanism. To them, the “CNAME-like A record” returned after internal resolution by PowerDNS lacks standardized protocol support, leading to compatibility issues. For cf pages, the test did actually resolve properly, but the system still didn’t recognize it, so access failed (though dig can see the IP returned by pdns). In the end, I gave up, so there’s currently no ALIAS record option in platform DNS. To solve this, users are advised to change NS and use the Gcore platform, which offers a mature DNS solution and supports root CNAME records.
Reference docs: Gcore Docs: Specify CNAME at root
- DDNS Core Features Improvement (More platform scripts to be added later)
* Access via URL: http://store.9v4.com/update_dns.php?key=xxx&order_id=xxx&record_name=xxx&record_value=xxx
*
* Parameter descriptions:
* - key: API key
* - order_id: Order ID
* - record_name: Record name
* - record_value: Record value (IP address)
* - record_type: Record type (optional, defaults to A)
* - record_ttl: TTL (optional, defaults to 600)
* - record_priority: MX priority (only needed for MX)
-
Security and Risk Control Upgrades
To address potential security risks and content abuse, I restructured the entire detection and complaint process.
From the independent Virustotal check platform to FOSSBilling integration:
https://store.9v4.com/virustotal (anonymous and logged-in users see differently; logged-in users can see which provider flagged abuse)
Previously: We relied on an independent Virustotal platform for proactive polling, using keyword locking and AI judgment to screen for malicious domains.
Now: To improve efficiency, I’ve deeply integrated this detection logic into the FOSSBilling system. The system will automatically run tighter risk scans. -
Abuse Complaint System Improvement:
Whenever users discover any violations or infringement, they can anonymously submit complaints via the abuse reporting channel. After review, I’ll forward the content to the user for handling, or, in serious cases, directly suspend the domain. Anonymous messaging is supported until users resolve or promise to resolve the abuse.
https://store.9v4.com/abuse/track/PKXYSG8T3A4V
Complaint page: https://store.9v4.com/abuse
Contact email: [[email protected]]
- Renewals Exploration: Invitation Code System
The main aim of perfecting the invitation code system is to create a user entry barrier—otherwise, unrestricted access only worsens abuse.
- Free VPS Trials:
I’ve basically refactored the FOSSBilling/Proxmox plugin, and it’s currently still under testing.
How renewals will be handled is still under consideration…
- Confirming .94v.net Can Be Applied For as a Long-Term Domain
Register a .94v.net subdomain using the newuser code and launch your project to apply for a long-term domain.
Before applying for a long-term domain, you should inform/write a brief statement…
Domain: myapp
Purpose
Guarantee
Of course, if the system detects inactivity or abuse, the domain will be deleted…
-
Future Operational Plans
-
Telegram Group Chat
- Free VPS Application
Once your .94v.net domain is accessible and content is safe, you can apply for a free VPS (renewal supported, once a month).
Without a .94v.net domain, please apply for a domain, complete your website deployment, then apply.
Ensure you have a substantial content site before applying; if rejected, you have to wait 3 days before reapplying.
Currently, this is just for testing—please provide feedback if you encounter issues, preferably with steps to reproduce, which helps me resolve them. Currently, only LXC is enabled, but I’ll eventually switch to KVM instead of LXC. All instances from this round of testing will be relaunched using KVM, so please do not store important data.
[reply]https://store.9v4.com/news/gift-process[/reply]
Has been displayed on the site
To be continued, edits pending.
