| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
strv_consume() is pretty expensive when invoked piecemeal, hence optimize it a bit by pre-allocating a properly sized
array.
|
|
The link objects expose as properties the current settings made with SetLinkDNS() and related calls, plus some more
information.
|
|
various configuration files
|
|
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.
|
|
These were previously forgotten, add them now.
|
|
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.
|
|
|
|
This should be generally useful information, hence show it.
|
|
|
|
resolved: hide public mDNS configuration knobs for now
|
|
Remove gcc warnings v2
|
|
These bits were intenionally left out while mDNS is under development.
Remove the exposed knobs and man page entries again until this is settled.
|
|
Fixes #2366
|
|
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).
|
|
If the first step was done via a search domain, make sure the subsequent steps are not.
|
|
|
|
IDNA checks
|
|
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 the poinetrs are equal, we don't have to do a deep comparison.
This is similar to a similar optimization we already have in place for RRs and keys.
|
|
Also verify whether the DNS RR types are actually suitable for a question.
|
|
|
|
equivalent
|
|
Fifteenth batch of DNSSEC patches
|
|
64 bit offset is now accepted, which is nice. The old function is
deprecated, and generates a compile time warning when used. We only
use an offset of 0, so we really don't care. Adapt to use the new
function, but fall back to the old one on older versions.
|
|
src/journal-remote/journal-remote.c:590:13: warning: Value MHD_HTTP_METHOD_NOT_ACCEPTABLE is deprecated, use MHD_HTTP_NOT_ACCEPTABLE
return mhd_respond(connection, MHD_HTTP_METHOD_NOT_ACCEPTABLE,
^
The new define was added in 0.9.38. Instead of requiring the new
libmicrohttpd version, provide the fallback, it is trivial.
|
|
|
|
Little change in practice, because the program will exit soon
afterwards, but the standard style of closing all fds is now followed.
Also gets rid of gcc warning about fd_ctrl and fd_uevent being
unitialized.
|
|
|
|
manager_{start,stop}_{slice,scope,unit} functions had an optional job
output parameter. But all callers specified job, so make the parameter
mandatory, add asserts. Also extract common job variable handling to
a helper function to avoid duplication.
Avoids gcc warning about job being unitialized.
|
|
We requested various fields using SD_BUS_CREDS_AUGMENT but at least
sd_bus_creds_get_tty can fail with ENXIO, not setting the output variable.
|
|
|
|
Merge separate two error handling statements into two nested ifs.
This looks cleaner, and avoids a gcc warning about *prefix being
uninitialized.
While at it, fix identation of logging statements elsewhere in the
file.
|
|
If the initial allocation succeeded, there is no way to
fail, so cleanup function is not necessary.
|
|
The code is correct, assuming that the kernel does not feed
us garbled data. Let's initialize those variables to avoid the
warning anyway.
|
|
Setting of dst_id was based on interplay of two booleans,
making the logic hard to follow (for humans and compilers alike).
gcc was confused and emmitted a warning about an uninitialized
variable. Rework the code to make it obvious that dst_id is
set properly.
|
|
|
|
|
|
Not every byte sequence is valid utf8. We allow escaping of non-utf8
sequences in strings by using octal and hexadecimal escape sequences
(\123 and \0xAB) for bytes at or above 128. Users of cunescape_one
could infer whether such use occured when they received an answer
between 128 and 256 in *ret (a non-ascii one byte character). But this
is subtle and misleading: the comments were wrong, because ascii is a
subset of unicode, so c != 0 did not mean non-unicode, but rather
ascii-subset-of-unicode-or-raw-byte. This was all rather confusing, so
make the "single byte" condition explicit.
I'm not convinced that allowing non-utf8 sequences to be produced is
useful in all cases where we allow it (e.g. in config files), but that
behaviour is unchanged, just made more explicit.
This also fixes an (invalid) gcc warning about unitialized variable
(*ret_unicode) in callers of cunescape_one.
|
