this simplifies the DNSSEC_OK (DO) bit handling logic in `Recursor`
as a side effect `Recursor` will now cache queries that have the DO bit
set whereas before it wasn't
previously, the FQDN of a NameServer was generated using a globally
shared, monotonically increasing counter. that resulted in a
unpredictable FQDN in the presence other tests running concurrently /
in parallel
with this change, the presence of other test threads does not affect the
FQDN automatically chosen for a NameServer. the FQDN becomes only a
function of the order in which the NameServers are created *within a
thread*
the `rr_type` field has been removed. this eliminates the possibility of
setting `rdata` to a type that does not match `rr_type`. as a
consequence, the `set_record_type` has also been removed
the `record_type` of the `Resource` is now derived from what's stored in
the `rdata` field
`rdata` is no longer an `Option`. `rdata = None` was being used to
represent update records. an `Update` variant has been added to the
`RData` enum. this variant is used to represent update records, which
have RDLENGTH set to 0.
the `Resource::{default,new}` constructors have been removed. they felt
error prone as in most cases one wants to set the `rdata` and `name`
fields since they have no sensible defaults. all uses of those
constructors now use the pre-existing `from_rdata` constructor
the `Resource::with` constructor has also been removed. it was pretty
similar to `from_rdata` but initialized `rr_type` and not `rdata`. all
uses of `Record::with` has been changed to `from_rdata`
the past-future job fails with latest nightly toolchain:
1.80.0-nightly (da159eb33 2024-05-28)
this commit pins the nightly version to a known to work version
closes#2223
`unbound` requires that the MNAME lies underneath the zone. That is
`primaryNN.nameservers.com.` is not a valid MNAME for a nameserver
authoritative over `mydomain.com.`. For that zone,
`primaryNN.mydomain.com.` would be a valid MNAME.
using `std::env::set_var` to set or change the value of either
DNS_TEST_SUBJECT or DNS_TEST_PEER is A Bad Idea, specially so when
tests are running in parallel
we can't forbid the use of `env::set_var` _but_ at least we can ensure
that even in its presence the return value of `dns_test::{subject,peer}`
will not change
this is accomplished using a "lazy" static variable that gets
initialized at most once during the lifetime of the process instead of
reading the env var each time `{subject,peer}` is called
to better convey the fact that the return value of `{subject,peer}`
won't change, we present them as static variables instead
When starting `hickory-dns` there is no easy way to check the start
sequence has finished & its fully ready to accept connections. Other
tools, e.g. unbound, are designed as services, they will correctly
manage their `pidfile`. They also could be queried by the `servicectl`
inside the Docker container.