2020-11-09 05:23:58 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
2014-07-22 21:48:41 +02:00
|
|
|
|
2015-10-27 03:01:06 +01:00
|
|
|
#include "alloc-util.h"
|
2015-06-02 20:49:43 +02:00
|
|
|
#include "dns-domain.h"
|
2016-01-18 20:21:55 +01:00
|
|
|
#include "dns-type.h"
|
2015-10-27 03:01:06 +01:00
|
|
|
#include "resolved-dns-question.h"
|
2014-07-22 21:48:41 +02:00
|
|
|
|
tree-wide: be more careful with the type of array sizes
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
2018-04-27 14:09:31 +02:00
|
|
|
DnsQuestion *dns_question_new(size_t n) {
|
2014-07-22 21:48:41 +02:00
|
|
|
DnsQuestion *q;
|
|
|
|
|
2020-11-03 18:31:03 +01:00
|
|
|
if (n > UINT16_MAX) /* We can only place 64K key in an question section at max */
|
|
|
|
n = UINT16_MAX;
|
2014-07-22 21:48:41 +02:00
|
|
|
|
|
|
|
q = malloc0(offsetof(DnsQuestion, keys) + sizeof(DnsResourceKey*) * n);
|
|
|
|
if (!q)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
q->n_ref = 1;
|
|
|
|
q->n_allocated = n;
|
|
|
|
|
|
|
|
return q;
|
|
|
|
}
|
|
|
|
|
2018-08-27 07:01:46 +02:00
|
|
|
static DnsQuestion *dns_question_free(DnsQuestion *q) {
|
|
|
|
size_t i;
|
2014-07-22 21:48:41 +02:00
|
|
|
|
2018-08-27 07:01:46 +02:00
|
|
|
assert(q);
|
2014-07-22 21:48:41 +02:00
|
|
|
|
2018-08-27 07:01:46 +02:00
|
|
|
for (i = 0; i < q->n_keys; i++)
|
|
|
|
dns_resource_key_unref(q->keys[i]);
|
|
|
|
return mfree(q);
|
2014-07-22 21:48:41 +02:00
|
|
|
}
|
|
|
|
|
2018-08-27 07:01:46 +02:00
|
|
|
DEFINE_TRIVIAL_REF_UNREF_FUNC(DnsQuestion, dns_question, dns_question_free);
|
|
|
|
|
2019-02-27 07:01:50 +01:00
|
|
|
int dns_question_add_raw(DnsQuestion *q, DnsResourceKey *key) {
|
|
|
|
/* Insert without checking for duplicates. */
|
|
|
|
|
|
|
|
assert(key);
|
|
|
|
assert(q);
|
|
|
|
|
|
|
|
if (q->n_keys >= q->n_allocated)
|
|
|
|
return -ENOSPC;
|
|
|
|
|
|
|
|
q->keys[q->n_keys++] = dns_resource_key_ref(key);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-07-22 21:48:41 +02:00
|
|
|
int dns_question_add(DnsQuestion *q, DnsResourceKey *key) {
|
2014-07-23 00:57:25 +02:00
|
|
|
int r;
|
|
|
|
|
2014-07-22 21:48:41 +02:00
|
|
|
assert(key);
|
|
|
|
|
2015-08-21 12:28:59 +02:00
|
|
|
if (!q)
|
|
|
|
return -ENOSPC;
|
|
|
|
|
2019-02-27 07:01:50 +01:00
|
|
|
for (size_t i = 0; i < q->n_keys; i++) {
|
2014-07-23 00:57:25 +02:00
|
|
|
r = dns_resource_key_equal(q->keys[i], key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r > 0)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-27 07:01:50 +01:00
|
|
|
return dns_question_add_raw(q, key);
|
2014-07-22 21:48:41 +02:00
|
|
|
}
|
|
|
|
|
2015-11-25 20:47:27 +01:00
|
|
|
int dns_question_matches_rr(DnsQuestion *q, DnsResourceRecord *rr, const char *search_domain) {
|
tree-wide: be more careful with the type of array sizes
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
2018-04-27 14:09:31 +02:00
|
|
|
size_t i;
|
2014-07-22 21:48:41 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(rr);
|
|
|
|
|
2015-08-21 12:28:59 +02:00
|
|
|
if (!q)
|
|
|
|
return 0;
|
|
|
|
|
2014-07-22 21:48:41 +02:00
|
|
|
for (i = 0; i < q->n_keys; i++) {
|
2015-11-25 20:47:27 +01:00
|
|
|
r = dns_resource_key_match_rr(q->keys[i], rr, search_domain);
|
2014-07-22 21:48:41 +02:00
|
|
|
if (r != 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-18 22:33:23 +01:00
|
|
|
int dns_question_matches_cname_or_dname(DnsQuestion *q, DnsResourceRecord *rr, const char *search_domain) {
|
tree-wide: be more careful with the type of array sizes
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
2018-04-27 14:09:31 +02:00
|
|
|
size_t i;
|
2014-07-22 21:48:41 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(rr);
|
|
|
|
|
2015-08-21 12:28:59 +02:00
|
|
|
if (!q)
|
|
|
|
return 0;
|
|
|
|
|
2016-01-18 22:33:23 +01:00
|
|
|
if (!IN_SET(rr->key->type, DNS_TYPE_CNAME, DNS_TYPE_DNAME))
|
|
|
|
return 0;
|
|
|
|
|
2014-07-22 21:48:41 +02:00
|
|
|
for (i = 0; i < q->n_keys; i++) {
|
2016-01-18 22:33:23 +01:00
|
|
|
/* For a {C,D}NAME record we can never find a matching {C,D}NAME record */
|
|
|
|
if (!dns_type_may_redirect(q->keys[i]->type))
|
|
|
|
return 0;
|
|
|
|
|
2015-12-02 18:46:32 +01:00
|
|
|
r = dns_resource_key_match_cname_or_dname(q->keys[i], rr->key, search_domain);
|
2014-07-22 21:48:41 +02:00
|
|
|
if (r != 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2014-07-30 14:46:40 +02:00
|
|
|
return 0;
|
2014-07-22 21:48:41 +02:00
|
|
|
}
|
|
|
|
|
2015-11-24 01:25:24 +01:00
|
|
|
int dns_question_is_valid_for_query(DnsQuestion *q) {
|
2014-07-22 21:48:41 +02:00
|
|
|
const char *name;
|
tree-wide: be more careful with the type of array sizes
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
2018-04-27 14:09:31 +02:00
|
|
|
size_t i;
|
2014-07-22 21:48:41 +02:00
|
|
|
int r;
|
|
|
|
|
2015-08-21 12:28:59 +02:00
|
|
|
if (!q)
|
|
|
|
return 0;
|
2014-07-22 21:48:41 +02:00
|
|
|
|
|
|
|
if (q->n_keys <= 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (q->n_keys > 65535)
|
|
|
|
return 0;
|
|
|
|
|
2016-02-13 20:54:15 +01:00
|
|
|
name = dns_resource_key_name(q->keys[0]);
|
2014-07-22 21:48:41 +02:00
|
|
|
if (!name)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Check that all keys in this question bear the same name */
|
2016-01-18 20:21:55 +01:00
|
|
|
for (i = 0; i < q->n_keys; i++) {
|
2014-07-30 14:46:40 +02:00
|
|
|
assert(q->keys[i]);
|
|
|
|
|
2016-01-18 20:21:55 +01:00
|
|
|
if (i > 0) {
|
2016-02-13 20:54:15 +01:00
|
|
|
r = dns_name_equal(dns_resource_key_name(q->keys[i]), name);
|
2016-01-18 20:21:55 +01:00
|
|
|
if (r <= 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!dns_type_is_valid_query(q->keys[i]->type))
|
|
|
|
return 0;
|
2014-07-22 21:48:41 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-01-18 20:21:30 +01:00
|
|
|
int dns_question_contains(DnsQuestion *a, const DnsResourceKey *k) {
|
tree-wide: be more careful with the type of array sizes
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
2018-04-27 14:09:31 +02:00
|
|
|
size_t j;
|
2015-07-28 18:38:54 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(k);
|
|
|
|
|
2015-08-21 12:28:59 +02:00
|
|
|
if (!a)
|
|
|
|
return 0;
|
|
|
|
|
2015-07-28 18:38:54 +02:00
|
|
|
for (j = 0; j < a->n_keys; j++) {
|
|
|
|
r = dns_resource_key_equal(a->keys[j], k);
|
|
|
|
if (r != 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int dns_question_is_equal(DnsQuestion *a, DnsQuestion *b) {
|
tree-wide: be more careful with the type of array sizes
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
2018-04-27 14:09:31 +02:00
|
|
|
size_t j;
|
2015-07-28 18:38:54 +02:00
|
|
|
int r;
|
|
|
|
|
2016-01-18 20:22:45 +01:00
|
|
|
if (a == b)
|
|
|
|
return 1;
|
|
|
|
|
2015-08-21 12:28:59 +02:00
|
|
|
if (!a)
|
|
|
|
return !b || b->n_keys == 0;
|
|
|
|
if (!b)
|
|
|
|
return a->n_keys == 0;
|
2015-07-28 18:38:54 +02:00
|
|
|
|
|
|
|
/* Checks if all keys in a are also contained b, and vice versa */
|
|
|
|
|
|
|
|
for (j = 0; j < a->n_keys; j++) {
|
|
|
|
r = dns_question_contains(b, a->keys[j]);
|
|
|
|
if (r <= 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < b->n_keys; j++) {
|
|
|
|
r = dns_question_contains(a, b->keys[j]);
|
|
|
|
if (r <= 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-09-04 01:56:23 +02:00
|
|
|
int dns_question_cname_redirect(DnsQuestion *q, const DnsResourceRecord *cname, DnsQuestion **ret) {
|
2014-07-22 21:48:41 +02:00
|
|
|
_cleanup_(dns_question_unrefp) DnsQuestion *n = NULL;
|
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
|
|
|
DnsResourceKey *key;
|
2014-07-22 21:48:41 +02:00
|
|
|
bool same = true;
|
|
|
|
int r;
|
|
|
|
|
2015-09-04 01:56:23 +02:00
|
|
|
assert(cname);
|
2014-07-22 21:48:41 +02:00
|
|
|
assert(ret);
|
2015-11-24 00:18:49 +01:00
|
|
|
assert(IN_SET(cname->key->type, DNS_TYPE_CNAME, DNS_TYPE_DNAME));
|
2014-07-22 21:48:41 +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
|
|
|
if (dns_question_size(q) <= 0) {
|
|
|
|
*ret = NULL;
|
2015-08-21 12:28:59 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
DNS_QUESTION_FOREACH(key, q) {
|
2015-11-24 00:18:49 +01:00
|
|
|
_cleanup_free_ char *destination = NULL;
|
|
|
|
const char *d;
|
|
|
|
|
|
|
|
if (cname->key->type == DNS_TYPE_CNAME)
|
|
|
|
d = cname->cname.name;
|
|
|
|
else {
|
2016-02-13 20:54:15 +01:00
|
|
|
r = dns_name_change_suffix(dns_resource_key_name(key), dns_resource_key_name(cname->key), cname->dname.name, &destination);
|
2015-11-24 00:18:49 +01:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (r == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
d = destination;
|
|
|
|
}
|
|
|
|
|
2016-02-13 20:54:15 +01:00
|
|
|
r = dns_name_equal(dns_resource_key_name(key), d);
|
2014-07-22 21:48:41 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
if (r == 0) {
|
|
|
|
same = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/* Fully the same, indicate we didn't do a thing */
|
2014-07-22 21:48:41 +02:00
|
|
|
if (same) {
|
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
|
|
|
*ret = NULL;
|
2014-07-22 21:48:41 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
n = dns_question_new(q->n_keys);
|
|
|
|
if (!n)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* Create a new question, and patch in the new name */
|
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
|
|
|
DNS_QUESTION_FOREACH(key, q) {
|
2014-07-22 21:48:41 +02:00
|
|
|
_cleanup_(dns_resource_key_unrefp) DnsResourceKey *k = NULL;
|
|
|
|
|
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
|
|
|
k = dns_resource_key_new_redirect(key, cname);
|
2014-07-22 21:48:41 +02:00
|
|
|
if (!k)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
r = dns_question_add(n, k);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2018-04-05 07:26:26 +02:00
|
|
|
*ret = TAKE_PTR(n);
|
2014-07-22 21:48:41 +02:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
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
|
|
|
|
2015-11-24 01:25:24 +01:00
|
|
|
const char *dns_question_first_name(DnsQuestion *q) {
|
|
|
|
|
|
|
|
if (!q)
|
|
|
|
return NULL;
|
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
|
|
|
|
|
|
|
if (q->n_keys < 1)
|
|
|
|
return NULL;
|
|
|
|
|
2016-02-13 20:54:15 +01:00
|
|
|
return dns_resource_key_name(q->keys[0]);
|
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
|
|
|
}
|
|
|
|
|
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_question_new_address(DnsQuestion **ret, int family, const char *name, bool convert_idna) {
|
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
|
|
|
_cleanup_(dns_question_unrefp) DnsQuestion *q = NULL;
|
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
|
|
|
_cleanup_free_ char *buf = NULL;
|
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 r;
|
|
|
|
|
|
|
|
assert(ret);
|
|
|
|
assert(name);
|
|
|
|
|
|
|
|
if (!IN_SET(family, AF_INET, AF_INET6, AF_UNSPEC))
|
|
|
|
return -EAFNOSUPPORT;
|
|
|
|
|
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
|
|
|
if (convert_idna) {
|
|
|
|
r = dns_name_apply_idna(name, &buf);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
2017-07-11 10:42:21 +02:00
|
|
|
if (r > 0 && !streq(name, buf))
|
2017-05-10 03:56:34 +02:00
|
|
|
name = buf;
|
2017-07-11 10:42:21 +02:00
|
|
|
else
|
|
|
|
/* We did not manage to create convert the idna name, or it's
|
|
|
|
* the same as the original name. We assume the caller already
|
2019-04-27 02:22:40 +02:00
|
|
|
* created an unconverted question, so let's not repeat work
|
2017-07-11 10:42:21 +02:00
|
|
|
* unnecessarily. */
|
|
|
|
return -EALREADY;
|
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
|
|
|
}
|
|
|
|
|
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
|
|
|
q = dns_question_new(family == AF_UNSPEC ? 2 : 1);
|
|
|
|
if (!q)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (family != AF_INET6) {
|
|
|
|
_cleanup_(dns_resource_key_unrefp) DnsResourceKey *key = NULL;
|
|
|
|
|
|
|
|
key = dns_resource_key_new(DNS_CLASS_IN, DNS_TYPE_A, name);
|
|
|
|
if (!key)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
r = dns_question_add(q, key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (family != AF_INET) {
|
|
|
|
_cleanup_(dns_resource_key_unrefp) DnsResourceKey *key = NULL;
|
|
|
|
|
|
|
|
key = dns_resource_key_new(DNS_CLASS_IN, DNS_TYPE_AAAA, name);
|
|
|
|
if (!key)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
r = dns_question_add(q, key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2018-04-05 07:26:26 +02:00
|
|
|
*ret = TAKE_PTR(q);
|
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
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int dns_question_new_reverse(DnsQuestion **ret, int family, const union in_addr_union *a) {
|
|
|
|
_cleanup_(dns_resource_key_unrefp) DnsResourceKey *key = NULL;
|
|
|
|
_cleanup_(dns_question_unrefp) DnsQuestion *q = NULL;
|
|
|
|
_cleanup_free_ char *reverse = NULL;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert(ret);
|
|
|
|
assert(a);
|
|
|
|
|
|
|
|
if (!IN_SET(family, AF_INET, AF_INET6, AF_UNSPEC))
|
|
|
|
return -EAFNOSUPPORT;
|
|
|
|
|
|
|
|
r = dns_name_reverse(family, a, &reverse);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
q = dns_question_new(1);
|
|
|
|
if (!q)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
key = dns_resource_key_new_consume(DNS_CLASS_IN, DNS_TYPE_PTR, reverse);
|
|
|
|
if (!key)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
reverse = NULL;
|
|
|
|
|
|
|
|
r = dns_question_add(q, key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
2018-04-05 07:26:26 +02:00
|
|
|
*ret = TAKE_PTR(q);
|
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
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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_question_new_service(
|
|
|
|
DnsQuestion **ret,
|
|
|
|
const char *service,
|
|
|
|
const char *type,
|
|
|
|
const char *domain,
|
|
|
|
bool with_txt,
|
|
|
|
bool convert_idna) {
|
|
|
|
|
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
|
|
|
_cleanup_(dns_resource_key_unrefp) DnsResourceKey *key = NULL;
|
|
|
|
_cleanup_(dns_question_unrefp) DnsQuestion *q = NULL;
|
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
|
|
|
_cleanup_free_ char *buf = NULL, *joined = NULL;
|
|
|
|
const char *name;
|
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 r;
|
|
|
|
|
|
|
|
assert(ret);
|
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
|
|
|
|
|
|
|
/* We support three modes of invocation:
|
|
|
|
*
|
|
|
|
* 1. Only a domain is specified, in which case we assume a properly encoded SRV RR name, including service
|
|
|
|
* type and possibly a service name. If specified in this way we assume it's already IDNA converted if
|
|
|
|
* that's necessary.
|
|
|
|
*
|
|
|
|
* 2. Both service type and a domain specified, in which case a normal SRV RR is assumed, without a DNS-SD
|
|
|
|
* style prefix. In this case we'll IDNA convert the domain, if that's requested.
|
|
|
|
*
|
|
|
|
* 3. All three of service name, type and domain are specified, in which case a DNS-SD service is put
|
|
|
|
* together. The service name is never IDNA converted, and the domain is if requested.
|
|
|
|
*
|
|
|
|
* It's not supported to specify a service name without a type, or no domain name.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (!domain)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (type) {
|
|
|
|
if (convert_idna) {
|
|
|
|
r = dns_name_apply_idna(domain, &buf);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
2017-05-10 03:56:34 +02:00
|
|
|
if (r > 0)
|
|
|
|
domain = buf;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
r = dns_service_join(service, type, domain, &joined);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
name = joined;
|
|
|
|
} else {
|
|
|
|
if (service)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
name = domain;
|
|
|
|
}
|
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
|
|
|
|
|
|
|
q = dns_question_new(1 + with_txt);
|
|
|
|
if (!q)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
key = dns_resource_key_new(DNS_CLASS_IN, DNS_TYPE_SRV, name);
|
|
|
|
if (!key)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
r = dns_question_add(q, key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
if (with_txt) {
|
|
|
|
dns_resource_key_unref(key);
|
|
|
|
key = dns_resource_key_new(DNS_CLASS_IN, DNS_TYPE_TXT, name);
|
|
|
|
if (!key)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
r = dns_question_add(q, key);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2018-04-05 07:26:26 +02:00
|
|
|
*ret = TAKE_PTR(q);
|
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
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|