Summary

  • The DNSKEY SEP bit marks intended operational use. It may help with parent-side DS workflows or signing and debugging software, but it is not a credential and does not establish a trust chain.
  • RFC 4034 and RFC 4035 preserve a hard boundary: validators must not change signature-validation behavior because bit 15 is set. A SEP-marked key still needs the Zone Key flag to verify RRset signatures.
  • Edward Lewis coauthored RFC 3757 with Olaf Kolkman and Jakob Schlyter. The record supports attribution of that standards contribution, not sole authorship, implementation credit or current employment claims.

DNSSEC has to connect two different kinds of statement. One is operational: an administrator may intend a key to serve a particular role, or may want a tool to present it for a particular task. The other is cryptographic: a validator must establish that signatures and key relationships satisfy the protocol. The Secure Entry Point bit, or SEP, belongs to the first category. Its narrow purpose makes it useful; treating it as if it belonged to the second would give one bit authority it does not have.

The original specification, RFC 3757, was published in April 2004 by Olaf Kolkman, Jakob Schlyter and Edward Lewis. It introduced the SEP flag in the DNSKEY flags field to identify keys intended to act as secure entry points. The document describes two operational uses: assisting procedures that generate Delegation Signer (DS) records, and identifying keys that an operator intends to configure statically. It also states that SEP is not used by the DNS verification protocol. That sentence marks the limit of the mechanism as clearly as its name marks its intended role.

The handoff begins in the child zone. The zone publishes DNSKEY records, and the SEP bit can express the operator’s intended handling of one or more of them. In a common arrangement, a key used for the Key Signing Key role is marked SEP, while a Zone Signing Key is not. An operator or a signing tool may use that distinction to identify the key that should be considered when preparing parent-side information. Yet the published bit is only an assertion of intended use. A parent must still obtain the correct DS material, verify that it corresponds to the child’s key, and publish the required parent-side record through its own process.

SEP cannot perform that comparison or certify that the parent accepted the intended key.

The next handoff is from key management to signature validation. RFCs 4034 and 4035, both published in March 2005, obsolete RFC 3757 and retain SEP in the DNSKEY model. RFC 4034 describes bit 15 as the SEP flag and as a hint for zone-signing or debugging software. RFC 4035 supplies the crucial validator rule: validation behavior MUST NOT change because the SEP bit is set. The same record model also distinguishes SEP from the Zone Key flag. A DNSKEY marked SEP still needs the Zone Key flag to be eligible to verify signatures over resource-record sets.

The two flags answer different questions: SEP indicates intended operational treatment; Zone Key indicates eligibility for a protocol role in signature verification.

That separation blocks a tempting but invalid inference. Seeing SEP on a DNSKEY does not prove that the key belongs to the zone, that a parent has established the DS relationship, or that any particular signature is valid. Conversely, a validator cannot treat a clear SEP bit as a reason to reject an otherwise valid signature. The bit is not a shortcut in either direction. The cryptographic chain, algorithm and protocol checks remain decisive under the relevant DNSSEC rules.

RFC 6781 explains why the distinction still matters to operators even though SEP has no validation role. It describes a common convention in which SEP is set on keys used for parent exchanges or possible trust-anchor configuration, usually KSKs, rather than ZSKs. It also discusses a single-type signing scheme, in which the same type of key handles functions that a split KSK/ZSK model would assign separately. In such a scheme, setting SEP consistently on all keys may be appropriate.

The operational hazard is not that the resolver changes its mathematics; it is that software built around an assumed split may classify, display or process keys in ways that do not match the deployment. RFC 6781 warns that some signing tools may become confused by a single-type scheme.

This is where the boundary becomes a design question rather than a flag question. A protocol can define a hint without making every tool interpret it well. The standard limits what a validator may do, while a signer or operator interface can still embody conventions about which key should be submitted, exported or checked. A deployment review should therefore ask what the actual tool does with SEP, which records it selects, and whether its output is independently checked against the intended DNSKEY and DS values. Those are prudent operational controls, not additional requirements stated by the RFCs.

The bit must also be kept separate from RFC 5011. That RFC defines an automated trust-anchor update mechanism with its own state and uses a distinct DNSKEY flag, REVOKE, in that mechanism. SEP may be used operationally in contexts that involve key roles, and RFC 6781 notes its relationship to RFC 5011 rollover practice; that does not make SEP the revocation signal or the trust-anchor update rule. One flag communicates intended key handling; the other participates in a separately specified state machine. Confusing them would collapse distinct purposes and create an unsafe reading of the record.

Edward Lewis’s place in this history is bounded by the primary record. RFC 3757 lists him as one of three coauthors. His IETF Datatracker profile records the RFC among his standards work, while his Internet Society Pulse byline page supplies limited public career context. These sources support saying that Lewis contributed to the specification. They do not show that he alone designed the bit, decided how all later standards would use it, or implemented a particular DNSSEC deployment. The RFC’s listing of ARIN is a historical affiliation, not evidence of current employment.

The record also has a clear empirical boundary. The RFCs describe intended semantics, normative behavior and a possible source of tool confusion. They do not measure how often operators rely on SEP, how many tools assume a split, whether any resolver has altered validation because of the bit, or how often a DS workflow has failed. No incident rate or deployment outcome can be inferred from the existence of the specification. A careful account can explain why the boundary matters without claiming that a failure occurred.

The most useful way to read SEP is therefore modest and precise: it is a label for operational intention that can help a human or tool manage keys. Its presence does not confer authority. The record can say how an operator wants a key handled; the cryptographic checks and parent-side process must establish what the network can trust.

Sources