When using NSEC/NSEC3 RRs from the cache to derive existance of arbitrary RRs, we should not get confused by the fact
that NSEC/NSEC3 RRs exist twice at zone cuts: once in the parent zone, and once in the child zone. For most RR types we
should only consult the latter since that's where the beef is. However, for DS lookups we have to check the former.
This change makes sure we never cache NSEC/NSEC3 RRs from any parent zone of a zone-cut. It also makes sure that when
we look for a DS RR in the cache we never consider any cached NSEC RR, as those are now always from the child zone.
We already maintain statistics about positive DNSSEC proofs, and count them up by 1 for each validated RRset. Now,
update the same counters each time we validated a negative query, so that the statistics are the combined result of all
validation checks, both positive and negative.
If we are looking for a DS RR we need to check the NSEC3 bitmap of the parent zone's NSEC3 RR, not the one from the
child. For any other RR we need to look at the child's however, hence enforce this with the bitmaps.
Note that not coverign checks only the lower zone's NSEC3 bitmaps matter, hence the existing check is fine.
The tool resolves way more than just hosts, hence give it a more generic name. This should be safe, as the tool is
currently undocumented. Before we add documentation for it, let's get the name right.
This also moves the C source into src/resolve/ (from src/resolve-host/), since the old name is a misnomer now. Also,
since it links directly to many of the C files of resolved it really belongs into resolved's directory anyway.
Not only report whether the server actually supports DNSSEC, but also first check whether DNSSEC is actually enabled
for it in our local configuration.
Also, export a per-link DNSSECSupported property in addition to the existing manager-wide property.
So far, we exposed SetLinkXYZ() on the Manager interface, to set a couple of link properties. This adds similar calls
SetXYZ() on the Link interface, and makes sure the former is little more than a shortcut to the latter.
SetLinkXYZ() has the benefit of not requiring a GetLink() round trip for setting these properties, while the method
actually belongs to the Link objects, and this change corrects that.
This is useful for alternative network management solutions (such as NetworkManager) to push DNS configuration data
into resolved.
The calls will fail should networkd already have taken possesion of a link, so that the bus API is only available if
we don't get the data from networkd.
For mDNS and LLMNR we already created the scopes only if the specific interfaces where actually up and suitable for
Multicasting. Add a similar (but weaker) logic for unicast DNS as well.
Certain Belkin routers appear to implement a broken DNS cache for A RRs and some others, but implement a pass-thru for
AAAA RRs. This has the effect that we quickly recognize the broken logic of the router when we do an A lookup, but for
AAAA everything works fine until we actually try to validate the request. Given that the validation will necessarily
fail ultimately let's make sure we remember even when downgrading a feature level that OPT or RRSIG was missing.
When we restart a transaction because of an incompatible server, pick a new transaction ID.
This should increase compatibility with DNS servers that don't like if they get different requests with the same
transaction ID.
given that DNSSEC lookups may result in quite a number of auxiliary transactions, let's better be safe than sorry and
also enforce a limit on the number of total transactions, not just on the number of queries.
Previously, when getting notified about a completed auxiliary DNSSEC transaction we'd immediately act on it, and
possibly abort the main transaction. This is problematic, as DNS transactions that already completed at the time we
started using them will never get the notification event, and hence never be acted on in the same way.
Hence, introduce a new call dns_transaction_dnssec_ready() that checks the state of auxiliary DNSSEC transactions, and
returns 1 when we are ready for the actual DNSSEC validation step. Then, make sure this is invoked when the auxiliary
transactions are first acquired (and thus possibly reused) as well when the notifications explained above take place.
This fixes problems particularly when doing combined A and AAAA lookups where the auxiliary DNSSEC transactions get
reused between them, and where we got confused if we reused an auxiliary DNSSEC transaction from one when it already
got completed from the other.
Let's avoid thinking that a CNAME/DNAME chain traversal could be a good idea if QTYPE is already CNAME/DNAME.
(Also, let's bail out early when trying to see if some RR is a suitable CNAME/DNAME for some other RR).
Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever
comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be
considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs.
Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using
UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix.
With this change IDNA conversion is done only:
- When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname()
- When the user passes a non-ASCII domain suffix when resolving a service using ResolveService()
No IDNA encoding is done anymore:
- When the user does raw ResolveRecord() RR resolving
- On the service part of a DNS-SD service name
Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something
is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a
classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead
for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one
encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.
If we have a signed DNAME RR response, there's no need to insist on a signature for a CNAME RR response, after all it
is unlikely to be signed, given the implicit synthethis of CNAME through DNAME RRs.
Quite often we read the same RR key multiple times from the same message. Try to replace them by a single object when
we notice this. Do so again when we add things to the cache.
This should reduce memory consumption a tiny bit.
In some cases we learn something about a server's feature level through its responses. If we notice that after doing
basic checking of a response, and after collecting all auxiliary DNSSEC info the feature level of the server is lower
than where we started, restart the whole transaction.
This is useful to deal with servers that response rubbish when talked to with too high feature levels.
