Add Dangling domains entry

WEB_SERVICE/DNS/_MEDIUM/DANGLING_DOMAINS/description.md

@@ -0,0 +1,100 @@
+Dangling domains occur when DNS records point to resources that are no longer active or under the organization's control. These misconfigurations can lead to domain hijacking, data leakage, and reputation damage. The following areas are key concerns in dangling domain management:
+
+## 1. Cloud Resource References
+DNS records pointing to deprovisioned cloud resources pose significant risks. Common misconfigurations include:
+* Orphaned CNAME records pointing to terminated cloud services
+* A records targeting released IP addresses
+```bash
+# Dangerous Dangling Record
+app.example.com.    IN CNAME   terminated-app.cloudservice.com.
+api.example.com.    IN A       203.0.113.0   # Released IP
+
+# Proper Decommissioning
+# 1. Remove DNS record before releasing resource
+# 2. Or replace with controlled placeholder
+app.example.com.    IN CNAME   service-offline.example.com.
+```
+
+## 2. Third-Party Service Integration
+Records pointing to discontinued third-party services create security vulnerabilities:
+* Abandoned subdomain delegations
+* Expired service endpoints
+```bash
+# Risky Configuration
+analytics.example.com.   IN CNAME   client-xyz.analytics-service.com.    # Service discontinued
+track.example.com.      IN CNAME   example.abandoned-tracker.com.        # Company defunct
+
+# Safe Configuration
+# Always maintain internal inventory of service dependencies
+analytics.example.com.   IN CNAME   active-client.current-service.com.
+```
+
+## 3. Subdomain Management
+Improper subdomain cleanup leads to potential takeover scenarios:
+* Forgotten development/staging environments
+* Legacy application subdomains
+* Inactive project environments
+```bash
+# Vulnerable Subdomains
+dev.example.com.        IN CNAME   old-project.github.io.        # Repository deleted
+stage.example.com.      IN CNAME   staging.heroku.com.          # App removed
+beta.example.com.       IN A       198.51.100.1                 # Server decommissioned
+
+# Proper Record Management
+# Regular audit and removal of inactive subdomains
+dev.example.com.        IN A       203.0.113.10                 # Internal development server
+staging.example.com.    IN CNAME   current-stage.example.com.   # Active staging environment
+```
+
+## 4. Mail Server Records
+Abandoned mail-related records can lead to email spoofing and phishing:
+* Outdated MX records
+* Deprecated mail server references
+```bash
+# Dangerous Mail Configuration
+example.com.    IN MX    10 legacy-mail.example.com.    # Server decommissioned
+mail.example.com.   IN A    203.0.113.50               # Released IP
+
+# Secure Configuration
+example.com.    IN MX    10 primary-mail.example.com.
+example.com.    IN MX    20 backup-mail.example.com.
+```
+
+## 5. Certificate Validation Records
+Abandoned domain validation records pose security risks:
+* Outdated ACME challenge records
+* Forgotten domain validation CNAME records
+```bash
+# Risky Validation Records
+_acme-challenge.example.com.    IN TXT    "abandoned-validation-token"
+validate.example.com.          IN CNAME   validate.oldcertprovider.com.
+
+# Clean Configuration
+# Remove validation records after certificate issuance
+# Use automated certificate management
+```
+
+## 6. Service Discovery Records
+Obsolete service discovery entries can expose internal infrastructure:
+* SRV records for discontinued services
+* Legacy service endpoint references
+```bash
+# Exposed Service Records
+_ldap._tcp.example.com.    IN SRV    0 0 389 old-dc.example.com.
+_xmpp._tcp.example.com.    IN SRV    0 0 5222 chat.example.com.
+
+# Proper Clean-up
+# Remove or update service records when decommissioning
+_ldap._tcp.example.com.    IN SRV    0 0 389 current-dc.example.com.
+```
+
+---
+
+These dangling domain misconfigurations can result in severe security incidents, including:
+* Domain takeover attacks
+* Data exfiltration through hijacked endpoints
+* Phishing campaigns using legitimate domains
+* Brand reputation damage
+* Exposure of internal infrastructure details
+
+Organizations should implement regular DNS auditing, maintain service inventories, and follow proper decommissioning procedures to prevent dangling domain vulnerabilities.

WEB_SERVICE/DNS/_MEDIUM/DANGLING_DOMAINS/meta.json

@@ -0,0 +1,30 @@
+{
+  "risk_rating": "medium",
+  "short_description": "A vulnerability where DNS records point to deprovisioned cloud resources, terminated services, or inactive endpoints, enabling potential domain hijacking and unauthorized control of subdomains.",
+  "references": {
+    "Dangling Domains: Security Threats, Detection and Prevalence": "https://unit42.paloaltonetworks.com/dangling-domains/",
+    "Dangling DNS and the dangers of subdomain hijacking": "https://www.spamhaus.org/resource-hub/dns/dangling-dns-and-the-dangers-of-subdomain-hijacking/#exploiting-spf-in-txt-records-for-hijacked-domains",
+    "Dangling DNS Record": "https://attaxion.com/glossary/dangling-dns-record/"
+  },
+  "title": "DNS Vulnerability: Dangling Domain Records",
+  "privacy_issue": true,
+  "security_issue": true,
+  "categories": {
+    "SOC2_CONTROLS": [
+      "CC_6_1",
+      "CC_6_6",
+      "CC_6_7",
+      "CC_6_8",
+      "CC_7_1",
+      "CC_7_2",
+      "CC_8_1"
+    ],
+    "CCPA": [
+      "CCPA_1798_150"
+    ],
+    "GDPR": [
+      "ART_25",
+      "ART_32"
+    ]
+  }
+}

WEB_SERVICE/DNS/_MEDIUM/DANGLING_DOMAINS/recommendation.md

@@ -0,0 +1,47 @@
+To mitigate the risks associated with dangling domains, consider the following recommendations:
+
+- **Start with Domain Inventory:** Begin with a comprehensive audit of all domains and subdomains:
+  ```bash
+  # Example Domain Inventory Format
+  domain: example.com
+  subdomains:
+    - app.example.com -> AWS CloudFront
+    - api.example.com -> Azure App Service
+    - mail.example.com -> Google Workspace
+  owner: DevOps Team
+  ```
+
+- **Implement Progressive Monitoring Levels:** Scale monitoring based on domain criticality:
+  | Domain Type          | Check Frequency | Reason                          |
+  |---------------------|-----------------|----------------------------------|
+  | Production Critical | Every 5 min     | Business-critical services      |
+  | Customer Facing     | Every 15 min    | Customer experience impact      |
+  | Internal Tools      | Every hour      | Internal operations support     |
+  | Development         | Every 6 hours   | Non-critical environments       |
+
+- **Regular Domain Auditing:**
+  * Validate all cloud resource connections
+  * Check third-party service dependencies
+  * Verify DNS record accuracy
+  * Monitor subdomain certificates
+
+- **Security Best Practices:**
+  * Use dedicated cloud credentials for DNS management
+  * Implement strict RBAC for DNS changes
+  * Enable audit logging for all DNS modifications
+  * Maintain DNS change approval workflows
+
+- **Operational Procedures:**
+  * Document all domain ownership details
+  * Create service decommissioning checklists
+  * Maintain cloud resource mapping
+  * Test domain takeover prevention measures
+
+- **Planned Decommissioning Strategy:**
+  1. Start with resource identification
+  2. Document all dependencies
+  3. Monitor for active connections
+  4. Remove DNS records
+  5. Archive configuration details
+
+These recommendations help ensure proper domain management and prevent dangling domain vulnerabilities while maintaining operational efficiency.