How Automatic Provisioning and Abuse Flags Work

No Manual Approval Queue

At is-cool-me, subdomain provisioning is fully automatic. When you authenticate via GitHub OAuth and request a subdomain, our system processes the registration in real time — no ticket, no waiting period, no moderator review. If your request passes our automated checks, the DNS record is created and the subdomain is live within seconds.

This is a deliberate design choice. Manual approval queues create friction for legitimate users, delay project launches, and do not scale. But automatic provisioning also creates risk: without human oversight at registration time, we must rely on automated systems to detect and block abuse before the subdomain becomes active. This article explains how those automated systems work, why some requests are flagged or rejected, and what you can do if your request does not go through.

How Automatic Provisioning Works

The provisioning pipeline executes the following sequence for every registration request:

1. GitHub OAuth Authentication: You sign in with GitHub, which provides us with your GitHub user ID, account creation date, public profile information, and email address. This is the foundation of our identity system.
2. Subdomain Selection: You choose an available subdomain name. Our system checks that the name is not already registered and does not match any exactly reserved names (e.g., internal domains, common typos of the root domain).
3. DNS Target Specification: You provide the target CNAME or A record. The system verifies that the target is syntactically valid and, for CNAME records, that the target is not a loop back to our own domain.
4. Abuse Flag Evaluation: The request is evaluated against all active abuse detection checks. This is the most complex step and is described in detail below.
5. DNS Record Creation: If all checks pass, the system creates the DNS record through our provider's API. The record propagates according to standard DNS TTL values (typically 60–300 seconds).
6. Confirmation: The subdomain is displayed in your dashboard with its current status and DNS configuration.

Steps 1–6 complete in under 2 seconds for a typical request. If the request is flagged at step 4, the provisioning is halted and the user receives an explanation message.

What Triggers Abuse Flags

Our abuse detection system evaluates each registration request against multiple signals. No single signal triggers an automatic rejection — the system uses a scoring model that considers the combination and severity of all signals.

Suspicious Keywords in Subdomain Names

The most common trigger. Our system maintains a blocklist of keywords and patterns that are frequently associated with abuse:

• Brand impersonation: "google", "facebook", "amazon", "microsoft", "apple", "paypal", "netflix", "instagram", "whatsapp", "telegram", "discord" — and hundreds of common misspellings and variations
• Phishing keywords: "login", "signin", "secure", "account", "verify", "auth", "2fa", "wallet", "seed", "recover", "support", "helpdesk"
• Admin-related: "admin", "administrator", "root", "panel", "cpanel", "webmail", "mail"
• Deceptive patterns: "free", "hack", "crack", "cheat", "mod", "unlock", "generator", "bot"

The system uses fuzzy matching, so simple character substitutions (e.g., "g00gle" or "googie") are also detected. The blocklist is updated regularly based on emerging threat intelligence and new abuse patterns.

Known Abuse Patterns

Beyond keywords, the system evaluates the overall structure of the subdomain name:

• Randomized strings: Subdomains that appear to be randomly generated (e.g., x7k9m2q4.is-pro.dev) are flagged — these are often used for disposable spam campaigns
• Hyphen-heavy names: Multiple consecutive hyphens or hyphens in unusual positions
• Length anomalies: Extremely short (fewer than 3 characters) or extremely long (more than 40 characters) subdomain names
• Repeated characters: Names with excessive repetition like aaaaa-bbbb-cccc.is-pro.dev

High-Risk TLD Combinations

Some top-level domains are more frequently associated with abuse than others. When a subdomain's CNAME target uses a high-risk TLD (e.g., .tk, .ml, .ga, .cf — the former Freenom TLDs), the system applies additional scrutiny. This is not an automatic rejection, but it increases the score of the overall evaluation.

Rapid Registration Patterns

Our system tracks registration velocity per GitHub account and per IP address. If you register more than a certain number of subdomains within a short time window, subsequent requests are flagged. The specific thresholds are not public (to prevent gaming), but the general principle is: the system expects human-like registration patterns, not automated bulk registration.

GitHub Account Age and Activity

New GitHub accounts with limited activity are higher-risk. Our system considers:

• Account age: Accounts created within the last 30 days receive additional scrutiny
• Public repositories: Accounts with zero public repositories or only forked repositories
• Profile completeness: Accounts without a verified email, bio, or avatar photo
• Prior abuse: Any history of abuse associated with the GitHub account ID (even if the account is new, we track anonymous abuse signals)

How the Flagging System Works

The flagging system uses a weighted scoring model. Each signal contributes a score to the overall evaluation, and the scores are combined to produce a final risk assessment:

Risk Score = (Subdomain Name Score × 0.35)
           + (Account Risk Score × 0.30)
           + (Registration Pattern Score × 0.20)
           + (Target Risk Score × 0.15)

If the total risk score exceeds a configurable threshold, the request is rejected. Scores just below the threshold may result in a "flagged for review" status, where the request is provisioned but placed on a watchlist for manual review within 24 hours.

The scoring model is retrained periodically based on confirmed abuse cases and false positive reports. This is a continuous improvement process — every time a user appeals a rejection and we determine it was a false positive, we adjust the model to reduce the likelihood of similar false positives in the future.

Common Rejection Reasons

If your subdomain request is rejected, the dashboard displays a specific reason. Here are the most common rejection reasons and what they mean:

Rejection Reason	What It Means	How to Fix
Subdomain name resembles known phishing pattern	The name matched a keyword or pattern on our blocklist	Choose a different name that reflects your actual project
Account too new or suspicious	Your GitHub account does not meet our minimum activity criteria	Build a public project, verify your email, or wait for your account to mature
Attempting to register blocked keyword	The name contains a string we reserve for platform safety	Review our blocked keywords list in the FAQ; choose an alternative
DNS verification failure	The target endpoint could not be resolved or returned an error	Verify the CNAME target or A record is valid and resolves
Rate limit exceeded	You registered too many subdomains too quickly	Wait 60 minutes before attempting another registration

What to Do If Your Request Is Rejected

Rejection is not permanent. Here is what to do step by step:

1. Read the rejection message: The dashboard shows the specific reason. Start by understanding which check failed.
2. Try a different subdomain name: If the issue is the name itself (phishing pattern or blocked keyword), choose a more descriptive, project-specific name. Instead of login-support.is-pro.dev, try myapp-docs.is-pro.dev.
3. Update your GitHub profile: If the issue is account age or activity, add a public repository, verify your email, and set a profile picture. These changes may not take effect immediately — our system caches GitHub profile data for up to 24 hours.
4. Contact support: If you believe the rejection was a false positive, contact us via the contact form or Discord. Include your GitHub username, the subdomain you tried to register, and an explanation of your project. Our moderation team will review the rejection and, if appropriate, manually approve the request or adjust the automated system.

How to Improve Your Chances of Approval

Based on the data from thousands of registration requests, here are the factors that correlate with smooth approvals:

• Use descriptive project names: my-todo-app.is-pro.dev is better than app.is-pro.dev. The more specific your name, the less likely it is to match an abuse pattern.
• Link to a real project: Point your subdomain to a GitHub Pages site, a Vercel/Netlify project, or any live application. A subdomain with live content has a much lower risk of being flagged after registration.
• Space out registrations: If you need multiple subdomains, register them one at a time with reasonable gaps (an hour or more between requests).
• Build GitHub presence: A profile with repositories, stars, and contributions signals that you are a real developer using the platform for legitimate purposes.
• Avoid trademarked terms: Even if you have a legitimate reason to use a brand name (e.g., writing a tutorial about "discord bots"), the automated system cannot distinguish intent — choose a name that reflects your project.

False Positives and System Improvement

We know our automated system is imperfect. False positives — legitimate requests that are incorrectly flagged — happen, and we take them seriously. Every false positive report helps us improve the system in two ways:

1. Direct fix: If a specific keyword or pattern is causing excessive false positives, we adjust the blocklist or scoring weight for that signal.
2. Model retraining: Flagged-but-approved requests are used as training data for the scoring model. Over time, the system learns to distinguish between genuine projects and abuse attempts more accurately.

We publish periodic transparency reports that include our false positive rate. Our current target is a false positive rate below 5% — meaning at least 95% of flagged requests are confirmed as genuine abuse. We are investing in better signal processing to reduce this further without compromising detection coverage.

Appeals Process

If your request was rejected and you believe it was a false positive, here is how to appeal:

1. Go to the contact page and select "Appeal a rejected subdomain" from the subject dropdown
2. Include your GitHub username, the subdomain name you tried to register, and a description of your project
3. Optional but helpful: link to your project's repository, live site, or documentation — this gives our moderators context to evaluate your request
4. Our moderation team will review the appeal within 48 hours
5. If approved, the subdomain will be manually provisioned and you will receive a confirmation
6. If denied, we will explain the reasoning and suggest alternatives (e.g., a different subdomain name that would pass the automated checks)

Appeals are reviewed by humans, not automated systems. We understand that automated flagging can be frustrating, and we want to make the appeals process as smooth as possible.

Conclusion

Automatic provisioning with abuse detection is a tradeoff. It gives legitimate users instant access to subdomains while creating barriers for bad actors. The system is not perfect, but it is constantly improving. If your request is rejected, do not take it personally — try a different name, build out your GitHub profile, or reach out to us for help.

We are committed to transparency about how our systems work. If you have questions about the flagging process that are not answered here, join our Discord community and ask — we are happy to explain.

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.