When the DNS_RESOURCE_KEY_CACHE_FLUSH flag is not set for an mDNS packet, we should not flush
the cache for RRs with matching keys. However, we were unconditionally flushing the cache
also for these packets.
Now mark all packets as cache_flush by default, except for these mDNS packets, and respect
that flag in the cache handling.
This fixes 90325e8c2e.
The logic of dns_cache_get() is now:
- look up the precise key;
- look up NXDOMAIN item;
- if an RR type that may be redirected
(i.e., not CNAME, DNAME, RRSIG, NSEC, NSEC3, SIG, KEY, or
NXT) look up a correpsonding CNAME or DNAME record;
- look up a corresponding NSEC record;
Before this change we would give up before potentially finding
negative cache entries for DNAME, CNAME and NSEC records, we
would return NSEC records for aliases where we had DNAME or CNAME
records available and we would incorrectly try to redirect DNSSEC RRs.
Apart from dropping redundant information, this fixes an issue
where, due to broken DNS servers, we can only be certain of whether
an apparent NODATA response is in fact an NXDOMAIN response after
explicitly resolving the canonical name. This issue is outlined in
RFC2308. Moreover, by caching NXDOMAIN for an existing name, we
would mistakenly return NXDOMAIN for types which should not be
redirected. I.e., a query for AAAA on test-nx-1.jklm.no correctly
returns NXDOMAIN, but a query for CNAME should return the record
and a query for DNAME should return NODATA.
Note that this means we will not cache an NXDOMAIN response in the
presence of redirection, meaning one redundant roundtrip in case the
name is queried again.
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
Quoting @teg:
"Contrary to what the comment said, we always verify redirect chains in
full, and cache all the CNAME records. There is therefore no need to
do extra negative caching along a CNAME chain."
This simply steals @teg's commit since we'll touch the SOA matching case
in a later patch, and rather want this bit gone, so that we don't have
to "fix" it, only to remove it later on.
For mDNS, if we're unable to stuff all known answers into the given packet,
allocate a new one, push the RR into that one and link it to the current
one.
This new functions exports cached records of type PTR, SRV and TXT into
an existing DnsPacket. This is used in order to fill in known records
to mDNS queries, for known answer supression.
This adds a new SD_RESOLVED_AUTHENTICATED flag for responses we return
on the bus. When set, then the data has been authenticated. For now this
mostly reflects the DNSSEC AD bit, if DNSSEC=trust is set. As soon as
the client-side validation is complete it will be hooked up to this flag
too.
We also set this bit whenver we generated the data ourselves, for
example, because it originates in our local LLMNR zone, or from the
built-in trust anchor database.
The "systemd-resolve-host" tool has been updated to show the flag state
for the data it shows.
When an RR type is not set in an NSEC, then the CNAME/DNAME types might
still be, hence check them too.
Otherwise we might end up refusing resolving of CNAME'd RRs if we cached
an NSEC before.
Sometimes when looking up entries in hashmaps indexed by a
DnsResourceKey it is helpful not having to allocate a full
DnsResourceKey dynamically just to use it as search key. Instead,
optionally allow allocation of a DnsResourceKey on the stack. Resource
keys allocated like that of course are subject to other lifetime cycles
than the usual Resource keys, hence initialize the reference counter to
to (unsigned) -1.
While we are at it, remove the prototype for
dns_resource_key_new_dname() which was never implemented.
If we have a precisely matching NSEC RR for a name, we can use its type
bit field to synthesize NODATA cache lookup results for all types not
mentioned in there.
This is useful for mDNS where NSEC RRs are used to indicate missing RRs
for a specific type, but is beneficial in other cases too.
To test this, consider these two lines:
systemd-resolve-host -t NSEC nasa.gov
systemd-resolve-host -t SRV nasa.gov
The second line will not result in traffic as the first line already
cached the NSEC field.
When a NXDATA or a NODATA response is received for an alias it may
include CNAME records from the redirect chain. We should cache the
response for each of these names to avoid needless roundtrips in
the future.
It is not sufficient to do the negative caching only for the
canonical name, as the included redirection chain is not guaranteed
to be complete. In fact, only the final CNAME record from the chain
is guaranteed to be included.
We take care not to cache entries that redirects outside the current
zone, as the SOA will then not be valid.
CNAME records are special in the way they are treated by DNS servers,
and our cache should mimic that behavior: In case a domain name has an
alias, its CNAME record is returned in place of any other.
Our cache was not doing this despite caching the CNAME records, this
entailed needless lookups to re-resolve the CNAME.
Currently, dns_cache_put() does a number of things:
1) It unconditionally removes all keys contained in the passed
question before adding keys from the newly arrived answers.
2) It puts positive entries into the cache for all RRs contained
in the answer.
3) It creates negative entries in the cache for all keys in the
question that are not answered.
Allow passing q = NULL in the parameters and skip 1) and 3), so
we can use that function for mDNS responses. In this case, the
question is irrelevant, we are interested in all answers we got.
Let's simplify things and only maintain a single RR key per transaction
object, instead of a full DnsQuestion. Unicast DNS and LLMNR don't
support multiple questions per packet anway, and Multicast DNS suggests
coalescing questions beyond a single dns query, across the whole system.
With this change we'll now also generate synthesized RRs for the local
LLMNR hostname (first label of system hostname), the local mDNS hostname
(first label of system hostname suffixed with .local), the "gateway"
hostname and all the reverse PTRs. This hence takes over part of what
nss-myhostname already implemented.
Local hostnames resolve to the set of local IP addresses. Since the
addresses are possibly on different interfaces it is necessary to change
the internal DnsAnswer object to track per-RR interface indexes, and to
change the bus API to always return the interface per-address rather than
per-reply. This change also patches the existing clients for resolved
accordingly (nss-resolve + systemd-resolve-host).
This also changes the routing logic for queries slightly: we now ensure
that the local hostname is never resolved via LLMNR, thus making it
trustable on the local system.
It is redundant to store 'hash' and 'compare' function pointers in
struct Hashmap separately. The functions always comprise a pair.
Store a single pointer to struct hash_ops instead.
systemd keeps hundreds of hashmaps, so this saves a little bit of
memory.
Tom Gundersen