ProtoCore v1.0.16
Deterministic, zero-heap network stack for embedded targets
Loading...
Searching...
No Matches
dns_resolver.h File Reference

Layer 3 (Network) - the asking side of DNS: a question out, an A record back (PROTOCORE_ENABLE_DNS_RESOLVER). More...

#include "protocore_config.h"

Go to the source code of this file.

Detailed Description

Layer 3 (Network) - the asking side of DNS: a question out, an A record back (PROTOCORE_ENABLE_DNS_RESOLVER).

RFC 1035 sec 4.1.2 QNAME in, RFC 1035 sec 3.4.1 A RDATA out. The query carries one question, QTYPE A, QCLASS IN, with RD set (RFC 1035 sec 4.1.1), and travels over UDP to server port 53 (RFC 1035 sec 4.2.1).

A response is accepted only when its ID echoes the query's, QR is set, and RCODE is 0 (RFC 1035 sec 4.1.1); RFC 5452 sec 9.1 names the ID as one of the attributes a response has to match before its data is used. The address it yields is then classified against the IPv4 Special-Purpose Address Registry (RFC 6890 sec 2.2.2) and the host group range (RFC 1112 sec 4): a remote name answering with "This host on this network", Limited Broadcast, Loopback, or a host group address is refused.

Nothing here blocks. The module owns one timer and one in-flight query: ::ResolverNs::resolve starts the query, marks itself busy and reports ::PROTOCORE_DNS_BUSY, and the caller asks again on its own tick. The response arrives on the UDP listener's normal drain, so the answer lands without this module pumping anything. Busy is the sending side only, and the response handler is always armed.

Two backends, chosen by PROTOCORE_HAS_VENDOR_DNS_RESOLVER. Where the platform's stack has its own resolver the module marshals into it and inherits its nameserver list and its cache. Where it does not, the portable resolver asks PROTOCORE_DNS_SERVER over the UDP listener, one query at a time with no cache, and ::ResolverNs::set_server points it at whatever address DHCP or provisioning turned up.

The query and the response are codecs in their own right, so they are reached as calls and tested as such: ::ResolverNs::query_build writes the question section, ::ResolverNs::answer_parse reads the first A record back, and the resolve is what puts a socket between them.

Author
Douglas Quigg (dstroy0)
Date
2026

Definition in file dns_resolver.h.