How We Think About Fair Use for Free Subdomains

What "Fair Use" Means for a Free Subdomain Service

When we say "fair use" at is-cool-me, we are describing a shared responsibility model. We provide free subdomains under the is-pro.dev and related domains because we believe developers should have easy access to DNS infrastructure for their projects. In return, we ask that each user consumes these resources in a way that does not degrade the experience for others or create risk for the platform as a whole.

Fair use is not a fixed number — it is a principle. It means using the service for its intended purpose (hosting real projects and applications) without abusing the free tier to run industrial-scale operations, host disposable spam domains, or circumvent platform safeguards. Think of it like a community garden: everyone is welcome to plant, but nobody should bring in a tractor and plant fifty acres.

Why Limits Exist

Every free service operates under resource constraints. For a DNS-based platform like is-cool-me, the constraints fall into three categories:

DNS Query Volume

Every subdomain we provision generates DNS queries — often hundreds of thousands per day for popular subdomains. Our upstream DNS providers (and our own infrastructure) have capacity limits. A single user registering 10,000 subdomains for a spam campaign could generate millions of queries per hour, degrading resolution latency for every other user. We enforce per-account limits on subdomain registrations to ensure query volume stays within our capacity budget.

Abuse Prevention

Free subdomain services are a favorite target for phishers, malware distributors, and spammers. A single phishing site on our platform can get our entire domain — including every legitimate user's subdomain — added to blocklists like Google Safe Browsing, Spamhaus, or SURBL. Once a domain is blacklisted, it can take weeks to get delisted, and some blocklists permanently degrade trust in the domain. Limits on registration patterns, keyword filtering, and content monitoring are all designed to prevent this outcome before it happens.

Resource Fairness

Our infrastructure (DNS servers, API gateways, databases, moderation tooling) is shared across all users. Rate limits and usage caps ensure that no single user can monopolize resources. This is standard practice for any multi-tenant service — AWS has service quotas, GitHub has rate limits, and we have fair use boundaries.

Common Fair Use Considerations

How Many Subdomains Can One User Register?

Each user authenticated via GitHub OAuth can register a reasonable number of subdomains for personal and project use. Our current policy allows multiple subdomains per user, but we monitor for patterns that indicate bulk registration for non-project purposes. If you are building a platform that needs subdomains for each customer, contact us to discuss a partnership — the free tier is designed for individual developers, not resellers.

Traffic and Bandwidth Expectations

is-cool-me provides DNS resolution, not hosting. We do not limit traffic to your hosted content (that is between you and your hosting provider). However, we do limit DNS query volume per subdomain. If your subdomain generates an unusually high volume of DNS queries (tens of thousands per minute), we may reach out to discuss your use case or recommend moving to a dedicated DNS provider. Most personal projects will never approach this threshold.

Prohibited Uses

The following uses are categorically prohibited under our fair use policy:

• Spam: Using subdomains to send or advertise unsolicited bulk email
• Phishing: Impersonating login pages, financial institutions, or other trusted services to steal credentials
• Malware distribution: Hosting or linking to malicious software, exploit kits, or drive-by download pages
• Disposable domains: Creating short-lived subdomains for spam campaigns or credential stuffing
• Reselling: Offering is-cool-me subdomains as a service to third parties
• Illegal content: Any content that violates applicable law in your jurisdiction or ours

Idle and Inactive Subdomains

Subdomains that do not resolve to active content for an extended period may be reclaimed. We define "inactive" as: the DNS record exists but the target endpoint returns a non-200 status (or does not resolve) for 90 consecutive days. Before reclaiming an inactive subdomain, we send a notification to the registered email address with a 14-day grace period to restore the target.

This policy prevents subdomain squatting — reserving names without using them — and ensures that the namespace remains available for active projects. If you need to temporarily pause a project, update the DNS record to point to a static maintenance page to keep the subdomain active.

How We Enforce Fair Use

Enforcement is layered and proportional. We use automated systems for first-line detection and human review for edge cases and appeals.

Automated Monitoring

Our monitoring pipeline tracks several metrics per account and per subdomain:

• Registration rate (subdomains created per hour)
• DNS query volume (queries per minute per subdomain)
• Content reachability and response status codes
• Keyword and pattern matching on subdomain names
• Known blocklist status (Google Safe Browsing, PhishTank, etc.)

When a metric exceeds a threshold, the system automatically flags the account for review. For clear violations (e.g., a subdomain name that matches a known phishing pattern), the system can suspend the subdomain immediately and notify the moderation team.

Rate Limiting

API endpoints for subdomain registration, DNS record updates, and account operations are rate-limited per user and per IP address. Rate limits protect our infrastructure from accidental or intentional abuse. If you hit a rate limit, wait for the window to reset — typically 60 seconds for most endpoints. Repeated rate limit violations may trigger a manual review.

Abuse Detection

We integrate with multiple threat intelligence feeds and blocklist services. When a subdomain appears on a blocklist, we automatically investigate and, if confirmed, suspend the subdomain and notify the owner. We also accept abuse reports from the community — see our guide on handling abuse reports for details.

What Happens When Limits Are Exceeded

Enforcement actions follow a graduated scale:

1. Warning: For first-time or low-severity violations, we send a warning via email and dashboard notification explaining the issue and what needs to change.
2. Temporary suspension: If the violation continues or is more serious (e.g., a phishing attempt detected early), the subdomain is temporarily suspended. DNS resolution is disabled, and the owner receives instructions for remediation.
3. Account review: For repeated or severe violations (e.g., malware distribution), the entire account is placed under review. All subdomains are suspended pending investigation.
4. Termination: In cases of intentional abuse, illegal content, or failure to remediate after multiple warnings, the account is terminated and all subdomains are reclaimed.

Examples: Fair vs. Unfair Usage

To make the policy concrete, here are examples of both fair and unfair usage patterns:

Scenario	Assessment	Why
Hosting a personal blog at blog.is-pro.dev	Fair	Single subdomain, real content, active maintenance
Registering 3 subdomains for 3 open-source projects	Fair	Project-linked, transparent ownership via GitHub
Registering 200 subdomains in one hour via automation	Unfair	Bulk registration pattern suggests abuse or reselling
Hosting a SaaS landing page that gets 50k daily visitors	Fair	Legitimate project with real traffic
Creating login-google.is-pro.dev	Unfair	Impersonation pattern — likely phishing
Using a subdomain as a redirect URL for an email campaign	Unfair	Potentially deceptive, associated with spam infrastructure

How to Stay Within Fair Use: Best Practices

• Register only what you need: Each subdomain should correspond to a real project or application. Avoid registering names "just in case" — you can always add more later.
• Keep your subdomains active: Point them to live, accessible content. If a project is deprecated, either redirect it or remove the DNS record.
• Use descriptive, honest names: Your subdomain should reflect your project's actual identity. Avoid names that could be confused with well-known brands or services.
• Respond to notifications: If we contact you about a subdomain issue, respond promptly. Non-responsive accounts are more likely to face enforcement actions.
• Secure your GitHub account: Since authentication is tied to GitHub, a compromised GitHub account could be used to register subdomains maliciously. Enable two-factor authentication on GitHub.

Appeals Process

If your subdomain or account was suspended and you believe it was a mistake, you can appeal through the following process:

1. Contact us via the contact form or our Discord server with the subject "Appeal: [your subdomain]"
2. Include your GitHub username, the subdomain(s) in question, and an explanation of why you believe the suspension was in error
3. Our moderation team will review the appeal within 48 hours
4. If the appeal is approved, the subdomain will be reinstated immediately
5. If the appeal is denied, we will explain the reasoning and, where applicable, suggest steps to remediate the issue

We take appeals seriously. False positives in our automated systems are inevitable, and we want to correct them quickly. Every appeal helps us improve our detection accuracy.

Future Plans: Scaling Fair Use

As is-cool-me grows, we are investing in more sophisticated fair use enforcement that is both more accurate and less burdensome for legitimate users. Our roadmap includes:

• Reputation-based scoring: Accounts with a long history of compliant usage will earn higher rate limits and more lenient automated checks
• Improved abuse detection ML: Better classification of phishing and spam patterns to reduce false positives
• Self-service appeal portal: A dashboard-based appeals system with faster turnaround times
• Usage analytics: Public transparency reports showing enforcement actions, uptime, and abuse trends
• Premium tier: For users who need higher limits, we are exploring a paid tier with dedicated support and expanded quotas

Our goal is to keep is-cool-me free and accessible for developers while maintaining the trust of the broader internet community. Fair use is how we balance those two priorities.

Deployment scenario from operations

Moderation decisions were reviewed with concrete evidence to separate unsafe behavior from legitimate project activity.

Common mistakes

• Treating policy language as vague guidance instead of enforceable boundaries.
• Submitting reports without timestamps or reproducible evidence.
• Assuming moderation outcomes are random when evidence is incomplete.

How to verify it works

1. Check decision rationale against published policy categories.
2. Confirm evidence package contains URLs, timing, and impact details.
3. Use appeal path when factual corrections are needed.