[Ach] DNSSEC and reference/mention to it

[Arsen STASIC]

@azet: DDoS utilizing DNSSEC is already an issue we have run into: 
First attacks appeared in autumn 2012, in January 2013 ccTLD .ch was
under attack
https://www.switch.ch/about/news/2013/ddos.html
and in March 2013 spamhouse.org 
http://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho

Software vendors have added RRL (Response Rate Limiting) to address
DNSSEC DDos. Since bind 9.9.4 its part of ISC's official bind release.
Red Hat took the RRL-patch and deployed it to REHL 6
(bind-9.8.2-0.17.rc1.el6). Ubuntu also ships bind with RRL since
version 9.8.4.dfsg.P1-5. And other vendors beside ISC (bind) also ship
patched versions for their nameserver software:
NSD: http://www.nlnetlabs.nl/projects/nsd/
Knot DNS: https://www.knot-dns.cz/

Regarding deployment of DNSSEC-zones:
https://xs.powerdns.com/dnssec-nl-graph/



@Julien: DNSSEC just checks the integrity of DNS. It's not more than
that. In order to check signatures an DNSSEC enabled resolver is also
needed!
Is it worth the effort? I do not know. But how could you with TLS
prevent, that someone has not changed DNS and points you somewhere else?
Who is really tracking if an certificate authority has changed in oder
to have evidence that possibly someone tries to redirect you? I have no
answers to that but DNSSEC can address it!
Everyone hat to decide on its own, if it's worth the effort. We are just
providing howtos to everyone.

-arsen


* Aaron Zauner <azet at azet.org> [2014-02-03 18:02 (+0100)]:
> So,.. does anybody remember this talk by DJB on DDOS via the DNSSEC
> protocol: http://cr.yp.to/talks/2009.08.10/slides.pdf
> 
> I'm not that up-to-date on that, but as far as I know this issue presists,
> right?
> 
> Aaron
> 
> 
> On Mon, Feb 3, 2014 at 5:24 PM, Julien Vehent <julien at linuxwall.info> wrote:
> 
> > On 2014-02-03 11:04, Alexander Wuerstlein wrote:
> >
> >> On 14-02-03 17:00, Julien Vehent <julien at linuxwall.info> wrote:
> >>
> >>>
> >>> There has been a lot of discussions on whether DNSSEC adds security when
> >>> already using TLS at the protocol level. The main argument is that both
> >>> TLS and DNSSEC use a 3rd party trust model, and thus have the same level
> >>> of security. If an attacker can obtain a certificate for example.net, he
> >>> should be capable of obtaining a signed DNS record for example.net.
> >>>
> >>> The question is then: is DNSSEC worth the effort?
> >>>
> >>
> >> That is a very HTTP-centric view of things which is only valid if there
> >> is nothing else. But redirecting SMTP connections via faked DNS entries
> >> is still a problem even with TLS since SMTP only uses opportunistic
> >> encryption with minimal or no checks. Other protocols may have similar
> >> (albeit similarly stupid) problems, so yes, DNSSEC is worth the effort,
> >> at least until every protocol does TLS properly and always.
> >>
> >>
> > HTTP is irrelevant here. The same security concept applies to any protocol
> > that relies on TLS. What you are discussing can be broken down in 3
> > categories;
> >  1. transport protocol is cleartext
> >  2. transport protocol uses opportunistic encryption (STARTTLS)
> >  3. transport protocol enforces TLS
> >
> > I am only challenging the level of security that DNSSEC adds in category 3.
> >
> > For category 1 and 2, we could argue that the need for transport level
> > encryption is still there, and not covered by DNSSEC. Thus, does DNSSEC
> > solve
> > a problem that is worth the (significant) effort it takes to deploy it.
> >
> > Or would that time be better spent enforcing TLS on those services?
> > (you can tell you smtp client to require STARTTLS, btw)
> >
> > - Julien
> >
> > _______________________________________________
> > Ach mailing list
> > Ach at lists.cert.at
> > http://lists.cert.at/cgi-bin/mailman/listinfo/ach
> >

> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140204/36edb2eb/attachment.sig>