2017-11-18 17:09:20 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1+ */
|
2014-07-16 00:26:02 +02:00
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include "sd-bus.h"
|
2015-11-18 22:46:33 +01:00
|
|
|
|
2014-07-22 21:48:41 +02:00
|
|
|
#include "set.h"
|
2020-08-16 13:45:55 +02:00
|
|
|
#include "varlink.h"
|
2014-07-16 00:26:02 +02:00
|
|
|
|
2015-11-25 20:47:27 +01:00
|
|
|
typedef struct DnsQueryCandidate DnsQueryCandidate;
|
2014-07-16 00:26:02 +02:00
|
|
|
typedef struct DnsQuery DnsQuery;
|
2020-09-08 19:41:44 +02:00
|
|
|
typedef struct DnsStubListenerExtra DnsStubListenerExtra;
|
2014-07-16 00:26:02 +02:00
|
|
|
|
2014-07-22 21:48:41 +02:00
|
|
|
#include "resolved-dns-answer.h"
|
2015-11-18 22:46:33 +01:00
|
|
|
#include "resolved-dns-question.h"
|
2015-11-25 20:47:27 +01:00
|
|
|
#include "resolved-dns-search-domain.h"
|
2020-05-06 19:10:59 +02:00
|
|
|
#include "resolved-dns-transaction.h"
|
2015-11-25 20:47:27 +01:00
|
|
|
|
|
|
|
struct DnsQueryCandidate {
|
|
|
|
DnsQuery *query;
|
|
|
|
DnsScope *scope;
|
|
|
|
|
|
|
|
DnsSearchDomain *search_domain;
|
|
|
|
|
|
|
|
int error_code;
|
|
|
|
Set *transactions;
|
|
|
|
|
|
|
|
LIST_FIELDS(DnsQueryCandidate, candidates_by_query);
|
|
|
|
LIST_FIELDS(DnsQueryCandidate, candidates_by_scope);
|
|
|
|
};
|
2014-07-16 00:26:02 +02:00
|
|
|
|
|
|
|
struct DnsQuery {
|
|
|
|
Manager *manager;
|
resolved: add ResolveService() bus call for resolving SRV and DNS-SD services
This also adds client-side support for this to systemd-resolve-host.
Note that the ResolveService() API can deal both with DNS-SD service
(consisting of service name, type and domain), as well as classic SRV
services (consisting just of a type and a domain), all exposed in the
same call.
This patch also reworks CNAME handling in order to reuse it between
hostname, RR and service lookups.
In contrast to Avahi and Bonjour, this new API will actually reolve the
A/AAAA RRs the SRV RRs point to in one go (unless this is explicitly
disabled). This normally comes for free, as these RRs are sent along
the SRV responses anyway, hence let's make use of that. This makes the
API considerably easier to use, as a single ResolveService() invocation
will return all necessary data to pick a server and connect() to it.
Note that this only implements the DNS-SD resolving step, it does not
implement DNS-SD browsing, as that makes sense primarily on mDNS, due to
its continuous nature.
2015-11-23 21:25:40 +01:00
|
|
|
|
|
|
|
/* When resolving a service, we first create a TXT+SRV query,
|
|
|
|
* and then for the hostnames we discover auxiliary A+AAAA
|
|
|
|
* queries. This pointer always points from the auxiliary
|
|
|
|
* queries back to the TXT+SRV query. */
|
|
|
|
DnsQuery *auxiliary_for;
|
|
|
|
LIST_HEAD(DnsQuery, auxiliary_queries);
|
|
|
|
unsigned n_auxiliary_queries;
|
|
|
|
int auxiliary_result;
|
|
|
|
|
resolved: rework IDNA logic
Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever
comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be
considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs.
Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using
UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix.
With this change IDNA conversion is done only:
- When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname()
- When the user passes a non-ASCII domain suffix when resolving a service using ResolveService()
No IDNA encoding is done anymore:
- When the user does raw ResolveRecord() RR resolving
- On the service part of a DNS-SD service name
Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something
is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a
classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead
for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one
encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.
2016-01-18 20:31:39 +01:00
|
|
|
/* The question, formatted in IDNA for use on classic DNS, and as UTF8 for use in LLMNR or mDNS. Note that even
|
|
|
|
* on classic DNS some labels might use UTF8 encoding. Specifically, DNS-SD service names (in contrast to their
|
|
|
|
* domain suffixes) use UTF-8 encoding even on DNS. Thus, the difference between these two fields is mostly
|
|
|
|
* relevant only for explicit *hostname* lookups as well as the domain suffixes of service lookups. */
|
|
|
|
DnsQuestion *question_idna;
|
|
|
|
DnsQuestion *question_utf8;
|
|
|
|
|
2014-08-14 01:00:15 +02:00
|
|
|
uint64_t flags;
|
|
|
|
int ifindex;
|
|
|
|
|
2016-06-20 21:24:46 +02:00
|
|
|
/* If true, the RR TTLs of the answer will be clamped by their current left validity in the cache */
|
|
|
|
bool clamp_ttl;
|
|
|
|
|
2014-07-31 17:46:40 +02:00
|
|
|
DnsTransactionState state;
|
2014-07-22 21:48:41 +02:00
|
|
|
unsigned n_cname_redirects;
|
2014-07-16 00:26:02 +02:00
|
|
|
|
2015-11-25 20:47:27 +01:00
|
|
|
LIST_HEAD(DnsQueryCandidate, candidates);
|
2014-07-16 00:26:02 +02:00
|
|
|
sd_event_source *timeout_event_source;
|
|
|
|
|
2014-07-17 19:38:37 +02:00
|
|
|
/* Discovered data */
|
2014-07-22 21:48:41 +02:00
|
|
|
DnsAnswer *answer;
|
|
|
|
int answer_rcode;
|
2015-12-18 20:09:30 +01:00
|
|
|
DnssecResult answer_dnssec_result;
|
|
|
|
bool answer_authenticated;
|
2015-11-26 22:51:35 +01:00
|
|
|
DnsProtocol answer_protocol;
|
|
|
|
int answer_family;
|
2015-11-25 20:47:27 +01:00
|
|
|
DnsSearchDomain *answer_search_domain;
|
2016-01-22 17:22:23 +01:00
|
|
|
int answer_errno; /* if state is DNS_TRANSACTION_ERRNO */
|
2017-02-08 19:22:49 +01:00
|
|
|
bool previous_redirect_unauthenticated;
|
2014-07-16 00:26:02 +02:00
|
|
|
|
2020-08-16 13:45:55 +02:00
|
|
|
/* Bus + Varlink client information */
|
2020-08-16 11:29:55 +02:00
|
|
|
sd_bus_message *bus_request;
|
2020-08-16 13:45:55 +02:00
|
|
|
Varlink *varlink_request;
|
2014-07-18 16:09:30 +02:00
|
|
|
int request_family;
|
resolved: add ResolveService() bus call for resolving SRV and DNS-SD services
This also adds client-side support for this to systemd-resolve-host.
Note that the ResolveService() API can deal both with DNS-SD service
(consisting of service name, type and domain), as well as classic SRV
services (consisting just of a type and a domain), all exposed in the
same call.
This patch also reworks CNAME handling in order to reuse it between
hostname, RR and service lookups.
In contrast to Avahi and Bonjour, this new API will actually reolve the
A/AAAA RRs the SRV RRs point to in one go (unless this is explicitly
disabled). This normally comes for free, as these RRs are sent along
the SRV responses anyway, hence let's make use of that. This makes the
API considerably easier to use, as a single ResolveService() invocation
will return all necessary data to pick a server and connect() to it.
Note that this only implements the DNS-SD resolving step, it does not
implement DNS-SD browsing, as that makes sense primarily on mDNS, due to
its continuous nature.
2015-11-23 21:25:40 +01:00
|
|
|
bool request_address_valid;
|
2014-07-16 00:26:02 +02:00
|
|
|
union in_addr_union request_address;
|
resolved: add ResolveService() bus call for resolving SRV and DNS-SD services
This also adds client-side support for this to systemd-resolve-host.
Note that the ResolveService() API can deal both with DNS-SD service
(consisting of service name, type and domain), as well as classic SRV
services (consisting just of a type and a domain), all exposed in the
same call.
This patch also reworks CNAME handling in order to reuse it between
hostname, RR and service lookups.
In contrast to Avahi and Bonjour, this new API will actually reolve the
A/AAAA RRs the SRV RRs point to in one go (unless this is explicitly
disabled). This normally comes for free, as these RRs are sent along
the SRV responses anyway, hence let's make use of that. This makes the
API considerably easier to use, as a single ResolveService() invocation
will return all necessary data to pick a server and connect() to it.
Note that this only implements the DNS-SD resolving step, it does not
implement DNS-SD browsing, as that makes sense primarily on mDNS, due to
its continuous nature.
2015-11-23 21:25:40 +01:00
|
|
|
unsigned block_all_complete;
|
resolved: rework IDNA logic
Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever
comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be
considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs.
Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using
UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix.
With this change IDNA conversion is done only:
- When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname()
- When the user passes a non-ASCII domain suffix when resolving a service using ResolveService()
No IDNA encoding is done anymore:
- When the user does raw ResolveRecord() RR resolving
- On the service part of a DNS-SD service name
Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something
is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a
classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead
for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one
encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.
2016-01-18 20:31:39 +01:00
|
|
|
char *request_address_string;
|
2014-07-16 00:26:02 +02:00
|
|
|
|
resolved: respond to local resolver requests on 127.0.0.53:53
In order to improve compatibility with local clients that speak DNS directly
(and do not use NSS or our bus API) listen locally on 127.0.0.53:53 and process
any queries made that way.
Note that resolved does not implement a full DNS server on this port, but
simply enough to allow normal, local clients to resolve RRs through resolved.
Specifically it does not implement queries without the RD bit set (these are
requests where recursive lookups are explicitly disabled), and neither queries
with DNSSEC DO set in combination with DNSSEC CD (i.e. DNSSEC lookups with
validation turned off). It also refuses zone transfers and obsolete RR types.
All lookups done this way will be rejected with a clean error code, so that the
client side can repeat the query with a reduced feature set.
The code will set the DNSSEC AD flag however, depending on whether the data
resolved has been validated (or comes from a local, trusted source).
Lookups made via this mechanisms are propagated to LLMNR and mDNS as necessary,
but this is only partially useful as DNS packets cannot carry IP scope data
(i.e. the ifindex), and hence link-local addresses returned cannot be used
properly (and given that LLMNR/mDNS are mostly about link-local communication
this is quite a limitation). Also, given that DNS tends to use IDNA for
non-ASCII names, while LLMNR/mDNS uses UTF-8 lookups cannot be mapped 1:1.
In general this should improve compatibility with clients bypassing NSS but
it is highly recommended for clients to instead use NSS or our native bus API.
This patch also beefs up the DnsStream logic, as it reuses the code for local
TCP listening. DnsStream now provides proper reference counting for its
objects.
In order to avoid feedback loops resolved will no silently ignore 127.0.0.53
specified as DNS server when reading configuration.
resolved listens on 127.0.0.53:53 instead of 127.0.0.1:53 in order to leave
the latter free for local, external DNS servers or forwarders.
This also changes the "etc.conf" tmpfiles snippet to create a symlink from
/etc/resolv.conf to /usr/lib/systemd/resolv.conf by default, thus making this
stub the default mode of operation if /etc is not populated.
2016-06-21 00:58:47 +02:00
|
|
|
/* DNS stub information */
|
|
|
|
DnsPacket *request_dns_packet;
|
|
|
|
DnsStream *request_dns_stream;
|
2017-02-08 19:12:55 +01:00
|
|
|
DnsPacket *reply_dns_packet;
|
2020-09-08 19:41:44 +02:00
|
|
|
DnsStubListenerExtra *stub_listener_extra;
|
resolved: respond to local resolver requests on 127.0.0.53:53
In order to improve compatibility with local clients that speak DNS directly
(and do not use NSS or our bus API) listen locally on 127.0.0.53:53 and process
any queries made that way.
Note that resolved does not implement a full DNS server on this port, but
simply enough to allow normal, local clients to resolve RRs through resolved.
Specifically it does not implement queries without the RD bit set (these are
requests where recursive lookups are explicitly disabled), and neither queries
with DNSSEC DO set in combination with DNSSEC CD (i.e. DNSSEC lookups with
validation turned off). It also refuses zone transfers and obsolete RR types.
All lookups done this way will be rejected with a clean error code, so that the
client side can repeat the query with a reduced feature set.
The code will set the DNSSEC AD flag however, depending on whether the data
resolved has been validated (or comes from a local, trusted source).
Lookups made via this mechanisms are propagated to LLMNR and mDNS as necessary,
but this is only partially useful as DNS packets cannot carry IP scope data
(i.e. the ifindex), and hence link-local addresses returned cannot be used
properly (and given that LLMNR/mDNS are mostly about link-local communication
this is quite a limitation). Also, given that DNS tends to use IDNA for
non-ASCII names, while LLMNR/mDNS uses UTF-8 lookups cannot be mapped 1:1.
In general this should improve compatibility with clients bypassing NSS but
it is highly recommended for clients to instead use NSS or our native bus API.
This patch also beefs up the DnsStream logic, as it reuses the code for local
TCP listening. DnsStream now provides proper reference counting for its
objects.
In order to avoid feedback loops resolved will no silently ignore 127.0.0.53
specified as DNS server when reading configuration.
resolved listens on 127.0.0.53:53 instead of 127.0.0.1:53 in order to leave
the latter free for local, external DNS servers or forwarders.
This also changes the "etc.conf" tmpfiles snippet to create a symlink from
/etc/resolv.conf to /usr/lib/systemd/resolv.conf by default, thus making this
stub the default mode of operation if /etc is not populated.
2016-06-21 00:58:47 +02:00
|
|
|
|
2014-07-17 19:38:37 +02:00
|
|
|
/* Completion callback */
|
2014-07-16 00:26:02 +02:00
|
|
|
void (*complete)(DnsQuery* q);
|
2014-07-22 21:48:41 +02:00
|
|
|
unsigned block_ready;
|
|
|
|
|
2014-08-06 16:32:55 +02:00
|
|
|
sd_bus_track *bus_track;
|
|
|
|
|
2014-07-16 00:26:02 +02:00
|
|
|
LIST_FIELDS(DnsQuery, queries);
|
resolved: add ResolveService() bus call for resolving SRV and DNS-SD services
This also adds client-side support for this to systemd-resolve-host.
Note that the ResolveService() API can deal both with DNS-SD service
(consisting of service name, type and domain), as well as classic SRV
services (consisting just of a type and a domain), all exposed in the
same call.
This patch also reworks CNAME handling in order to reuse it between
hostname, RR and service lookups.
In contrast to Avahi and Bonjour, this new API will actually reolve the
A/AAAA RRs the SRV RRs point to in one go (unless this is explicitly
disabled). This normally comes for free, as these RRs are sent along
the SRV responses anyway, hence let's make use of that. This makes the
API considerably easier to use, as a single ResolveService() invocation
will return all necessary data to pick a server and connect() to it.
Note that this only implements the DNS-SD resolving step, it does not
implement DNS-SD browsing, as that makes sense primarily on mDNS, due to
its continuous nature.
2015-11-23 21:25:40 +01:00
|
|
|
LIST_FIELDS(DnsQuery, auxiliary_queries);
|
2014-07-16 00:26:02 +02:00
|
|
|
};
|
|
|
|
|
2016-01-05 17:56:45 +01:00
|
|
|
enum {
|
|
|
|
DNS_QUERY_MATCH,
|
|
|
|
DNS_QUERY_NOMATCH,
|
|
|
|
DNS_QUERY_RESTARTED,
|
|
|
|
};
|
|
|
|
|
2015-11-25 20:47:27 +01:00
|
|
|
DnsQueryCandidate* dns_query_candidate_free(DnsQueryCandidate *c);
|
2020-06-03 12:53:27 +02:00
|
|
|
DEFINE_TRIVIAL_CLEANUP_FUNC(DnsQueryCandidate*, dns_query_candidate_free);
|
|
|
|
|
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_query_candidate_notify(DnsQueryCandidate *c);
|
2015-11-25 20:47:27 +01:00
|
|
|
|
resolved: rework IDNA logic
Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever
comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be
considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs.
Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using
UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix.
With this change IDNA conversion is done only:
- When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname()
- When the user passes a non-ASCII domain suffix when resolving a service using ResolveService()
No IDNA encoding is done anymore:
- When the user does raw ResolveRecord() RR resolving
- On the service part of a DNS-SD service name
Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something
is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a
classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead
for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one
encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.
2016-01-18 20:31:39 +01:00
|
|
|
int dns_query_new(Manager *m, DnsQuery **q, DnsQuestion *question_utf8, DnsQuestion *question_idna, int family, uint64_t flags);
|
2014-07-16 00:26:02 +02:00
|
|
|
DnsQuery *dns_query_free(DnsQuery *q);
|
2014-07-17 19:38:37 +02:00
|
|
|
|
resolved: add ResolveService() bus call for resolving SRV and DNS-SD services
This also adds client-side support for this to systemd-resolve-host.
Note that the ResolveService() API can deal both with DNS-SD service
(consisting of service name, type and domain), as well as classic SRV
services (consisting just of a type and a domain), all exposed in the
same call.
This patch also reworks CNAME handling in order to reuse it between
hostname, RR and service lookups.
In contrast to Avahi and Bonjour, this new API will actually reolve the
A/AAAA RRs the SRV RRs point to in one go (unless this is explicitly
disabled). This normally comes for free, as these RRs are sent along
the SRV responses anyway, hence let's make use of that. This makes the
API considerably easier to use, as a single ResolveService() invocation
will return all necessary data to pick a server and connect() to it.
Note that this only implements the DNS-SD resolving step, it does not
implement DNS-SD browsing, as that makes sense primarily on mDNS, due to
its continuous nature.
2015-11-23 21:25:40 +01:00
|
|
|
int dns_query_make_auxiliary(DnsQuery *q, DnsQuery *auxiliary_for);
|
|
|
|
|
2014-07-17 19:38:37 +02:00
|
|
|
int dns_query_go(DnsQuery *q);
|
2014-07-22 21:48:41 +02:00
|
|
|
void dns_query_ready(DnsQuery *q);
|
2014-07-16 00:26:02 +02:00
|
|
|
|
resolved: add ResolveService() bus call for resolving SRV and DNS-SD services
This also adds client-side support for this to systemd-resolve-host.
Note that the ResolveService() API can deal both with DNS-SD service
(consisting of service name, type and domain), as well as classic SRV
services (consisting just of a type and a domain), all exposed in the
same call.
This patch also reworks CNAME handling in order to reuse it between
hostname, RR and service lookups.
In contrast to Avahi and Bonjour, this new API will actually reolve the
A/AAAA RRs the SRV RRs point to in one go (unless this is explicitly
disabled). This normally comes for free, as these RRs are sent along
the SRV responses anyway, hence let's make use of that. This makes the
API considerably easier to use, as a single ResolveService() invocation
will return all necessary data to pick a server and connect() to it.
Note that this only implements the DNS-SD resolving step, it does not
implement DNS-SD browsing, as that makes sense primarily on mDNS, due to
its continuous nature.
2015-11-23 21:25:40 +01:00
|
|
|
int dns_query_process_cname(DnsQuery *q);
|
2014-07-16 00:26:02 +02:00
|
|
|
|
2020-08-16 13:43:51 +02:00
|
|
|
void dns_query_complete(DnsQuery *q, DnsTransactionState state);
|
2014-08-06 16:32:55 +02:00
|
|
|
|
resolved: rework IDNA logic
Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever
comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be
considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs.
Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using
UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix.
With this change IDNA conversion is done only:
- When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname()
- When the user passes a non-ASCII domain suffix when resolving a service using ResolveService()
No IDNA encoding is done anymore:
- When the user does raw ResolveRecord() RR resolving
- On the service part of a DNS-SD service name
Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something
is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a
classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead
for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one
encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.
2016-01-18 20:31:39 +01:00
|
|
|
DnsQuestion* dns_query_question_for_protocol(DnsQuery *q, DnsProtocol protocol);
|
|
|
|
|
|
|
|
const char *dns_query_string(DnsQuery *q);
|
|
|
|
|
2014-07-16 00:26:02 +02:00
|
|
|
DEFINE_TRIVIAL_CLEANUP_FUNC(DnsQuery*, dns_query_free);
|
2017-02-08 19:22:49 +01:00
|
|
|
|
|
|
|
bool dns_query_fully_authenticated(DnsQuery *q);
|