Based on this patch i had submitted to RedHat
(https://issues.redhat.com/browse/RHEL-56280), i am submitting this
patch to this upstream systemd.
There is no way to explicitly enable/disable IPv6 AAAA queries.
Problem was that i am using RHEL9 and some applications does not use a
newer glibc that supports `no-aaaa` option in `/etc/resolv.conf`. So
some applications will still resolve IPv6 AAAA even with `no-aaaa`
option and it is inconsistent across the system where some work and some
don't.
So this systemd-resolved patch catch-all queries and disable IPv6 AAAA
queries for all applications in the OS by having an option
`RefuseRecordTypes=AAAA` to disable IPv6 AAAA queries.
Although https://github.com/systemd/systemd/pull/28136 tries to fix this
automatically but it still does not work with
`net.ipv6.conf.all.disable_ipv6 = 1`. Also tried with explicitly
removing the conditional and force set `family = AF_INET` and still
resolves AAAA records.
The issue is that i want to explicitly disable IPv6 AAAA queries instead
of systemd-resolved to figure out itself which address family it is
using, which always have problems.
Add a new method to io.systemd.Resolve.Monitor that allows subscribing
to changes in the systemd-resolved DNS configuration. The new method
emits the full DNS configuration (one entry for global configuration,
and one entry for each interface), any time the configuration is
updated.
The dbus property getter for DefaultRoute does not simply check
link->default_route. Instead, if l->default_route is not explicitly
configured, it checks dns_scope_is_default_route(l->unicast_scope).
Add a link_get_default_route() helper with this logic so that it can be
used for consistency.
We check this by opening a UDP socket and attempting to connect. We do
not send any traffic on it, but this will tell us if there are routes to
the DNS server.
This will be used in a later commit.
No functional change. Make it more clear that these varlink connections
are subscribed to query results. This prepares for adding SubscribeDNS
to the varlink API.
Given we have the generic interface, let's hook it up everywhere.
This doesnt bother with the Reload() call usually, since that's more
involved, but hooks up the other relevant functions where applicable.
Fixes#22575, as suggested by poettering in #35514.
Intended as a workaround for some buggy routers, which refuse to send empty
replies. If systemd-resolved starts two DnsTransactions, one for A and one
for AAAA, and the domain in question has no AAAA entry, then the server will
send a reply for A and no reply for AAAA. Correct behavior for the server would
be to send an empty reply for AAAA.
systemd-resolved would previously keep retrying the AAAA transaction, and
eventually timeout the whole query, returning an error to the caller.
Now, if the server replies to one query and not another, we cut short the
timeout and return the partial result. Returning the partial result allows
the rest of the system to keep working. It matches how e.g. glibc libnss_dns
behaves.
The values that were previously hardcoded in sd-varlink.c are now defined
in new varlink_set_info_systemd() and that function is called everywhere
where we create a server.
In https://bugzilla.redhat.com/show_bug.cgi?id=2322937 we're getting
an error message:
Okt 29 22:21:03 fedora systemd-resolved[29311]: Could not create manager: Cannot allocate memory
I expect that this actually comes from dnstls_manager_init(), the
openssl version. But without real logs it's hard to know for sure.
Use EIO instead of ENOMEM, because the problem is unlikely to be actually
related to memory.
We often used a pattern like if (!FLAGS_SET(flags, SD_JSON_FORMAT_OFF)),
which is rather verbose and also contains a double negative, which we try
to avoid. Add a little helper to avoid an explicit bit check.
This change clarifies an aditional thing: in some cases we treated
SD_JSON_FORMAT_OFF as a flag (flags & SD_JSON_FORMAT_OFF), while in other cases
we treated it as an independent enum value (flags == SD_JSON_FORMAT_OFF).
In the first form, flags like SD_JSON_FORMAT_SSE do _not_ turn the json
output on, while in the second form they do. Let's use the first form
everywhere.
No functional change intended.
Initially I wasn't sure if this helper should be made public or just internal,
but it seems such a common pattern that if we expose the flags, we might just
as well expose it too, to make life easier for any consumers.
CNAME doesn't exist at the zone apex. When we get an unsigned noerror
response to a direct query for a CNAME record, we don't yet know if this
name is zone apex. We already request the correct DS record in this
case, but previously skipped it at validation time, causing the answer
to appear bogus. Make sure to also consider the DS record for the query
name for negative replies.
Previously a full packet was cached only if the CD bit was set, but this
no longer corresponds to the cases where bypass is enabled.
Update the cache to retain a full packet in the cases where it might
actually be useful.
This is useful for a validating resolver to indicate to a non-validating
resolver when checking was disabled for the query. This matches the
behavior of the major public resovlers in response to queries with CD bu
tnot DO set.
Following 13e15dae9f, resolved does not forward the AD bit for bypass
queries, but resolved also didn't do it's own validation, making these
replies appear to never be authentic. We should enable validation for
bypass queries.
Let's disable our own validation when processing a +cd query, and also
ensure that it skips the cache so that we don't accidentally fail to
return inauthentic replies from upstream.
Previously, when we had a bypass transaction without cd, a cached,
authenticated, reply with cd could be served, leaving the cd bit
erroneously set in the reply. Only reply with a CD bit if the client
requested it.
Fixes: 13e15dae9f (resolved: clear the AD bit for bypass packets)
../src/resolve/resolved-bus.c: In function ‘call_link_method’:
../src/resolve/resolved-bus.c:1769:16: warning: ‘l’ may be used uninitialized [-Wmaybe-uninitialized]
1769 | return handler(message, l, error);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
../src/resolve/resolved-bus.c:1755:15: note: ‘l’ was declared here
1755 | Link *l;
| ^
../src/resolve/resolved-bus.c: In function ‘bus_method_get_link’:
../src/resolve/resolved-bus.c:1828:13: warning: ‘l’ may be used uninitialized [-Wmaybe-uninitialized]
1828 | p = link_bus_path(l);
| ^~~~~~~~~~~~~~~~
../src/resolve/resolved-bus.c:1816:15: note: ‘l’ was declared here
1816 | Link *l;
| ^