The argument only exists to be used to override/fill in the RRSIG record
of the answer item. Hence actually use it instead of ignore it.
(Not sure how this got lost earlier.)
Fixes: #18714
There's no "answer_auxiliary" object anymore, it's all one "answer"
object, and we have per-item flags that tell us which section things are
from, i.e. from the main answer section, or the additional or
authoritative ones.
CNAME following was broken by 775ae35403
where we'd not properly collect RRs along the CNAME path. Good thing
though is that we don't have to anymore: since we nowadays propagate all
sections of the upstream replies into the cache and back to stub clients
all the information should already be available anyway, and there's no
need for us to collect it.
Fixes: #18690
See https://bugzilla.redhat.com/show_bug.cgi?id=1893417 for the back story:
the fallback hostname matters a lot in certain environments. Right now the only
way to configure the fallback hostname is by recompiling systemd, which is
obviously problematic in case when the fallback hostname shall differ between
different editions of the same distro that share a single compiled rpm.
By making this overridable through an envvar, we're providing an escape hatch
without making this a top-level api. Later on a way to set this through
os-release is added, but I think the approach with the variable is still
useful. It it very convenient for testing, or to override settings only in a
particular service, etc.
The stub DNS server is authoritative for the RRs we synthesize, such as
localhost, _gateway, and entries from /etc/hosts, and also for trust anchors.
Partially fixes https://github.com/systemd/systemd/issues/17972
argv[0] might be prefixed by a path, and we shouldn't get confused by
that. Hence provide a simple helper call that abstracts the checking
away, which we can use everywhere, and expose the same behaviour, even
if argv[0] is not set.
(While we are at it, port all other multi-call binaries over to the new
helper, too)
Follow-up for: d41a9e4fc1
Fragmenting sucks, let's avoid it. Thus let's start tracking the maximum
fragment size we receive.
Also, let's redo a transaction via TCP if we see fragmenting on UDP, as
effective mitigation against DNS fragment attacks.
Let's take all MTU info we possibly have into account, i.e. the one
reported via netlink, as before and the one the socket might now (from
PMTUD and such), clamped by our own ideas.
We can later use this to adapt our announced EDNS buffer size in order
to avoid fragmentation to make the best of large datagrams while still
avoiding he security weaknesses of it.
This nicely covers the case when optarg is optional. The same parser can be
used when the option string passed to getopt_long() requires a parameter and
when it doesn't.
The error messages are made consistent.
Also fixes a log error c&p in --crash-reboot message.
If the server doesn't copy the DO bit from request to response, this is
a very early and easy indication that it doesn#t support DNSSEC
properly. Hence, let's immediately downgrade to non-DNSSEC mode if we
see this – if permissive mode is on and this is allowed.
This is an updated version of #8608 with more restrictive logic. To
quite the original bug:
Some captive portals, lie and do not respond with the captive portal
IP address, if the query is with EDNS0 enabled and D0 bit set to
zero. Thus retry "secure" domain name look ups with less secure
methods, upon NXDOMAIN.
https://github.com/dns-violations/dns-violations/blob/master/2018/DVE-2018-0001.md
Yes, this fix sucks hard, but I guess this is what we need to do to make
sure resolved works IRL.
Heavily based on the original patch from Dimitri John Ledkov, and I
copied the commentary verbatim.
Replaces: #8608
This adds minimal support for RFC5001 NSID to the stub resolver. This
useful to identify systemd-resolved when talking to the stub resolver,
and distuingishing the packets resolved answers itself (where NSID is
now set) from those which it proxies 1:1 upstream (where NSID will not
be set, or set to whatever the upstream server has it set to).
The NSID chosen consist of two parts:
1. The first part is derived from /etc/machine-id and identifies the
resolved instance in a stable way.
2. The second part is the fixed string ".resolved.systemd.io".
This thus maybe used for a veriety of checks:
a. Am I talking to a resolved stub?
b. Am I talking to the same stub as last time?
c. Am I talking to the local resolved?
Given that the first part leaks the identity of the system in away two
protections are in place:
I) The NSID is only included on the main stub, not the extra stub. The
main stub has with a TTL of 1 and other protections a lot of safety
in place that the datagrams never leave the local system, thus the
identifying info is only accessible to the local system — but
/etc/machine-id is accessible to local software anyway.
II) The NSID is hashed from /etc/machine-id in a non-invertable way, so
that the machine ID itself isn't leaked, but only an identifier
derived from it.
Example dig run:
```
$ dig +nsid localhost @127.0.0.53
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc33 <<>> +nsid localhost @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46917
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
; NSID: 35 33 64 34 61 34 66 63 32 31 32 65 34 31 61 30 39 66 30 39 65 33 32 34 63 64 64 38 30 36 32 33 2e 72 65 73 6f 6c 76 65 64 2e 73 79 73 74 65 6d 64 2e 69 6f ("53d4a4fc212e41a09f09e324cdd80623.resolved.systemd.io")
;; QUESTION SECTION:
;localhost. IN A
;; ANSWER SECTION:
localhost. 0 IN A 127.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Do Nov 12 20:57:16 CET 2020
;; MSG SIZE rcvd: 110
```
Zbigniew Jędrzejewski-Szmek
Joerg Behrmann
Sergey Bugaev
Lennart Poettering
Sven Mueller
Yu Watanabe
Benjamin Robin