mirror of
https://github.com/systemd/systemd
synced 2024-09-06 00:41:36 +00:00
resolved: rename "downgrade-ok" mode to "allow-downgrade"
After discussing this with Tom, we figured out "allow-downgrade" sounds nicer.
This commit is contained in:
parent
f41b446a76
commit
1ed8c0fbb4
|
@ -143,13 +143,13 @@
|
|||
<varlistentry>
|
||||
<term><varname>DNSSEC=</varname></term>
|
||||
<listitem><para>Takes a boolean argument or
|
||||
<literal>downgrade-ok</literal>. If true all DNS lookups are
|
||||
<literal>allow-downgrade</literal>. If true all DNS lookups are
|
||||
DNSSEC-validated locally (excluding LLMNR and Multicast
|
||||
DNS). If a response for a lookup request is detected invalid
|
||||
this is returned as lookup failure to applications. Note that
|
||||
this mode requires a DNS server that supports DNSSEC. If the
|
||||
DNS server does not properly support DNSSEC all validations
|
||||
will fail. If set to <literal>downgrade-ok</literal> DNSSEC
|
||||
will fail. If set to <literal>allow-downgrade</literal> DNSSEC
|
||||
validation is attempted, but if the server does not support
|
||||
DNSSEC properly, DNSSEC mode is automatically disabled. Note
|
||||
that this mode makes DNSSEC validation vulnerable to
|
||||
|
@ -176,7 +176,7 @@
|
|||
lookups will fail, as it cannot be proved anymore whether
|
||||
lookups are correctly signed, or validly unsigned. If
|
||||
<varname>DNSSEC=</varname> is set to
|
||||
<literal>downgrade-ok</literal> the resolver will
|
||||
<literal>allow-downgrade</literal> the resolver will
|
||||
automatically turn off DNSSEC validation in such a case.</para>
|
||||
|
||||
<para>Client programs looking up DNS data will be informed
|
||||
|
@ -193,7 +193,7 @@
|
|||
DNSSEC correctly, and where software or trust anchor updates
|
||||
happen regularly. On other systems it is recommended to set
|
||||
<varname>DNSSEC=</varname> to
|
||||
<literal>downgrade-ok</literal>.</para>
|
||||
<literal>allow-downgrade</literal>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
|
@ -1568,7 +1568,7 @@ int dnssec_test_nsec(DnsAnswer *answer, DnsResourceKey *key, DnssecNsecResult *r
|
|||
|
||||
static const char* const dnssec_mode_table[_DNSSEC_MODE_MAX] = {
|
||||
[DNSSEC_NO] = "no",
|
||||
[DNSSEC_DOWNGRADE_OK] = "downgrade-ok",
|
||||
[DNSSEC_ALLOW_DOWNGRADE] = "allow-downgrade",
|
||||
[DNSSEC_YES] = "yes",
|
||||
};
|
||||
DEFINE_STRING_TABLE_LOOKUP(dnssec_mode, DnssecMode);
|
||||
|
|
|
@ -37,7 +37,7 @@ enum DnssecMode {
|
|||
* DNSSEC properly, downgrade to non-DNSSEC operation. Of
|
||||
* course, we then are vulnerable to a downgrade attack, but
|
||||
* that's life and what is configured. */
|
||||
DNSSEC_DOWNGRADE_OK,
|
||||
DNSSEC_ALLOW_DOWNGRADE,
|
||||
|
||||
/* Insist on DNSSEC server support, and rather fail than downgrading. */
|
||||
DNSSEC_YES,
|
||||
|
|
|
@ -939,7 +939,7 @@ static int dns_transaction_prepare(DnsTransaction *t, usec_t ts) {
|
|||
* this means we cannot do any DNSSEC logic
|
||||
* anymore. */
|
||||
|
||||
if (t->scope->dnssec_mode == DNSSEC_DOWNGRADE_OK) {
|
||||
if (t->scope->dnssec_mode == DNSSEC_ALLOW_DOWNGRADE) {
|
||||
/* We are in downgrade mode. In this
|
||||
* case, synthesize an unsigned empty
|
||||
* response, so that the any lookup
|
||||
|
@ -2266,7 +2266,7 @@ int dns_transaction_validate_dnssec(DnsTransaction *t) {
|
|||
|
||||
dns_server_packet_rrsig_missing(t->server);
|
||||
|
||||
if (t->scope->dnssec_mode == DNSSEC_DOWNGRADE_OK) {
|
||||
if (t->scope->dnssec_mode == DNSSEC_ALLOW_DOWNGRADE) {
|
||||
|
||||
/* Downgrading is OK? If so, just consider the information unsigned */
|
||||
|
||||
|
|
Loading…
Reference in a new issue