Dnssec stripping not resulting in serv fail?

Unbound
1

Hi,

I was recently at the SFO airport, and ran into a DNS server on their free
wifi that does DNSSEC stripping. Or at least, it knows about dnssec related
RRTYPE's (DNSKEY, etc) but does not serve RRSIG's when requesting dnssec with
the DO bit.

In my case, I had unbound running and configured it to use the dhcp supplied
forwarder using: unbound-control forward 1.2.3.4

It was just primed with the root key. There is a trust path from the root all
the way down to xelerance.org. However, unbound gave me the IP without me
specifying the CD bit. It logged:

unbound: [23014:0] info: incoming scrubbed packet: ;;

I had harden-dnssec-stripped:yes

I'm not very comfortable that applications receive this potentially forged data,
even if unbound returns it without the AD bit. This is more then insecure, this
is "tampered with".

What is the reasoning behind this decision with unbound?

Isn't harden-dnssec-stripped supposed to toggle this?

Could we have an option that would ServFail data from confirmed scrubbed packets?

Paul

2

Hi Paul,

Hi,

I was recently at the SFO airport, and ran into a DNS server on their free
wifi that does DNSSEC stripping. Or at least, it knows about dnssec related
RRTYPE's (DNSKEY, etc) but does not serve RRSIG's when requesting dnssec
with
the DO bit.

It should servfail.

In my case, I had unbound running and configured it to use the dhcp
supplied
forwarder using: unbound-control forward 1.2.3.4

But that statement leaves the cache intact, where a previously validated
(at home or the office) RR may reside.

It was just primed with the root key. There is a trust path from the
root all
the way down to xelerance.org. However, unbound gave me the IP without me
specifying the CD bit. It logged:

unbound: [23014:0] info: incoming scrubbed packet: ;;

If you start logging it should log lots more than that. If you get
there again, it could be helpful to clear the cache and then try with
logging enabled.

I think you had a valid entry in the cache, that was returned, without
actually sending queries at SFO.

Best regards,
   Wouter

3

I was recently at the SFO airport, and ran into a DNS server on their free
wifi that does DNSSEC stripping. Or at least, it knows about dnssec related
RRTYPE's (DNSKEY, etc) but does not serve RRSIG's when requesting dnssec
with
the DO bit.

It should servfail.

It did not.

In my case, I had unbound running and configured it to use the dhcp
supplied
forwarder using: unbound-control forward 1.2.3.4

But that statement leaves the cache intact, where a previously validated
(at home or the office) RR may reside.

I always restarted unbound fully.

If you start logging it should log lots more than that. If you get
there again, it could be helpful to clear the cache and then try with
logging enabled.

I did capture the logs, mailed to you offlist.

I think you had a valid entry in the cache, that was returned, without
actually sending queries at SFO.

I don't think so. For each test I ran a "service unbound restart", and
since resolv.conf was not configured to use 127.0.0.1, nothing could
have used unbound until I started sending it queries for xelerance.org
after I ran the unbound-control forward statement.

Paul

4

Hi Paul,

It should servfail.

It did not.

What was the query that servfailed? I can see in the logs that it is
retrying xelerance.org queries (for A, AAAA and type RRSIG). Because
type RRSIG cannot be validated, you may have received a reply for that one.

Could it be that your (Mac?) tried to fail over to another DNS server
even though you did not want that? What you say about resolv.conf makes
this unlikely, and you did a straight dig @127.0.0.1, I guess.

I always restarted unbound fully.

Good to know.

I did capture the logs, mailed to you offlist.

Thanks!

Did you notice these lines:
remote control failed ssl crypto error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol

Looks like some garbage connection to the unbound-control port.

I don't think so. For each test I ran a "service unbound restart", and
since resolv.conf was not configured to use 127.0.0.1, nothing could
have used unbound until I started sending it queries for xelerance.org
after I ran the unbound-control forward statement.

It looks like you have a downstream validator, and this unbound does not
have a lot of trust anchors? It has trust anchors, right? I can see
you editing trust anchor config earlier in the logs. The downstream
validator seems to make DNSKEY and RRSIG queries. And I see a lot of
retries (due to DNSSEC failures?).

These logs are confusing, I see they are log level 4 or 5 or so, but
they are missing stuff (such as the configured trust anchors printout at
start).

Best regards,
   Wouter

5

What was the query that servfailed?

There was nothing that servfailed, that was the point.

I can see in the logs that it is
retrying xelerance.org queries (for A, AAAA and type RRSIG). Because
type RRSIG cannot be validated, you may have received a reply for that one.

Yes, I digged specifically for xelerance.org

Could it be that your (Mac?) tried to fail over to another DNS server

no. It was Fedora Linux, resolv.conf not used at all

even though you did not want that? What you say about resolv.conf makes
this unlikely, and you did a straight dig @127.0.0.1, I guess.

Yes.

I always restarted unbound fully.

Good to know.

I did capture the logs, mailed to you offlist.

Thanks!

Did you notice these lines:
remote control failed ssl crypto error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol

Looks like some garbage connection to the unbound-control port.

I might have made some unbound-control command errors. I don't remember.

It looks like you have a downstream validator, and this unbound does not
have a lot of trust anchors?

It just had the root key.

It has trust anchors, right? I can see
you editing trust anchor config earlier in the logs.

Yes, I had some syntax errors before i finally had the syntax right :slight_smile:

The downstream
validator seems to make DNSKEY and RRSIG queries. And I see a lot of
retries (due to DNSSEC failures?).

I guess?

These logs are confusing, I see they are log level 4 or 5 or so, but
they are missing stuff (such as the configured trust anchors printout at
start).

I grepped for "unbound". I'll check the logs and see if some lines do not
contain that string.

Paul

6

Hi Paul,

There was nothing that servfailed, that was the point.

Yes, of course.

Yes, I digged specifically for xelerance.org

It looks like unbound acted as if it was not configured with a trust
anchor, it did not try to prime its trust anchor, for example.

If you start unbound with verbosity 4 (-vvvv) it prints the trust
anchors and root hints as it is starting.

You can also examine what unbound thinks is configured with
unbound-checkconf -o auto-trust-anchor-file
and unbound-control get_option auto-trust-anchor-file

(or, dlv-anchor-file, or trust-anchor-file, or trust-anchor).

no. It was Fedora Linux, resolv.conf not used at all

ok

I might have made some unbound-control command errors. I don't remember.

Yeah, maybe it you killed it before the TLS init succeeded.

It just had the root key.

Weird, it does not act like it has one. I do see it go into the
validator, but then does not act like there is a root key. Or as if you
had domain-insecure: xelerance.org configured.

Yes, I had some syntax errors before i finally had the syntax right :slight_smile:

Sorry about that :slight_smile:

I grepped for "unbound". I'll check the logs and see if some lines do not
contain that string.

unlikely to be there, it logs with 'unbound:' all the time. But thanks
for looking.

Best regards,
   Wouter