Reference

std/dns/wire

std/dns/src/wire.trb

The wire format of RFC 1035 section 4: a Message from bytes and back, names compressed by pointers (section 4.1.4), the EDNS0 record of RFC 6891, and the query and response helpers a transport needs - so that std/network, std/tls and std/http only move bytes (docs/design/DNS.md section 2).

Reading never indexes past what it checked: every read goes through a ByteReader of std/binary, whose failure becomes a DnsError that names the part of the message the bytes end in, so bytes from the network cannot make it panic. Writing goes into a ByteWriter, whose width types make every field's range a check at the caller.

extend Result<Value, ReadError>

extend<Value> Result<Value, ReadError>

Not documented.

fn inside

fn inside(part: String, scope: Scope): Result<Value, DnsError>

What was read, or the failure of scope that says the bytes end inside part.

fn query

fn query(name: DomainName, recordType: RecordType, identifier: Int, recursionDesired: Bool = true, dnssecOk: Bool = false): Bytes

The bytes of a standard query for the records of recordType at name: one question in class Internet, recursion desired unless recursionDesired says otherwise, and an EDNS0 record that offers a UDP payload of 1232 bytes and sets the DO bit where dnssecOk asks for DNSSEC records. The identifier is taken modulo 65536; a transport draws it at random for every query (RFC 5452 section 9.2). What it sends is these bytes, as they are over UDP and after a length of two bytes over TCP (RFC 7766 section 8).

Examples

const bytes = query(DomainName.tryFrom("example.test")?, RecordType.A, 4660)
print bytes.length()

fn readResponse

fn readResponse(bytes: Bytes, query: Bytes): Result<Message, DnsError>

The response in bytes, checked against the query it is supposed to answer: it is a response, its identifier and operation are the query's, and its question section is the query's, the names compared without their case - or empty, which a server may send with an error code. What the response says is not judged here: a NameError, an empty answer and a truncated response (truncated, to be asked again over TCP) are messages like any other.

Errors