# DNS SERVFAIL evidence sheet for an event domain

Use this sheet to record observations before anyone changes DNSSEC, a nameserver delegation or a website record. Replace the example name; do not include credentials or attendee data.

**Event / affected flow:** ______  **Exact FQDN:** ______  **Record type (A, AAAA, CNAME, MX, TXT, etc.):** ______

**First observed (time and zone):** ______  **Reported by / location:** ______  **Incident owner:** ______

## 1. Record the same query at each layer

| Time | Resolver or authoritative nameserver queried | Exact name / type | Response code and answer | Extended DNS Error or tool detail | Notes |
| --- | --- | --- | --- | --- | --- |
| [time] | [affected network resolver] | [FQDN/type] | [SERVFAIL/etc.] | [detail] | [context] |
| [time] | [independent public resolver] | [same FQDN/type] | [result] | [detail] | [context] |
| [time] | [parent/delegated authoritative server] | [same FQDN/type] | [result] | [detail] | [context] |

Suggested read-only commands for an operator with `dig` (replace example values):

```sh
dig @1.1.1.1 tickets.example.org A
dig @8.8.8.8 tickets.example.org A
dig @ns1.example-dns.net tickets.example.org A
```

The addresses above are examples, not a requirement to use those resolvers. First confirm the domain's currently delegated authoritative nameservers. Do not publish or remove DNS records as part of evidence gathering.

## 2. Branch the investigation

- [ ] If one local network fails but independent resolvers succeed, involve its resolver or network administrator.
- [ ] If multiple validating resolvers fail, compare authoritative answers and recent delegation/registrar changes.
- [ ] If an authoritative server is unreachable or returns inconsistent answers, involve its DNS provider.
- [ ] If only validating queries fail, ask the DNSSEC owner to inspect parent DS, child DNSKEY, signatures and any Extended DNS Error.

The following is diagnostic only. A successful response when DNSSEC checking is disabled can point toward validation trouble. It is **not** a reason to leave DNSSEC disabled or delete a DS record without a reviewed change plan.

```sh
dig @1.1.1.1 tickets.example.org A +cd
```

## 3. Handoff and recovery record

**Recent DNS/registrar changes:** ______  **Current parent NS and DS:** ______

**Affected attendee steps:** event page ______, registration ______, ticket delivery ______, email ______.

**Likely owner based on evidence:** local resolver / authoritative DNS / DNSSEC-registrar / still unknown.

**Approved change and rollback owner:** ______  **Change time:** ______

**Repeat observations after change:** ______  **Attendee-path result:** ______  **Unresolved questions:** ______

Sources: [Google Public DNS domain troubleshooting](https://developers.google.com/speed/public-dns/docs/troubleshooting/domains), [Cloudflare DNSSEC troubleshooting](https://developers.cloudflare.com/dns/dnssec/troubleshooting/), [Amazon Route 53 DNSSEC troubleshooting](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-troubleshoot.html).