Skip to content

Commit 5c54aa2

Browse files
Raiders0786Raiders0786
committed
testing
1 parent ca520e0 commit 5c54aa2

File tree

1 file changed

+270
-0
lines changed

1 file changed

+270
-0
lines changed

‎docs/pages/infrastructure/dns-and-domain-registration.mdx‎

Lines changed: 270 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,270 @@
1+
---
2+
title: "DNS and Domain Registration Security"
3+
tags:
4+
- Engineer/Developer
5+
- Security Specialist
6+
- Operations & Strategy
7+
contributors:
8+
- role: wrote
9+
users: [Raiders0786]
10+
---
11+
12+
import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components'
13+
14+
<TagProvider>
15+
<TagFilter />
16+
17+
# DNS and Domain Registration Security
18+
19+
<TagList tags={frontmatter.tags} />
20+
<AttributionList contributors={frontmatter.contributors} />
21+
22+
DNS (Domain Name System) is the backbone of the internet, translating domain names into IP addresses. In Web3, domain security is particularly critical as compromised domains can lead to irreversible financial losses through wallet drainers and phishing attacks. Unlike traditional web applications where stolen funds can sometimes be recovered, blockchain transactions are permanent, making domain security a matter of financial survival for Web3 projects.
23+
24+
## Understanding the Attack Surface
25+
26+
### How DNS Resolution Works
27+
When users type your domain, their request traverses multiple trust points:
28+
1. Local device cache
29+
2. ISP DNS resolver
30+
3. Root nameservers
31+
4. TLD registry servers
32+
5. Your authoritative nameservers
33+
34+
Each step represents a potential attack vector 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.
35+
36+
### Common Attack Vectors
37+
- **Social Engineering at Registrars**: Attackers convince support staff they're legitimate owners using publicly available information
38+
- **Expired Domain Sniping**: Domains that expire enter a grace period before becoming publicly available to anyone
39+
- **DNS Hijacking**: Unauthorized changes to DNS records redirecting traffic to malicious servers
40+
- **Email Interception**: Compromised MX records allowing password reset attacks and communication interception
41+
- **DNS Tunneling**: Encoding data within DNS queries for covert communication channels, often used for data exfiltration
42+
43+
## DNS-Level Security
44+
45+
### DNSSEC Implementation
46+
DNSSEC provides cryptographic authentication of DNS responses.
47+
48+
1. **Enable DNSSEC signing** at your DNS provider
49+
2. **Publish DS records** to your registrar
50+
3. **Monitor DNSSEC validation** status regularly
51+
4. **Test configuration** using tools like DNSViz or Verisign DNSSEC Debugger
52+
53+
### CAA Records
54+
Certificate Authority Authorization records specify which CAs can issue certificates for your domain.
55+
56+
```dns
57+
example.com. CAA 0 issue "letsencrypt.org"
58+
example.com. CAA 0 issue "digicert.com"
59+
example.com. CAA 0 iodef "mailto:security@example.com"
60+
```
61+
62+
### Email Security Configuration
63+
64+
#### SPF (Sender Policy Framework)
65+
```dns
66+
example.com. TXT "v=spf1 include:_spf.google.com ~all"
67+
```
68+
69+
#### DMARC (Domain-based Message Authentication)
70+
```dns
71+
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com"
72+
```
73+
74+
#### DKIM (DomainKeys Identified Mail)
75+
Configure with your email provider and publish public keys in DNS.
76+
77+
#### MTA-STS (Mail Transfer Agent Strict Transport Security)
78+
```dns
79+
_mta-sts.example.com. TXT "v=STSv1; id=20240101000000"
80+
```
81+
82+
## Registrar Security
83+
84+
### Choosing a Secure Registrar
85+
86+
#### Enterprise-Grade Registrars (Recommended)
87+
- **MarkMonitor**: Used by Fortune 500 companies, requires legal documentation for changes
88+
- **CSC (Corporation Service Company)**: Registry-level domain locks, dedicated account management
89+
- **AWS Route53**: IAM policy integration, CloudTrail logging, uses Amazon Registrar for major TLDs
90+
- **Cloudflare Registrar**: No markup pricing, automatic DNSSEC, built-in DDoS protection
91+
92+
#### Consumer Registrars to Avoid for Critical Domains
93+
- GoDaddy (history of social engineering vulnerabilities)
94+
- Consumer-focused services (Google Domains/Squarespace)
95+
- Resellers (additional attack surface)
96+
97+
### Registrar-Level Protections
98+
99+
#### 1. Registry Lock (EPP Lock)
100+
Registry lock prevents unauthorized transfers at the registry level, not just the registrar.
101+
- **What it does**: Requires manual verification with the registry for any changes
102+
- **How to enable**: Contact enterprise registrars for registry-operator level locks
103+
- **Note**: Different from standard transfer locks which only prevent transfers between registrars
104+
105+
#### 2. Multi-Factor Authentication
106+
- **Hardware Security Keys** (YubiKey/FIDO2): Most secure option
107+
- **TOTP Applications**: Minimum acceptable standard
108+
- **Avoid SMS 2FA**: Vulnerable to SIM swapping
109+
110+
#### 3. Dedicated Security Contact Email
111+
```
112+
❌ admin@yourdomain.com (circular dependency)
113+
❌ personal@gmail.com (too many attack vectors)
114+
✅ domain-security-only@protonmail.com (isolated, dedicated purpose)
115+
```
116+
117+
#### 4. Access Control Best Practices
118+
- Document all personnel with registrar access
119+
- Use role-based access where available
120+
- Implement approval workflows for critical changes
121+
- Regular access audits (quarterly minimum)
122+
123+
## Monitoring and Detection
124+
125+
### DNS Record Monitoring
126+
Watch for these warning signs:
127+
- Nameserver (NS) record changes
128+
- TTL values dropping below 300 seconds
129+
- New A/AAAA records or changes to existing ones
130+
- MX record modifications
131+
- CAA record removal
132+
- DNSSEC disabled unexpectedly
133+
134+
### Certificate Transparency Monitoring
135+
- Monitor CT logs for unauthorized certificate issuance
136+
- Set up alerts for new certificates via services like crt.sh monitoring
137+
- Watch for wildcard certificates if you don't use them
138+
139+
### Passive DNS Monitoring
140+
Track historical DNS resolution data to detect:
141+
- Brief record changes (often missed in periodic checks)
142+
- Geographic anomalies in resolved IPs
143+
- Suspicious hosting provider changes
144+
145+
## Setting Up Alerts
146+
147+
### Critical Alerts (Immediate Response Required)
148+
149+
1. **Registrar Changed**
150+
- **What it monitors**: Changes to your domain's registrar
151+
- **Why it's critical**: Indicates potential domain hijacking or unauthorized transfer
152+
- **Response**: Immediate verification and potential incident response activation
153+
154+
2. **Nameserver Changed**
155+
- **What it monitors**: Changes to nameserver records
156+
- **Why it's critical**: Attackers often change nameservers to redirect traffic to malicious servers
157+
- **Response**: Verify legitimacy, check if you initiated the change
158+
159+
3. **DNSSEC Broken**
160+
- **What it monitors**: DNSSEC validation failures or disabled DNSSEC
161+
- **Why it's critical**: DNS responses can be tampered with, leading to man-in-the-middle attacks
162+
- **Response**: Investigate signing issues, check for configuration changes
163+
164+
4. **CAA Records Removed**
165+
- **What it monitors**: Removal of Certificate Authority Authorization records
166+
- **Why it's critical**: Allows any CA to issue certificates for your domain, enabling SSL certificate attacks
167+
- **Response**: Restore CAA records immediately, investigate who removed them
168+
169+
5. **TTL Drop Under 60 Seconds**
170+
- **What it monitors**: Time-to-live values dropping below 60 seconds
171+
- **Why it's critical**: Very low TTLs can indicate preparation for rapid DNS changes (attack preparation)
172+
- **Response**: Investigate why TTL was lowered, verify it's legitimate
173+
174+
### High Priority Alerts (Investigate Within Hours)
175+
176+
1. **A Record Changed**
177+
- **What it monitors**: Changes to IP address mappings
178+
- **Why it's important**: Could redirect users to malicious servers
179+
- **Response**: Verify the new IP address is legitimate and expected
180+
181+
2. **MX Record Changed**
182+
- **What it monitors**: Changes to mail server configurations
183+
- **Why it's important**: Could intercept emails, including password reset messages
184+
- **Response**: Verify mail server changes are authorized
185+
186+
3. **DMARC Policy Weakened**
187+
- **What it monitors**: Changes from "reject" to "quarantine" or "none"
188+
- **Why it's important**: Weaker policies allow more spoofed emails to reach users
189+
- **Response**: Investigate why policy was weakened, restore if unauthorized
190+
191+
4. **Unexpected Certificate Issued**
192+
- **What it monitors**: New SSL certificates issued for your domain
193+
- **Why it's important**: Could indicate certificate-based attacks or unauthorized issuance
194+
- **Response**: Verify the certificate was requested by your team, revoke if unauthorized
195+
196+
## Incident Response Plan
197+
198+
### Immediate Response
199+
1. **Verify the compromise** - Check DNS records via multiple resolvers
200+
2. **Access registrar account** - Attempt login, check for lockout
201+
3. **Contact registrar security team** - Use pre-documented emergency contacts
202+
4. **Document everything** - Screenshot all current settings
203+
204+
### Containment
205+
1. **Invoke registry lock** if available
206+
2. **Update NS records** if you maintain access
207+
3. **Warn users** via social media/status page
208+
4. **Contact law enforcement** if significant theft occurred
209+
210+
### Recovery
211+
1. **Regain control** through registrar security procedures
212+
2. **Audit all DNS records** against known-good baseline
213+
3. **Reset all credentials** for registrar and DNS hosting
214+
4. **Review access logs** to understand attack vector
215+
216+
### Post-Incident
217+
1. **Conduct thorough investigation**
218+
2. **Update security measures** based on lessons learned
219+
3. **Consider legal action** if appropriate
220+
4. **Publish transparency report** to rebuild trust
221+
222+
223+
## Web3-Specific Considerations
224+
225+
### Why Domain Security is Critical in Web3
226+
- **Irreversible transactions**: Stolen funds cannot be reversed
227+
- **Direct wallet interactions**: Users connect wallets directly to your domain
228+
- **Smart contract immutability**: Contracts can't help if users never reach them
229+
- **Reputation damage**: One incident can permanently destroy protocol trust
230+
231+
### Additional Web3 Protections
232+
- Consider ENS domains as backup communication channels
233+
- Implement multiple warning channels (Twitter, Discord, Telegram)
234+
- Use IPFS or other decentralized hosting for critical security notices
235+
- Maintain cryptographically signed DNS record hashes on-chain
236+
237+
## Historical Context
238+
239+
### Notable Domain Security Incidents
240+
Domain hijacking has impacted numerous Web3 projects:
241+
- **[Curve Finance (2022)](https://rekt.news/curve-finance-rekt)**: DNS hijacking led to $575k in stolen funds through frontend compromise
242+
- **[Galxe (2023)](https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide)**: DNS hijack resulted in over 1,100 wallets drained for $270k
243+
- **[Compound Finance (2024)](https://www.bitget.com/news/detail/12560604092919#:~:text=The%20attack%20was%20first%20detected%20when%20users,to%20access%20Compound%20Finance%27s%20interface%20at%20compound.)**: Domain takeover attempt prevented by registry lock
244+
245+
These incidents highlight the critical importance of proper domain security measures.
246+
247+
## References and Resources
248+
249+
### Tools
250+
- [DNSViz](https://dnsviz.net/) - DNSSEC visualization and debugging
251+
- [Certificate Transparency Search](https://crt.sh/) - Monitor certificate issuance
252+
- [DNS Dumpster](https://dnsdumpster.com/) - DNS reconnaissance tool
253+
- [MXToolbox](https://mxtoolbox.com/) - DNS and email configuration testing
254+
- [Passive DNS](https://passivedns.mnemonic.no/) - Historical DNS resolution data
255+
256+
### Incident Response Contacts
257+
- [SEAL Alliance](https://www.securityalliance.org/contact) - Web3 emergency response team
258+
- Your registrar's security team (document contact info)
259+
- Local FBI/law enforcement cybercrime division
260+
261+
### Standards and Best Practices
262+
- [NIST Special Publication 800-81-2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf) - Secure Domain Name System Deployment Guide
263+
- [ICANN DNSSEC Resources](https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en)
264+
- [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461) - MTA-STS specification
265+
- [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489) - DMARC specification
266+
- [DNS Security in Web3: Attacks & Monitoring Setup Explained](https://web3secnews.substack.com/p/the-hidden-dns-threats-that-could) - Comprehensive Web3 DNS security guide
267+
268+
---
269+
</TagProvider>
270+
<ContributeFooter />

0 commit comments

Comments
 (0)