Verifying answers from this node

Everything on this page you can check yourself in under a minute. If any of it does not behave as described, that is a real problem and we would like to hear about it.

1. Is the answer authoritative?

Ask this node directly, with recursion disabled, and look for the aa flag in the response header. An authoritative server sets it; a cache does not.

$ dig +norecurse @ns2.clouderra.ru clouderra.ru SOA

;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr aa                    <- aa must be present
;; ANSWER SECTION:
clouderra.ru.   IN  SOA  a.ns.selectel.ru. ...

+norecurse matters. Without it a misconfigured resolver in the path can answer on this node's behalf and you will be looking at a cached record while believing you queried us. If the aa flag is missing, you did not reach this node.

2. Does recursion leak?

It must not. Asking this node about a zone it does not hold has to produce a refusal, not an answer. An authoritative server that answers for the whole internet is an open resolver and a liability to everyone.

$ dig @ns2.clouderra.ru example.com A

;; ->>HEADER<<- opcode: QUERY, status: REFUSED
;; flags: qr                        <- no ra, no aa, no answer section

REFUSED is the correct outcome. If you ever get a real answer for a zone we do not host, report it to security@clouderra.ru and we will treat it as an incident rather than a support question.

3. Does this copy match the primary?

Compare serials. The standby is allowed to lag by up to one refresh interval; a persistent difference means the transfer is broken and the node should not be promoted.

$ for s in a.ns.selectel.ru ns2.clouderra.ru; do
>   echo -n "$s "; dig +short +norecurse @$s clouderra.ru SOA | awk '{print $3}'
> done

Both numbers should be equal, or the second one lower by exactly the number of changes made in the last few minutes. A second serial that is higher than the primary's is never correct and means someone edited data on the secondary by hand.

4. Is TCP available?

Authoritative service over TCP is not optional — responses larger than the UDP limit depend on it, and a firewall that passes UDP 53 while dropping TCP 53 produces failures that look like random timeouts.

$ dig +tcp +norecurse @ns2.clouderra.ru clouderra.ru NS

5. Rate limiting

Identical queries repeated from one source are truncated with the TC bit or dropped outright. This is response rate limiting and it is deliberate: it makes this node useless as a reflector in an amplification attack. A legitimate resolver retries over TCP and succeeds; a spoofed flood does not.

If you are running a measurement study and the limiter is in your way, mail noc@clouderra.ru with your source prefixes and the window you need, and we will exempt you rather than have you work around it.

What this page is not

It is not a diagnostic tool for your own resolver. If a name in one of our zones does not resolve for you but the checks above pass, the problem is between your resolver and the servers in the delegation — and this node, being outside the delegation, is not part of that path. Start with dig +trace from your side.