Trust rules and DNSSEC signatures

[Florian Weimer via Unbound-users]

Does Unbound use otherwise non-trustworthy data simply because it has
valid DNSSEC signatures?

I'm asking because of this recent dnsop thread:

  

Re: TCP fallback on timeout

[Viktor Dukhovni via Unbound-users]

On Wed, Apr 26, 2017 at 08:14:09PM -0700, Jacob Hoffman-Andrews wrote:

> I'm trying to understand Unbound's TCP fallback better. Is it expected
> that Unbound will fall back to TCP when UDP queries timeout, or only if
> it receives a truncated ANSWER?

Only when truncated as you observed.

> Specifically, I'm trying to make CAA queries, and finding that, when
> querying a certain DNS provider (NetRegistry), UDP queries time out but
> TCP queries succeed.

That provider has a misconfigured (often Arbor Networks) firewall
in front of their nameservers, and the firewall is dropping queries
for all but a set of "standard" RRtypes.  Ofen in my experience
(when the firewall is Arbor Networks) IPv6 UDP queries also work,
when the nameservers have IPv6 addresses.  In other words, the
filtering is in place only for UDP+IPv4.

The right thing to do is to not implement work-arounds for the
problem on the client end.  Instead, let operational errors lead
to failure, but notify the operator so they remediate the issue.
This will fix lookup issues for CAA, CDS, TLSA, SMIMEA, OPENPGPKEY,
whether the resolver is unbound, BIND, ...

If you email me a small list of problem domains (served by the
problem nameservers), I can get the ball rolling, open a new
entry under:

https://github.com/dns-violations/dns-violations

and notify the errant provider.

-- 
Viktor.

Re: Trust rules and DNSSEC signatures

[Paul Wouters via Unbound-users]

> On Apr 27, 2017, at 08:11, Florian Weimer via Unbound-users 
>  wrote:
> 
> Does Unbound use otherwise non-trustworthy data simply because it has
> valid DNSSEC signatures?
> 

How can data be signed and validated and also "non-trustworthy" ?

I see how data can be unwanted or superfluous, but if it validates then the 
daemon could obtain the same data using direct queries. So I am not sure what 
the actual problem is. "If crypto fails then evil could happen" isn't a very 
convincing augment against additional signed data and efforts to reduce latency 
in a proper implementation.

Paul

Re: Trust rules and DNSSEC signatures

[Florian Weimer via Unbound-users]

* Paul Wouters:

>> On Apr 27, 2017, at 08:11, Florian Weimer via Unbound-users
>>  wrote:
>> 
>> Does Unbound use otherwise non-trustworthy data simply because it has
>> valid DNSSEC signatures?
>> 
>
> How can data be signed and validated and also "non-trustworthy" ?

Non-trustworthy according to DNS rules.  For example, data from the
target in a complete different zone for which the server providing the
reply is not even authoritative.

> I see how data can be unwanted or superfluous, but if it validates
> then the daemon could obtain the same data using direct queries.

Only if the cryptographic validation is correct.

> So I am not sure what the actual problem is. "If crypto fails then
> evil could happen" isn't a very convincing augment against
> additional signed data and efforts to reduce latency in a proper
> implementation.

It absolutely is because cryptographic never works correctly.  Most
people assume they don't have to worry too much about DNSSEC
validation bugs because there are other non-cryptographic security
features an attacker would have to bypass as well.

If DNSSEC, as implemented, disables these security features and more,
then enabling DNSSEC increases risk.

Enabling DNSSEC is fine if it is an add-on measure, but if it throws
out pretty much all the other protocol protections, it's unlikely that
it's a win from a security perspective.

Re: TCP fallback on timeout

[Jacob Hoffman-Andrews via Unbound-users]

On 04/27/2017 07:27 AM, Viktor Dukhovni via Unbound-users wrote:
> On Wed, Apr 26, 2017 at 08:14:09PM -0700, Jacob Hoffman-Andrews wrote:
>
>> I'm trying to understand Unbound's TCP fallback better. Is it expected
>> that Unbound will fall back to TCP when UDP queries timeout, or only if
>> it receives a truncated ANSWER?
> Only when truncated as you observed.
Thanks for the info.

Another question: For CA queries in general (A, , TXT, CAA), Let's
Encrypt has gotten feedback that using TCP to query authoritative
resolvers is more secure and less likely to be spoofed. Unfortunately,
DNS servers aren't required to support TCP. This is another reason why
we've been considering running to recursive resolvers, one with
tcp-upstream: yes, and one with tcp-upstream: no. The idea would be that
the CA software (Boulder) would first attempt to query the tcp-upstream:
yes instance, and fall back to the tcp-upstream: no instance on errors.
In your opinion, is this a reasonable setup, and does it meaningfully
increase protections against spoofing?

Re: Trust rules and DNSSEC signatures

[Robert Edmonds via Unbound-users]

Florian Weimer via Unbound-users wrote:
> Does Unbound use otherwise non-trustworthy data simply because it has
> valid DNSSEC signatures?
> 
> I'm asking because of this recent dnsop thread:
> 
>   

Hi, Florian:

It's been a while since I studied the Unbound architecture, but I
believe the answer to your question is "no", due to Unbound's separation
of iteration and validation into separate modules. (E.g.,
'module-config: "validator iterator"'.) If I understand correctly, the
iterator module is responsible for "scrubbing" response messages, which
includes things like deleting out-of-zone information from the response,
and it doesn't scrub conditionally based on whether the validator module
is also present in the module stack.

-- 
Robert Edmonds
edmo...@debian.org

Re: Trust rules and DNSSEC signatures

[Robert Edmonds via Unbound-users]

Florian Weimer via Unbound-users wrote:
> * Paul Wouters:
> 
> >> On Apr 27, 2017, at 08:11, Florian Weimer via Unbound-users
> >>  wrote:
> >> 
> >> Does Unbound use otherwise non-trustworthy data simply because it has
> >> valid DNSSEC signatures?
> >> 
> >
> > How can data be signed and validated and also "non-trustworthy" ?
> 
> Non-trustworthy according to DNS rules.  For example, data from the
> target in a complete different zone for which the server providing the
> reply is not even authoritative.
> 
> > I see how data can be unwanted or superfluous, but if it validates
> > then the daemon could obtain the same data using direct queries.
> 
> Only if the cryptographic validation is correct.

Why? If an attacker can steal a zone signing key and use it to forge
signatures, *and* a validator implementation does not enforce
out-of-bailiwick rules for validly signed data, then there is no need
for the forged data to also be available via direct queries. That is a
good reason to continue to reject out-of-bailiwick data even if it is
validly signed.

-- 
Robert Edmonds
edmo...@debian.org

Re: TCP fallback on timeout

[Havard Eidnes via Unbound-users]

> Unfortunately, DNS servers aren't required to support TCP.

IMHO, that is an all too commonly held misconception.  Publishing name
servers need to support TCP as well.  I'm pretty sure section 4.2 of
RFC 1035 mandates it.  It doesn't use the formal requirements keywords
because it predates the RFC which defined their use in this document
series.

Regards,

- Håvard

Re: TCP fallback on timeout

[Paul Vixie via Unbound-users]

Havard Eidnes via Unbound-users wrote:
>> Unfortunately, DNS servers aren't required to support TCP.
> 
> IMHO, that is an all too commonly held misconception.  Publishing name
> servers need to support TCP as well.  I'm pretty sure section 4.2 of
> RFC 1035 mandates it.  It doesn't use the formal requirements keywords
> because it predates the RFC which defined their use in this document
> series.

"mandate" and "required" would be stronger words than the context could
sustain.

in practical terms, there are and have always been and will always be
authority name servers who never set TC=1 on UDP, and which do not
support TCP, either by design or because of firewalls. these name
servers work just fine, and that "works just fine" attribute has first
mover advantage: any client that uses only TCP will get no service from
those name servers, and the client not the server will be found "at
fault" for the nonfunction, and so the client will be "fixed" rather
than the server.

so in effect, TCP is not required, and will never be required. the
installed base and its long tail matter more than the wording of 1035.

-- 
P Vixie