picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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:
Lennart Poettering 2016-01-05 17:44:16 +01:00
parent f41b446a76
commit 1ed8c0fbb4
4 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
man/resolved.conf.xml
View File

@ -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>

2
src/resolve/resolved-dns-dnssec.c
View File

@ -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);

2
src/resolve/resolved-dns-dnssec.h
View File

@ -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,

4
src/resolve/resolved-dns-transaction.c
View File

@ -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 */