diff options
author | Lennart Poettering <lennart@poettering.net> | 2016-01-18 20:31:39 +0100 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2016-01-18 23:31:16 +0100 |
commit | 23b298bce75a0d1f4f15f34458af9678b4a30c3a (patch) | |
tree | f1137704b66a45e057e22b74f6c01534536f1b1b /.dir-locals.el | |
parent | b6800689e03456efd0430d171ebf962f64b94eb0 (diff) |
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.
Diffstat (limited to '.dir-locals.el')
0 files changed, 0 insertions, 0 deletions