[Ach] DNSSEC and reference/mention to it

[Klaus Darilion]

Just to mention another small benefit: DNSSEC is necessary to prove that 
a domain does not exist - TLS can not help here, as there is not TLS 
connection.

regards
Klaus


On 04.02.2014 08:43, Arsen STASIC wrote:
> @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
>
>
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20140204/786fa59e/attachment.html>