Age | Commit message (Collapse) | Author |
|
authenticated
Doing DNS retrieval on non-authenticated crypt keys is useless, hence warn
loudly about it.
|
|
Let's make sure DNSSEC gets more testing, by defaulting DNSSEC to
"allow-downgrade" mode. Since distros should probably not ship DNSSEC enabled
by default add a configure switch to disable this again.
DNSSEC in "allow-downgrade" mode should mostly work without affecting user
experience. There's one exception: some captive portal systems rewrite DNS in
order to redirect HTTP traffic to the captive portal. If these systems
implement DNS servers that are otherwise DNSSEC-capable (which in fact is
pretty unlikely, but still...), then this will result in the captive portal
being inaccessible. To fix this support in NetworkManager (or any other network
management solution that does captive portal detection) is required, which
simply turns off DNSSEC during the captive portal detection, and resets it back
to the default (i.e. on) after captive portal authentication is complete.
|
|
If the hostname passed to ResolveHostname() is actually an IP address that is
correctly formatted as string parse it as such, avoid any DNS traffic and
return the data in parsed form.
This is useful for clients which can simply call the bus function now without
caring about the precise formatting of specified hostnames. This mimics
getaddrinfo()'s behaviour with the AI_NUMERICHOST flag set.
Note that this logic is only implemented for ResolveHostname(), but not for
calls such as ResolveRecord(), for which only DNS domain names may be used as
input.
The "authenticated" flag is set for look-ups of this type, after all no
untrusted network traffic is involved.
|
|
Another property name fuck-up. The property contains both search and routing
domains and hence should be exposed as "Domains" rather than "SearchDomains".
The counterpart in the Link object was correctly named, and the
SetLinkDomains() and SetDomains() setter calls too, hence let's get this right,
too.
(Yepp, a minor API break actually, but given that this was so far not
documented, and only 3 days public let's fix this now)
|
|
|
|
By mistake the "DNSSECSupported" bus property of the Link object got named
"DNSSECSupport". Internally, it's named correctly, and the counterpart on the
"Manager" object got named correctly too.
Technically this rename is an API break, but given that the interface is not
documented or widely announced yet, and just 3 days in a published release,
let's just fix this, and hope nobody notices.
|
|
Better support of OPENPGPKEY, CAA, TLSA packets and tests
|
|
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
|
|
|
|
Also add example files with TLSA and SSHFP records.
|
|
|
|
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.
|
|
|
|
This makes the behaviour more consistent. Before we would not rewind
after some errors, but this seems to have been an unintentional
omission.
|
|
$ systemd-resolve --openpgp zbyszek@fedoraproject.org
d08ee310438ca124a6149ea5cc21b6313b390dce485576eff96f8722._openpgpkey.fedoraproject.org. IN OPENPGPKEY
mQINBFBHPMsBEACeInGYJCb+7TurKfb6wGyTottCDtiSJB310i37/6ZYoeIay/5soJjlM
yfMFQ9T2XNT/0LM6gTa0MpC1st9LnzYTMsT6tzRly1D1UbVI6xw0g0vE5y2Cjk3xUwAyn
...
|
|
It's annoying to have the exact same function in three places.
It's stored in src/shared, but it's not added to the library to
avoid the dependency on libgcrypt.
|
|
ISO/IEC 9899:1999 §7.21.1/2 says:
Where an argument declared as size_t n specifies the length of the array
for a function, n can have the value zero on a call to that
function. Unless explicitly stated otherwise in the description of a
particular function in this subclause, pointer arguments on such a call
shall still have valid values, as described in 7.1.4.
In base64_append_width memcpy was called as memcpy(x, NULL, 0). GCC 4.9
started making use of this and assumes This worked fine under -O0, but
does something strange under -O3.
This patch fixes a bug in base64_append_width(), fixes a possible bug in
journal_file_append_entry_internal(), and makes use of the new function
to simplify the code in other places.
|
|
|
|
This should be handled fine now by .dir-locals.el, so need to carry that
stuff in every file.
|
|
|
|
Fixes: #2361
|
|
|
|
Fixes: #2514
|
|
clang is apparently not smart enough to detect when a switch statement contains case statements for all possible values
of the used type. Work around that.
(And while we are at it, normalize indentation a bit)
Fixes: #2504
|
|
Previously, if a hostanem is resolved with AF_UNSPEC specified, this would be used as indication to resolve both an
AF_INET and an AF_INET6 address. With this change this logic is altered: an AF_INET address is only resolved if there's
actually a routable IPv4 address on the specific interface, and similar an AF_INET6 address is only resolved if there's
a routable IPv6 address. With this in place, it's ensured that the returned data is actually connectable by
applications. This logic mimics glibc's resolver behaviour.
Note that if the client asks explicitly for AF_INET or AF_INET6 it will get what it asked for.
This also simplifies the logic how it is determined whether a specific lookup shall take place on a scope.
Specifically, the checks with dns_scope_good_key() are now moved out of the transaction code and into the query code,
so that we don't even create a transaction object on a specific scope if we cannot execute the resolution on it anyway.
|
|
HAVE_IDN is not defined when systemd is build without it
|
|
|
|
|
|
It's not used anywhere else.
|
|
Preparation to make gcrypt optional.
|
|
I'm not defining _DNS_SERVER_TYPE_MAX/INVALID as usual in the enum,
because it wouldn't be used, and then gcc would complain that
various enums don't test for _DNS_SERVER_TYPE_MAX. It seems better
to define the macro rather than add assert_not_reached() in multiple
places.
|
|
For consistency, generic.size is renamed to generic.data_size.
nsec3.next_hashed_name comparison was missing a size check.
|
|
|
|
This mirrors the behaviour of host and makes the conversion to and from
string symmetrical.
|
|
|
|
|
|
|
|
Example output:
_443._tcp.fedoraproject.org IN TLSA 0 0 1 GUAL5bejH7czkXcAeJ0vCiRxwMnVBsDlBMBsFtfLF8A=
-- Cert. usage: CA constraint
-- Selector: Full Certificate
-- Matching type: SHA-256
|
|
|
|
|
|
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
|
|
Otherwise it's unclear if it's /etc/resolv.conf or some
other file that is meant.
|
|
From dd0bc0f1
|
|
This gets rid of the private DNSSEC TODO and moves it in the main TODO dump site, as the DNSSEC implementation is
pretty complete now, and the remaining bits are low-priority.
|
|
Lets make sure we always take notice of network changes before answering client requests.
This way, calls like SetLinkDNS() become race-free as the specified interface index is guarantee to have been processed
if it exists before we make changes to it.
|
|
DNS response
If we encounter NXDOMAIN, but find at least one matching RR in a response, then patch it to become SUCCESS. This should
clean up handling of CNAME/DNAMEs, and makes sure broken servers and those conforming to RFC 6604 are treated the same
way. The new behaviour opposes the logic suggested in RFC 6604, but given that some servers don't implement it
correctly, and given that in some ways the CNAME/DNAME chains will be incomplete anyway, and given that DNSSEC
generally only allows us to prove the first element of a CNAME/DNAME chain, this should simplify things for us.
|
|
|
|
Following the changes to expose the "routing" and "search" domain concepts in networkd, actually make resolved use
them. It will now use routing domains exclusively for making DNS routing decisions, and use search domains additionally
for extending single-label names.
|
|
Previously, .network files only knew a vaguely defined "Domains=" concept, for which the documentation declared it was
the "DNS domain" for the network connection, without specifying what that means.
With this the Domains setting is reworked, so that there are now "routing" domains and "search" domains. The former are
to be used by resolved to route DNS request to specific network interfaces, the latter is to be used for searching
single-label hostnames with (in addition to being used for routing). Both settings are configured in the "Domains="
setting. Normal domain names listed in it are now considered search domains (for compatibility with existing setups),
while those prefixed with "~" are considered routing domains only. To route all lookups to a specific interface the
routing domain "." may be used, referring to the root domain. An alternative syntax for this is the "*", as was already
implemented before using the "wildcard" domain concept.
This commit adds proper parsers for this new logic, and exposes this via the sd-network API. This information is not
used by resolved yet, this will be added in a later commit.
|
|
So far, abritrary NSEC and NSEC3 RRs were implicitly consider "primary" for any transaction, meaning we'd abort the
transaction immediately if we couldn't validate it. With this patch this logic is removed, and the NSEC/NSEC3 RRs will
not be considered primary anymore. This has the effect that they will be dropped from the message if they don't
validate, but processing continues. This is safe to do, as they are required anyway to validate positive wildcard and
negative responses, and if they are missing then, then message will be considered unsigned, which hence means the
outcome is effectively the same.
This is benefical in case the server sends us NSEC/NSEC3 RRs that are not directly related to the lookup we did, but
simply auxiliary information. Previously, if we couldn't authenticate those RRs we'd fail the entire lookup while with
this change we'll simply drop the auxiliary information and proceed without it.
|