[dns-operations] Emoji "Female" symbol fails to resolve at Google's 8.8.8.8 & 8.8.4.4

[Phillip Hallam-Baker]

On Wed, Jul 12, 2017 at 11:41 AM, Jacques Latour <jacques.latour at cira.ca>
wrote:

>
> > DS records now withdrawn and domain working again.
>
> :-( how about fixing DNSSEC instead?
>
>
​To do that, you have to understand what it is for. Which folk refuse to
consider.

The big problem of DNSSEC is that there is only one type of information
that is worth securing with it that can be secured with it - security
policy. And DANE is broken for reasons its perpetrators were aware of but
chose to ignore.

The first step is to define the service resolution mechanism. IETF has done
this with the extended SRV + TXT record scheme but the people who did that
work were being hounded by purists who didn't understand the issues so we
have a framework in which each application can roll their own security
policy rather than an actual mechanism.


So imagine your DNS has records like

$origin example.com.
_http._tcp  SRV ..blah
_http._tcp  TXT "tls=require/1.3 pkix="MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ"

Which means connect using a minimum of TLS 1.3 and a cert that matches or
validates under a cert matching this fingerprint.

OK so now you can stop a downgrade attack using a validating resolver and
the DNS resolution protocol. But the problem is that the attacker can still
perform a downgrade attack and so can an incompetent sysadmin. And there
are enough of those for DNS resolvers to start turning off validation if
too much fails..  :(


This issue led me to the realization that the DNS resolver should do the
full recursive discovery and cache information for future use so that if
signatures don't validate, you can back up to a previous security policy
which was likely OK.

Of course once your DNS resolver is this intelligent it might as well do
the SRV jump for you and hand you back the TLS cert of the service. That
allows you to begin the initial handshake encrypted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170712/8d070894/attachment.html>