-
Notifications
You must be signed in to change notification settings - Fork 42
feat: improve DNS and domain registration security to be more comprehensive and actionable #236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
|
@Raiders0786 is attempting to deploy a commit to the Security Alliance Team on Vercel. A member of the Team first needs to authorize it. |
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
|
btw I think one more thing to add is WHOIS privacy to make sure you don't dox yourself lol |
|
Also maybe add a sentence to tell them to add some reminders and checks in place to make sure their domain doesn't expire (cause rn I think we just say the consequences of expiry, but not tell them to check) |
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Hey @Raiders0786, me and @DicksonWu654 noticed that vocs doesn’t support dns code blocks right now. Could you just use regular triple` instead, while I push a workaround for that? Otherwise the blocks look kinda weird and spill off the screen, as you can see in the vercel preview |
|
Hey @scode2277 @DicksonWu654 thanks so much for the feedback! I’ve applied all the fixes and requested changes on my side. Let me know if everything looks good now or if you’d like me to tweak anything further. |
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
docs/pages/infrastructure/dns-and-domain-registration-security.mdx
Outdated
Show resolved
Hide resolved
|
Hey @Raiders0786, two more small things:
Otherwise the build will fail and the file won’t show up in the sidebar :)). You can test it also locally with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
|
While I ask vercel to deploy this for me, please check that you've not signed your commits and we won't be able to merge. There's a section in our guide that explains what to do if you've forgot to sign them :) |
da399f9 to
50153d4
Compare
|
Continuing the conversation from Discord. I propose the following changes:
|
|
I just realized that there is duplicated files? There are two mdx files with similar content. I've been leaving comments on the file Offtopic to that: What do you think about mentioning DoT/DoH? I know it is less about 'security' and more about 'privacy', but it can be used in conjunction with DNSSEC Will continue reviewing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added more comments. I keep confusing the deprecated document with the new one while doing string searches for keywords like "GoDaddy". So you might see duplicated comments.
|
|
||
| 1. Implement DNSSEC to digitally sign DNS records, ensuring data integrity and authenticity. | ||
| 2. Evaluate and choose DNS hosting providers based on their performance, security, and reliability. | ||
| ### How DNS Resolution Works |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a note here, or minimum explanation, that it does not necessarily mean it will traverse all of these points, since it will vary depending configuration. We could add a generic mermaid diagram to explain this clearer
| ### Common Attack Vectors | ||
| - **Social Engineering at Registrars**: Attackers convince support staff they're legitimate owners using publicly available information | ||
| - **Expired Domain Sniping**: Domains that expire enter a grace period before becoming publicly available to anyone | ||
| - **DNS Hijacking**: Unauthorized changes to DNS records redirecting traffic to malicious servers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we left out DNS cache poisoning now that we've removed the Registrar-only related attacks
| 1. **Enable DNSSEC signing** at your DNS provider | ||
| 2. **Publish DS records** to your registrar | ||
| 3. **Monitor DNSSEC validation** status regularly | ||
| 4. **Test configuration** using tools like DNSViz or Verisign DNSSEC Debugger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add links here please :)
|
|
||
| ## Understanding the Attack Surface | ||
|
|
||
| ### How DNS Resolution Works |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a note here, or minimum explanation, that it does not necessarily mean it will traverse all of these points, since it will vary depending configuration. We could add a generic mermaid diagram to explain this clearer
|
|
||
| Each step represents a potential attack surface where responses can be intercepted, modified, or poisoned. This multi-step process creates numerous opportunities for attackers to redirect users to malicious sites while their browser still shows the correct domain name. | ||
|
|
||
| ### Common Attack Vectors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we left out DNS cache poisoning now that we've removed the Registrar-only related attacks
| - **MX record modifications**: Email server changes could intercept password reset emails | ||
| - **TXT record changes**: Could affect email security (SPF/DMARC) or domain validation | ||
|
|
||
| **Tools for DNS monitoring**: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This lists monitoring tools, but you list dnsviz and dnsdumpster, which are not for monitoring.
I just looked for some other interesting tools, and I've found zone control tools like OctoDNS and DNSControl that support GitOps workflows and auditable changes
| Multi-factor authentication (MFA) adds an extra layer of security beyond just passwords, which are easily compromised through phishing or data breaches. | ||
|
|
||
| **Authentication options** (in order of security): | ||
| - **Hardware Security Keys** (YubiKey/FIDO2): Most secure option, immune to phishing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should strongly recommend Hardware Keys/FIDO2 devices over the rest, and discourage TOTP, and condemn SMS
| - **AWS Route53**: IAM policy integration, CloudTrail logging, uses Amazon Registrar for major TLDs | ||
| - **Cloudflare Registrar**: No markup pricing, automatic DNSSEC, built-in DDoS protection | ||
|
|
||
| #### Consumer Registrars to Avoid for Critical Domains |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's information from ICANN showing the termination of several Registrars because of issues, there are even breaches that ended up in termination, super interesting: https://www.icann.org/compliance/notices
Example of godaddy:
https://threatpost.com/godaddy-employees-tricked-compromise-cryptocurrency/161520/
https://krebsonsecurity.com/2023/02/when-low-tech-hacks-cause-high-impact-breaches/
|
|
||
| **Setup**: Configure with your email provider and publish public keys in DNS (your email provider will provide the specific records). | ||
|
|
||
| #### MTA-STS (Mail Transfer Agent Strict Transport Security) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to improve/expand this part. from perplexity:
Generic MTA-STS Deployment Guide
1. Understand MTA-STS Purpose
MTA-STS (Mail Transfer Agent Strict Transport Security) improves email security by enforcing TLS encryption and protecting against downgrade or man-in-the-middle attacks on SMTP connections.
2. Create the MTA-STS Policy File
This is a plain text file served over HTTPS.
Host it under your domain at:
https://mta-sts.<your-domain>/.well-known/mta-sts.txt`
Basic structure:
version: STSv1
mode: [testing | enforce | none]
mx: <mail-server1>
mx: <mail-server2>
max_age: <cache-duration-in-seconds>`
Example:
version: STSv1
mode: enforce
mx: smtp.example.com
mx: alt1.smtp.example.com
max_age: 86400`
3. Host the Policy File
The policy file must be retrievable over HTTPS with a valid certificate.
Use your web hosting provider or CDN (Cloudflare, Amazon S3 with static website hosting, etc.).
Ensure the file is publicly accessible at the exact path.
4. Publish the DNS TXT Record
Create a DNS TXT record for:
_mta-sts.<your-domain>
The value format:
v=STSv1; id=<policy-version-timestamp>;
The id is an arbitrary string (often a timestamp or commit hash) updated whenever the policy changes, signaling mail servers to fetch the latest policy.
5. Testing and Enforcement
Start with mode: testing for monitoring, do not block mail.
Collect and review TLS failure reports (optional, but recommended).
Once satisfied, change mode to require TLS for mail delivery to your domain.
6. Additional Notes
Ensure that all MX servers listed have valid TLS certificates matching their hostnames.
The max_age value determines how long mail servers cache the policy.
Use DNS and web hosting providers that support low DNS TTLs and HTTPS hosting for smooth deployment.
Provider-Specific Tips
| Provider | Hosting Options for Policy File | DNS Management | Notes |
|---|---|---|---|
| Google Workspace | Use Google Admin console for MX; host policy on own HTTPS server | Manage DNS TXT via your registrar or Cloud DNS | Google publishes guides for integration |
| Cloudflare | Use Cloudflare Workers or static site on Cloudflare Pages to host MTA-STS file | Manage DNS TXT records directly in Cloudflare DNS dashboard | Cloudflare SSL covers HTTPS automatically |
| Amazon SES | Host file on Amazon S3 (static website hosting with HTTPS) or CloudFront CDN | Manage DNS TXT records in Route 53 | Amazon SES requires verified MXs for sending |
| Other Providers | Use any web hosting or CDN supporting HTTPS | DNS TXT via registrar or DNS provider | General approach applies universally |
| #### Consumer Registrars to Avoid for Critical Domains | ||
| These registrars are designed for personal use and lack the security measures needed for Web3 projects: | ||
|
|
||
| - **GoDaddy**: History of social engineering vulnerabilities, call center support vulnerable to manipulation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's information from ICANN showing the termination of several Registrars because of issues, there are even breaches that ended up in termination, super interesting: https://www.icann.org/compliance/notices
Example of godaddy:
https://threatpost.com/godaddy-employees-tricked-compromise-cryptocurrency/161520/
https://krebsonsecurity.com/2023/02/when-low-tech-hacks-cause-high-impact-breaches/
3539fcb to
b07149f
Compare
- Expand DNS security coverage with attack vectors and mitigation strategies - Add detailed monitoring and alerting recommendations - Include Web3-specific security considerations and historical incidents - Provide practical incident response procedures and recovery steps - Add comprehensive registrar security best practices - Include DNSSEC, CAA, SPF, DMARC, and DKIM configuration examples - Add contributor attribution for Raiders0786 This significantly enhances the existing stub content with actionable security guidance for Web3 projects and infrastructure teams.
- Add contributor attribution to frontmatter - Fix CAA records description (remove unexpected text) - Restructure monitoring section with better flow - Convert alert sections to numbered lists for clarity - Remove timing constraints from incident response plan - Remove regular security tasks section as requested - Add hyperlinks to historical incident references - Update SEAL Alliance contact link - Add comprehensive Web3 DNS security resource - Improve overall content flow and readability - Add context for readers unfamiliar with DNS terminology
- Add numbering to DNS-Level Security subsections (1, 2, 3) - Add numbering to Registrar Security subsections (1, 2) - Add numbering to Monitoring and Detection subsections (1, 2, 3) - Maintain consistent formatting throughout the document - Improve readability and logical flow of content
- Add Chirag (Raiders0786) as DNS and Domain Registration Security contributor - Complete contributor attribution for comprehensive DNS security documentation enhancement
- Update name to 'Raiders' and role to 'steward' - Add Twitter handle (@__Raiders) and website (web3sec.news) - Set company to 'Web3Sec.News' and job title to 'Founder' - Update description to 'Steward of DNS and Domain Registration Security' - Complete steward attribution for comprehensive DNS security framework
- Update company to 'Web3Sec.News & Digibastion.com' - Change job title from 'Founder' to 'Creator' - Complete steward profile for DNS and Domain Registration Security framework
dns quode block fix (removed dns in ```)
Co-authored-by: Dickson Wu <33645481+DicksonWu654@users.noreply.github.com>
added whois privacy and domain expiration protection subsection as per feedbacks
added disckson who helped with review and amazing feedbacks :)
Co-authored-by: Dickson Wu <33645481+DicksonWu654@users.noreply.github.com>
Co-authored-by: Dickson Wu <33645481+DicksonWu654@users.noreply.github.com>
DNS and Domain Registration Security file changes
…bpages); improve DNSSEC, MTA-STS, DMARC, registry lock, RDAP; update sidebar
…add monitoring/IR details
|
Friendly reminder to pull from develop, and resolve all comments when they are ready! |
Changes summary
Frameworks PR Checklist
If you are touching an existing piece of content, tag current contributors from the attribution list: Added Raiders0786 as primary contributor to both page frontmatter and contributors.json
If there is a steward for that framework, ask the steward to review it: I'm the steward for infrastructure/DNS security, will request review from infrastructure or security stewards via discord
If you're modifying the general outline, make sure to use
src/config/SUMMARY.developand notsrc/SUMMARY.md: No outline modifications made, only content enhancements within existing frameworkIf you need feedback for your content from the wider community, share the PR in our Discord: Will share in
framework-reviewersDiscord channelReview changes to ensure there are no typos, see instructions below: Manual review completed for typos and formatting consistency