DNS

Cybersecurity / 24 Sep 2026 / 6 min read

NSEC3 Hashes DNSSEC Denial Records Without Hiding Guessable Names

A DNSSEC signature can authenticate data that exists, but a resolver also needs cryptographic evidence when a requested name or record type is absent. A plain unsigned NXDOMAIN response cannot provide that property: an attacker able to alter DNS traffic could fabricate the same response. NSEC3 supplies signed denial records while replacing clear-text owner names in the denial chain with hashes. RFC 5155 defines NSEC3 as an alternative to NSEC for authenticated denial of existence. Its main privacy-related distinction is narrow but useful: walking an NSEC chain directly reveals neighboring owner names, whereas NSEC3 exposes hashes that require additional work to map back to candidate names.

Cybersecurity DNSSEC

Cybersecurity / 24 Sep 2026 / 5 min read

DNS Cookies Bind UDP Requests to Return-Path Reachability

UDP lets a sender place a source address in a datagram without a transport handshake that proves the sender can receive traffic at that address. DNS inherits that property when it runs over UDP. An off-path attacker can therefore send a query with a forged source address and try to make a DNS server direct its response toward another host. DNS Cookies add a lightweight challenge-and-return mechanism inside EDNS. RFC 7873 defines the COOKIE option, while RFC 9018 tightens Server Cookie construction for interoperable deployments. The mechanism does not turn UDP into an authenticated transport. It gives DNS clients and servers additional evidence about whether a peer has participated in an earlier exchange at the relevant network address.

Cybersecurity DNS

Cybersecurity / 24 Sep 2026 / 5 min read

DNS Cookies Bind UDP Replies to Recent Client State

UDP gives DNS low-overhead transport, but its source address can be forged and its replies can be imitated by an off-path sender. DNS Cookies add a small piece of client-generated state and, after contact with a supporting server, server-generated state. The mechanism raises the cost of off-path forgery without requiring a server to keep a session table for every client. The mechanism is deliberately limited. RFC 7873 describes DNS Cookies as lightweight transaction security against off-path denial-of-service, amplification, forgery, and cache-poisoning attacks. It does not protect against an adversary that can observe the DNS exchange. RFC 9018 later tightened cookie construction so independently implemented anycast servers can interoperate.

Cybersecurity DNS

Cybersecurity / 24 Sep 2026 / 6 min read

CDS and CDNSKEY Automate DNSSEC Delegation Trust Updates

A DNSSEC-signed child zone can rotate its signing keys without changing the delegation immediately, but validators ultimately depend on the DS record set published by the parent. That parent-side state creates an operational handoff: a new key in the child does not become a secure delegation anchor merely because the child publishes it. CDS and CDNSKEY provide an in-band mechanism for that handoff. RFC 7344 defines records that a child can publish at its zone apex to signal prospective DS parameters. A parental agent can retrieve the signal, validate it under the applicable rules, apply local acceptance policy, and update the parent-side DS set.

Cybersecurity DNSSEC

Cybersecurity / 24 Sep 2026 / 6 min read

CAA Records Constrain Public Certificate Issuance

A public certificate authority does more than validate control of a DNS name. Before issuing a certificate, a CA that follows the CAA specification also checks DNS for a Certification Authority Authorization policy relevant to each requested name. That policy can narrow the set of issuers permitted to create certificates for the domain. CAA is an issuance control, not a replacement for domain-control validation. An authorized CA still has to apply its normal validation and issuance requirements. The record adds another decision: even after validation succeeds, is this issuer permitted by the domain’s published CAA policy?

Cybersecurity CAA

Cybersecurity / 24 Sep 2026 / 4 min read

CAA Narrows Certificate Issuance to Authorized CAs

Public certificate authorities validate control of a domain name before issuing a certificate, but domain control is not the only policy a domain operator can publish. Certificate Authority Authorization (CAA), specified in RFC 8659, adds a DNS-based signal that states which CAs are permitted to issue for a name. CAA does not replace domain-control validation. It adds another decision point before issuance: a conforming CA checks the applicable CAA policy and proceeds only when that policy permits the CA to issue the requested certificate.

Cybersecurity CAA

Cybersecurity / 23 Sep 2026 / 6 min read

NSEC3 Opt-Out Trades Denial Proof for Delegation Scale

DNSSEC needs a cryptographic answer not only when data exists, but also when a requested name or record does not exist. NSEC3 supplies that negative proof through a chain of hashed owner names. For zones dominated by delegations to unsigned children, representing every insecure delegation in that chain can create substantial maintenance work. NSEC3 Opt-Out changes that trade-off. An Opt-Out span may cover insecure delegations without giving each one a matching NSEC3 record. The result can reduce NSEC3-chain updates in large delegation-heavy zones, but the omitted names no longer receive the same authenticated existence or nonexistence statement.

Cybersecurity DNSSEC

Cybersecurity / 23 Sep 2026 / 5 min read

DNS Cookies Limit Off-Path DNS Amplification and Forgery

UDP makes DNS efficient, but its source address can be forged by an off-path sender. A small query carrying a victim’s address can trigger a larger response toward that victim, creating reflection and amplification. Forged replies also matter to resolvers because an attacker may try to inject an answer before the legitimate response arrives. DNS Cookies add a lightweight transaction token to this boundary. RFC 7873 defines the COOKIE EDNS option, while RFC 9018 updates the server-side construction so implementations can interoperate, including in multi-vendor anycast deployments. The mechanism is deliberately limited: it raises the cost of off-path forgery, but it is not encryption, DNS data authentication, or protection from an adversary that can observe traffic on path.

Cybersecurity DNS

Cybersecurity / 23 Sep 2026 / 4 min read

CAA Records Restrict Certificate Authority Issuance

CAA Records Restrict Certificate Authority Issuance A public certificate authority can issue a certificate only after satisfying its validation and policy requirements. DNS Certification Authority Authorization adds another control: the domain holder can publish a CAA resource record set that states which issuers are authorized for a name. CAA is an issuance constraint, not a replacement for domain-control validation. An authorized CA still has to perform the validation required by its certificate policy. Conversely, successful domain validation does not permit a compliant CA to disregard an applicable CAA restriction.

Cybersecurity PKI

Cybersecurity / 23 Sep 2026 / 5 min read

Aggressive DNSSEC Caching Reuses Authenticated Denial Proofs

A conventional DNS negative cache remembers a negative result for a specific query. DNSSEC adds richer material to that response: NSEC and NSEC3 records can cryptographically prove that names or record types do not exist. RFC 8198 permits a validating resolver to reuse those cached proofs for later queries that fall inside the proven space. This behavior is called aggressive use of the DNSSEC-validated cache. It can suppress repeated authoritative lookups for names whose nonexistence is already established by validated data. The mechanism is more than a performance optimization: fewer unnecessary queries also reduce exposure of misspelled or random names beyond the recursive resolver and can absorb part of the load created by random-QNAME traffic.

Cybersecurity DNS

Cybersecurity / 22 Sep 2026 / 6 min read

DNSSEC Authenticates DNS Data with a Signed Chain

DNSSEC Authenticates DNS Data with a Signed Chain DNS normally answers a naming question: which records are associated with a domain name? The protocol’s basic response path does not, by itself, give a validating resolver cryptographic evidence that the returned record set is the data authorized by the zone owner. DNS Security Extensions, or DNSSEC, add that evidence. A signed zone publishes public keys and signatures that allow a validating resolver to authenticate DNS data through a chain rooted in a configured trust anchor. DNSSEC protects authenticity and integrity of DNS data. It does not encrypt queries or responses, and it does not conceal the names being requested.

Cybersecurity DNS

Cybersecurity / 22 Sep 2026 / 6 min read

DNS CAA Narrows Certificate Authority Issuance

DNS CAA Narrows Certificate Authority Issuance Public certificate issuance depends on a certificate authority validating control of the requested domain name. DNS Certification Authority Authorization (CAA) adds a separate policy signal: a domain can publish which certificate authorities are permitted to issue for that name. CAA does not replace domain-control validation, prove that a requester is legitimate, or protect a private key. Its role is narrower. A conforming public certificate authority checks the applicable CAA policy before issuance and must not issue when that policy forbids it.

Cybersecurity PKI

Cybersecurity / 22 Sep 2026 / 6 min read

CAA Records Constrain Certificate Authority Issuance

CAA Records Constrain Certificate Authority Issuance A certificate authority can validate control of a domain and still face a separate policy question: is this CA authorized by the domain operator to issue for that name? Certification Authority Authorization, or CAA, gives the DNS namespace a record type for expressing that constraint. CAA operates before certificate issuance. A participating public CA checks the relevant DNS CAA policy and evaluates whether its issuer identity is authorized. The mechanism does not make a certificate trusted, revoke an existing certificate, or tell a browser to reject a certificate after issuance. It narrows the set of issuers that should create new certificates for the domain.

Cybersecurity DNS

Cybersecurity / 21 Sep 2026 / 7 min read

DNSSEC Validates DNS Data Through Signed Delegations

DNSSEC Validates DNS Data Through Signed Delegations DNS normally answers questions about names and resource records without cryptographic proof that the returned data came from the zone operator. DNS Security Extensions (DNSSEC) add signatures and a delegation chain that a validating resolver can check before treating signed DNS data as authentic. The protection is specific. DNSSEC provides data-origin authentication and integrity for DNS data. It does not encrypt queries or responses, hide queried names, or authenticate the application reached after resolution. A valid signed A record can establish that the record is authentic within the DNSSEC chain; it does not establish that the server at that address is safe.

Cybersecurity DNS

Cybersecurity / 21 Sep 2026 / 6 min read

DNSSEC DS Records Link Parent and Child Trust

DNSSEC DS Records Link Parent and Child Trust DNSSEC signs DNS data, but a signature is useful to a validator only when the signing key can be connected to a trusted starting point. That connection has to cross zone boundaries. A resolver validating data below a delegation cannot treat a child zone’s DNSKEY as authentic merely because the child publishes it. The DS resource record supplies the link. It is authoritative data in the parent zone and identifies DNSKEY material in the delegated child. Once the parent side is authenticated, a matching DS can authenticate the corresponding child key, allowing validation to continue into the child zone.

Cybersecurity DNSSEC

Cybersecurity / 21 Sep 2026 / 5 min read

DNS CAA Narrows Which CAs May Issue Certificates

DNS CAA Narrows Which CAs May Issue Certificates A publicly trusted certificate authority can issue a certificate only after completing the validation required by its policy and the applicable ecosystem rules. DNS Certification Authority Authorization (CAA) adds another control: a domain can publish which CAs are authorized to issue certificates for that DNS namespace. CAA does not replace domain-control validation, certificate transparency, or certificate verification by clients. It constrains issuance at the CA side. A CA processing a request checks the relevant CAA policy before issuance and must not issue when the policy forbids it.

Cybersecurity PKI

Cybersecurity / 20 Sep 2026 / 8 min read

DNS Rebinding Turns Name Validation into a Time-of-Use Risk

DNS Rebinding Turns Name Validation into a Time-of-Use Risk An outbound HTTP feature may appear safe after it rejects literal loopback and private IP addresses. The service parses a user-supplied URL, resolves its hostname, checks the returned address against an allowlist, then lets the HTTP client open the connection. Those steps contain a gap. The policy decision applies to an address observed at one moment, while the network connection may perform another DNS lookup later. If the hostname is controlled by an attacker, its DNS answers can change between those events. The validated name stays identical while the destination address changes.

Cybersecurity DNS

Cybersecurity / 20 Sep 2026 / 6 min read

DNS CAA Narrows Which Certificate Authorities May Issue for a Domain

DNS CAA Narrows Which Certificate Authorities May Issue for a Domain Publicly trusted TLS certificates are issued by certificate authorities that satisfy browser and operating-system trust requirements. A domain operator normally chooses one CA, but the public trust ecosystem can contain many authorities capable of issuing certificates that clients would accept. Certification Authority Authorization (CAA) records add a DNS policy at issuance time. A domain can state which CAs are permitted to issue certificates for it. RFC 8659 defines the processing model, including record lookup, property tags, and issuer behavior.

Cybersecurity DNS

Cloud Computing / 19 Sep 2026 / 5 min read

Wildcard Subdomains on Cloudflare Workers: Routing and TLS Boundaries

A hostname such as demo.instara.app can reach a Cloudflare Worker through one wildcard DNS record and one Worker Route. A deeper hostname such as web.demo.instara.app can resolve through the same wildcard DNS record and still fail before the Worker runs because the edge certificate does not cover that hostname. That distinction matters because three independent mechanisms participate in the request: DNS resolution | v Worker Route matching | v TLS certificate coverage They all use wildcard syntax, but they do not have identical matching rules.

Cloud Computing Cloudflare Workers

Tech / 19 Sep 2026 / 7 min read

Web3 Domains Do Not Replace DNS: The ENS Resolution Boundary

A name such as alice.eth looks like an Internet domain, but its resolution path is not the same as example.com. A conventional domain normally enters the Domain Name System, where resolvers follow the DNS hierarchy to obtain records such as A, AAAA, MX, or TXT. An ENS name enters a different naming system whose authoritative state is expressed through Ethereum smart contracts. That distinction is the practical boundary behind many claims about “Web3 domains.” The name can be globally meaningful to software that implements ENS resolution while remaining unknown to a DNS resolver. A browser, wallet, or dApp therefore needs an ENS-aware resolution path before .eth can behave like a useful name.

Tech Web3

Cybersecurity / 19 Sep 2026 / 7 min read

DNS Rebinding Preserves Web Origin While the Network Destination Changes

DNS Rebinding Preserves Web Origin While the Network Destination Changes A browser can treat two requests as same-origin even when the TCP connections behind them terminate at different IP addresses. The origin model is built from the URL scheme, host, and port. DNS resolution is a network operation beneath that identity. If a hostname resolves to one address and later resolves to another, the browser-facing origin can remain unchanged. DNS rebinding exploits that separation. An attacker-controlled hostname can initially resolve to an attacker-controlled server that delivers script, then later resolve to an address reachable from the victim’s network. Subject to browser, resolver, transport, and target-service behavior, subsequent requests for the same hostname can then cross a network boundary without becoming cross-origin in the browser’s origin model.

Cybersecurity Browser Security

Cybersecurity / 16 Sep 2026 / 7 min read

DNSSEC Denial Proofs Let Resolvers Synthesize Negative Answers

DNSSEC Denial Proofs Let Resolvers Synthesize Negative Answers A recursive resolver receives a query for a random subdomain beneath a signed zone and already holds a validated denial record from an earlier lookup. The queried label was never sent to the authoritative server, yet the resolver can still return an authenticated negative result. The answer is not a guess and is not ordinary exact-match negative caching. It is derived from cryptographic evidence that covers a portion of the DNS namespace.

Cybersecurity DNS

Cybersecurity / 16 Sep 2026 / 10 min read

DNS Rebinding Turns Name Resolution Into a Moving Network Boundary

A browser loads script from an attacker-controlled hostname while that name resolves to a public server. Seconds later, another lookup for the same hostname returns a private address such as an RFC 1918 destination. The browser still sees the same scheme, host, and port in the URL, yet a subsequent connection can terminate at a different machine. That gap between web origin identity and network destination is the basis of DNS rebinding. The same-origin policy primarily reasons about origins expressed through URL components; it does not define an origin by the IP address selected by DNS for each connection. An attacker who controls both a hostname and its DNS answers can exploit that separation when a browser is permitted to resolve the name to a target reachable from the user’s network.

Cybersecurity DNS

Cybersecurity / 16 Sep 2026 / 9 min read

DNS Rebinding Turns Name Resolution Into a Browser Network Pivot

DNS Rebinding Turns Name Resolution Into a Browser Network Pivot A browser can load active content from a public server, keep the same URL origin, then resolve that origin name to a different IP address later. If the new address reaches a service on a private network, the browser has become a transport path between attacker-controlled code and a target that was never intended to accept requests from the public Internet.

Cybersecurity DNS