skip to content

Reading the DNSSEC record 'example.net. 3600 IN DNSKEY 257 3 13 ...', what do the flags, protocol and algorithm fields tell you?

level: middleimportance: should knowfreq 20%

answer

  1. two bits that matter
  2. a hint validators ignore
  3. a constant kept for history
  4. 8, 13, 15 versus 5 and 7

basics

~20 s

Flags 257 means a zone key (256) with the Secure Entry Point bit (1), the usual KSK marking; protocol is always 3; algorithm 13 is ECDSAP256SHA256. The key tag is not stored but computed from the record.

solid answer

~50 s

The flags field is 16 bits: bit 7 is the **Zone Key** flag (value 256) and bit 15 the **Secure Entry Point** flag (value 1), so `257` is a zone key marked as an entry point — by convention the KSK — and `256` a plain zone key, usually a ZSK. RFC 4034 makes SEP only a hint: validators MUST NOT change their behaviour because of it, and a single combined key is legal. The protocol field MUST be `3`; any other value makes the key invalid. The algorithm field names the signing algorithm: `8` RSASHA256, `13` ECDSAP256SHA256, `15` ED25519 are the RECOMMENDED choices in the IANA registry RFC 9904 set up, while RFC 9905 says `5` and `7` (RSA/SHA-1) MUST NOT be used for new keys. The key tag that RRSIG and DS records quote is computed from this RDATA, not stored in it.

go deeper

for a junior

Recall that 257 marks the key-signing key and 256 the zone-signing key, and that the protocol field is always 3.

for a middle

Explain the two flag bits, that SEP is only a hint, which algorithm numbers are current, and that the key tag is computed from the record.

for a senior

Spot a DNSKEY that cannot work: a zero Zone Key bit, a protocol other than 3, a SHA-1 algorithm on a new key, or flags changed after the DS was built.

for a principal

Weigh algorithm choice across an estate: what RFC 9905's SHA-1 deprecation forces, and why the registry now carries the guidance instead of a fixed RFC.

## The layout A `DNSKEY` record (type 48, RFC 4034 §2) has four RDATA fields: | Field | Size | Presentation | Meaning | |---|---|---|---| | Flags | 2 octets | `0`, `256` or `257` in RFC 4034 | Which flag bits are set | | Protocol | 1 octet | always `3` | Fixed value kept from the older KEY record | | Algorithm | 1 octet | number or mnemonic | Signing algorithm and the format of the key field | | Public Key | variable | Base64 | The key material | ## The flags field, bit by bit RFC 4034 numbers bits from 0 (most significant) to 15 (least significant), so each named bit has a decimal value: - **Bit 7, Zone Key, value 256.** Set means the record holds a DNS zone key and its owner name MUST be a zone name. Clear means some other kind of key that MUST NOT be used to verify RRSIGs. - **Bit 15, Secure Entry Point (SEP), value 1.** Set marks a key intended as the target of a parent's DS or as a trust anchor. It is "only intended to be a hint": validators MUST NOT alter their behaviour based on it, and a SEP key without the Zone Key bit cannot legally sign. - **Bit 8, REVOKE, value 128**, was added later by RFC 5011 for trust-anchor updates; a revoked key therefore reads `385`. - All other bits are reserved: zero on creation, ignored on receipt. So `256` is a zone key without SEP (the usual zone-signing key) and `257` is a zone key with SEP (the usual key-signing key). The split itself is **operational practice**, not protocol: RFC 6781 calls a key that does both jobs a Single-Type Signing Scheme and suggests setting SEP on every key in that case. ## The protocol field RFC 4034 §2.1.2: the field MUST be `3`, and a DNSKEY with any other value MUST be treated as invalid during verification. It survives only for compatibility with the early KEY record. It carries no information, which is exactly why interviewers ask about it. ## The algorithm field The number names the algorithm and fixes the key format. The ones to recognise: | Number | Mnemonic | Defined in | Signing status in the IANA registry | |---|---|---|---| | 5 | RSASHA1 | RFC 4034 Appendix A.1 | MUST NOT (RFC 9905) | | 7 | RSASHA1-NSEC3-SHA1 | RFC 5155 | MUST NOT (RFC 9905) | | 8 | RSASHA256 | RFC 5702 | RECOMMENDED | | 13 | ECDSAP256SHA256 | RFC 6605 | RECOMMENDED | | 15 | ED25519 | RFC 8080 | RECOMMENDED | RFC 9904 obsoleted RFC 8624 and moved the "use for signing" and "use for validation" guidance into columns of the IANA registries; RFC 9905 then set the two SHA-1 algorithms to MUST NOT for creating DNSKEY and RRSIG records, while validator software must still be able to check them because some zones still use them; RFC 9905 also tells resolver operators to treat them as unsupported, so such zones end up validated as insecure. ## The key tag: computed, not stored RRSIG and DS records refer to a key by a 16-bit **key tag** (RFC 4034 Appendix B). It is computed by summing the DNSKEY RDATA in 2-octet groups and folding the carry. Consequences worth stating: 1. Because flags are part of the RDATA, changing a key's flags (256 to 257, or setting REVOKE) changes its key tag. 2. The key tag is **not unique**: two keys can share one, and implementations MUST NOT assume otherwise — a validator tries every matching key. 3. Tools print it as a comment beside the record; it never appears in the DNSKEY wire format. ## Reading the example `example.net. 3600 IN DNSKEY 257 3 13 ...` is a zone key for `example.net` with SEP set, the fixed protocol 3, signing with ECDSA P-256 and SHA-256. It is very likely the key the parent's DS points at — but only the DS itself proves which key that is.

  • If a zone signs everything with one combined key, what flags should that DNSKEY carry?
    257. RFC 6781 suggests setting SEP on all keys when no KSK/ZSK distinction is made, so the key the DS points to is marked as an entry point. The protocol does not require a split, and validators ignore SEP, so the choice affects tooling and readability, not validation.
  • Why does republishing a DNSSEC key with flags 257 instead of 256 break a DS that already points at it?
    The key tag and the DS digest are both computed over the full DNSKEY RDATA, and the flags are part of it. Changing the flags yields a new key tag and a new digest, so the existing DS no longer matches any key in the child's DNSKEY RRset.

saying these in an interview costs you the question

  • Validators accept DNSKEY RRset signatures only from keys with the SEP flag.
  • The protocol field may hold values other than 3 for other key uses.
  • The key tag is a field stored inside the DNSKEY record.
  • A key tag uniquely identifies one key within a zone.
  • RSA/SHA-1, algorithm 5, is still a reasonable choice for new signing keys.
  • The DNSSEC protocol requires every zone to have a separate KSK and ZSK.