Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #8569 > unrolled thread

DNS Qname minimisation

Back to article view | Back to linux.debian.project

Contents

  DNS Qname minimisation Hugo Maxwell Connery <hmco@env.dtu.dk> - 2016-03-23 16:50 +0100
    Re: DNS Qname minimisation Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2016-03-23 17:30 +0100
    Re: DNS Qname minimisation Robert Edmonds <edmonds@debian.org> - 2016-03-24 00:40 +0100
      Re: DNS Qname minimisation Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-03-24 02:30 +0100
        Re: DNS Qname minimisation Ondřej Surý <ondrej@sury.org> - 2016-03-24 10:50 +0100
          Re: DNS Qname minimisation Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-03-24 17:50 +0100
        Re: DNS Qname minimisation Henrique de Moraes Holschuh <hmh@debian.org> - 2016-03-28 20:20 +0200
          Re: DNS Qname minimisation Florian Weimer <fw@deneb.enyo.de> - 2016-03-28 22:00 +0200
            Re: DNS Qname minimisation Ondřej Surý <ondrej@sury.org> - 2016-03-31 22:00 +0200

#8569 — DNS Qname minimisation

Hi,

I strongly encourage the Debian Project, in collaboration
with other major GNU/Linux distributors to implement that
standards coming out of the IETF to respond to the mass
surveillance of the Internet illustrated by the Snowden 
disclosures.

The DNS Qname minimisation standard has just been released
and can be found at:

https://datatracker.ietf.org/doc/rfc7816/

The other major standard for DNS privacy is DNS over TLS
which is in the final stages of standardisation:

https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-09

Long live Debian,

  Hugo Connery

[toc] | [next] | [standalone]

#8570

[Multipart message — attachments visible in raw view] — view raw

On 24/03/2016 2:07 AM, Hugo Maxwell Connery wrote:
> I strongly encourage the Debian Project, in collaboration
> with other major GNU/Linux distributors to implement that
> standards coming out of the IETF to respond to the mass
> surveillance of the Internet illustrated by the Snowden 
> disclosures.

Tor proxy with remote dns over socks.....

Trouble is, at times, some bad actors won't allow you to view their
websites over Tor; no problem, they lose a visitor.

Cheers
AndrewM

[toc] | [prev] | [next] | [standalone]

#8571

Hugo Maxwell Connery wrote:
> I strongly encourage the Debian Project, in collaboration
> with other major GNU/Linux distributors to implement that
> standards coming out of the IETF to respond to the mass
> surveillance of the Internet illustrated by the Snowden 
> disclosures.
> 
> The DNS Qname minimisation standard has just been released
> and can be found at:
> 
> https://datatracker.ietf.org/doc/rfc7816/

Hi,

GNU/Linux distributors are generally not that involved in the actual
implementation of most RFCs. For the DNS protocol, the upstream software
developers are almost entirely responsible for implementing new features
(though there are a few DDs who are also upstream DNS developers). This
particular feature must be implemented by recursive DNS servers, and
there are a number of those in Debian: unbound, knot-resolver, bind,
pdns-recursor, and a few others.

DNS qname minimisation is already available in Debian; unbound 1.5.8 in
testing and jessie-backports has support for it, which can be enabled by
adding the following config snippet to /etc/unbound/unbound.conf.d/:

    server:
        qname-minimisation: yes

TTBOMK, the knot-resolver package also has qname minimisation support,
but I have not used it before.

ISC has declared that they will support qname minimisation
(https://twitter.com/ISCdotORG/status/700009184352337920), but I don't
see any signs that it has been implemented yet in their git repository.
Since BIND 9.11 is about to be released, I would guess that it would
have to wait until BIND 9.12.

PowerDNS has tagged the feature request asking for qname minimisation
support as "rec-4.1.0" (https://github.com/PowerDNS/pdns/issues/2311),
so I guess it might be supported in an upcoming release.

> The other major standard for DNS privacy is DNS over TLS
> which is in the final stages of standardisation:
> 
> https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-09

This one requires changes to the DNS resolver running on end hosts. The
most logical place to put the code needed for this in a GNU/Linux
distribution would be in a long-lived daemon that can establish and keep
alive the needed TLS connections. systemd-resolved is one possibility,
though at FOSDEM Lennart Poettering mentioned that systemd-resolved
probably would not support DNS-over-TLS unless it were widely deployed
on the server side, IIRC.

Unbound has support for SSL connections, so one possibility would be to
install a local unbound server on each machine and continue to use the
traditional glibc stub resolver with "nameserver 127.0.0.1" in
/etc/resolv.conf.

-- 
Robert Edmonds
edmonds@debian.org

[toc] | [prev] | [next] | [standalone]

#8572

Robert Edmonds writes ("Re: DNS Qname minimisation"):
> DNS qname minimisation is already available in Debian; unbound 1.5.8 in
> testing and jessie-backports has support for it, which can be enabled by
> adding the following config snippet to /etc/unbound/unbound.conf.d/:
> 
>     server:
>         qname-minimisation: yes

Perhaps we should enable it by default ?  Debian testing is a good
place for such things I think.  If the authors/promoters of qname
minimisation think it is ready for deployment soon, then maybe the
Debian unbound maintainers should be consulted.  (Or indeed, unbound
upstream.)

I did have one question for Hugo: is there a conventional optimisation
or compromise in the qname minimisation for ip6.arpa lookups ?
Without such a thing, the large number of labels in an ip6.arpa
lookup, compared to the usually comparatively small number of zone
cuts, would mean a big performance hit.

Eg (picking my server's primary IPv6 address):

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.e.1.0.8.a.b.0.1.0.0.2.ip6.arpa PTR
                                        3.e.1.0.8.a.b.0.1.0.0.2.ip6.arpa SOA
                                                8.a.b.0.1.0.0.2.ip6.arpa SOA
                                                    b.0.1.0.0.2.ip6.arpa SOA
                                                                ip6.arpa SOA

Ian.

[toc] | [prev] | [next] | [standalone]

#8573

On Thu, Mar 24, 2016, at 02:25, Ian Jackson wrote:
> Robert Edmonds writes ("Re: DNS Qname minimisation"):
> > DNS qname minimisation is already available in Debian; unbound 1.5.8 in
> > testing and jessie-backports has support for it, which can be enabled by
> > adding the following config snippet to /etc/unbound/unbound.conf.d/:
> > 
> >     server:
> >         qname-minimisation: yes
> 
> Perhaps we should enable it by default ?  Debian testing is a good
> place for such things I think.  If the authors/promoters of qname
> minimisation think it is ready for deployment soon, then maybe the
> Debian unbound maintainers should be consulted.  (Or indeed, unbound
> upstream.)

JFTR Knot Resolver (knot-resolver) has only QNAME minimisation mode
(with some workarounds for Akamai and other broken DNS).

> I did have one question for Hugo: is there a conventional optimisation
> or compromise in the qname minimisation for ip6.arpa lookups ?
> Without such a thing, the large number of labels in an ip6.arpa
> lookup, compared to the usually comparatively small number of zone
> cuts, would mean a big performance hit.

The performance hit will be the only when the cache is cold (the RFC
addressed that in Section 6:
https://tools.ietf.org/html/rfc7816#section-6).

That said, f.e. Knot Resolver switch to full resolution when it
encounters first empty non-terminal in the resolution (mainly because
Akamai crappy CDN DNS implementation, but it also helps this case), so
the actual resolution looks like this with cold cache:

$ ./daemon/kresd -a 127.0.0.1\#5353 $(mktemp -d) -f 1 -v
[plan] plan
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.e.1.0.8.a.b.0.1.0.0.2.ip6.arpa.'
type 'PTR'
[resl]   => using root hints
[resl]   => querying: '2001:dc3::500' score: 10 zone cut: '.' m12n:
'aRpA.' type: 'NS'
[resl]      optional: '202.12.27.33' score: 10 zone cut: '.' m12n:
'aRpA.' type: 'NS'
[resl]      optional: '2001:500:3::b00' score: 10 zone cut: '.' m12n:
'aRpA.' type: 'NS'
[resl]      optional: '199.7.83.42' score: 10 zone cut: '.' m12n:
'aRpA.' type: 'NS'
[iter]   <= rcode: NOERROR
[iter]   <= found cut, retrying with non-minimized name
[resl]   <= server: '202.12.27.33' rtt: 324 ms
[resl]   => querying: '2001:dc3::500' score: 10 zone cut: '.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.E.1.0.8.A.B.0.1.0.0.2.ip6.ARPa.'
type: 'PTR'
[resl]      optional: '202.12.27.33' score: 10 zone cut: '.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.E.1.0.8.A.B.0.1.0.0.2.ip6.ARPa.'
type: 'PTR'
[resl]      optional: '2001:500:3::b00' score: 10 zone cut: '.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.E.1.0.8.A.B.0.1.0.0.2.ip6.ARPa.'
type: 'PTR'
[resl]      optional: '199.7.83.42' score: 10 zone cut: '.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.E.1.0.8.A.B.0.1.0.0.2.ip6.ARPa.'
type: 'PTR'
[iter]   <= referral response, follow
[resl]   <= server: '202.12.27.33' rtt: 325 ms
[resl]   => querying: '2001:67c:e0::2' score: 10 zone cut: 'ip6.arpa.'
m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.e.1.0.8.a.b.0.1.0.0.2.iP6.ArPA.'
type: 'PTR'
[resl]      optional: '193.0.9.2' score: 10 zone cut: 'ip6.arpa.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.e.1.0.8.a.b.0.1.0.0.2.iP6.ArPA.'
type: 'PTR'
[resl]      optional: '2001:dc0:2001:a:4608::59' score: 10 zone cut:
'ip6.arpa.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.e.1.0.8.a.b.0.1.0.0.2.iP6.ArPA.'
type: 'PTR'
[resl]      optional: '202.12.29.59' score: 10 zone cut: 'ip6.arpa.'
m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.e.1.0.8.a.b.0.1.0.0.2.iP6.ArPA.'
type: 'PTR'
[iter]   <= referral response, follow
[resl]   <= server: '2001:67c:e0::2' rtt: 14 ms
[plan]   plan 'tinnie.arin.net.' type 'AAAA'
[resl]     => using root hints
[resl]     => querying: '2001:dc3::500' score: 10 zone cut: '.' m12n:
'net.' type: 'NS'
[resl]        optional: '202.12.27.33' score: 10 zone cut: '.' m12n:
'net.' type: 'NS'
[resl]        optional: '2001:500:3::b00' score: 10 zone cut: '.' m12n:
'net.' type: 'NS'
[resl]        optional: '199.7.83.42' score: 10 zone cut: '.' m12n:
'net.' type: 'NS'
[iter]     <= referral response, follow
[resl]     <= server: '202.12.27.33' rtt: 326 ms
[resl]     => querying: '192.55.83.30' score: 10 zone cut: 'net.' m12n:
'aRiN.neT.' type: 'NS'
[resl]        optional: '192.41.162.30' score: 10 zone cut: 'net.' m12n:
'aRiN.neT.' type: 'NS'
[resl]        optional: '192.52.178.30' score: 10 zone cut: 'net.' m12n:
'aRiN.neT.' type: 'NS'
[resl]        optional: '192.48.79.30' score: 10 zone cut: 'net.' m12n:
'aRiN.neT.' type: 'NS'
[iter]     <= referral response, follow
[resl]     <= server: '192.55.83.30' rtt: 151 ms
[resl]     => querying: '2001:500:a9::108' score: 10 zone cut:
'arin.net.' m12n: 'TINnie.Arin.Net.' type: 'AAAA'
[resl]        optional: '199.5.26.108' score: 10 zone cut: 'arin.net.'
m12n: 'TINnie.Arin.Net.' type: 'AAAA'
[resl]        optional: '2001:500:31::108' score: 10 zone cut:
'arin.net.' m12n: 'TINnie.Arin.Net.' type: 'AAAA'
[resl]        optional: '199.71.0.108' score: 10 zone cut: 'arin.net.'
m12n: 'TINnie.Arin.Net.' type: 'AAAA'
[iter]     <= rcode: NOERROR
[resl]     <= server: '2001:500:a9::108' rtt: 145 ms
[resl]   => querying: '2001:500:13::c7d4:35' score: 10 zone cut:
'b.0.1.0.0.2.ip6.arpa.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.E.1.0.8.A.b.0.1.0.0.2.IP6.arPA.'
type: 'PTR'
[iter]   <= referral response, follow
[resl]   <= server: '2001:500:13::c7d4:35' rtt: 93 ms
[resl]   => querying: '2001:67c:e0::6' score: 10 zone cut:
'8.a.b.0.1.0.0.2.ip6.arpa.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.E.1.0.8.A.B.0.1.0.0.2.Ip6.ARPa.'
type: 'PTR'
[resl]      optional: '193.0.9.6' score: 10 zone cut:
'8.a.b.0.1.0.0.2.ip6.arpa.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.E.1.0.8.A.B.0.1.0.0.2.Ip6.ARPa.'
type: 'PTR'
[iter]   <= referral response, follow
[resl]   <= server: '2001:67c:e0::6' rtt: 14 ms
[plan]   plan 'master.ns.chiark.greenend.org.uk.' type 'AAAA'
[resl]     => using root hints
[resl]     => querying: '2001:dc3::500' score: 10 zone cut: '.' m12n:
'uk.' type: 'NS'
[resl]        optional: '202.12.27.33' score: 10 zone cut: '.' m12n:
'uk.' type: 'NS'
[resl]        optional: '2001:500:3::b00' score: 10 zone cut: '.' m12n:
'uk.' type: 'NS'
[resl]        optional: '199.7.83.42' score: 10 zone cut: '.' m12n:
'uk.' type: 'NS'
[iter]     <= referral response, follow
[resl]     <= server: '202.12.27.33' rtt: 325 ms
[resl]     => querying: '2401:fd80:404::1' score: 10 zone cut: 'uk.'
m12n: 'OrG.UK.' type: 'NS'
[resl]        optional: '43.230.48.1' score: 10 zone cut: 'uk.' m12n:
'OrG.UK.' type: 'NS'
[resl]        optional: '2a01:618:404::1' score: 10 zone cut: 'uk.'
m12n: 'OrG.UK.' type: 'NS'
[resl]        optional: '213.248.220.1' score: 10 zone cut: 'uk.' m12n:
'OrG.UK.' type: 'NS'
[iter]     <= rcode: NOERROR
[iter]     <= found cut, retrying with non-minimized name
[resl]     <= server: '2401:fd80:404::1' rtt: 22 ms
[resl]     => querying: '2a01:618:404::1' score: 10 zone cut: 'uk.'
m12n: 'MaSter.NS.ChIARK.greeNend.ORG.UK.' type: 'AAAA'
[resl]        optional: '213.248.220.1' score: 10 zone cut: 'uk.' m12n:
'MaSter.NS.ChIARK.greeNend.ORG.UK.' type: 'AAAA'
[resl]        optional: '2401:fd80:400::1' score: 10 zone cut: 'uk.'
m12n: 'MaSter.NS.ChIARK.greeNend.ORG.UK.' type: 'AAAA'
[resl]        optional: '103.49.80.1' score: 10 zone cut: 'uk.' m12n:
'MaSter.NS.ChIARK.greeNend.ORG.UK.' type: 'AAAA'
[iter]     <= referral response, follow
[resl]     <= server: '2a01:618:404::1' rtt: 22 ms
[resl]     => querying: '212.13.197.229' score: 10 zone cut:
'greenend.org.uk.' m12n: 'mAStER.NS.cHiarK.GReeneNd.oRg.uK.' type:
'AAAA'
[iter]     <= rcode: NOERROR
[ pc ]     => answer cached for TTL=900
[resl]     <= server: '212.13.197.229' rtt: 25 ms
[plan]   plan 'master.ns.chiark.greenend.org.uk.' type 'A'
[ rc ]     => satisfied from cache
[iter]     <= rcode: NOERROR
[resl]   => querying: '212.13.197.229' score: 25 zone cut:
'3.e.1.0.8.a.b.0.1.0.0.2.ip6.arpa.' m12n:
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.e.1.0.8.a.B.0.1.0.0.2.Ip6.ArPA.'
type: 'PTR'
[iter]   <= rcode: NOERROR
[resl]   <= server: '212.13.197.229' rtt: 26 ms
[resl] finished: 4, queries: 4, mempool: 49200 B

I don't know details of Unbound implementation of QNAME-min, but there
will be talk about it next week @DNS-OARC and I'll be also speaking
about Knot Resolver if you are interested.

Cheers,
-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

[toc] | [prev] | [next] | [standalone]

#8574

Ondřej Surý writes ("Re: DNS Qname minimisation"):
> [facts]

Thanks for the information!

Regards,
Ian.

[toc] | [prev] | [next] | [standalone]

#8577

On Wed, Mar 23, 2016, at 22:25, Ian Jackson wrote:
> Robert Edmonds writes ("Re: DNS Qname minimisation"):
> > DNS qname minimisation is already available in Debian; unbound 1.5.8 in
> > testing and jessie-backports has support for it, which can be enabled by
> > adding the following config snippet to /etc/unbound/unbound.conf.d/:
> > 
> >     server:
> >         qname-minimisation: yes
> 
> Perhaps we should enable it by default ?  Debian testing is a good

There are serious potential operation issues with Qname minimization.

Right now, there are CDN and CDN-like domains that exhibit broken DNS
behavior (return NXDOMAIN instead of NODATA for intermediary nodes
already within the authority of the broken DNS server).  This kind of
problem should be expected on any other DNS application that has servers
synthesizing answers, so it is unlikely to be "just" CDNs.

On the CDN side, Akamai were warned that their authoritative servers
were broken and would interfere with Qname minimization in February
2015[1], and it is still not fixed.  It is the same bad behavior that
happened to ECN, and if it follows the same pattern: you have a few
serious vendors (like Cloudflare[1]) that fix their stuff fast, and all
the rest, which will ride the long tail forever and effectively sabotage
the technology, regardless of whether they're doing it on purpose or
not.

[1] Huque, Verisign. Query name minimization and authoritative DNS
server behavior, DNS-OARC 2015,
     https://indico.dns-oarc.net/event/21/contribution/9/material/slides/0.pdf

There is a workaround available for the broken-CDN issue: on the first
NXDOMAIN reply from an intermediary (Qname minimized) query, you disable
Qname minimization entirely and do the full query.  This opens up Qname
minimization to attacks that "disable it" by triggering this workaround
and forcing a full query.

Worse, if this workaround is the only way for a future DNS application
to signal Qname minimization resolvers to query the full name on a deep
chain (see below), it *will* get used (and/or abused) for that,
effectively redefining what NXDOMAIN means in practice, and not in a
helpful way.  This is not a good thing for DNS operations and future
scalability, at all.

There is also the query amplification factor on deep chains, such as
those found on reverse-zone style zones.  This is not restricted to
ip6.arpa: for example, it includes DNS-based IP address RBLs.  This can
be a problem for certain DNS applications: even three extra queries per
IPv4 reverse-zone RBL lookup on a mail server can be too much, and
caching won't help (miss ratio is high, TTL is very low, and effective
caching would have to be done at a level before Qname minimization can
happen).  For IPv6, it will be a lot more than just three extra queries.

On a typical email message in my INBOX, we're talking about an extra
hundred queries per message (RBL lookups are done by the
content-filtering engine for every "received" header, not just ESMTP
envelope and TCP connection).  And that's for IPv4, for IPv6 it can be
much worse.

Unlike the CDN issue, the deep-chain issue is a design defect in Qname
minimization (not DNS!), and it has possibly very detrimental
implications to a subset of future DNS applications: it gets in the way
of use of any such deep chains.

> I did have one question for Hugo: is there a conventional optimisation
> or compromise in the qname minimisation for ip6.arpa lookups ?
> Without such a thing, the large number of labels in an ip6.arpa
> lookup, compared to the usually comparatively small number of zone
> cuts, would mean a big performance hit.

Well, even for IPv4 it would already be too much.  A workaround for this
*specific* degradation case would be to detect reverse-IPv4 and
reverse-IPv6 patterns (and others such as ENUM), and disable the
minimization steps on that *section* of the domain.  We should also
blacklist the well-known reverse zones.  That would take care of
in-addr.arpa and ip6.arpa, as well as IP-address-based RBLs.

However, in the long term this is only a step above from maintaining a
blacklist of domains that should not be subject to Qname minimization.
It doesn't really fix the real problem, and we'd have to keep deploying
more and more workarounds for any other new tech that needs it.

THIS is a side I really, really don't like: it makes *full* Qname
minimization smell like "NAT for the DNS":  NAT broke the end-to-end
nature of the Internet, causing untold damage that will last for at
least one more decade.  I really hope I am wrong about this, but it
looks to me like Qname minimization *as it stands right now* would be
detrimental to a subset of future DNS applications.  And unlike NAT[2],
you will be hard pressed to show that Qname minimization, limited as it
is at preserving privacy, is worth that kind of price.

Note that selective Qname minimization doesn't have any of those
problems, and its blacklist is small, very slow changing, and
standards-driven, so it could be kept at IANA.  Alternatively, the DNS
itself could carry information to blacklist Qname minimization --  that
would need some careful consideration, though.

However, keep in mind that the worst people at mining data from DNS are
actually the massive ISPs doing deep packet inspection on DNS traffic
and data mining their recursive resolvers serving 90% of the Internet
users around the world.  Qname minimization is *absolutely useless*
against that.  We may be paying a very heavy price limiting our future
and breaking things in exchange for nothing of real value (because it
did too little to actually protect privacy in any relevant way).

[2] There is no way we could have deployed IPv6 fast enough in the late
1990s and early 2000s, and that's just looking at the hardware side.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <hmh@debian.org>

[toc] | [prev] | [next] | [standalone]

#8578

* Henrique de Moraes Holschuh:

> On the CDN side, Akamai were warned that their authoritative servers
> were broken and would interfere with Qname minimization in February
> 2015[1], and it is still not fixed.  It is the same bad behavior that
> happened to ECN

It is similar to ECN indeed.  In both cases, people changed the
specification, and complained loudly when their changes are
incompatible with the installation base.

In fact, the problem with NODATA responses is that it is rather
difficult for stub resolvers to tell a NODATA response from a working
recursive resolver from a “I don't provide recursive service” response
from a non-working recursive resolver.  NXDOMAIN would be unambiguous
in these situations.  It's likely one reason why most implementations
moved towards NXDOMAIN in the late 90s.

[toc] | [prev] | [next] | [standalone]

#8584

On Mon, Mar 28, 2016, at 21:30, Florian Weimer wrote:
> * Henrique de Moraes Holschuh:
> 
> > On the CDN side, Akamai were warned that their authoritative servers
> > were broken and would interfere with Qname minimization in February
> > 2015[1], and it is still not fixed.  It is the same bad behavior that
> > happened to ECN
> 
> It is similar to ECN indeed.  In both cases, people changed the
> specification, and complained loudly when their changes are
> incompatible with the installation base.

Not sure if that's the case. I think that Akamain implementation is just
broken and needs to be fixed. We'll push Akamai to fix that now that RFC
7816 is out.

I completely don't agree with "NAT for DNS", on the contrary, the QNAME
minimization is transparent for end clients and can be deployed
gradually as resolvers adds support for that.

As for the deep-chains -> some .arpa optimizations probably should land
in the code, but I would point out, that you are mostly ignoring the
caching behaviour of DNS, that would cause QNAME minimization to burst
more queries in the beginning, but after the cache is hot, it won't
(shouldn't have) much operational impact. The more harm is usually done
by TTL < #smallnumberofseconds.

O.
-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web