2017-11-18 17:09:20 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1+ */
|
2014-07-31 17:46:40 +02:00
|
|
|
#pragma once
|
|
|
|
|
|
|
|
typedef struct DnsTransaction DnsTransaction;
|
|
|
|
typedef enum DnsTransactionState DnsTransactionState;
|
2015-11-26 23:33:55 +01:00
|
|
|
typedef enum DnsTransactionSource DnsTransactionSource;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
enum DnsTransactionState {
|
|
|
|
DNS_TRANSACTION_NULL,
|
|
|
|
DNS_TRANSACTION_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,
|
2015-12-18 19:49:25 +01:00
|
|
|
DNS_TRANSACTION_RCODE_FAILURE,
|
2014-07-31 17:46:40 +02:00
|
|
|
DNS_TRANSACTION_SUCCESS,
|
|
|
|
DNS_TRANSACTION_NO_SERVERS,
|
|
|
|
DNS_TRANSACTION_TIMEOUT,
|
|
|
|
DNS_TRANSACTION_ATTEMPTS_MAX_REACHED,
|
|
|
|
DNS_TRANSACTION_INVALID_REPLY,
|
2016-01-22 17:22:23 +01:00
|
|
|
DNS_TRANSACTION_ERRNO,
|
2014-07-31 17:46:40 +02:00
|
|
|
DNS_TRANSACTION_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,
|
2016-01-04 22:35:54 +01:00
|
|
|
DNS_TRANSACTION_NO_TRUST_ANCHOR,
|
2016-01-08 17:10:49 +01:00
|
|
|
DNS_TRANSACTION_RR_TYPE_UNSUPPORTED,
|
2016-01-20 21:28:22 +01:00
|
|
|
DNS_TRANSACTION_NETWORK_DOWN,
|
2016-01-22 12:09:38 +01:00
|
|
|
DNS_TRANSACTION_NOT_FOUND, /* like NXDOMAIN, but when LLMNR/TCP connections fail */
|
2014-07-31 17:46:40 +02:00
|
|
|
_DNS_TRANSACTION_STATE_MAX,
|
|
|
|
_DNS_TRANSACTION_STATE_INVALID = -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
|
|
|
#define DNS_TRANSACTION_IS_LIVE(state) IN_SET((state), DNS_TRANSACTION_NULL, DNS_TRANSACTION_PENDING, DNS_TRANSACTION_VALIDATING)
|
|
|
|
|
2015-11-26 23:33:55 +01:00
|
|
|
enum DnsTransactionSource {
|
|
|
|
DNS_TRANSACTION_NETWORK,
|
|
|
|
DNS_TRANSACTION_CACHE,
|
|
|
|
DNS_TRANSACTION_ZONE,
|
2015-12-03 18:31:24 +01:00
|
|
|
DNS_TRANSACTION_TRUST_ANCHOR,
|
2015-11-26 23:33:55 +01:00
|
|
|
_DNS_TRANSACTION_SOURCE_MAX,
|
|
|
|
_DNS_TRANSACTION_SOURCE_INVALID = -1
|
|
|
|
};
|
|
|
|
|
2015-11-18 22:46:33 +01:00
|
|
|
#include "resolved-dns-answer.h"
|
2014-07-31 17:46:40 +02:00
|
|
|
#include "resolved-dns-packet.h"
|
|
|
|
#include "resolved-dns-question.h"
|
2015-11-18 22:46:33 +01:00
|
|
|
#include "resolved-dns-scope.h"
|
2016-09-01 00:33:21 +02:00
|
|
|
#include "resolved-dns-server.h"
|
|
|
|
#include "resolved-dns-stream.h"
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
struct DnsTransaction {
|
|
|
|
DnsScope *scope;
|
|
|
|
|
2015-08-21 22:55:01 +02:00
|
|
|
DnsResourceKey *key;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
DnsTransactionState state;
|
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
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
uint16_t id;
|
|
|
|
|
2015-12-26 14:18:11 +01:00
|
|
|
bool tried_stream:1;
|
|
|
|
|
2015-12-18 14:22:46 +01:00
|
|
|
bool initial_jitter_scheduled:1;
|
|
|
|
bool initial_jitter_elapsed:1;
|
2014-08-05 17:01:33 +02:00
|
|
|
|
2016-06-20 21:24:46 +02:00
|
|
|
bool clamp_ttl:1;
|
|
|
|
|
2016-12-02 14:01:56 +01:00
|
|
|
bool probing:1;
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
DnsPacket *sent, *received;
|
2015-11-26 22:51:35 +01:00
|
|
|
|
|
|
|
DnsAnswer *answer;
|
|
|
|
int answer_rcode;
|
2015-12-18 20:09:30 +01:00
|
|
|
DnssecResult answer_dnssec_result;
|
2015-11-26 23:33:55 +01:00
|
|
|
DnsTransactionSource answer_source;
|
2016-01-05 01:35:28 +01:00
|
|
|
uint32_t answer_nsec_ttl;
|
2016-01-22 17:22:23 +01:00
|
|
|
int answer_errno; /* if state is DNS_TRANSACTION_ERRNO */
|
2015-12-18 14:37:06 +01:00
|
|
|
|
|
|
|
/* Indicates whether the primary answer is authenticated,
|
|
|
|
* i.e. whether the RRs from answer which directly match the
|
|
|
|
* question are authenticated, or, if there are none, whether
|
|
|
|
* the NODATA or NXDOMAIN case is. It says nothing about
|
|
|
|
* additional RRs listed in the answer, however they have
|
|
|
|
* their own DNS_ANSWER_AUTHORIZED FLAGS. Note that this bit
|
|
|
|
* is defined different than the AD bit in DNS packets, as
|
|
|
|
* that covers more than just the actual primary answer. */
|
2015-12-03 21:04:52 +01:00
|
|
|
bool answer_authenticated;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-12-18 14:37:06 +01:00
|
|
|
/* Contains DNSKEY, DS, SOA RRs we already verified and need
|
|
|
|
* to authenticate this reply */
|
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
|
|
|
DnsAnswer *validated_keys;
|
|
|
|
|
2015-07-28 02:32:24 +02:00
|
|
|
usec_t start_usec;
|
2015-11-30 22:35:51 +01:00
|
|
|
usec_t next_attempt_after;
|
2014-07-31 17:46:40 +02:00
|
|
|
sd_event_source *timeout_event_source;
|
|
|
|
unsigned n_attempts;
|
|
|
|
|
2017-12-08 19:48:15 +01:00
|
|
|
unsigned n_picked_servers;
|
|
|
|
|
2015-12-26 14:53:17 +01:00
|
|
|
/* UDP connection logic, if we need it */
|
2015-08-25 18:51:21 +02:00
|
|
|
int dns_udp_fd;
|
|
|
|
sd_event_source *dns_udp_event_source;
|
2015-07-09 14:19:55 +02:00
|
|
|
|
2015-12-26 14:53:17 +01:00
|
|
|
/* TCP connection logic, if we need it */
|
|
|
|
DnsStream *stream;
|
|
|
|
|
2015-08-25 18:51:21 +02:00
|
|
|
/* The active server */
|
2015-06-24 18:54:12 +02:00
|
|
|
DnsServer *server;
|
|
|
|
|
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
|
|
|
/* The features of the DNS server at time of transaction start */
|
2016-01-11 19:38:25 +01:00
|
|
|
DnsServerFeatureLevel current_feature_level;
|
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
|
|
|
|
2016-06-23 23:24:38 +02:00
|
|
|
/* If we got SERVFAIL back, we retry the lookup, using a lower feature level than we used before. */
|
|
|
|
DnsServerFeatureLevel clamp_feature_level;
|
|
|
|
|
2015-11-25 20:47:27 +01:00
|
|
|
/* Query candidates this transaction is referenced by and that
|
|
|
|
* shall be notified about this specific transaction
|
|
|
|
* completing. */
|
2016-02-22 20:39:45 +01:00
|
|
|
Set *notify_query_candidates, *notify_query_candidates_done;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
/* Zone items this transaction is referenced by and that shall
|
|
|
|
* be notified about completion. */
|
2016-02-22 20:39:45 +01:00
|
|
|
Set *notify_zone_items, *notify_zone_items_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
|
|
|
|
|
|
|
/* Other transactions that this transactions is referenced by
|
|
|
|
* and that shall be notified about completion. This is used
|
|
|
|
* when transactions want to validate their RRsets, but need
|
|
|
|
* another DNSKEY or DS RR to do so. */
|
2016-02-22 20:39:45 +01:00
|
|
|
Set *notify_transactions, *notify_transactions_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
|
|
|
|
|
|
|
/* The opposite direction: the transactions this transaction
|
|
|
|
* created in order to request DNSKEY or DS RRs. */
|
|
|
|
Set *dnssec_transactions;
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
unsigned block_gc;
|
|
|
|
|
|
|
|
LIST_FIELDS(DnsTransaction, transactions_by_scope);
|
2018-04-22 15:23:45 +02:00
|
|
|
LIST_FIELDS(DnsTransaction, transactions_by_stream);
|
2014-07-31 17:46:40 +02:00
|
|
|
};
|
|
|
|
|
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
|
|
|
DnsTransaction* dns_transaction_free(DnsTransaction *t);
|
|
|
|
|
2016-01-04 22:22:47 +01:00
|
|
|
bool dns_transaction_gc(DnsTransaction *t);
|
2014-07-31 17:46:40 +02:00
|
|
|
int dns_transaction_go(DnsTransaction *t);
|
|
|
|
|
|
|
|
void dns_transaction_process_reply(DnsTransaction *t, DnsPacket *p);
|
|
|
|
void dns_transaction_complete(DnsTransaction *t, DnsTransactionState state);
|
|
|
|
|
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
|
|
|
void dns_transaction_notify(DnsTransaction *t, DnsTransaction *source);
|
|
|
|
int dns_transaction_validate_dnssec(DnsTransaction *t);
|
|
|
|
int dns_transaction_request_dnssec_keys(DnsTransaction *t);
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
const char* dns_transaction_state_to_string(DnsTransactionState p) _const_;
|
|
|
|
DnsTransactionState dns_transaction_state_from_string(const char *s) _pure_;
|
|
|
|
|
2015-11-26 23:33:55 +01:00
|
|
|
const char* dns_transaction_source_to_string(DnsTransactionSource p) _const_;
|
|
|
|
DnsTransactionSource dns_transaction_source_from_string(const char *s) _pure_;
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
/* LLMNR Jitter interval, see RFC 4795 Section 7 */
|
2014-08-05 17:01:33 +02:00
|
|
|
#define LLMNR_JITTER_INTERVAL_USEC (100 * USEC_PER_MSEC)
|
2014-07-31 17:46:40 +02:00
|
|
|
|
2015-08-25 14:08:29 +02:00
|
|
|
/* mDNS Jitter interval, see RFC 6762 Section 5.2 */
|
|
|
|
#define MDNS_JITTER_MIN_USEC (20 * USEC_PER_MSEC)
|
|
|
|
#define MDNS_JITTER_RANGE_USEC (100 * USEC_PER_MSEC)
|
|
|
|
|
2016-12-02 14:01:56 +01:00
|
|
|
/* mDNS probing interval, see RFC 6762 Section 8.1 */
|
|
|
|
#define MDNS_PROBING_INTERVAL_USEC (250 * USEC_PER_MSEC)
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
/* Maximum attempts to send DNS requests, across all DNS servers */
|
2017-02-15 19:56:59 +01:00
|
|
|
#define DNS_TRANSACTION_ATTEMPTS_MAX 24
|
2014-07-31 17:46:40 +02:00
|
|
|
|
|
|
|
/* Maximum attempts to send LLMNR requests, see RFC 4795 Section 2.7 */
|
|
|
|
#define LLMNR_TRANSACTION_ATTEMPTS_MAX 3
|
|
|
|
|
2016-12-02 14:01:56 +01:00
|
|
|
/* Maximum attempts to send MDNS requests, see RFC 6762 Section 8.1 */
|
|
|
|
#define MDNS_TRANSACTION_ATTEMPTS_MAX 3
|
|
|
|
|
|
|
|
#define TRANSACTION_ATTEMPTS_MAX(p) (((p) == DNS_PROTOCOL_LLMNR) ? \
|
|
|
|
LLMNR_TRANSACTION_ATTEMPTS_MAX : \
|
|
|
|
(((p) == DNS_PROTOCOL_MDNS) ? \
|
|
|
|
MDNS_TRANSACTION_ATTEMPTS_MAX : \
|
|
|
|
DNS_TRANSACTION_ATTEMPTS_MAX))
|