How do I report a security issue?

Email security@dnscale.eu with enough detail to reproduce — affected endpoint, expected vs actual behaviour, proof-of-concept payload (sanitised). We acknowledge receipt within 24 hours. If encryption is required before DNScale publishes its production PGP key, request a secure exchange path in the initial email.

Do you pay bug bounties?

DNScale does not run a paid bounty program at this time. We do publicly acknowledge researchers who follow this policy and produce valid, novel reports — including in our post-incident reports and on a dedicated acknowledgements page (in development). For researchers who require bounty as a precondition for disclosure, this program isn't currently set up for that.

DNScale's production services: dnscale.eu and subdomains, the customer dashboard, the public REST API, our authoritative nameservers (NS records and infrastructure), our published Terraform / DNSControl providers, DNS query handling, billing integration. Out of scope: third-party services we use (Stripe, hosting providers), purely DoS attacks against our infrastructure, social engineering of staff, physical attacks on our premises.

What if my finding involves a third-party service we depend on?

Report to us anyway with details. We'll determine whether it's our responsibility to coordinate with the third party, route the report appropriately, or advise you to report directly. We'll acknowledge your finding either way.

How long will it take to fix?

Severity-dependent. We target: 24 hours acknowledgement, 72 hours initial triage and severity classification, 30 days for high-severity remediation, 90 days for medium-severity, 180 days for low-severity. We coordinate disclosure timing with the reporter — ideally aligning public disclosure with the fix being deployed and customers being able to mitigate.

What about legal protection?

We commit not to pursue legal action against researchers who: act in good faith, stay within scope, do not access or modify customer data beyond what's necessary to demonstrate the issue, do not perform DoS or destructive testing, and disclose responsibly. This is a coordinated-disclosure policy, not a substitute for laws on computer access — but within the scope and conduct described, you have our written safe harbour.

DNScale Vulnerability Disclosure Policy

How to responsibly report security vulnerabilities to DNScale — scope, expected response times, safe-harbour provisions, and what gets published afterwards.

Updated 5 May 2026

TL;DR

DNScale runs a coordinated vulnerability disclosure program. Report security issues to security@dnscale.eu. We acknowledge reports within 24 hours, triage within 72 hours, and target a fix or mitigation within 30 days for high-severity issues. Good-faith research within scope is protected — we won't pursue legal action against researchers who follow this policy. We coordinate disclosure timing with reporters and publish post-incident reports for significant issues.

What you'll learn

Identify the in-scope and out-of-scope assets for security research at DNScale
Understand the expected timeline for acknowledgement, triage, and remediation
Recognise the safe-harbour terms for good-faith research
Submit a complete, actionable vulnerability report

DNScale runs critical authoritative DNS infrastructure for paying customers. Security is core to what we sell. If you've found a vulnerability — in our service, our API, our infrastructure, or our published software — we want to hear from you, fix it, and credit you for the work.

This policy describes how to report responsibly, what to expect from us in return, and what protections you have as a researcher acting in good faith.

For the broader operational picture, see DNScale infrastructure and EU operations.

How to Report

Email: security@dnscale.eu

PGP key: pending publication. DNScale will publish the production security-team key and fingerprint on /security once ready; do not use placeholder key material.

Machine-readable contact: https://dnscale.eu/.well-known/security.txt (RFC 9116)

If encryption is required before the production PGP key is published, send a minimal plain email and request a secure exchange path for follow-up.

What to include

A good vulnerability report includes:

Affected endpoint or asset — URL, API path, hostname, IP, file, etc.
Description of the issue — what's wrong, what an attacker could do
Reproduction steps — exact requests, payloads, conditions, environment
Impact assessment — what data, what users, what scale
Suggested mitigation if you have one
Whether you've disclosed this to anyone else (other vendors, public, etc.)
How you'd like to be credited (or not) on disclosure

We don't expect a polished writeup. A working proof-of-concept and clear reproduction steps are far more valuable than prose.

Scope

In scope

DNScale production services: dnscale.eu and subdomains
The DNScale customer dashboard
The DNScale public REST API
DNScale's authoritative nameservers (e.g., ns1.dnscale.eu, ns2.dnscale.eu) and the responses they serve
DNScale-published software:
- Official DNScale Terraform provider
- Official DNScale DNSControl provider
- Other tools published from DNScale's official GitHub
Billing integration (the DNScale-side handling of customer billing data)
DNScale-operated email infrastructure
DNS query handling, DNSSEC implementation, AXFR handling

Out of scope

Third-party services we use (Stripe, our hosting providers, our peering partners)
Customer-uploaded content / customer-configured DNS data — those are the customer's responsibility, not ours
Pure denial-of-service attacks against our infrastructure (don't test these)
Social engineering of DNScale staff
Physical attacks against our premises or staff
Vulnerabilities in third-party libraries that aren't actively exploitable in our deployment context (please still report; we'll route appropriately)
Theoretical issues without a working proof-of-concept
Self-XSS that requires the user to paste payload into their own console

If you're not sure whether something is in scope, send the report anyway and we'll make the call.

What to Expect From Us

Stage	Target time	What happens
Acknowledgement	24 hours	We confirm receipt of your report.
Initial triage	72 hours	We assess validity and severity, and tell you which one.
Status update	Weekly	While the issue is open, we send you weekly status emails.
Fix or mitigation	Severity-dependent (see below)	The issue is resolved or mitigated.
Coordinated disclosure	At fix deployment	We coordinate timing with you for public disclosure.
Post-incident report	After significant issues	We publish on the blog where customer-confidential details aren't at stake.

Remediation timelines

Severity	Description	Target time-to-fix
Critical	Remote unauthenticated takeover, mass customer data exposure	< 7 days
High	Authenticated escalation, individual customer data exposure, DNSSEC integrity issue	< 30 days
Medium	Information leak with limited impact, requires uncommon prerequisites	< 90 days
Low	Best-practice violations, theoretical issues, defence-in-depth gaps	< 180 days

These are targets, not contractual SLAs. We'll communicate honestly if a fix takes longer than these windows — and explain why.

Safe Harbour

We commit not to pursue legal action against you under the Computer Fraud and Abuse Act (CFAA) or equivalent laws in EU jurisdictions, provided you:

Act in good faith to identify and report security issues to DNScale.
Stay within scope as defined above.
Do not access or modify customer data beyond what's strictly necessary to demonstrate the vulnerability. If you encounter customer data, stop, report what you found, and don't retain it.
Do not perform destructive testing. This includes DoS attacks, mass data deletion, and persistent backdoor installation. If you're not sure whether a test is destructive, ask first.
Disclose responsibly. Give us time to fix. Coordinate public disclosure with us.
Do not extort. Bug bounty programs do not exist as ransom; this isn't one.

This safe harbour is a commitment from DNScale, not a comprehensive legal protection — local laws still apply. But within the scope and conduct described above, you have our written commitment.

Public Acknowledgements

We publicly credit researchers who follow this policy and produce valid reports. By default, when a report is fixed and disclosed, we acknowledge:

The researcher's preferred name (or pseudonym) and optional contact link
The class of issue (we may withhold specific technical details if customer mitigation is still in progress)
Approximate disclosure timeline

You can opt out of public acknowledgement at any time. Just let us know.

We do not currently run a paid bounty program. If your research model requires bounty as a precondition, this disclosure path is not currently set up for that — though we may offer programmes through HackerOne, Intigriti, or similar in the future.

Coordinated Disclosure

For most issues, we follow a "fix first, disclose after" pattern:

You report. We acknowledge and triage.
We develop a fix. We may share design details with you for review.
We deploy the fix. We notify affected customers if applicable.
After the fix has been deployed and customer-side mitigation (if any) has been completed, we coordinate public disclosure with you.

For high-severity issues affecting many customers, we may delay public disclosure until customers have had time to update or rotate credentials. This window is typically 30 days but can be longer for complex issues.

If a third party has already publicly disclosed the issue (or it's actively being exploited), all of this collapses — we ship the fix as fast as possible and disclose immediately.

Out-of-Scope Issues That Are Still Worth Reporting

Some issues aren't in scope for our SLA but we still want to know about:

Customer-side misconfiguration patterns we should make harder to introduce. If you find a customer with an obviously bad DNS configuration, telling us helps us add product guard rails — even if their specific account isn't our security issue.
Third-party library vulnerabilities in dependencies we ship. We'll route to upstream and track our own update.
Best-practice violations that aren't directly exploitable but that erode defence in depth. We track these as security debt.

For these, send the report anyway. We'll respond and decide how to handle.

What This Policy Doesn't Cover

This page documents how to report security vulnerabilities. It does not cover:

Customer support requests — use support@dnscale.eu or the dashboard support flow.
Abuse complaints — use abuse@dnscale.eu for customers misusing DNScale services.
Regulatory inquiries — use legal@dnscale.eu.
Press inquiries — use press@dnscale.eu.
Bug reports for non-security defects — use the GitHub repos for our open-source providers, or support for the service itself.

DNScale infrastructure and EU operations
NIS2 and DNS compliance
DNS security best practices
Multi-factor authentication guide
/.well-known/security.txt — machine-readable security contact (RFC 9116)
/security — human-readable security contact page and PGP publication status

References

RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
disclose.io — Open-source standardised vulnerability disclosure terms
ISO/IEC 29147 — Information technology — Security techniques — Vulnerability disclosure
ISO/IEC 30111 — Information technology — Security techniques — Vulnerability handling processes

Frequently asked questions

How do I report a security issue?: Email security@dnscale.eu with enough detail to reproduce — affected endpoint, expected vs actual behaviour, proof-of-concept payload (sanitised). We acknowledge receipt within 24 hours. If encryption is required before DNScale publishes its production PGP key, request a secure exchange path in the initial email.
Do you pay bug bounties?: DNScale does not run a paid bounty program at this time. We do publicly acknowledge researchers who follow this policy and produce valid, novel reports — including in our post-incident reports and on a dedicated acknowledgements page (in development). For researchers who require bounty as a precondition for disclosure, this program isn't currently set up for that.
What's in scope?: DNScale's production services: dnscale.eu and subdomains, the customer dashboard, the public REST API, our authoritative nameservers (NS records and infrastructure), our published Terraform / DNSControl providers, DNS query handling, billing integration. Out of scope: third-party services we use (Stripe, hosting providers), purely DoS attacks against our infrastructure, social engineering of staff, physical attacks on our premises.
What if my finding involves a third-party service we depend on?: Report to us anyway with details. We'll determine whether it's our responsibility to coordinate with the third party, route the report appropriately, or advise you to report directly. We'll acknowledge your finding either way.
How long will it take to fix?: Severity-dependent. We target: 24 hours acknowledgement, 72 hours initial triage and severity classification, 30 days for high-severity remediation, 90 days for medium-severity, 180 days for low-severity. We coordinate disclosure timing with the reporter — ideally aligning public disclosure with the fix being deployed and customers being able to mitigate.
What about legal protection?: We commit not to pursue legal action against researchers who: act in good faith, stay within scope, do not access or modify customer data beyond what's necessary to demonstrate the issue, do not perform DoS or destructive testing, and disclose responsibly. This is a coordinated-disclosure policy, not a substitute for laws on computer access — but within the scope and conduct described, you have our written safe harbour.

Ready to manage your DNS with confidence?

DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.

Start free