RFC 8080 describes how to use EdDSA keys and signatures in DNSSEC. It
uses the curves Ed25519 and Ed448. Libgcrypt 1.8.1 does not support
Ed448, so only the Ed25519 is supported at the moment. Once Libgcrypt
supports Ed448, support for it can be trivially added to resolve.
When we return the full RR wire data, let's make sure the TTL included in it is
adjusted by the time the RR sat in the cache.
As an optimization we do this only for ResolveRecord() and not for
ResolveHostname() and friends, since adjusting the TTL means copying the RR
object, and we don#t want to do that if there's no reason to.
(ResolveHostname() and friends don't return the TTL hence there's no reason to
in that case)
https://tools.ietf.org/html/rfc6698#section-2.2 says:
> The certificate association data field MUST be represented as a string
> of hexadecimal characters. Whitespace is allowed within the string of
> hexadecimal characters
When the buffer is allocated on the stack we do not have to check for
failure everywhere. This is especially useful in debug statements, because
we can put dns_resource_key_to_string() call in the debug statement, and
we do not need a seperate if (log_level >= LOG_DEBUG) for the conversion.
dns_resource_key_to_string() is changed not to provide any whitespace
padding. Most callers were stripping the whitespace with strstrip(),
and it did not look to well anyway. systemd-resolve output is not column
aligned anymore.
The result of the conversion is not stored in DnsTransaction object
anymore. It is used only for debugging, so it seems fine to generate it
when needed.
Various debug statements are extended to provide more information.
Left-over unknown flags are printed numerically. Otherwise,
it wouldn't be known what bits are remaining without knowning
what the known bits are.
A test case is added to verify the flag printing code:
============== src/resolve/test-data/fake-caa.pkts ==============
google.com. IN CAA 0 issue "symantec.com"
google.com. IN CAA 128 issue "symantec.com"
-- Flags: critical
google.com. IN CAA 129 issue "symantec.com"
-- Flags: critical 1
google.com. IN CAA 22 issue "symantec.com"
-- Flags: 22
Packets are stored in a simple format:
<size> <packet-wire-format> <size> <packet-wire-format> ...
Packets for some example domains are dumped, to test rr code for various
record types. Currently:
A
AAAA
CAA
DNSKEY
LOC
MX
NS
NSEC
OPENPGPKEY
SOA
SPF
TXT
The hashing code is executed, but results are not checked.
Also build other tests in src/resolve only with --enable-resolve.
We try to fit the lengthy key data into available space. If the other
fields take less than half of the available columns, we use align everything
in the remaining columns. Otherwise, we put everything after a newline,
indented with 8 spaces.
This is similar to dig and other tools do.
$ COLUMNS=78 ./systemd-resolve -t any .
. IN SOA a.root-servers.net nstld.verisign-grs.com 2016012701 1800 900 604800 86400
. IN RRSIG SOA RSASHA256 0 86400 20160206170000 20160127160000 54549
S1uhUoBAReAFi5wH/KczVDgwLb+B9Zp57dSYj9aX4XxBhKuzccIducpg0wWXhjCRAWuzY
fQ/J2anm4+C4BLUTdlytPIemd42SUffQk2WGuuukI8e67nkrNF3WFtoeXQ4OchsyO24t2
rxi682Zo9ViqmXZ+MSsjWKt1jdem4noaY=
. IN NS h.root-servers.net
. IN NS k.root-servers.net
. IN NS e.root-servers.net
. IN NS c.root-servers.net
. IN NS b.root-servers.net
. IN NS g.root-servers.net
. IN NS d.root-servers.net
. IN NS f.root-servers.net
. IN NS i.root-servers.net
. IN NS j.root-servers.net
. IN NS m.root-servers.net
. IN NS a.root-servers.net
. IN NS l.root-servers.net
. IN RRSIG NS RSASHA256 0 518400 20160206170000 20160127160000 54549
rxhmTVKUgs72G3VzL+1JRuD0nGLIrPM+ISfmUx0eYUH5wZD5XMu2X+8PfkAsEQT1dziPs
ac+zK1YZPbNgr3yGI5H/wEbK8S7DmlvO+/I9WKTLp/Zxn3yncvnTOdjFMZxkAqHbjVOm+
BFz7RjQuvCQlEJX4PQBFphgEnkiOnmMdI=
. IN NSEC aaa ( NS SOA RRSIG NSEC DNSKEY )
. IN RRSIG NSEC RSASHA256 0 86400 20160206170000 20160127160000 54549
HY49/nGkUJJP1zLmH33MIKnkNH33jQ7bsAHE9itEjvC4wfAzgq8+Oh9fjYav1R1GDeJ2Z
HOu3Z2uDRif10R8RsmZbxyZXJs7eHui9KcAMot1U4uKCCooC/5GImf+oUDbvaraUCMQRU
D3mUzoa0BGWfxgZEDqZ55raVFT/olEgG8=
. IN DNSKEY 257 3 RSASHA256 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0
O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0
NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL4
96M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1ap
AzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6
dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ2
5AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1
ihz0=
. IN DNSKEY 256 3 RSASHA256 AwEAAbr/RV0stAWYbmKOldjShp4AOQGOyY3ATI1NUpP4X1qBs
6lsXpc+1ABgv6zkg02IktjZrHnmD0HsElu3wqXMrT5KL1W7Sp
mg0Pou9WZ8QttdTKXwrVXrASsaGI2z/pLBSnK8EdzqUrTVxY4
TEGZtxV519isM06CCMihxTn5cfFBF
. IN RRSIG DNSKEY RSASHA256 0 172800 20160204235959 20160121000000 19036
XYewrVdYKRDfZptAATwT+W4zng04riExV36+z04kok09W0RmOtDlQrlrwHLlD2iN/zYpg
EqGgDF5T2xlrQdNpn+PFHhypHM7NQAgLTrwmiw6mGbV0bsZN3rhFxHwW7QVUFAvo9eNVu
INrjm+sArwxq3DnPkmA+3K4ikKD2iiT/jT91VYr9SHFqXXURccLjI+nmaE7m31hXcirX/
r5i3J+B4Fx4415IavSD72r7cmruocnCVjcp+ZAUKeMyW+RwigzevLz3oEcCZ4nrTpGLEj
wFaVePYoP+rfdmfLfTdmkkm4APRJa2My3XOdGFlgNS1pW1pH4az5LapLE2vMO7p1aQ==
-- Information acquired via protocol DNS in 14.4ms.
-- Data is authenticated: no
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.
This fills in the last few gaps:
- When checking if a domain is non-existing, also check that no wildcard for it exists
- Ensure we don't base "covering" tests on NSEC RRs from a parent zone
- Refuse to accept expanded wildcard NSEC RRs for absence proofs.
Having this information available is useful when we need to check whether various RRs are suitable for proofs. This
information is stored in the RRs as number of labels to skip from the beginning of the owner name to reach the
synthesizing source/signer. Simple accessor calls are then added to retrieve the signer/source from the RR using this
information.
This also moves validation of a a number of RRSIG parameters into a new call dnssec_rrsig_prepare() that as side-effect
initializes the two numeric values.
When validating a transaction we initially collect DNSKEY, DS, SOA RRs
in the "validated_keys" list, that we need for the proofs. This includes
DNSKEY and DS data from our trust anchor database. Quite possibly we
learn that some of these DNSKEY/DS RRs have been revoked between the
time we request and collect those additional RRs and we begin the
validation step. In this case we need to make sure that the respective
DS/DNSKEY RRs are removed again from our list. This patch adds that, and
strips known revoked trust anchor RRs from the validated list before we
begin the actual validation proof, and each time we add more DNSKEY
material to it while we are doing the proof.
This adds negative trust anchor support and allows reading trust anchor
data from disk, from files
/etc/systemd/dnssec-trust-anchors.d/*.positive and
/etc/systemd/dnssec-trust-anchros.d/*.negative, as well as the matching
counterparts in /usr/lib and /run.
The positive trust anchor files are more or less compatible to normal
DNS zone files containing DNSKEY and DS RRs. The negative trust anchor
files contain only new-line separated hostnames for which to require no
signing.
By default no trust anchor files are installed, in which case the
compiled-in root domain DS RR is used, as before. As soon as at least
one positive root anchor for the root is defined via trust anchor files
this buil-in DS RR is not added though.
We don't implement it, and we have no intention to, but at least mention
that it exists.
(This also adds a couple of other algorithms to the algorithm string
list, where these strings were missing previously.)
When we verified a signature, fix up the RR's TTL to the original TTL
mentioned in the signature, and store the signature expiry information
in the RR, too. Then, use that when adding RRs to the cache.
Let's simplify usage and memory management of DnsResourceRecord's
dns_resource_record_to_string() call: cache the formatted string as
part of the object, and return it on subsequent calls, freeing it when
the DnsResourceRecord itself is freed.
Let's make DNS class helpers more like DNS type helpers, let's move them
from resolved-dns-rr.[ch] into dns-type.[ch].
This also adds two new calls dns_class_is_pseudo() and
dns_class_is_valid_rr() which operate similar to dns_type_is_pseudo()
and dns_type_is_valid_rr() but for classes instead of types.
This should hopefully make handling of DNS classes and DNS types more
alike.
This large patch adds a couple of mechanisms to ensure we get NSEC3 and
proof-of-unsigned support into place. Specifically:
- Each item in an DnsAnswer gets two bit flags now:
DNS_ANSWER_AUTHENTICATED and DNS_ANSWER_CACHEABLE. The former is
necessary since DNS responses might contain signed as well as unsigned
RRsets in one, and we need to remember which ones are signed and which
ones aren't. The latter is necessary, since not we need to keep track
which RRsets may be cached and which ones may not be, even while
manipulating DnsAnswer objects.
- The .n_answer_cachable of DnsTransaction is dropped now (it used to
store how many of the first DnsAnswer entries are cachable), and
replaced by the DNS_ANSWER_CACHABLE flag instead.
- NSEC3 proofs are implemented now (lacking support for the wildcard
part, to be added in a later commit).
- Support for the "AD" bit has been dropped. It's unsafe, and now that
we have end-to-end authentication we don't need it anymore.
- An auxiliary DnsTransaction of a DnsTransactions is now kept around as
least as long as the latter stays around. We no longer remove the
auxiliary DnsTransaction as soon as it completed. THis is necessary,
as we now are interested not only in the RRsets it acquired but also
in its authentication status.
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.
After all, that's how this is done in DNS, and is particularly important
if we look a DS/DNSKEY RRs for the root zone itself, where the owner
name would otherwise be shown as completely empty (i.e. missing).
When iterating through RR lists we frequently end up comparing RRs and
RR keys with themselves, hence att a minor optimization to check ptr
values first, before doing a deep comparison.
Previously, we'd never do any single-label or root domain lookups via
DNS, thus leaving single-label lookups to LLMNR and the search path
logic in order that single-label names don't leak too easily onto the
internet. With this change we open things up a bit, and only prohibit
A/AAAA lookups of single-label/root domains, but allow all other
lookups. This should provide similar protection, but allow us to resolve
DNSKEY+DS RRs for the top-level and root domains.
(This also simplifies handling of the search domain detection, and gets
rid of dns_scope_has_search_domains() in favour of
dns_scope_get_search_domains()).
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.
