2014-07-31 17:46:40 +02:00
|
|
|
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
|
|
|
|
|
|
|
|
/***
|
|
|
|
This file is part of systemd.
|
|
|
|
|
|
|
|
Copyright 2014 Lennart Poettering
|
|
|
|
|
|
|
|
systemd is free software; you can redistribute it and/or modify it
|
|
|
|
under the terms of the GNU Lesser General Public License as published by
|
|
|
|
the Free Software Foundation; either version 2.1 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
systemd is distributed in the hope that it will be useful, but
|
|
|
|
WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
Lesser General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU Lesser General Public License
|
|
|
|
along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
***/
|
|
|
|
|
|
|
|
#include "af-list.h"
|
2015-10-27 03:01:06 +01:00
|
|
|
#include "alloc-util.h"
|
2015-08-21 22:55:01 +02:00
|
|
|
#include "dns-domain.h"
|
2015-10-25 13:14:12 +01:00
|
|
|
#include "fd-util.h"
|
|
|
|
#include "random-util.h"
|
2015-12-01 00:53:42 +01:00
|
|
|
#include "resolved-dns-cache.h"
|
2015-10-25 13:14:12 +01:00
|
|
|
#include "resolved-dns-transaction.h"
|
|
|
|
#include "resolved-llmnr.h"
|
2015-10-26 22:31:05 +01:00
|
|
|
#include "string-table.h"
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
DnsTransaction* dns_transaction_free(DnsTransaction *t) {
|
2015-11-25 20:47:27 +01:00
|
|
|
DnsQueryCandidate *c;
|
2014-07-31 17:46:40 +02:00
|
|
|
DnsZoneItem *i;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
DnsTransaction *z;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
if (!t)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
sd_event_source_unref(t->timeout_event_source);
|
|
|
|
|
|
|
|
dns_packet_unref(t->sent);
|
|
|
|
dns_packet_unref(t->received);
|
2015-11-26 22:51:35 +01:00
|
|
|
|
|
|
|
dns_answer_unref(t->answer);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-08-25 18:51:21 +02:00
|
|
|
sd_event_source_unref(t->dns_udp_event_source);
|
|
|
|
safe_close(t->dns_udp_fd);
|
2015-07-09 14:19:55 +02:00
|
|
|
|
2015-06-24 18:54:12 +02:00
|
|
|
dns_server_unref(t->server);
|
2014-07-31 17:46:40 +02:00
|
|
|
dns_stream_free(t->stream);
|
|
|
|
|
|
|
|
if (t->scope) {
|
2015-11-26 23:51:59 +01:00
|
|
|
hashmap_remove_value(t->scope->transactions_by_key, t->key, t);
|
|
|
|
LIST_REMOVE(transactions_by_scope, t->scope->transactions, t);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
if (t->id != 0)
|
|
|
|
hashmap_remove(t->scope->manager->dns_transactions, UINT_TO_PTR(t->id));
|
|
|
|
}
|
|
|
|
|
2015-08-24 23:15:51 +02:00
|
|
|
dns_resource_key_unref(t->key);
|
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
while ((c = set_steal_first(t->notify_query_candidates)))
|
2015-11-25 20:47:27 +01:00
|
|
|
set_remove(c->transactions, t);
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
set_free(t->notify_query_candidates);
|
2015-11-25 20:47:27 +01:00
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
while ((i = set_steal_first(t->notify_zone_items)))
|
2014-07-31 17:46:40 +02:00
|
|
|
i->probe_transaction = NULL;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
set_free(t->notify_zone_items);
|
|
|
|
|
|
|
|
while ((z = set_steal_first(t->notify_transactions)))
|
|
|
|
set_remove(z->dnssec_transactions, t);
|
|
|
|
set_free(t->notify_transactions);
|
|
|
|
|
|
|
|
while ((z = set_steal_first(t->dnssec_transactions))) {
|
|
|
|
set_remove(z->notify_transactions, t);
|
|
|
|
dns_transaction_gc(z);
|
|
|
|
}
|
|
|
|
set_free(t->dnssec_transactions);
|
|
|
|
|
|
|
|
dns_answer_unref(t->validated_keys);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-12-18 14:20:03 +01:00
|
|
|
free(t->key_string);
|
2014-07-31 17:46:40 +02:00
|
|
|
free(t);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_TRIVIAL_CLEANUP_FUNC(DnsTransaction*, dns_transaction_free);
|
|
|
|
|
|
|
|
void dns_transaction_gc(DnsTransaction *t) {
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
if (t->block_gc > 0)
|
|
|
|
return;
|
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
if (set_isempty(t->notify_query_candidates) &&
|
|
|
|
set_isempty(t->notify_zone_items) &&
|
|
|
|
set_isempty(t->notify_transactions))
|
2014-07-31 17:46:40 +02:00
|
|
|
dns_transaction_free(t);
|
|
|
|
}
|
|
|
|
|
2015-08-21 22:55:01 +02:00
|
|
|
int dns_transaction_new(DnsTransaction **ret, DnsScope *s, DnsResourceKey *key) {
|
2014-07-31 17:46:40 +02:00
|
|
|
_cleanup_(dns_transaction_freep) DnsTransaction *t = NULL;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(ret);
|
|
|
|
assert(s);
|
2015-08-21 22:55:01 +02:00
|
|
|
assert(key);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-12-09 19:08:45 +01:00
|
|
|
/* Don't allow looking up invalid or pseudo RRs */
|
2015-12-10 15:01:04 +01:00
|
|
|
if (!dns_type_is_valid_query(key->type))
|
2015-12-09 19:08:45 +01:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* We only support the IN class */
|
2015-12-10 15:01:04 +01:00
|
|
|
if (key->class != DNS_CLASS_IN && key->class != DNS_CLASS_ANY)
|
2015-12-09 19:08:45 +01:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2014-08-13 01:00:18 +02:00
|
|
|
r = hashmap_ensure_allocated(&s->manager->dns_transactions, NULL);
|
2014-07-31 17:46:40 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
2015-11-26 23:51:59 +01:00
|
|
|
r = hashmap_ensure_allocated(&s->transactions_by_key, &dns_resource_key_hash_ops);
|
2015-08-24 23:15:51 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
t = new0(DnsTransaction, 1);
|
|
|
|
if (!t)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2015-08-25 18:51:21 +02:00
|
|
|
t->dns_udp_fd = -1;
|
2015-11-26 23:33:55 +01:00
|
|
|
t->answer_source = _DNS_TRANSACTION_SOURCE_INVALID;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
t->dnssec_result = _DNSSEC_RESULT_INVALID;
|
2015-08-21 22:55:01 +02:00
|
|
|
t->key = dns_resource_key_ref(key);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-08-24 23:15:51 +02:00
|
|
|
/* Find a fresh, unused transaction id */
|
2014-07-31 17:46:40 +02:00
|
|
|
do
|
|
|
|
random_bytes(&t->id, sizeof(t->id));
|
|
|
|
while (t->id == 0 ||
|
|
|
|
hashmap_get(s->manager->dns_transactions, UINT_TO_PTR(t->id)));
|
|
|
|
|
|
|
|
r = hashmap_put(s->manager->dns_transactions, UINT_TO_PTR(t->id), t);
|
|
|
|
if (r < 0) {
|
|
|
|
t->id = 0;
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-11-26 23:51:59 +01:00
|
|
|
r = hashmap_replace(s->transactions_by_key, t->key, t);
|
2015-08-24 23:15:51 +02:00
|
|
|
if (r < 0) {
|
|
|
|
hashmap_remove(s->manager->dns_transactions, UINT_TO_PTR(t->id));
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-11-26 23:51:59 +01:00
|
|
|
LIST_PREPEND(transactions_by_scope, s->transactions, t);
|
2014-07-31 17:46:40 +02:00
|
|
|
t->scope = s;
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
*ret = t;
|
|
|
|
|
|
|
|
t = NULL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dns_transaction_stop(DnsTransaction *t) {
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
t->timeout_event_source = sd_event_source_unref(t->timeout_event_source);
|
|
|
|
t->stream = dns_stream_free(t->stream);
|
2015-11-26 22:51:35 +01:00
|
|
|
|
|
|
|
/* Note that we do not drop the UDP socket here, as we want to
|
|
|
|
* reuse it to repeat the interaction. */
|
2014-07-31 17:46:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void dns_transaction_tentative(DnsTransaction *t, DnsPacket *p) {
|
2014-08-06 17:21:00 +02:00
|
|
|
_cleanup_free_ char *pretty = NULL;
|
2014-07-31 17:46:40 +02:00
|
|
|
DnsZoneItem *z;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
assert(p);
|
|
|
|
|
|
|
|
if (manager_our_packet(t->scope->manager, p) != 0)
|
|
|
|
return;
|
|
|
|
|
2014-08-06 17:21:00 +02:00
|
|
|
in_addr_to_string(p->family, &p->sender, &pretty);
|
|
|
|
|
2015-12-18 14:20:03 +01:00
|
|
|
log_debug("Transaction %" PRIu16 " for <%s> on scope %s on %s/%s got tentative packet from %s.",
|
|
|
|
t->id,
|
|
|
|
dns_transaction_key_string(t),
|
2014-07-31 17:46:40 +02:00
|
|
|
dns_protocol_to_string(t->scope->protocol),
|
|
|
|
t->scope->link ? t->scope->link->name : "*",
|
2014-08-06 17:21:00 +02:00
|
|
|
t->scope->family == AF_UNSPEC ? "*" : af_to_name(t->scope->family),
|
|
|
|
pretty);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2014-08-06 16:15:35 +02:00
|
|
|
/* RFC 4795, Section 4.1 says that the peer with the
|
|
|
|
* lexicographically smaller IP address loses */
|
2014-08-10 22:48:16 +02:00
|
|
|
if (memcmp(&p->sender, &p->destination, FAMILY_ADDRESS_SIZE(p->family)) >= 0) {
|
|
|
|
log_debug("Peer has lexicographically larger IP address and thus lost in the conflict.");
|
2014-08-06 16:15:35 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-08-10 22:48:16 +02:00
|
|
|
log_debug("We have the lexicographically larger IP address and thus lost in the conflict.");
|
2014-08-06 16:15:35 +02:00
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
t->block_gc++;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
while ((z = set_first(t->notify_zone_items))) {
|
2014-08-10 22:28:12 +02:00
|
|
|
/* First, make sure the zone item drops the reference
|
|
|
|
* to us */
|
|
|
|
dns_zone_item_probe_stop(z);
|
|
|
|
|
|
|
|
/* Secondly, report this as conflict, so that we might
|
|
|
|
* look for a different hostname */
|
2014-07-31 17:46:40 +02:00
|
|
|
dns_zone_item_conflict(z);
|
2014-08-10 22:28:12 +02:00
|
|
|
}
|
2014-07-31 17:46:40 +02:00
|
|
|
t->block_gc--;
|
|
|
|
|
|
|
|
dns_transaction_gc(t);
|
|
|
|
}
|
|
|
|
|
|
|
|
void dns_transaction_complete(DnsTransaction *t, DnsTransactionState state) {
|
2015-11-25 20:47:27 +01:00
|
|
|
DnsQueryCandidate *c;
|
2014-07-31 17:46:40 +02:00
|
|
|
DnsZoneItem *z;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
DnsTransaction *d;
|
2014-07-31 17:46:40 +02:00
|
|
|
Iterator i;
|
|
|
|
|
|
|
|
assert(t);
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
assert(!DNS_TRANSACTION_IS_LIVE(state));
|
2014-08-05 17:02:23 +02:00
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
/* Note that this call might invalidate the query. Callers
|
|
|
|
* should hence not attempt to access the query or transaction
|
|
|
|
* after calling this function. */
|
|
|
|
|
2015-12-18 14:20:03 +01:00
|
|
|
log_debug("Transaction %" PRIu16 " for <%s> on scope %s on %s/%s now complete with <%s> from %s (%s).",
|
|
|
|
t->id,
|
|
|
|
dns_transaction_key_string(t),
|
2014-07-31 17:46:40 +02:00
|
|
|
dns_protocol_to_string(t->scope->protocol),
|
|
|
|
t->scope->link ? t->scope->link->name : "*",
|
|
|
|
t->scope->family == AF_UNSPEC ? "*" : af_to_name(t->scope->family),
|
2015-11-26 23:33:55 +01:00
|
|
|
dns_transaction_state_to_string(state),
|
2015-12-18 14:20:03 +01:00
|
|
|
t->answer_source < 0 ? "none" : dns_transaction_source_to_string(t->answer_source),
|
|
|
|
t->answer_authenticated ? "authenticated" : "unsigned");
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
t->state = state;
|
|
|
|
|
|
|
|
dns_transaction_stop(t);
|
|
|
|
|
|
|
|
/* Notify all queries that are interested, but make sure the
|
|
|
|
* transaction isn't freed while we are still looking at it */
|
|
|
|
t->block_gc++;
|
2015-12-18 14:23:48 +01:00
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
SET_FOREACH(c, t->notify_query_candidates, i)
|
|
|
|
dns_query_candidate_notify(c);
|
|
|
|
SET_FOREACH(z, t->notify_zone_items, i)
|
|
|
|
dns_zone_item_notify(z);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-12-18 14:23:48 +01:00
|
|
|
if (!set_isempty(t->notify_transactions)) {
|
|
|
|
DnsTransaction **nt;
|
|
|
|
unsigned j, n = 0;
|
|
|
|
|
|
|
|
/* We need to be careful when notifying other
|
|
|
|
* transactions, as that might destroy other
|
|
|
|
* transactions in our list. Hence, in order to be
|
|
|
|
* able to safely iterate through the list of
|
|
|
|
* transactions, take a GC lock on all of them
|
|
|
|
* first. Then, in a second loop, notify them, but
|
|
|
|
* first unlock that specific transaction. */
|
|
|
|
|
|
|
|
nt = newa(DnsTransaction*, set_size(t->notify_transactions));
|
|
|
|
SET_FOREACH(d, t->notify_transactions, i) {
|
|
|
|
nt[n++] = d;
|
|
|
|
d->block_gc++;
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(n == set_size(t->notify_transactions));
|
|
|
|
|
|
|
|
for (j = 0; j < n; j++) {
|
|
|
|
if (set_contains(t->notify_transactions, nt[j]))
|
|
|
|
dns_transaction_notify(nt[j], t);
|
|
|
|
|
|
|
|
nt[j]->block_gc--;
|
|
|
|
dns_transaction_gc(nt[j]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
t->block_gc--;
|
2014-07-31 17:46:40 +02:00
|
|
|
dns_transaction_gc(t);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int on_stream_complete(DnsStream *s, int error) {
|
|
|
|
_cleanup_(dns_packet_unrefp) DnsPacket *p = NULL;
|
|
|
|
DnsTransaction *t;
|
|
|
|
|
|
|
|
assert(s);
|
|
|
|
assert(s->transaction);
|
|
|
|
|
|
|
|
/* Copy the data we care about out of the stream before we
|
|
|
|
* destroy it. */
|
|
|
|
t = s->transaction;
|
|
|
|
p = dns_packet_ref(s->read_packet);
|
|
|
|
|
|
|
|
t->stream = dns_stream_free(t->stream);
|
|
|
|
|
|
|
|
if (error != 0) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-08-06 16:15:35 +02:00
|
|
|
if (dns_packet_validate_reply(p) <= 0) {
|
2015-09-03 12:04:31 +02:00
|
|
|
log_debug("Invalid TCP reply packet.");
|
2014-08-06 16:15:35 +02:00
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_INVALID_REPLY);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
dns_scope_check_conflicts(t->scope, p);
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
t->block_gc++;
|
|
|
|
dns_transaction_process_reply(t, p);
|
|
|
|
t->block_gc--;
|
|
|
|
|
|
|
|
/* If the response wasn't useful, then complete the transition now */
|
|
|
|
if (t->state == DNS_TRANSACTION_PENDING)
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_INVALID_REPLY);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dns_transaction_open_tcp(DnsTransaction *t) {
|
2015-07-25 05:12:49 +02:00
|
|
|
DnsServer *server = NULL;
|
2014-07-31 17:46:40 +02:00
|
|
|
_cleanup_close_ int fd = -1;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
if (t->stream)
|
|
|
|
return 0;
|
|
|
|
|
2015-07-11 22:21:26 +02:00
|
|
|
switch (t->scope->protocol) {
|
|
|
|
case DNS_PROTOCOL_DNS:
|
2015-06-24 18:54:12 +02:00
|
|
|
fd = dns_scope_tcp_socket(t->scope, AF_UNSPEC, NULL, 53, &server);
|
2015-07-11 22:21:26 +02:00
|
|
|
break;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-07-11 22:21:26 +02:00
|
|
|
case DNS_PROTOCOL_LLMNR:
|
2015-08-21 12:26:34 +02:00
|
|
|
/* When we already received a reply to this (but it was truncated), send to its sender address */
|
2014-07-31 17:46:40 +02:00
|
|
|
if (t->received)
|
2015-06-24 18:54:12 +02:00
|
|
|
fd = dns_scope_tcp_socket(t->scope, t->received->family, &t->received->sender, t->received->sender_port, NULL);
|
2014-07-31 17:46:40 +02:00
|
|
|
else {
|
|
|
|
union in_addr_union address;
|
2015-03-27 12:02:49 +01:00
|
|
|
int family = AF_UNSPEC;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
/* Otherwise, try to talk to the owner of a
|
|
|
|
* the IP address, in case this is a reverse
|
|
|
|
* PTR lookup */
|
2015-08-21 22:55:01 +02:00
|
|
|
|
|
|
|
r = dns_name_address(DNS_RESOURCE_KEY_NAME(t->key), &family, &address);
|
2014-07-31 17:46:40 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r == 0)
|
|
|
|
return -EINVAL;
|
2015-08-21 22:51:05 +02:00
|
|
|
if (family != t->scope->family)
|
2015-08-24 23:47:28 +02:00
|
|
|
return -ESRCH;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-06-24 18:54:12 +02:00
|
|
|
fd = dns_scope_tcp_socket(t->scope, family, &address, LLMNR_PORT, NULL);
|
2014-07-31 17:46:40 +02:00
|
|
|
}
|
2015-07-11 22:21:26 +02:00
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2014-07-31 17:46:40 +02:00
|
|
|
return -EAFNOSUPPORT;
|
2015-07-11 22:21:26 +02:00
|
|
|
}
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
if (fd < 0)
|
|
|
|
return fd;
|
|
|
|
|
|
|
|
r = dns_stream_new(t->scope->manager, &t->stream, t->scope->protocol, fd);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
fd = -1;
|
|
|
|
|
|
|
|
r = dns_stream_write_packet(t->stream, t->sent);
|
|
|
|
if (r < 0) {
|
|
|
|
t->stream = dns_stream_free(t->stream);
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-06-24 18:54:12 +02:00
|
|
|
dns_server_unref(t->server);
|
|
|
|
t->server = dns_server_ref(server);
|
2014-07-31 17:46:40 +02:00
|
|
|
t->received = dns_packet_unref(t->received);
|
2015-11-26 22:51:35 +01:00
|
|
|
t->answer = dns_answer_unref(t->answer);
|
2015-12-11 13:36:25 +01:00
|
|
|
t->n_answer_cacheable = 0;
|
2015-11-26 22:51:35 +01:00
|
|
|
t->answer_rcode = 0;
|
2014-07-31 17:46:40 +02:00
|
|
|
t->stream->complete = on_stream_complete;
|
|
|
|
t->stream->transaction = t;
|
|
|
|
|
|
|
|
/* The interface index is difficult to determine if we are
|
|
|
|
* connecting to the local host, hence fill this in right away
|
|
|
|
* instead of determining it from the socket */
|
|
|
|
if (t->scope->link)
|
|
|
|
t->stream->ifindex = t->scope->link->ifindex;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-07-25 04:45:26 +02:00
|
|
|
static void dns_transaction_next_dns_server(DnsTransaction *t) {
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
t->server = dns_server_unref(t->server);
|
2015-08-25 18:51:21 +02:00
|
|
|
t->dns_udp_event_source = sd_event_source_unref(t->dns_udp_event_source);
|
|
|
|
t->dns_udp_fd = safe_close(t->dns_udp_fd);
|
2015-07-25 04:45:26 +02:00
|
|
|
|
|
|
|
dns_scope_next_dns_server(t->scope);
|
|
|
|
}
|
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
static void dns_transaction_cache_answer(DnsTransaction *t) {
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
/* For mDNS we cache whenever we get the packet, rather than
|
|
|
|
* in each transaction. */
|
|
|
|
if (!IN_SET(t->scope->protocol, DNS_PROTOCOL_DNS, DNS_PROTOCOL_LLMNR))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* We never cache if this packet is from the local host, under
|
|
|
|
* the assumption that a locally running DNS server would
|
|
|
|
* cache this anyway, and probably knows better when to flush
|
|
|
|
* the cache then we could. */
|
|
|
|
if (!DNS_PACKET_SHALL_CACHE(t->received))
|
|
|
|
return;
|
|
|
|
|
|
|
|
dns_cache_put(&t->scope->cache,
|
|
|
|
t->key,
|
|
|
|
t->answer_rcode,
|
|
|
|
t->answer,
|
2015-12-11 13:36:25 +01:00
|
|
|
t->n_answer_cacheable,
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
t->answer_authenticated,
|
|
|
|
0,
|
|
|
|
t->received->family,
|
|
|
|
&t->received->sender);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dns_transaction_process_dnssec(DnsTransaction *t) {
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
/* Are there ongoing DNSSEC transactions? If so, let's wait for them. */
|
|
|
|
if (!set_isempty(t->dnssec_transactions))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* All our auxiliary DNSSEC transactions are complete now. Try
|
|
|
|
* to validate our RRset now. */
|
|
|
|
r = dns_transaction_validate_dnssec(t);
|
|
|
|
if (r < 0) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!IN_SET(t->dnssec_result, _DNSSEC_RESULT_INVALID, DNSSEC_VALIDATED, DNSSEC_NO_SIGNATURE /* FOR NOW! */)) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_DNSSEC_FAILED);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
dns_transaction_cache_answer(t);
|
|
|
|
|
|
|
|
if (t->answer_rcode == DNS_RCODE_SUCCESS)
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_SUCCESS);
|
|
|
|
else
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_FAILURE);
|
|
|
|
}
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
void dns_transaction_process_reply(DnsTransaction *t, DnsPacket *p) {
|
2015-07-28 02:32:24 +02:00
|
|
|
usec_t ts;
|
2014-07-31 17:46:40 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
assert(p);
|
|
|
|
assert(t->state == DNS_TRANSACTION_PENDING);
|
2015-07-28 02:32:24 +02:00
|
|
|
assert(t->scope);
|
|
|
|
assert(t->scope->manager);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
/* Note that this call might invalidate the query. Callers
|
|
|
|
* should hence not attempt to access the query or transaction
|
|
|
|
* after calling this function. */
|
|
|
|
|
2015-12-09 18:00:58 +01:00
|
|
|
log_debug("Processing incoming packet on transaction %" PRIu16".", t->id);
|
|
|
|
|
2015-07-11 22:21:26 +02:00
|
|
|
switch (t->scope->protocol) {
|
2015-12-09 18:00:58 +01:00
|
|
|
|
2015-07-11 22:21:26 +02:00
|
|
|
case DNS_PROTOCOL_LLMNR:
|
2014-07-31 17:46:40 +02:00
|
|
|
assert(t->scope->link);
|
|
|
|
|
|
|
|
/* For LLMNR we will not accept any packets from other
|
|
|
|
* interfaces */
|
|
|
|
|
|
|
|
if (p->ifindex != t->scope->link->ifindex)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (p->family != t->scope->family)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Tentative packets are not full responses but still
|
|
|
|
* useful for identifying uniqueness conflicts during
|
|
|
|
* probing. */
|
2015-07-11 02:35:16 +02:00
|
|
|
if (DNS_PACKET_LLMNR_T(p)) {
|
2014-07-31 17:46:40 +02:00
|
|
|
dns_transaction_tentative(t, p);
|
|
|
|
return;
|
|
|
|
}
|
2015-07-11 22:21:26 +02:00
|
|
|
|
|
|
|
break;
|
|
|
|
|
2015-07-11 02:44:46 +02:00
|
|
|
case DNS_PROTOCOL_MDNS:
|
|
|
|
assert(t->scope->link);
|
|
|
|
|
|
|
|
/* For mDNS we will not accept any packets from other interfaces */
|
|
|
|
if (p->ifindex != t->scope->link->ifindex)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (p->family != t->scope->family)
|
|
|
|
return;
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
2015-07-11 22:21:26 +02:00
|
|
|
case DNS_PROTOCOL_DNS:
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2015-08-04 10:37:59 +02:00
|
|
|
assert_not_reached("Invalid DNS protocol.");
|
2014-07-31 17:46:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (t->received != p) {
|
|
|
|
dns_packet_unref(t->received);
|
|
|
|
t->received = dns_packet_ref(p);
|
|
|
|
}
|
|
|
|
|
2015-11-26 23:33:55 +01:00
|
|
|
t->answer_source = DNS_TRANSACTION_NETWORK;
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
if (p->ipproto == IPPROTO_TCP) {
|
|
|
|
if (DNS_PACKET_TC(p)) {
|
|
|
|
/* Truncated via TCP? Somebody must be fucking with us */
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_INVALID_REPLY);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DNS_PACKET_ID(p) != t->id) {
|
|
|
|
/* Not the reply to our query? Somebody must be fucking with us */
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_INVALID_REPLY);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
sd-event: make sure sd_event_now() cannot fail
Previously, if the event loop never ran before sd_event_now() would
fail. With this change it will instead fall back to invoking now(). This
way, the function cannot fail anymore, except for programming error when
invoking it with wrong parameters.
This takes into account the fact that many callers did not handle the
error condition correctly, and if the callers did, then they kept simply
invoking now() as fall back on their own. Hence let's shorten the code
using this call, and make things more robust, and let's just fall back
to now() internally.
Whether now() is used or the cache timestamp may still be detected via
the return value of sd_event_now(). If > 0 is returned, then the fall
back to now() was used, if == 0 is returned, then the cached value was
returned.
This patch also simplifies many of the invocations of sd_event_now():
the manual fall back to now() can be removed. Also, in cases where the
call is invoked withing void functions we can now protect the invocation
via assert_se(), acknowledging the fact that the call cannot fail
anymore except for programming errors with the parameters.
This change is inspired by #841.
2015-08-03 17:29:09 +02:00
|
|
|
assert_se(sd_event_now(t->scope->manager->event, clock_boottime_or_monotonic(), &ts) >= 0);
|
2015-07-28 02:32:24 +02:00
|
|
|
|
|
|
|
switch (t->scope->protocol) {
|
2015-12-09 17:49:05 +01:00
|
|
|
|
2015-07-28 02:32:24 +02:00
|
|
|
case DNS_PROTOCOL_DNS:
|
|
|
|
assert(t->server);
|
|
|
|
|
2015-07-16 14:39:55 +02:00
|
|
|
if (IN_SET(DNS_PACKET_RCODE(p), DNS_RCODE_FORMERR, DNS_RCODE_SERVFAIL, DNS_RCODE_NOTIMP)) {
|
|
|
|
|
2015-12-09 17:49:05 +01:00
|
|
|
/* Request failed, immediately try again with reduced features */
|
2015-07-16 14:39:55 +02:00
|
|
|
log_debug("Server returned error: %s", dns_rcode_to_string(DNS_PACKET_RCODE(p)));
|
|
|
|
|
|
|
|
dns_server_packet_failed(t->server, t->current_features);
|
|
|
|
|
|
|
|
r = dns_transaction_go(t);
|
|
|
|
if (r < 0) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
} else
|
resolved: announce support for large UDP packets
This is often needed for proper DNSSEC support, and even to handle AAAA records
without falling back to TCP.
If the path between the client and server is fully compliant, this should always
work, however, that is not the case, and overlarge packets will get mysteriously
lost in some cases.
For that reason, we use a similar fallback mechanism as we do for palin EDNS0,
EDNS0+DO, etc.:
The large UDP size feature is different from the other supported feature, as we
cannot simply verify that it works based on receiving a reply (as the server
will usually send us much smaller packets than what we claim to support, so
simply receiving a reply does not mean much).
For that reason, we keep track of the largest UDP packet we ever received, as this
is the smallest known good size (defaulting to the standard 512 bytes). If
announcing the default large size of 4096 fails (in the same way as the other
features), we fall back to the known good size. The same logic of retrying after a
grace-period applies.
2015-07-06 16:48:24 +02:00
|
|
|
dns_server_packet_received(t->server, t->current_features, ts - t->start_usec, p->size);
|
2015-07-28 02:32:24 +02:00
|
|
|
|
|
|
|
break;
|
2015-12-09 17:49:05 +01:00
|
|
|
|
2015-07-28 02:32:24 +02:00
|
|
|
case DNS_PROTOCOL_LLMNR:
|
|
|
|
case DNS_PROTOCOL_MDNS:
|
|
|
|
dns_scope_packet_received(t->scope, ts - t->start_usec);
|
|
|
|
break;
|
2015-12-09 17:49:05 +01:00
|
|
|
|
2015-07-28 02:32:24 +02:00
|
|
|
default:
|
2015-12-09 17:49:05 +01:00
|
|
|
assert_not_reached("Invalid DNS protocol.");
|
2015-07-28 02:32:24 +02:00
|
|
|
}
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
if (DNS_PACKET_TC(p)) {
|
2015-09-03 12:09:11 +02:00
|
|
|
|
|
|
|
/* Truncated packets for mDNS are not allowed. Give up immediately. */
|
|
|
|
if (t->scope->protocol == DNS_PROTOCOL_MDNS) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_INVALID_REPLY);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
/* Response was truncated, let's try again with good old TCP */
|
|
|
|
r = dns_transaction_open_tcp(t);
|
|
|
|
if (r == -ESRCH) {
|
|
|
|
/* No servers found? Damn! */
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_NO_SERVERS);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (r < 0) {
|
2015-12-09 17:49:05 +01:00
|
|
|
/* On LLMNR, if we cannot connect to the host,
|
2014-07-31 17:46:40 +02:00
|
|
|
* we immediately give up */
|
|
|
|
if (t->scope->protocol == DNS_PROTOCOL_LLMNR) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* On DNS, couldn't send? Try immediately again, with a new server */
|
2015-07-25 04:45:26 +02:00
|
|
|
dns_transaction_next_dns_server(t);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
r = dns_transaction_go(t);
|
|
|
|
if (r < 0) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-09 17:49:05 +01:00
|
|
|
/* Parse message, if it isn't parsed yet. */
|
2014-07-31 17:46:40 +02:00
|
|
|
r = dns_packet_extract(p);
|
|
|
|
if (r < 0) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_INVALID_REPLY);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-12-09 18:00:58 +01:00
|
|
|
if (IN_SET(t->scope->protocol, DNS_PROTOCOL_DNS, DNS_PROTOCOL_LLMNR)) {
|
|
|
|
|
2015-09-03 12:09:11 +02:00
|
|
|
/* Only consider responses with equivalent query section to the request */
|
2015-12-09 17:49:05 +01:00
|
|
|
r = dns_packet_is_reply_for(p, t->key);
|
|
|
|
if (r < 0) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (r == 0) {
|
2015-09-03 12:09:11 +02:00
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_INVALID_REPLY);
|
|
|
|
return;
|
|
|
|
}
|
2015-07-09 02:58:15 +02:00
|
|
|
|
2015-09-03 12:09:11 +02:00
|
|
|
/* Install the answer as answer to the transaction */
|
|
|
|
dns_answer_unref(t->answer);
|
|
|
|
t->answer = dns_answer_ref(p->answer);
|
|
|
|
t->answer_rcode = DNS_PACKET_RCODE(p);
|
|
|
|
t->answer_authenticated = t->scope->dnssec_mode == DNSSEC_TRUST && DNS_PACKET_AD(p);
|
|
|
|
|
2015-12-11 13:36:25 +01:00
|
|
|
/* According to RFC 4795, section 2.9. only the RRs
|
|
|
|
* from the answer section shall be cached. However,
|
|
|
|
* if we know the message is authenticated, we might
|
|
|
|
* as well cache everything. */
|
|
|
|
if (t->answer_authenticated)
|
|
|
|
t->n_answer_cacheable = (unsigned) -1; /* everything! */
|
|
|
|
else
|
|
|
|
t->n_answer_cacheable = DNS_PACKET_ANCOUNT(t->received); /* only the answer section */
|
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
r = dns_transaction_request_dnssec_keys(t);
|
|
|
|
if (r < 0) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (r > 0) {
|
|
|
|
/* There are DNSSEC transactions pending now. Update the state accordingly. */
|
|
|
|
t->state = DNS_TRANSACTION_VALIDATING;
|
2015-12-18 14:26:48 +01:00
|
|
|
dns_transaction_stop(t);
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
return;
|
|
|
|
}
|
2015-09-03 12:09:11 +02:00
|
|
|
}
|
2014-07-31 17:46:40 +02:00
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
dns_transaction_process_dnssec(t);
|
2014-07-31 17:46:40 +02:00
|
|
|
}
|
|
|
|
|
2015-07-27 20:18:43 +02:00
|
|
|
static int on_dns_packet(sd_event_source *s, int fd, uint32_t revents, void *userdata) {
|
|
|
|
_cleanup_(dns_packet_unrefp) DnsPacket *p = NULL;
|
|
|
|
DnsTransaction *t = userdata;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
assert(t->scope);
|
|
|
|
|
|
|
|
r = manager_recv(t->scope->manager, fd, DNS_PROTOCOL_DNS, &p);
|
|
|
|
if (r <= 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
if (dns_packet_validate_reply(p) > 0 &&
|
2015-07-28 02:32:24 +02:00
|
|
|
DNS_PACKET_ID(p) == t->id)
|
2015-07-27 20:18:43 +02:00
|
|
|
dns_transaction_process_reply(t, p);
|
2015-07-28 02:32:24 +02:00
|
|
|
else
|
2015-12-09 17:49:05 +01:00
|
|
|
log_debug("Invalid DNS packet, ignoring.");
|
2015-07-27 20:18:43 +02:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-07-15 19:22:29 +02:00
|
|
|
static int dns_transaction_emit(DnsTransaction *t) {
|
2015-07-27 20:18:43 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
2015-07-15 19:22:29 +02:00
|
|
|
if (t->scope->protocol == DNS_PROTOCOL_DNS && !t->server) {
|
|
|
|
DnsServer *server = NULL;
|
|
|
|
_cleanup_close_ int fd = -1;
|
2015-07-27 20:18:43 +02:00
|
|
|
|
2015-07-15 19:22:29 +02:00
|
|
|
fd = dns_scope_udp_dns_socket(t->scope, &server);
|
|
|
|
if (fd < 0)
|
|
|
|
return fd;
|
2015-07-27 20:18:43 +02:00
|
|
|
|
2015-08-25 18:51:21 +02:00
|
|
|
r = sd_event_add_io(t->scope->manager->event, &t->dns_udp_event_source, fd, EPOLLIN, on_dns_packet, t);
|
2015-07-15 19:22:29 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
2015-07-27 20:18:43 +02:00
|
|
|
|
2015-08-25 18:51:21 +02:00
|
|
|
t->dns_udp_fd = fd;
|
2015-07-15 19:22:29 +02:00
|
|
|
fd = -1;
|
|
|
|
t->server = dns_server_ref(server);
|
|
|
|
}
|
2015-07-27 20:18:43 +02:00
|
|
|
|
2015-06-23 23:06:09 +02:00
|
|
|
r = dns_scope_emit(t->scope, t->dns_udp_fd, t->server, t->sent);
|
2015-07-15 19:22:29 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
2015-07-27 20:18:43 +02:00
|
|
|
|
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches
will implement the reset of that scheme.
If we get a server error back, or if after several attempts we don't
get a reply at all, we switch from UDP to TCP for the given
server for the current and all subsequent requests. However, if
we ever successfully received a reply over UDP, we never fall
back to TCP, and once a grace-period has passed, we try to upgrade
again to using UDP. The grace-period starts off at five minutes
after the current feature level was verified and then grows
exponentially to six hours. This is to mitigate problems due
to temporary lack of network connectivity, but at the same time
avoid flooding the network with retries when the feature attempted
feature level genuinely does not work.
Note that UDP is likely much more commonly supported than TCP,
but depending on the path between the client and the server, we
may have more luck with TCP in case something is wrong. We really
do prefer UDP though, as that is much more lightweight, that is
why TCP is only the last resort.
[0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
2015-07-06 08:15:25 +02:00
|
|
|
if (t->server)
|
|
|
|
t->current_features = t->server->possible_features;
|
|
|
|
|
2015-07-15 19:22:29 +02:00
|
|
|
return 0;
|
2015-07-27 20:18:43 +02:00
|
|
|
}
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
static int on_transaction_timeout(sd_event_source *s, usec_t usec, void *userdata) {
|
|
|
|
DnsTransaction *t = userdata;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(s);
|
|
|
|
assert(t);
|
|
|
|
|
2015-08-25 17:57:58 +02:00
|
|
|
if (!t->initial_jitter_scheduled || t->initial_jitter_elapsed) {
|
|
|
|
/* Timeout reached? Increase the timeout for the server used */
|
|
|
|
switch (t->scope->protocol) {
|
|
|
|
case DNS_PROTOCOL_DNS:
|
|
|
|
assert(t->server);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-08-25 17:57:58 +02:00
|
|
|
dns_server_packet_lost(t->server, t->current_features, usec - t->start_usec);
|
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches
will implement the reset of that scheme.
If we get a server error back, or if after several attempts we don't
get a reply at all, we switch from UDP to TCP for the given
server for the current and all subsequent requests. However, if
we ever successfully received a reply over UDP, we never fall
back to TCP, and once a grace-period has passed, we try to upgrade
again to using UDP. The grace-period starts off at five minutes
after the current feature level was verified and then grows
exponentially to six hours. This is to mitigate problems due
to temporary lack of network connectivity, but at the same time
avoid flooding the network with retries when the feature attempted
feature level genuinely does not work.
Note that UDP is likely much more commonly supported than TCP,
but depending on the path between the client and the server, we
may have more luck with TCP in case something is wrong. We really
do prefer UDP though, as that is much more lightweight, that is
why TCP is only the last resort.
[0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
2015-07-06 08:15:25 +02:00
|
|
|
|
2015-08-25 17:57:58 +02:00
|
|
|
break;
|
|
|
|
case DNS_PROTOCOL_LLMNR:
|
|
|
|
case DNS_PROTOCOL_MDNS:
|
|
|
|
dns_scope_packet_lost(t->scope, usec - t->start_usec);
|
2015-07-28 02:32:24 +02:00
|
|
|
|
2015-08-25 17:57:58 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
assert_not_reached("Invalid DNS protocol.");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (t->initial_jitter_scheduled)
|
|
|
|
t->initial_jitter_elapsed = true;
|
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches
will implement the reset of that scheme.
If we get a server error back, or if after several attempts we don't
get a reply at all, we switch from UDP to TCP for the given
server for the current and all subsequent requests. However, if
we ever successfully received a reply over UDP, we never fall
back to TCP, and once a grace-period has passed, we try to upgrade
again to using UDP. The grace-period starts off at five minutes
after the current feature level was verified and then grows
exponentially to six hours. This is to mitigate problems due
to temporary lack of network connectivity, but at the same time
avoid flooding the network with retries when the feature attempted
feature level genuinely does not work.
Note that UDP is likely much more commonly supported than TCP,
but depending on the path between the client and the server, we
may have more luck with TCP in case something is wrong. We really
do prefer UDP though, as that is much more lightweight, that is
why TCP is only the last resort.
[0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
2015-07-06 08:15:25 +02:00
|
|
|
}
|
|
|
|
|
2015-12-18 14:26:48 +01:00
|
|
|
log_debug("Timeout reached on transaction %" PRIu16 ".", t->id);
|
|
|
|
|
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches
will implement the reset of that scheme.
If we get a server error back, or if after several attempts we don't
get a reply at all, we switch from UDP to TCP for the given
server for the current and all subsequent requests. However, if
we ever successfully received a reply over UDP, we never fall
back to TCP, and once a grace-period has passed, we try to upgrade
again to using UDP. The grace-period starts off at five minutes
after the current feature level was verified and then grows
exponentially to six hours. This is to mitigate problems due
to temporary lack of network connectivity, but at the same time
avoid flooding the network with retries when the feature attempted
feature level genuinely does not work.
Note that UDP is likely much more commonly supported than TCP,
but depending on the path between the client and the server, we
may have more luck with TCP in case something is wrong. We really
do prefer UDP though, as that is much more lightweight, that is
why TCP is only the last resort.
[0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
2015-07-06 08:15:25 +02:00
|
|
|
/* ...and try again with a new server */
|
|
|
|
dns_transaction_next_dns_server(t);
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
r = dns_transaction_go(t);
|
|
|
|
if (r < 0)
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-07-28 02:32:24 +02:00
|
|
|
static usec_t transaction_get_resend_timeout(DnsTransaction *t) {
|
|
|
|
assert(t);
|
|
|
|
assert(t->scope);
|
|
|
|
|
|
|
|
switch (t->scope->protocol) {
|
|
|
|
case DNS_PROTOCOL_DNS:
|
|
|
|
assert(t->server);
|
|
|
|
|
|
|
|
return t->server->resend_timeout;
|
|
|
|
case DNS_PROTOCOL_MDNS:
|
2015-08-28 16:48:37 +02:00
|
|
|
assert(t->n_attempts > 0);
|
|
|
|
return (1 << (t->n_attempts - 1)) * USEC_PER_SEC;
|
|
|
|
case DNS_PROTOCOL_LLMNR:
|
2015-07-28 02:32:24 +02:00
|
|
|
return t->scope->resend_timeout;
|
|
|
|
default:
|
|
|
|
assert_not_reached("Invalid DNS protocol.");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-10 11:25:26 +01:00
|
|
|
static int dns_transaction_prepare(DnsTransaction *t, usec_t ts) {
|
2014-07-31 17:46:40 +02:00
|
|
|
bool had_stream;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
had_stream = !!t->stream;
|
|
|
|
|
|
|
|
dns_transaction_stop(t);
|
|
|
|
|
|
|
|
if (t->n_attempts >= TRANSACTION_ATTEMPTS_MAX(t->scope->protocol)) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_ATTEMPTS_MAX_REACHED);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (t->scope->protocol == DNS_PROTOCOL_LLMNR && had_stream) {
|
|
|
|
/* If we already tried via a stream, then we don't
|
|
|
|
* retry on LLMNR. See RFC 4795, Section 2.7. */
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_ATTEMPTS_MAX_REACHED);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
t->n_attempts++;
|
2015-07-28 02:32:24 +02:00
|
|
|
t->start_usec = ts;
|
2014-07-31 17:46:40 +02:00
|
|
|
t->received = dns_packet_unref(t->received);
|
2015-11-26 22:51:35 +01:00
|
|
|
t->answer = dns_answer_unref(t->answer);
|
2015-12-11 13:36:25 +01:00
|
|
|
t->n_answer_cacheable = 0;
|
2015-11-26 22:51:35 +01:00
|
|
|
t->answer_rcode = 0;
|
2015-11-26 23:33:55 +01:00
|
|
|
t->answer_source = _DNS_TRANSACTION_SOURCE_INVALID;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-12-03 18:31:24 +01:00
|
|
|
/* Check the trust anchor. Do so only on classic DNS, since DNSSEC does not apply otherwise. */
|
|
|
|
if (t->scope->protocol == DNS_PROTOCOL_DNS) {
|
|
|
|
r = dns_trust_anchor_lookup(&t->scope->manager->trust_anchor, t->key, &t->answer);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r > 0) {
|
|
|
|
t->answer_rcode = DNS_RCODE_SUCCESS;
|
|
|
|
t->answer_source = DNS_TRANSACTION_TRUST_ANCHOR;
|
2015-12-03 21:04:52 +01:00
|
|
|
t->answer_authenticated = true;
|
2015-12-03 18:31:24 +01:00
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_SUCCESS);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check the zone, but only if this transaction is not used
|
2015-11-18 15:33:37 +01:00
|
|
|
* for probing or verifying a zone item. */
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
if (set_isempty(t->notify_zone_items)) {
|
2015-11-18 15:33:37 +01:00
|
|
|
|
2015-11-26 22:51:35 +01:00
|
|
|
r = dns_zone_lookup(&t->scope->zone, t->key, &t->answer, NULL, NULL);
|
2015-11-18 15:33:37 +01:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r > 0) {
|
2015-11-26 22:51:35 +01:00
|
|
|
t->answer_rcode = DNS_RCODE_SUCCESS;
|
2015-11-26 23:33:55 +01:00
|
|
|
t->answer_source = DNS_TRANSACTION_ZONE;
|
2015-12-03 21:04:52 +01:00
|
|
|
t->answer_authenticated = true;
|
2015-11-18 15:33:37 +01:00
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_SUCCESS);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-05 01:42:15 +02:00
|
|
|
/* Check the cache, but only if this transaction is not used
|
|
|
|
* for probing or verifying a zone item. */
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
if (set_isempty(t->notify_zone_items)) {
|
2014-08-01 18:09:07 +02:00
|
|
|
|
2014-08-05 01:42:15 +02:00
|
|
|
/* Before trying the cache, let's make sure we figured out a
|
|
|
|
* server to use. Should this cause a change of server this
|
|
|
|
* might flush the cache. */
|
|
|
|
dns_scope_get_dns_server(t->scope);
|
2014-08-01 18:09:07 +02:00
|
|
|
|
2014-08-05 01:42:15 +02:00
|
|
|
/* Let's then prune all outdated entries */
|
|
|
|
dns_cache_prune(&t->scope->cache);
|
|
|
|
|
2015-12-03 21:04:52 +01:00
|
|
|
r = dns_cache_lookup(&t->scope->cache, t->key, &t->answer_rcode, &t->answer, &t->answer_authenticated);
|
2014-08-05 01:42:15 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r > 0) {
|
2015-11-26 23:33:55 +01:00
|
|
|
t->answer_source = DNS_TRANSACTION_CACHE;
|
2015-11-26 22:51:35 +01:00
|
|
|
if (t->answer_rcode == DNS_RCODE_SUCCESS)
|
2014-08-05 01:42:15 +02:00
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_SUCCESS);
|
|
|
|
else
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_FAILURE);
|
|
|
|
return 0;
|
|
|
|
}
|
2014-07-31 17:46:40 +02:00
|
|
|
}
|
|
|
|
|
2015-11-30 19:06:36 +01:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-11-30 12:47:11 +01:00
|
|
|
static int dns_transaction_make_packet_mdns(DnsTransaction *t) {
|
|
|
|
|
|
|
|
_cleanup_(dns_packet_unrefp) DnsPacket *p = NULL;
|
2015-12-01 00:53:42 +01:00
|
|
|
bool add_known_answers = false;
|
2015-11-30 12:47:11 +01:00
|
|
|
DnsTransaction *other;
|
|
|
|
unsigned qdcount;
|
|
|
|
usec_t ts;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
assert(t->scope->protocol == DNS_PROTOCOL_MDNS);
|
|
|
|
|
2015-12-04 08:03:59 +01:00
|
|
|
/* Discard any previously prepared packet, so we can start over and coalesce again */
|
2015-11-30 12:47:11 +01:00
|
|
|
t->sent = dns_packet_unref(t->sent);
|
|
|
|
|
|
|
|
r = dns_packet_new_query(&p, t->scope->protocol, 0, false);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
r = dns_packet_append_key(p, t->key, NULL);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
qdcount = 1;
|
|
|
|
|
2015-12-01 00:53:42 +01:00
|
|
|
if (dns_key_is_shared(t->key))
|
|
|
|
add_known_answers = true;
|
|
|
|
|
2015-11-30 12:47:11 +01:00
|
|
|
/*
|
|
|
|
* For mDNS, we want to coalesce as many open queries in pending transactions into one single
|
|
|
|
* query packet on the wire as possible. To achieve that, we iterate through all pending transactions
|
|
|
|
* in our current scope, and see whether their timing contraints allow them to be sent.
|
|
|
|
*/
|
|
|
|
|
|
|
|
assert_se(sd_event_now(t->scope->manager->event, clock_boottime_or_monotonic(), &ts) >= 0);
|
|
|
|
|
|
|
|
LIST_FOREACH(transactions_by_scope, other, t->scope->transactions) {
|
|
|
|
|
|
|
|
/* Skip ourselves */
|
|
|
|
if (other == t)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (other->state != DNS_TRANSACTION_PENDING)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (other->next_attempt_after > ts)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (qdcount >= UINT16_MAX)
|
|
|
|
break;
|
|
|
|
|
|
|
|
r = dns_packet_append_key(p, other->key, NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we can't stuff more questions into the packet, just give up.
|
|
|
|
* One of the 'other' transactions will fire later and take care of the rest.
|
|
|
|
*/
|
|
|
|
if (r == -EMSGSIZE)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
2015-12-10 11:25:26 +01:00
|
|
|
r = dns_transaction_prepare(other, ts);
|
2015-11-30 12:47:11 +01:00
|
|
|
if (r <= 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ts += transaction_get_resend_timeout(other);
|
|
|
|
|
|
|
|
r = sd_event_add_time(
|
|
|
|
other->scope->manager->event,
|
|
|
|
&other->timeout_event_source,
|
|
|
|
clock_boottime_or_monotonic(),
|
|
|
|
ts, 0,
|
|
|
|
on_transaction_timeout, other);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
other->state = DNS_TRANSACTION_PENDING;
|
|
|
|
other->next_attempt_after = ts;
|
|
|
|
|
|
|
|
qdcount ++;
|
2015-12-01 00:53:42 +01:00
|
|
|
|
|
|
|
if (dns_key_is_shared(other->key))
|
|
|
|
add_known_answers = true;
|
2015-11-30 12:47:11 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
DNS_PACKET_HEADER(p)->qdcount = htobe16(qdcount);
|
|
|
|
|
2015-12-01 00:53:42 +01:00
|
|
|
/* Append known answer section if we're asking for any shared record */
|
|
|
|
if (add_known_answers) {
|
|
|
|
r = dns_cache_export_shared_to_packet(&t->scope->cache, p);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-11-30 12:47:11 +01:00
|
|
|
t->sent = p;
|
|
|
|
p = NULL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dns_transaction_make_packet(DnsTransaction *t) {
|
|
|
|
_cleanup_(dns_packet_unrefp) DnsPacket *p = NULL;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
if (t->scope->protocol == DNS_PROTOCOL_MDNS)
|
|
|
|
return dns_transaction_make_packet_mdns(t);
|
|
|
|
|
|
|
|
if (t->sent)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
r = dns_packet_new_query(&p, t->scope->protocol, 0, t->scope->dnssec_mode == DNSSEC_YES);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
r = dns_scope_good_key(t->scope, t->key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r == 0)
|
|
|
|
return -EDOM;
|
|
|
|
|
|
|
|
r = dns_packet_append_key(p, t->key, NULL);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
DNS_PACKET_HEADER(p)->qdcount = htobe16(1);
|
|
|
|
DNS_PACKET_HEADER(p)->id = t->id;
|
|
|
|
|
|
|
|
t->sent = p;
|
|
|
|
p = NULL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-11-30 19:06:36 +01:00
|
|
|
int dns_transaction_go(DnsTransaction *t) {
|
|
|
|
usec_t ts;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
assert_se(sd_event_now(t->scope->manager->event, clock_boottime_or_monotonic(), &ts) >= 0);
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
|
2015-12-10 11:25:26 +01:00
|
|
|
r = dns_transaction_prepare(t, ts);
|
2015-11-30 19:06:36 +01:00
|
|
|
if (r <= 0)
|
|
|
|
return r;
|
|
|
|
|
2015-12-18 14:20:03 +01:00
|
|
|
log_debug("Excercising transaction %" PRIu16 " for <%s> on scope %s on %s/%s.",
|
|
|
|
t->id,
|
|
|
|
dns_transaction_key_string(t),
|
|
|
|
dns_protocol_to_string(t->scope->protocol),
|
|
|
|
t->scope->link ? t->scope->link->name : "*",
|
|
|
|
t->scope->family == AF_UNSPEC ? "*" : af_to_name(t->scope->family));
|
2015-11-30 19:06:36 +01:00
|
|
|
|
2015-08-25 17:57:58 +02:00
|
|
|
if (!t->initial_jitter_scheduled &&
|
2015-08-25 14:08:29 +02:00
|
|
|
(t->scope->protocol == DNS_PROTOCOL_LLMNR ||
|
|
|
|
t->scope->protocol == DNS_PROTOCOL_MDNS)) {
|
|
|
|
usec_t jitter, accuracy;
|
2014-08-05 17:01:33 +02:00
|
|
|
|
|
|
|
/* RFC 4795 Section 2.7 suggests all queries should be
|
|
|
|
* delayed by a random time from 0 to JITTER_INTERVAL. */
|
|
|
|
|
2015-08-25 17:57:58 +02:00
|
|
|
t->initial_jitter_scheduled = true;
|
2014-08-05 17:01:33 +02:00
|
|
|
|
|
|
|
random_bytes(&jitter, sizeof(jitter));
|
2015-08-25 14:08:29 +02:00
|
|
|
|
|
|
|
switch (t->scope->protocol) {
|
|
|
|
case DNS_PROTOCOL_LLMNR:
|
|
|
|
jitter %= LLMNR_JITTER_INTERVAL_USEC;
|
|
|
|
accuracy = LLMNR_JITTER_INTERVAL_USEC;
|
|
|
|
break;
|
|
|
|
case DNS_PROTOCOL_MDNS:
|
|
|
|
jitter %= MDNS_JITTER_RANGE_USEC;
|
|
|
|
jitter += MDNS_JITTER_MIN_USEC;
|
|
|
|
accuracy = MDNS_JITTER_RANGE_USEC;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
assert_not_reached("bad protocol");
|
|
|
|
}
|
2014-08-05 17:01:33 +02:00
|
|
|
|
|
|
|
r = sd_event_add_time(
|
|
|
|
t->scope->manager->event,
|
|
|
|
&t->timeout_event_source,
|
|
|
|
clock_boottime_or_monotonic(),
|
2015-08-25 14:08:29 +02:00
|
|
|
ts + jitter, accuracy,
|
2014-08-05 17:01:33 +02:00
|
|
|
on_transaction_timeout, t);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
t->n_attempts = 0;
|
2015-11-30 22:35:51 +01:00
|
|
|
t->next_attempt_after = ts;
|
2014-08-05 17:01:33 +02:00
|
|
|
t->state = DNS_TRANSACTION_PENDING;
|
|
|
|
|
2015-08-25 14:08:29 +02:00
|
|
|
log_debug("Delaying %s transaction for " USEC_FMT "us.", dns_protocol_to_string(t->scope->protocol), jitter);
|
2014-08-05 17:01:33 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
/* Otherwise, we need to ask the network */
|
|
|
|
r = dns_transaction_make_packet(t);
|
|
|
|
if (r == -EDOM) {
|
|
|
|
/* Not the right request to make on this network?
|
|
|
|
* (i.e. an A request made on IPv6 or an AAAA request
|
|
|
|
* made on IPv4, on LLMNR or mDNS.) */
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_NO_SERVERS);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
if (t->scope->protocol == DNS_PROTOCOL_LLMNR &&
|
2015-08-21 22:55:01 +02:00
|
|
|
(dns_name_endswith(DNS_RESOURCE_KEY_NAME(t->key), "in-addr.arpa") > 0 ||
|
|
|
|
dns_name_endswith(DNS_RESOURCE_KEY_NAME(t->key), "ip6.arpa") > 0)) {
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
/* RFC 4795, Section 2.4. says reverse lookups shall
|
|
|
|
* always be made via TCP on LLMNR */
|
|
|
|
r = dns_transaction_open_tcp(t);
|
|
|
|
} else {
|
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches
will implement the reset of that scheme.
If we get a server error back, or if after several attempts we don't
get a reply at all, we switch from UDP to TCP for the given
server for the current and all subsequent requests. However, if
we ever successfully received a reply over UDP, we never fall
back to TCP, and once a grace-period has passed, we try to upgrade
again to using UDP. The grace-period starts off at five minutes
after the current feature level was verified and then grows
exponentially to six hours. This is to mitigate problems due
to temporary lack of network connectivity, but at the same time
avoid flooding the network with retries when the feature attempted
feature level genuinely does not work.
Note that UDP is likely much more commonly supported than TCP,
but depending on the path between the client and the server, we
may have more luck with TCP in case something is wrong. We really
do prefer UDP though, as that is much more lightweight, that is
why TCP is only the last resort.
[0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
2015-07-06 08:15:25 +02:00
|
|
|
/* Try via UDP, and if that fails due to large size or lack of
|
|
|
|
* support try via TCP */
|
2015-07-15 19:22:29 +02:00
|
|
|
r = dns_transaction_emit(t);
|
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches
will implement the reset of that scheme.
If we get a server error back, or if after several attempts we don't
get a reply at all, we switch from UDP to TCP for the given
server for the current and all subsequent requests. However, if
we ever successfully received a reply over UDP, we never fall
back to TCP, and once a grace-period has passed, we try to upgrade
again to using UDP. The grace-period starts off at five minutes
after the current feature level was verified and then grows
exponentially to six hours. This is to mitigate problems due
to temporary lack of network connectivity, but at the same time
avoid flooding the network with retries when the feature attempted
feature level genuinely does not work.
Note that UDP is likely much more commonly supported than TCP,
but depending on the path between the client and the server, we
may have more luck with TCP in case something is wrong. We really
do prefer UDP though, as that is much more lightweight, that is
why TCP is only the last resort.
[0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
2015-07-06 08:15:25 +02:00
|
|
|
if (r == -EMSGSIZE || r == -EAGAIN)
|
2014-07-31 17:46:40 +02:00
|
|
|
r = dns_transaction_open_tcp(t);
|
|
|
|
}
|
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches
will implement the reset of that scheme.
If we get a server error back, or if after several attempts we don't
get a reply at all, we switch from UDP to TCP for the given
server for the current and all subsequent requests. However, if
we ever successfully received a reply over UDP, we never fall
back to TCP, and once a grace-period has passed, we try to upgrade
again to using UDP. The grace-period starts off at five minutes
after the current feature level was verified and then grows
exponentially to six hours. This is to mitigate problems due
to temporary lack of network connectivity, but at the same time
avoid flooding the network with retries when the feature attempted
feature level genuinely does not work.
Note that UDP is likely much more commonly supported than TCP,
but depending on the path between the client and the server, we
may have more luck with TCP in case something is wrong. We really
do prefer UDP though, as that is much more lightweight, that is
why TCP is only the last resort.
[0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
2015-07-06 08:15:25 +02:00
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
if (r == -ESRCH) {
|
|
|
|
/* No servers to send this to? */
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_NO_SERVERS);
|
|
|
|
return 0;
|
2015-06-24 18:54:12 +02:00
|
|
|
} else if (r < 0) {
|
2014-08-05 04:15:45 +02:00
|
|
|
if (t->scope->protocol != DNS_PROTOCOL_DNS) {
|
|
|
|
dns_transaction_complete(t, DNS_TRANSACTION_RESOURCES);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
/* Couldn't send? Try immediately again, with a new server */
|
2015-07-25 04:45:26 +02:00
|
|
|
dns_transaction_next_dns_server(t);
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
return dns_transaction_go(t);
|
|
|
|
}
|
|
|
|
|
2015-11-30 22:35:51 +01:00
|
|
|
ts += transaction_get_resend_timeout(t);
|
|
|
|
|
2014-08-01 00:55:51 +02:00
|
|
|
r = sd_event_add_time(
|
|
|
|
t->scope->manager->event,
|
|
|
|
&t->timeout_event_source,
|
|
|
|
clock_boottime_or_monotonic(),
|
2015-11-30 22:35:51 +01:00
|
|
|
ts, 0,
|
2014-08-01 00:55:51 +02:00
|
|
|
on_transaction_timeout, t);
|
2014-07-31 17:46:40 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
t->state = DNS_TRANSACTION_PENDING;
|
2015-11-30 22:35:51 +01:00
|
|
|
t->next_attempt_after = ts;
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
static int dns_transaction_add_dnssec_transaction(DnsTransaction *t, DnsResourceKey *key, DnsTransaction **ret) {
|
|
|
|
DnsTransaction *aux;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
assert(ret);
|
|
|
|
assert(key);
|
|
|
|
|
|
|
|
aux = dns_scope_find_transaction(t->scope, key, true);
|
|
|
|
if (!aux) {
|
|
|
|
r = dns_transaction_new(&aux, t->scope, key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
} else {
|
|
|
|
if (set_contains(t->dnssec_transactions, aux)) {
|
|
|
|
*ret = aux;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
r = set_ensure_allocated(&t->dnssec_transactions, NULL);
|
|
|
|
if (r < 0)
|
|
|
|
goto gc;
|
|
|
|
|
|
|
|
r = set_ensure_allocated(&aux->notify_transactions, NULL);
|
|
|
|
if (r < 0)
|
|
|
|
goto gc;
|
|
|
|
|
|
|
|
r = set_put(t->dnssec_transactions, aux);
|
|
|
|
if (r < 0)
|
|
|
|
goto gc;
|
|
|
|
|
|
|
|
r = set_put(aux->notify_transactions, t);
|
|
|
|
if (r < 0) {
|
|
|
|
(void) set_remove(t->dnssec_transactions, aux);
|
|
|
|
goto gc;
|
|
|
|
}
|
|
|
|
|
|
|
|
*ret = aux;
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
gc:
|
|
|
|
dns_transaction_gc(aux);
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dns_transaction_request_dnssec_rr(DnsTransaction *t, DnsResourceKey *key) {
|
|
|
|
_cleanup_(dns_answer_unrefp) DnsAnswer *a = NULL;
|
|
|
|
DnsTransaction *aux;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
assert(key);
|
|
|
|
|
|
|
|
/* Try to get the data from the trust anchor */
|
|
|
|
r = dns_trust_anchor_lookup(&t->scope->manager->trust_anchor, key, &a);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r > 0) {
|
|
|
|
r = dns_answer_extend(&t->validated_keys, a);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This didn't work, ask for it via the network/cache then. */
|
|
|
|
r = dns_transaction_add_dnssec_transaction(t, key, &aux);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
if (aux->state == DNS_TRANSACTION_NULL) {
|
|
|
|
r = dns_transaction_go(aux);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int dns_transaction_request_dnssec_keys(DnsTransaction *t) {
|
|
|
|
DnsResourceRecord *rr;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
if (t->scope->dnssec_mode != DNSSEC_YES)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
DNS_ANSWER_FOREACH(rr, t->answer) {
|
|
|
|
|
|
|
|
switch (rr->key->type) {
|
|
|
|
|
|
|
|
case DNS_TYPE_RRSIG: {
|
|
|
|
/* For each RRSIG we request the matching DNSKEY */
|
|
|
|
_cleanup_(dns_resource_key_unrefp) DnsResourceKey *dnskey = NULL;
|
|
|
|
|
|
|
|
/* If this RRSIG is about a DNSKEY RR and the
|
|
|
|
* signer is the same as the owner, then we
|
|
|
|
* already have the DNSKEY, and we don't have
|
|
|
|
* to look for more. */
|
|
|
|
if (rr->rrsig.type_covered == DNS_TYPE_DNSKEY) {
|
|
|
|
r = dns_name_equal(rr->rrsig.signer, DNS_RESOURCE_KEY_NAME(rr->key));
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r > 0)
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If the signer is not a parent of the owner,
|
|
|
|
* then the signature is bogus, let's ignore
|
|
|
|
* it. */
|
|
|
|
r = dns_name_endswith(DNS_RESOURCE_KEY_NAME(rr->key), rr->rrsig.signer);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
dnskey = dns_resource_key_new(rr->key->class, DNS_TYPE_DNSKEY, rr->rrsig.signer);
|
|
|
|
if (!dnskey)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
log_debug("Requesting DNSKEY to validate transaction %" PRIu16" (key tag: %" PRIu16 ").", t->id, rr->rrsig.key_tag);
|
|
|
|
|
|
|
|
r = dns_transaction_request_dnssec_rr(t, dnskey);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case DNS_TYPE_DNSKEY: {
|
|
|
|
/* For each DNSKEY we request the matching DS */
|
|
|
|
_cleanup_(dns_resource_key_unrefp) DnsResourceKey *ds = NULL;
|
|
|
|
|
|
|
|
ds = dns_resource_key_new(rr->key->class, DNS_TYPE_DS, DNS_RESOURCE_KEY_NAME(rr->key));
|
|
|
|
if (!ds)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
log_debug("Requesting DS to validate transaction %" PRIu16" (key tag: %" PRIu16 ").", t->id, dnssec_keytag(rr));
|
|
|
|
|
|
|
|
r = dns_transaction_request_dnssec_rr(t, ds);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
break;
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
return !set_isempty(t->dnssec_transactions);
|
|
|
|
}
|
|
|
|
|
|
|
|
void dns_transaction_notify(DnsTransaction *t, DnsTransaction *source) {
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
assert(IN_SET(t->state, DNS_TRANSACTION_PENDING, DNS_TRANSACTION_VALIDATING));
|
|
|
|
assert(source);
|
|
|
|
|
|
|
|
/* Invoked whenever any of our auxiliary DNSSEC transactions
|
|
|
|
completed its work. We simply copy the answer from that
|
|
|
|
transaction over. */
|
|
|
|
|
|
|
|
if (source->state != DNS_TRANSACTION_SUCCESS) {
|
|
|
|
log_debug("Auxiliary DNSSEC RR query failed.");
|
|
|
|
t->dnssec_result = DNSSEC_FAILED_AUXILIARY;
|
|
|
|
} else {
|
|
|
|
r = dns_answer_extend(&t->validated_keys, source->answer);
|
|
|
|
if (r < 0) {
|
|
|
|
log_error_errno(r, "Failed to merge validated DNSSEC key data: %m");
|
|
|
|
t->dnssec_result = DNSSEC_FAILED_AUXILIARY;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Detach us from the DNSSEC transaction. */
|
|
|
|
(void) set_remove(t->dnssec_transactions, source);
|
|
|
|
(void) set_remove(source->notify_transactions, t);
|
|
|
|
|
|
|
|
/* If the state is still PENDING, we are still in the loop
|
|
|
|
* that adds further DNSSEC transactions, hence don't check if
|
|
|
|
* we are ready yet. If the state is VALIDATING however, we
|
|
|
|
* should check if we are complete now. */
|
|
|
|
if (t->state == DNS_TRANSACTION_VALIDATING)
|
|
|
|
dns_transaction_process_dnssec(t);
|
|
|
|
}
|
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
static int dns_transaction_is_primary_response(DnsTransaction *t, DnsResourceRecord *rr) {
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
assert(rr);
|
|
|
|
|
|
|
|
/* Check if the specified RR is the "primary" response,
|
|
|
|
* i.e. either matches the question precisely or is a
|
2015-12-14 21:22:40 +01:00
|
|
|
* CNAME/DNAME for it, or is any kind of NSEC/NSEC3 RR */
|
|
|
|
|
|
|
|
if (IN_SET(rr->key->type, DNS_TYPE_NSEC, DNS_TYPE_NSEC3))
|
|
|
|
return 1;
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
|
|
|
|
r = dns_resource_key_match_rr(t->key, rr, NULL);
|
|
|
|
if (r != 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
r = dns_resource_key_match_cname_or_dname(t->key, rr->key, NULL);
|
|
|
|
if (r != 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dns_transaction_validate_dnskey_by_ds(DnsTransaction *t) {
|
|
|
|
DnsResourceRecord *rr;
|
|
|
|
int ifindex, r;
|
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
/* Add all DNSKEY RRs from the answer that are validated by DS
|
|
|
|
* RRs from the list of validated keys to the lis of validated
|
|
|
|
* keys. */
|
|
|
|
|
|
|
|
DNS_ANSWER_FOREACH_IFINDEX(rr, ifindex, t->answer) {
|
|
|
|
|
|
|
|
r = dnssec_verify_dnskey_search(rr, t->validated_keys);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* If so, the DNSKEY is validated too. */
|
|
|
|
r = dns_answer_add_extend(&t->validated_keys, rr, ifindex);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
int dns_transaction_validate_dnssec(DnsTransaction *t) {
|
|
|
|
_cleanup_(dns_answer_unrefp) DnsAnswer *validated = NULL;
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
bool dnskeys_finalized = false;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
DnsResourceRecord *rr;
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
int r;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
/* We have now collected all DS and DNSKEY RRs in
|
|
|
|
* t->validated_keys, let's see which RRs we can now
|
|
|
|
* authenticate with that. */
|
|
|
|
|
|
|
|
if (t->scope->dnssec_mode != DNSSEC_YES)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Already validated */
|
|
|
|
if (t->dnssec_result != _DNSSEC_RESULT_INVALID)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (IN_SET(t->answer_source, DNS_TRANSACTION_ZONE, DNS_TRANSACTION_TRUST_ANCHOR)) {
|
|
|
|
t->dnssec_result = DNSSEC_VALIDATED;
|
|
|
|
t->answer_authenticated = true;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-12-18 14:20:03 +01:00
|
|
|
log_debug("Validating response from transaction %" PRIu16 " (%s).", t->id, dns_transaction_key_string(t));
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
|
|
|
|
/* First see if there are DNSKEYs we already known a validated DS for. */
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
r = dns_transaction_validate_dnskey_by_ds(t);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
|
|
|
|
for (;;) {
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
bool changed = false;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
|
|
|
|
DNS_ANSWER_FOREACH(rr, t->answer) {
|
|
|
|
DnssecResult result;
|
|
|
|
|
|
|
|
if (rr->key->type == DNS_TYPE_RRSIG)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
r = dnssec_verify_rrset_search(t->answer, rr->key, t->validated_keys, USEC_INFINITY, &result);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
if (log_get_max_level() >= LOG_DEBUG) {
|
|
|
|
_cleanup_free_ char *rrs = NULL;
|
|
|
|
|
|
|
|
(void) dns_resource_record_to_string(rr, &rrs);
|
|
|
|
log_debug("Looking at %s: %s", rrs ? strstrip(rrs) : "???", dnssec_result_to_string(result));
|
|
|
|
}
|
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
if (result == DNSSEC_VALIDATED) {
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
|
|
|
|
/* Add the validated RRset to the new list of validated RRsets */
|
|
|
|
r = dns_answer_copy_by_key(&validated, t->answer, rr->key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
if (rr->key->type == DNS_TYPE_DNSKEY) {
|
|
|
|
/* If we just validated a
|
|
|
|
* DNSKEY RRset, then let's
|
|
|
|
* add these keys to the set
|
|
|
|
* of validated keys for this
|
|
|
|
* transaction. */
|
|
|
|
|
|
|
|
r = dns_answer_copy_by_key(&t->validated_keys, t->answer, rr->key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now, remove this RRset from the RRs still to process */
|
|
|
|
r = dns_answer_remove_by_key(&t->answer, rr->key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
/* Exit the loop, we dropped something from the answer, start from the beginning */
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
changed = true;
|
|
|
|
break;
|
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
} else if (dnskeys_finalized) {
|
|
|
|
/* If we haven't read all DNSKEYs yet
|
|
|
|
* a negative result of the validation
|
|
|
|
* is irrelevant, as there might be
|
|
|
|
* more DNSKEYs coming. */
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
r = dns_transaction_is_primary_response(t, rr);
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r > 0) {
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
/* This is a primary response
|
|
|
|
* to our question, and it
|
|
|
|
* failed validation. That's
|
|
|
|
* fatal. */
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
t->dnssec_result = result;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
/* This is just some auxiliary
|
|
|
|
* data. Just remove the RRset and
|
|
|
|
* continue. */
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
r = dns_answer_remove_by_key(&t->answer, rr->key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
/* Exit the loop, we dropped something from the answer, start from the beginning */
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
changed = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (changed)
|
|
|
|
continue;
|
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
if (!dnskeys_finalized) {
|
|
|
|
/* OK, now we know we have added all DNSKEYs
|
|
|
|
* we possibly could to our validated
|
|
|
|
* list. Now run the whole thing once more,
|
|
|
|
* and strip everything we still cannot
|
|
|
|
* validate.
|
|
|
|
*/
|
|
|
|
dnskeys_finalized = true;
|
|
|
|
continue;
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
}
|
|
|
|
|
resolved: refactor DNSSEC answer validation
This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:
1. populate validated keys list for this transaction from DS RRs
2. as long as the following changes the unvalidated answer list:
2a. try to validate the first RRset we find in unvalidated answer
list
2b. if that worked: add to validated answer; if DNSKEY also add to
validated keys list; remove from unvalidated answer.
2c. continue at 2a, with the next RRset, or restart from the
beginning when we hit the end
3. as long as the following changes the unvalidated answer list:
3a. try to validate the first RRset again. This will necessarily
fail, but we learn the precise error
3b. If this was a "primary" response to the question, fail the
entire transaction. "Primary" in this context means that it is
directly a response to the query, or a CNAME/DNAME for it.
3c. Otherwise, remove the RRset from the unvalidated answer list.
Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.
Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.
2015-12-11 14:00:08 +01:00
|
|
|
/* We're done */
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
dns_answer_unref(t->answer);
|
|
|
|
t->answer = validated;
|
|
|
|
validated = NULL;
|
|
|
|
|
2015-12-11 13:36:25 +01:00
|
|
|
/* Everything that's now in t->answer is known to be good, hence cacheable. */
|
|
|
|
t->n_answer_cacheable = (unsigned) -1; /* everything! */
|
|
|
|
|
2015-12-14 21:26:42 +01:00
|
|
|
/* At this point the answer only contains validated
|
|
|
|
* RRsets. Now, let's see if it actually answers the question
|
|
|
|
* we asked. If so, great! If it doesn't, then see if
|
|
|
|
* NSEC/NSEC3 can prove this. */
|
|
|
|
r = dns_answer_match_key(t->answer, t->key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r > 0) {
|
|
|
|
/* Yes, it answer the question, everything is authenticated. */
|
|
|
|
t->dnssec_result = DNSSEC_VALIDATED;
|
|
|
|
t->answer_rcode = DNS_RCODE_SUCCESS;
|
|
|
|
t->answer_authenticated = true;
|
|
|
|
} else if (r == 0) {
|
|
|
|
DnssecNsecResult nr;
|
|
|
|
|
|
|
|
/* Bummer! Let's check NSEC/NSEC3 */
|
|
|
|
r = dnssec_test_nsec(t->answer, t->key, &nr);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
switch (nr) {
|
|
|
|
|
|
|
|
case DNSSEC_NSEC_NXDOMAIN:
|
|
|
|
/* NSEC proves the domain doesn't exist. Very good. */
|
|
|
|
t->dnssec_result = DNSSEC_VALIDATED;
|
|
|
|
t->answer_rcode = DNS_RCODE_NXDOMAIN;
|
|
|
|
t->answer_authenticated = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DNSSEC_NSEC_NODATA:
|
|
|
|
/* NSEC proves that there's no data here, very good. */
|
|
|
|
t->dnssec_result = DNSSEC_VALIDATED;
|
|
|
|
t->answer_rcode = DNS_RCODE_SUCCESS;
|
|
|
|
t->answer_authenticated = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DNSSEC_NSEC_NO_RR:
|
|
|
|
/* No NSEC data? Bummer! */
|
|
|
|
t->dnssec_result = DNSSEC_UNSIGNED;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DNSSEC_NSEC_FOUND:
|
|
|
|
/* NSEC says it needs to be there, but we couldn't find it? Bummer! */
|
|
|
|
t->dnssec_result = DNSSEC_NSEC_MISMATCH;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
assert_not_reached("Unexpected NSEC result.");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-12-18 14:20:03 +01:00
|
|
|
const char *dns_transaction_key_string(DnsTransaction *t) {
|
|
|
|
assert(t);
|
|
|
|
|
|
|
|
if (!t->key_string) {
|
|
|
|
if (dns_resource_key_to_string(t->key, &t->key_string) < 0)
|
|
|
|
return "n/a";
|
|
|
|
}
|
|
|
|
|
|
|
|
return strstrip(t->key_string);
|
|
|
|
}
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
static const char* const dns_transaction_state_table[_DNS_TRANSACTION_STATE_MAX] = {
|
|
|
|
[DNS_TRANSACTION_NULL] = "null",
|
|
|
|
[DNS_TRANSACTION_PENDING] = "pending",
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
[DNS_TRANSACTION_VALIDATING] = "validating",
|
2014-07-31 17:46:40 +02:00
|
|
|
[DNS_TRANSACTION_FAILURE] = "failure",
|
|
|
|
[DNS_TRANSACTION_SUCCESS] = "success",
|
|
|
|
[DNS_TRANSACTION_NO_SERVERS] = "no-servers",
|
|
|
|
[DNS_TRANSACTION_TIMEOUT] = "timeout",
|
|
|
|
[DNS_TRANSACTION_ATTEMPTS_MAX_REACHED] = "attempts-max-reached",
|
|
|
|
[DNS_TRANSACTION_INVALID_REPLY] = "invalid-reply",
|
|
|
|
[DNS_TRANSACTION_RESOURCES] = "resources",
|
|
|
|
[DNS_TRANSACTION_ABORTED] = "aborted",
|
resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabled
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
2015-12-09 18:13:16 +01:00
|
|
|
[DNS_TRANSACTION_DNSSEC_FAILED] = "dnssec-failed",
|
2014-07-31 17:46:40 +02:00
|
|
|
};
|
|
|
|
DEFINE_STRING_TABLE_LOOKUP(dns_transaction_state, DnsTransactionState);
|
2015-11-26 23:33:55 +01:00
|
|
|
|
|
|
|
static const char* const dns_transaction_source_table[_DNS_TRANSACTION_SOURCE_MAX] = {
|
|
|
|
[DNS_TRANSACTION_NETWORK] = "network",
|
|
|
|
[DNS_TRANSACTION_CACHE] = "cache",
|
|
|
|
[DNS_TRANSACTION_ZONE] = "zone",
|
2015-12-03 18:31:24 +01:00
|
|
|
[DNS_TRANSACTION_TRUST_ANCHOR] = "trust-anchor",
|
2015-11-26 23:33:55 +01:00
|
|
|
};
|
|
|
|
DEFINE_STRING_TABLE_LOOKUP(dns_transaction_source, DnsTransactionSource);
|