# Security Considerations

This document describes the security considerations for DNS-AID (DNS-based Agent Identification and Discovery) as specified in [draft-mozleywilliams-dnsop-bandaid](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-bandaid/).

## 1. Threat Model (STRIDE Analysis)

DNS-AID inherits security properties from DNS and adds agent-specific considerations. This analysis uses the STRIDE framework.

### 1.1 Threat Summary

| Threat | Attack Vector | Mitigation | Requirement Level |
|--------|---------------|------------|-------------------|
| **S**poofing | DNS cache poisoning, response forgery | DNSSEC validation | MUST |
| **T**ampering | Record modification in transit | DNSSEC signing | MUST |
| **R**epudiation | False agent claims | Domain verification | MUST |
| **I**nformation Disclosure | Zone enumeration | NSEC3 with opt-out | SHOULD |
| **D**enial of Service | DNS amplification, query floods | Rate limiting | MUST |
| **E**levation of Privilege | Unauthorized DNS updates | TSIG authentication | MUST |

### 1.2 Detailed Threat Analysis

#### 1.2.1 Spoofing: DNS Cache Poisoning

**Threat:** An attacker poisons a DNS resolver's cache with forged DNS-AID records, redirecting agent discovery to malicious endpoints.

**Attack Scenario:**
1. Attacker sends forged DNS responses with malicious SVCB records
2. Resolver caches the forged records
3. Legitimate agents connect to attacker-controlled endpoints
4. Attacker intercepts or manipulates agent communications

**Mitigation:**
- **DNSSEC Validation (MUST):** All DNS-AID implementations MUST validate DNSSEC signatures on returned records
- **DANE/TLSA (SHOULD):** Implementations SHOULD verify endpoint certificates via DANE

**Implementation:**
```python
# DNS-AID discovery MUST validate DNSSEC
async def discover_agent(fqdn: str) -> Agent:
    response = await resolver.query(fqdn, "SVCB")

    if not response.dnssec_validated:
        raise DNSSECValidationError(f"DNSSEC validation failed for {fqdn}")

    return parse_svcb_response(response)
```

#### 1.2.2 Tampering: Record Modification

**Threat:** An attacker modifies DNS-AID records in transit to redirect traffic or alter agent capabilities.

**Attack Scenario:**
1. Man-in-the-middle intercepts DNS queries
2. Attacker modifies SVCB target or TXT capabilities
3. Client receives tampered records

**Mitigation:**
- **DNSSEC Signing (MUST):** Domain operators MUST sign DNS-AID zones with DNSSEC
- **End-to-End Validation:** Clients MUST reject unsigned or invalid signatures

**Zone Configuration:**
```
; DNSSEC-signed zone file
$ORIGIN _agents.example.com.
$TTL 3600

; SVCB record with DNSSEC
_network._mcp  SVCB 1 mcp.example.com. alpn="mcp" port=443

; RRSIG will be generated by DNSSEC signing process
```

#### 1.2.3 Repudiation: False Agent Claims

**Threat:** A malicious party publishes DNS-AID records for agents they do not control, or denies publishing records.

**Attack Scenario:**
1. Attacker gains control of a domain's DNS
2. Attacker publishes records for fake agents
3. Users trust the fake agents based on domain reputation

**Mitigation:**
- **Domain Verification (MUST):** Directory services MUST verify domain ownership before indexing
- **DNSSEC Chain of Trust:** Valid DNSSEC provides non-repudiable proof of record publication
- **Audit Logging:** Implementations SHOULD maintain audit logs of record changes

**Verification Protocol:**
```
1. Domain owner submits domain for indexing
2. Directory generates unique verification token
3. Owner creates TXT record: _dns-aid-verify.example.com TXT "token=abc123"
4. Directory verifies TXT record via DNSSEC-validated query
5. Domain is marked as verified
```

#### 1.2.4 Information Disclosure: Zone Enumeration

**Threat:** An attacker enumerates all agents published in a zone by walking NSEC records.

**Attack Scenario:**
1. Attacker queries for non-existent name under _agents
2. NSEC response reveals next name in zone
3. Attacker iterates to discover all agent names

**Mitigation:**
- **NSEC3 (SHOULD):** Zone operators SHOULD use NSEC3 instead of NSEC
- **NSEC3 Opt-Out (SHOULD):** Large zones SHOULD use NSEC3 opt-out for unsigned delegations
- **Private Agents:** Sensitive agents SHOULD NOT be published in public DNS

**NSEC3 Configuration:**
```
; nsec3param generation
nsec3param 1 0 10 aabbccdd

; This prevents trivial zone enumeration while maintaining
; DNSSEC denial-of-existence proofs
```

#### 1.2.5 Denial of Service: DNS Amplification

**Threat:** An attacker uses DNS-AID queries for amplification attacks or overwhelms discovery services.

**Attack Scenarios:**
1. **Amplification:** Attacker sends spoofed queries; responses are larger than queries
2. **Query Flood:** Attacker floods resolver or authoritative server with queries
3. **Directory Exhaustion:** Attacker overwhelms the agent directory with crawl requests

**Mitigation:**
- **Rate Limiting (MUST):** All DNS-AID services MUST implement rate limiting
- **Response Rate Limiting (RRL):** Authoritative servers SHOULD enable DNS RRL
- **Query Minimization:** Clients SHOULD use QNAME minimization

**Rate Limiting Configuration:**
```yaml
# Directory API rate limits
rate_limits:
  search:
    requests_per_second: 10
    burst: 50
  submit:
    requests_per_hour: 100
    burst: 10
  crawl:
    domains_per_minute: 5
    concurrent: 10
```

#### 1.2.6 Elevation of Privilege: Unauthorized Updates

**Threat:** An attacker gains unauthorized ability to modify DNS-AID records.

**Attack Scenarios:**
1. Attacker compromises DNS provider credentials
2. Attacker exploits DDNS vulnerabilities
3. Attacker hijacks domain registration

**Mitigation:**
- **TSIG Authentication (MUST):** DDNS updates MUST use TSIG authentication
- **Least Privilege:** DNS update keys SHOULD be scoped to specific zones
- **Multi-Factor Authentication:** DNS provider accounts SHOULD use MFA
- **Certificate Pinning:** API integrations SHOULD pin provider certificates

**TSIG Configuration:**
```
; TSIG key for DDNS updates
key "dns-aid-update-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-secret";
};

; Zone update policy - restrict to _agents subtree only
zone "example.com" {
    update-policy {
        grant dns-aid-update-key subdomain _agents.example.com. ANY;
    };
};
```

## 2. Protocol-Specific Security

### 2.1 SVCB Record Security

**Requirements:**
- SVCB records MUST be DNSSEC-signed
- The `mandatory` parameter SHOULD include `alpn` for protocol enforcement
- Target endpoints MUST use TLS 1.2 or higher

**Secure SVCB Example:**
```
_network._mcp._agents.example.com. 3600 IN SVCB 1 mcp.example.com. (
    mandatory="alpn"
    alpn="mcp"
    port="443"
)
```

### 2.2 TXT Record Security

**Requirements:**
- TXT records MUST be DNSSEC-signed
- Capability values MUST be validated against known capabilities
- Version strings MUST follow semantic versioning

**Validation:**
```python
VALID_CAPABILITIES = {"chat", "code", "search", "image", "voice"}

def validate_capabilities(txt_record: str) -> list[str]:
    """Validate TXT record capabilities."""
    caps = parse_capabilities(txt_record)

    for cap in caps:
        if cap not in VALID_CAPABILITIES:
            raise ValueError(f"Unknown capability: {cap}")

    return caps
```

### 2.3 Endpoint Security

**Requirements:**
- Agent endpoints MUST use HTTPS with valid certificates
- Endpoints SHOULD support DANE/TLSA for certificate binding
- Endpoints MUST implement authentication for sensitive operations

**DANE/TLSA Verification:**
```
; TLSA record for certificate pinning
_443._tcp.mcp.example.com. TLSA 3 1 1 (
    2bb183af... ; SHA-256 hash of certificate
)
```

## 3. Operational Security

### 3.1 Key Management

| Key Type | Rotation Period | Storage |
|----------|-----------------|---------|
| DNSSEC KSK | 2 years | HSM recommended |
| DNSSEC ZSK | 30 days | Secure key store |
| TSIG keys | 90 days | Secrets manager |
| API keys | 90 days | Secrets manager |

### 3.2 Monitoring and Detection

**MUST Monitor:**
- DNSSEC validation failures
- Unusual query patterns (enumeration attempts)
- Failed authentication attempts
- Rate limit violations

**SHOULD Monitor:**
- Certificate changes for endpoints
- New agent registrations
- Capability changes

### 3.3 Incident Response

**DNS Compromise Response:**
1. Immediately rotate DNSSEC keys
2. Invalidate all TSIG keys
3. Audit all recent record changes
4. Notify affected parties
5. Publish incident report

## 4. Compliance Requirements

### 4.1 Requirement Levels

Per [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html):

| Requirement | Level | Rationale |
|-------------|-------|-----------|
| DNSSEC validation | MUST | Prevents spoofing and tampering |
| DNSSEC signing | MUST | Provides cryptographic authenticity |
| Domain verification | MUST | Prevents unauthorized claims |
| Rate limiting | MUST | Prevents denial of service |
| TSIG for updates | MUST | Prevents unauthorized modifications |
| NSEC3 | SHOULD | Mitigates zone enumeration |
| DANE/TLSA | SHOULD | Provides certificate binding |
| Audit logging | SHOULD | Enables forensic analysis |

### 4.2 Security Checklist

- [ ] DNSSEC enabled and validated on all queries
- [ ] TSIG keys configured for DDNS with minimum privileges
- [ ] Rate limiting implemented on all public endpoints
- [ ] TLS 1.2+ enforced on all agent connections
- [ ] Domain verification required before indexing
- [ ] Monitoring configured for security events
- [ ] Incident response plan documented

## References

- [RFC 4033](https://www.rfc-editor.org/rfc/rfc4033.html) - DNS Security Introduction and Requirements
- [RFC 4034](https://www.rfc-editor.org/rfc/rfc4034.html) - Resource Records for DNSSEC
- [RFC 4035](https://www.rfc-editor.org/rfc/rfc4035.html) - Protocol Modifications for DNSSEC
- [RFC 6698](https://www.rfc-editor.org/rfc/rfc6698.html) - DANE TLSA
- [RFC 8945](https://www.rfc-editor.org/rfc/rfc8945.html) - Secret Key Transaction Authentication for DNS (TSIG)
- [RFC 9460](https://www.rfc-editor.org/rfc/rfc9460.html) - SVCB and HTTPS Resource Records
