DANE of SMTP Survey

Wed Jun 2 14:57:07 UTC 2021

On Wed, Jun 2, 2021 at 8:54 AM Bjørn Mork <bjorn at mork.no> wrote:

> Jeroen Massar via NANOG <nanog at nanog.org> writes:
>
> > For many organisations DNSSEC is 'scary' and a burden as it feels
> > 'fragile' for them.
>
> For "many"?  Can you name one that doesn't feel like that?
>
> https://www.arin.net/vault/announcements/2019/20190204.html
>
> https://www.ripe.net/support/service-announcements/dnssec-validation-problem-with-ripe.net
>
> DNSSEC *is* scary, fragile and a burden.  The question is whether the
> alternatives are worse.
>

Certainly. It's probably not even difficult. My large organization doesn't
find DNSSEC 'scary' or a burden and didn't even when we started in 2011. It
was simply a technical challenge that needed to be designed and integrated.
We have authoritative DNSSEC signing and recursive DNSSEC validation in
place. Public and internal authoritative DNS is mostly signed and
validation is enforced throughout our multi-layered recursive
infrastructure. A number of other organizations also do DNSSEC and have
been doing it.

I know our Internet email team is aware of the use of DANE for SMTP TLS and
are considering it, but DNSSEC is not a factor at all in their evaluation.
It's a given, just part of the DNS infrastructure they use. And I'm not
aware of any "alternative" that does what DNSSEC does. The only choice is
whether you care about verifiable DNS response integrity or not. As far as
'fragile' goes, I assume that would be implementation dependent. There's no
inherent reason an architecture would be 'fragile'. Or if you mean failure
to properly maintain your zones will break your DNS, that would be true for
any strong integrity assurance mechanism that could possibly be designed.
Integrity assurance means if things are supposed to be secured and cannot
be validated they will not resolve. That's an underlying requirement any
mechanism would have to meet or it's not providing integrity assurance.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210602/0e79ceba/attachment.html>