How it works
How Raven Handles a DNS Request
Follow a request from the first access check to the answer. See where Raven applies security rules, uses saved answers, or stops a request.
DNS processing stages
01Network Access
Listener • Firewall • Client rules
02DNS Message Check
One complete DNS question
03Rate & Abuse Limits
Query rate • Cookies • Active requests
04DNS Guard — Request Check
Domains • Threat lists • Activity
05Cache Lookup
Reuse fresh answers • Never serve expired data
06DNS Resolution
Uses the selected DNS lookup method.
07DNSSEC — When Enabled
Local checks • Upstream AD is not trusted
08DNS Guard — Answer Check
IP ranges • CNAME/NS • Rebinding
09Cache Storage
Answers / Not-found results • TTL not extended
10Response Protection
Response size • TCP retry • Rate limits
01Network Access
Listener • Firewall • Client rules
02DNS Message Check
One complete DNS question
03Rate & Abuse Limits
Query rate • Cookies • Active requests
04DNS Guard — Request Check
Domains • Threat lists • Activity
05Cache Lookup
Reuse fresh answers • Never serve expired data
06DNS Resolution
Uses the selected DNS lookup method.
07DNSSEC — When Enabled
Local checks • Upstream AD is not trusted
08DNS Guard — Answer Check
IP ranges • CNAME/NS • Rebinding
09Cache Storage
Answers / Not-found results • TTL not extended
10Response Protection
Response size • TCP retry • Rate limits
This diagram groups the main checks. The path depends on the active settings and available cached data. DNS Guard request and answer checks can be switched off separately; DNSSEC runs when enabled.
Inside the resolver
From request to response.
See what Raven receives, what it checks, and how it prepares the reply. Each number matches a stage in the diagram.
Start at the client
What enters Raven?
A client, such as a computer, sends a DNS question. It might ask for the IP address of a domain. Raven receives the question over UDP or TCP, together with the client’s IP address and connection details.
example.com ARequest an IPv4 address- Question
- The domain name and record type. A requests an IPv4 address; AAAA requests an IPv6 address.
- Client details
- The client’s IP address, where the message arrived, and whether it uses UDP or TCP.
- Request options
- Options such as the supported reply size and the client’s DNSSEC flags. These are explained in the steps below.
This is a simplified overview. The active settings and the result of each check determine how the request is handled. Some requests stop early, and optional checks can be turned off.
- Receive the request
Network Access
Raven checks where the request came from and whether the client is allowed to use the service.
InputA DNS message sent over UDP or TCP, the client’s IP address, and the network interface receiving it.
Processing details for stage 01: Network Access3 topics
- Allowed addresses and ports
- Raven listens for DNS requests on the addresses and ports selected in its settings. Firewall rules control which network interfaces can receive traffic.
- Firewall check
- Raven’s firewall drops new TCP and UDP traffic that does not match an allowed rule. If no external DNS listener is configured, Raven adds no firewall rule to allow external DNS traffic.
- Client access rules
- The client’s IP address is checked against the configured access rules, also called the client ACL.
Access deniedTraffic blocked by the firewall is dropped before DNS processing.
NextAn allowed request can continue through the DNS checks.
- Receive the request
DNS Message Check
Raven checks that the DNS message can be read and contains exactly one complete, valid question.
InputThe DNS header and the question: the domain name and requested record type.
Processing details for stage 02: DNS Message Check2 topics
- Message format
- The message must contain one complete DNS question. Invalid or incomplete messages do not continue to a DNS lookup.
- Handling broken messages
- If a packet is too short to contain a safe DNS header, Raven sends no reply. If the header can be read but the question is incomplete, it returns a header-only FORMERR response, meaning a format error.
Invalid messageRaven returns a small error response or sends no reply, depending on what can safely be read.
NextA valid question continues to rate and abuse limits.
- Receive the request
Rate & Abuse Limits
Raven limits how many requests it accepts and processes at once. These checks help control load before a DNS lookup begins.
InputThe valid question, client IP, connection type, and configured capacity limits.
Processing details for stage 03: Rate & Abuse Limits3 topics
- Requests per second
- The license sets the QPS limit: queries per second. An optional limit in DNS settings can lower that value. Raven uses the already checked license settings rather than reading the license file for each accepted query.
- Requests in progress
- Rate limits and limits on active requests apply across the service, by connection type, and by client.
- Abuse controls
- Raven supports DNS Cookies and sends small replies to ANY queries, which ask for all record types. These are part of its controls against DNS abuse.
Limit reachedOverload normally returns SERVFAIL, a server failure response. An administrator can select REFUSED or DROP instead. Rejection by a per-client limit normally returns REFUSED.
NextAn accepted request continues to the DNS Guard request check.
- Inspect the request
DNS Guard — Request Check
When this check is enabled, DNS Guard checks the requested domain against security rules before looking in the cache or contacting another DNS server.
InputThe client IP, requested domain, record type, and relevant activity history.
Processing details for stage 04: DNS Guard — Request Check4 topics
- Security rules
- Rules can depend on the client, record type, domain, and rule priority. Domain rules support exact names, domain endings, wildcards, and text patterns. Raven checks and prepares these rules before using them for requests.
- Threat lists
- Raven uses domain indicators, imported threat feeds, and Response Policy Zones (RPZ), which provide DNS response rules. Supported actions include REFUSED, NXDOMAIN, SINKHOLE, and LOG_ONLY. Custom response records are also supported.
- Unusual activity
- Checks can look for high TXT request rates, many different subdomains, repeated name-not-found results, random-looking names, and long names. Rate-based checks look at activity over time. Repeated risky periods can trigger blocking; healthy periods can allow recovery. Configured domain and client exceptions also apply.
- Optional checks
- Request and answer checks are both enabled by default. An administrator can turn either one off. Turning this check off lets the request continue without this domain inspection.
Rule matchedA blocking rule can stop the lookup. REFUSED denies the request; NXDOMAIN returns a name-not-found result. SINKHOLE uses a configured replacement destination after its settings have been checked.
NextAn allowed request continues to the cache. LOG_ONLY records the match and lets the request continue.
- Find an answer
Cache Lookup
The cache holds results from earlier lookups. Raven checks whether a matching, unexpired result is available for this request.
InputThe request details and the current cache version.
Processing details for stage 05: Cache Lookup3 topics
- Match the request
- The saved result must match the full request details and the current cache version.
- Check the expiry
- Raven never returns an expired cache entry, including when other DNS servers cannot answer.
- Use the cache or look up the answer
- A matching fresh result can be reused. If no suitable result is available, Raven starts a new DNS lookup using the selected resolution method.
NextA suitable cached result can supply the answer. Otherwise, Raven looks it up through the DNS resolution stage.
- Find an answer
DNS Resolution
When the cache cannot supply an answer, Raven looks it up using the method selected by the administrator.
InputA question without a suitable cached answer.
Processing details for stage 06: DNS Resolution4 topics
- Four lookup methods
- Forwarder sends the question to a configured DNS server. Root DNS starts from Raven’s built-in root-server list and follows the DNS hierarchy. The two combined methods try Root DNS then Forwarder, or Forwarder then Root DNS. A valid NXDOMAIN means the name does not exist; NODATA means the requested record is absent. These are final answers, not reasons to try another method.
- Following other DNS servers
- Raven checks that each referral moves the lookup forward. It only trusts attached name-server addresses within the relevant DNS zone; other name-server addresses are looked up separately. QNAME minimization limits how much of the requested name is shared during this process.
- Reply checks and work limits
- Replies must match the question sent. Raven rejects invalid replies and referrals that do not advance the lookup. It limits the number of exchanges, servers, lookup steps, and requests running at once.
- Connections to DNS servers
- Raven supports UDP, TCP, DNS over TLS (DoT), and DNS over HTTPS (DoH). DoT and DoH encrypt the connection and require certificate and server-name checks. Private certificate authorities and extra public-key checks are supported. Switching from encrypted DNS to plain DNS is allowed by default and can be disabled. The selected settings determine which connections are used.
Lookup failedIf the lookup methods fail, Raven returns SERVFAIL. It does not replace the failed result with an expired cached answer.
NextThe result goes through DNSSEC checks when enabled, then the DNS Guard answer check when enabled.
- Check the answer
DNSSEC — When Enabled
When DNSSEC is enabled, Raven checks DNS signatures itself. It does not trust another DNS server’s claim that an answer has already been verified.
InputThe DNS result, its signature records or signed proof that data is absent, Raven’s trusted keys, and the client’s DNSSEC flags.
Processing details for stage 07: DNSSEC — When Enabled4 topics
- Checking signatures
- Raven checks DNS keys, signatures, their chain of trust, and signed proof of missing DNS data. DNSSEC checks signed data; it does not encrypt the query.
- Secure or Insecure
- Secure means local DNSSEC checks verified the result. Insecure means there is no complete signed chain; it does not mean the domain is malicious. The AD flag marks verified data. Raven clears the AD flag received from other servers. Only a locally Secure result can get AD=1, and only when the client has not set CD=1.
- Failed checks and the CD flag
- Bogus means DNSSEC checks failed. With CD=0, Raven returns SERVFAIL and extra error information (EDE) when possible. CD=1 means the client has set Checking Disabled: unchecked data can then be returned with AD=0. It is not marked as verified.
- Unknown results and temporary exceptions
- Indeterminate means the result cannot be marked Secure. A Negative Trust Anchor (NTA) is a recorded, temporary DNSSEC exception for one exact non-root domain. It requires a reason and an expiry time. Permanent and wildcard exceptions are rejected.
DNSSEC check failedBogus with CD=0 returns SERVFAIL. With CD=1, unchecked data may be returned, but it is never marked Secure.
NextResults that can be returned continue with their DNSSEC status. If DNSSEC is disabled, this check is skipped.
- Check the answer
DNS Guard — Answer Check
When this check is enabled, DNS Guard examines the addresses and names in the DNS answer before it is sent to the client.
InputThe addresses and target names in the answer, together with the configured security rules.
Processing details for stage 08: DNS Guard — Answer Check3 topics
- Addresses in the answer
- Raven checks IPv4 and IPv6 answers (A and AAAA records) against IP addresses and IP ranges listed in its security rules.
- Other names in the answer
- The checks also cover CNAME targets, which are aliases to other names, and NS targets, which identify name servers. The configured DNS rebinding rules also apply to returned addresses and targets.
- Separate control
- An administrator can enable or disable this check independently of the request check. Turning it off removes this inspection of the returned addresses and names.
Answer blocked by a ruleA matching rule can return REFUSED, NXDOMAIN, or a configured sinkhole response instead of the original answer.
NextAn allowed answer continues toward delivery. A LOG_ONLY rule records the match and allows the answer.
- Prepare the response
Cache Storage
Raven can save suitable results in memory for later requests. Saving a result does not extend how long the DNS data remains valid.
InputA result that can be cached, its remaining lifetime, and the current cache version.
Processing details for stage 09: Cache Storage3 topics
- Answers and not-found results
- Raven keeps positive and negative results in memory. Negative caching follows RFC 2308 and can save valid NXDOMAIN and NODATA results.
- Remaining lifetime
- TTL, or time to live, controls how long a result can be reused. Raven never increases a short or zero TTL. Expired results are not served.
- Refreshing the cache
- Raven limits background cache-refresh jobs. It checks the cache version so refresh work is kept within the correct version.
NextThe response still needs the output size and rate checks. Later requests can reuse saved results only while they remain valid.
- Prepare the response
Response Protection
Raven checks the size and rate of outgoing replies before sending them to the client. This helps limit oversized and repeated UDP responses.
InputThe outgoing reply, the connection type, and the response size the client supports.
Processing details for stage 10: Response Protection3 topics
- Reply size
- A UDP reply without EDNS is limited to 512 bytes. EDNS lets the client state a larger supported size. Raven uses the smaller of that size and the administrator’s limit.
- Complete groups of records
- Raven keeps DNS record sets, called RRsets, whole when fitting the reply. If the answer must be shortened, TC=1 tells the client it can retry over TCP for a larger response.
- Repeated UDP replies
- Response Rate Limiting (RRL) limits similar UDP replies. When the limit is reached, Raven normally sends a minimal reply with TC=1, or drops the reply when configured to do so.
Reply limitedRaven may send a shortened reply or no reply when the output limits require it.
NextThe client receives an answer, a response selected by a rule, an error, or a TCP retry signal. DROP means no reply is sent.
Back to the same client
What the client receives
The reply depends on the lookup result, the active rules, and the checks that ran.
- Answer
- A result from the cache or a new lookup that the applied checks allow Raven to return.
- Response selected by a rule
- A configured sinkhole response, REFUSED, or NXDOMAIN. A normal DNS lookup can also return NXDOMAIN when a name does not exist.
- Error
- FORMERR means the request format is wrong. SERVFAIL can mean that the lookup failed or that DNSSEC checks failed with CD=0.
- TCP retry or no reply
- TC=1 tells the client it can retry over TCP. DROP means Raven sends no DNS reply.
Alongside the query
Logs and monitoring
Raven sends activity information to its monitoring and logging tools. It limits the query and incident details kept for review. Query decisions do not wait for calls to the log database, analytics service, or management API.
- Recent requests
- Live Query shows a limited list of recent requests held in memory: client IP, domain, response code, DNSSEC result, and action. This list is lost when Raven restarts; it is not a permanent archive.
- Service statistics
- Query rates, CPU and memory use, network activity, and active sessions help administrators monitor the service. The dashboard shows measurements and summaries, not a capture of every packet.
- Security events
- DNS Guard records rule matches and unusual activity for review. Related activity can be grouped into incidents with a limited number of examples. Events can be sent to external monitoring tools through Syslog or webhooks; delivery depends on the network and receiving system.