[dns-operations] DNS challenge+response paper

[Mark Andrews]

On a quick partial read he doesn’t really understand how DNS COOKIES work.
When you talk about them protecting the zone, not the server, you know that
they are not properly understood.

Also DNS COOKIES work in concert with RRL and could be used in concert
with DNS-over-TCP.  COOKIE have also been deployed for a number of years
and there is zero evidence that real life behaviour has been looked at.

6.8% of TLD servers respond with a valid server cookie.
https://ednscomp.isc.org/compliance/ts/tld-graphs.html

What I’d like to see what percentage of queries had a DNS COOKIE or SIT (65001)
option in them for the last 3 years in the DITL traffic so we can see
deployment rates in recursive servers.  SIT was what named sent prior to
the DNS COOKIE code point being allocated.

The paper also ignores the benefits the client sees in deploying DNS COOKIE. It
is a win for both sides to deploy.

Mark

> On 22 Jun 2018, at 3:14 am, Mark Allman <mallman at icir.org> wrote:
> 
> 
> I think the last time I flogged a paper on here, it was me who ended
> up getting flogged.  But, I apparently don't learn, so here is
> another one ... :-)
> 
> Comments appreciated!
> 
> allman
> 
> 
> Rami Al-Dalky, Michael Rabinovich, Mark Allman. Practical
> Challenge-Response for DNS. ACM Computer Communication Review,
> 48(3), July 2018. To appear.
> 
> https://www.icir.org/mallman/pubs/ARA18/
> 
> Abstract:
> 
>  Authoritative DNS servers are susceptible to being leveraged in
>  denial of service attacks in which the attacker sends DNS queries
>  while masquerading as a victim---and hence causing the DNS server
>  to send the responses to the victim. This reflection off innocent
>  DNS servers hides the attackers identity and often allows the
>  attackers to amplify their traffic by employing small requests to
>  elicit large responses. Several challenge-response techniques have
>  been proposed to establish a requester's identity before sending a
>  full answer. However, none of these are practical in that they do
>  not work in the face of "resolver pools"---or groups of DNS
>  resolvers that work in concert to lookup records in the DNS. In
>  these cases a challenge transmitted to some resolver R1 may be
>  handled by a resolver R2, hence leaving an authoritative DNS
>  server wondering whether R2 is in fact another resolver in the
>  pool or a victim. We offer a practical challenge-response
>  mechanism that uses challenge chains to establish identity in the
>  face of resolver pools. We illustrate that the practical cost of
>  our scheme in terms of added delay is small.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org