Re: DNS Qname minimisation
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>
Reply to: