DNSSEC validation by default?

Unbound
1

Hi,

I'm evaluating replacing a BIND9 resolver with Unbound. The resolver under
consideration performs DNSSEC validation using a configured trust-anchor for
an internal-only signed zone which contains SSHFP records.

Both BIND9 (running on 127.0.0.1) and Unbound (on 127.0.0.2) are able to
validate successfully:

$ drill -D @127.0.0.1 login.kerna.ie. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 59631
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; login.kerna.ie. IN NS

;; ANSWER SECTION:
login.kerna.ie. 2210 IN NS apollo.kerna.ie.
login.kerna.ie. 2210 IN RRSIG NS 5 3 14400 20081012130506 20080714130506 37514 login.kerna.ie. V7vsIJSkOFhWlITuKpKZ1qWng6nQ9ufD0H7l0dod1c45RQHfdDbz49J5QZuhOjafwocIXPx6pxKdcIsuskac0AWR214X9x/51Blym/suC8kSpndgEIzstsf+ZoRFph6PWq7RuoBN7ANgKDrCnHlFmmIBuRmiJ7WodSTWZk/lPUs= ;{id = 37514}

$ drill -D @127.0.0.2 login.kerna.ie. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 4326
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; login.kerna.ie. IN NS

;; ANSWER SECTION:
login.kerna.ie. 13792 IN NS apollo.kerna.ie.
login.kerna.ie. 13792 IN RRSIG NS 5 3 14400 20081012130506 20080714130506 37514 login.kerna.ie. V7vsIJSkOFhWlITuKpKZ1qWng6nQ9ufD0H7l0dod1c45RQHfdDbz49J5QZuhOjafwocIXPx6pxKdcIsuskac0AWR214X9x/51Blym/suC8kSpndgEIzstsf+ZoRFph6PWq7RuoBN7ANgKDrCnHlFmmIBuRmiJ7WodSTWZk/lPUs= ;{id = 37514}

A difference in behaviour occurs when I query without setting the DO bit. BIND
validates and sets AD but Unbound does not:

$ drill @127.0.0.1 login.kerna.ie. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 56073
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; login.kerna.ie. IN NS

;; ANSWER SECTION:
login.kerna.ie. 1943 IN NS apollo.kerna.ie.

$ drill @127.0.0.2 login.kerna.ie. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 44238
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; login.kerna.ie. IN NS

;; ANSWER SECTION:
login.kerna.ie. 14400 IN NS apollo.kerna.ie.

My stub resolver (FreeBSD 6.3) doesn't set DO so OpenSSH rejects the SSHFP
records it finds when using Unbound because they're not marked as secure. Is
it possible for Unbound to validate everything it can and set AD
accordingly? Or have I got the wrong end of the stick and it's actually
BIND that's misbehaving in some (admittedly convenient) way?

The behaviour is the same with Unbound 1.0.0 and 1.0.2 FWIW.

Many thanks,
james

2

Hi James,

You are using an older version of Bind9 I think; since this was
considered bad behaviour by Bind, and fixed in recent releases.
It was fixed because some legacy boxes (adsl I think) did not like
getting AD bits in their replies and crash or hang on it.

If you just want to get an AD bit in the reply if its secure, set the AD
bit in the query to signal that you are ready and able to receive the AD
bit in the reply.

That means getting your stub resolver to set 'AD' in queries.

This has just been documented in the lastest dnssec-bis-updates draft in
the IETF dnsext working group.

Sorry for the breakage,
~ Wouter

James Raftery wrote:

Hi,

I'm evaluating replacing a BIND9 resolver with Unbound. The resolver under
consideration performs DNSSEC validation using a configured

trust-anchor for

an internal-only signed zone which contains SSHFP records.

Both BIND9 (running on 127.0.0.1) and Unbound (on 127.0.0.2) are able to
validate successfully:

$ drill -D @127.0.0.1 login.kerna.ie. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 59631
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; login.kerna.ie. IN NS

;; ANSWER SECTION:
login.kerna.ie. 2210 IN NS apollo.kerna.ie.
login.kerna.ie. 2210 IN RRSIG NS 5 3 14400 20081012130506

20080714130506 37514 login.kerna.ie.
V7vsIJSkOFhWlITuKpKZ1qWng6nQ9ufD0H7l0dod1c45RQHfdDbz49J5QZuhOjafwocIXPx6pxKdcIsuskac0AWR214X9x/51Blym/suC8kSpndgEIzstsf+ZoRFph6PWq7RuoBN7ANgKDrCnHlFmmIBuRmiJ7WodSTWZk/lPUs=
;{id = 37514}

$ drill -D @127.0.0.2 login.kerna.ie. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 4326
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; login.kerna.ie. IN NS

;; ANSWER SECTION:
login.kerna.ie. 13792 IN NS apollo.kerna.ie.
login.kerna.ie. 13792 IN RRSIG NS 5 3 14400 20081012130506

20080714130506 37514 login.kerna.ie.
V7vsIJSkOFhWlITuKpKZ1qWng6nQ9ufD0H7l0dod1c45RQHfdDbz49J5QZuhOjafwocIXPx6pxKdcIsuskac0AWR214X9x/51Blym/suC8kSpndgEIzstsf+ZoRFph6PWq7RuoBN7ANgKDrCnHlFmmIBuRmiJ7WodSTWZk/lPUs=
;{id = 37514}

A difference in behaviour occurs when I query without setting the DO

bit. BIND

validates and sets AD but Unbound does not:

$ drill @127.0.0.1 login.kerna.ie. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 56073
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; login.kerna.ie. IN NS

;; ANSWER SECTION:
login.kerna.ie. 1943 IN NS apollo.kerna.ie.

$ drill @127.0.0.2 login.kerna.ie. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 44238
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; login.kerna.ie. IN NS

;; ANSWER SECTION:
login.kerna.ie. 14400 IN NS apollo.kerna.ie.

My stub resolver (FreeBSD 6.3) doesn't set DO so OpenSSH rejects the SSHFP
records it finds when using Unbound because they're not marked as

secure. Is

3

You are using an older version of Bind9 I think; since this was
considered bad behaviour by Bind, and fixed in recent releases.
It was fixed because some legacy boxes (adsl I think) did not like
getting AD bits in their replies and crash or hang on it.

correct (and I was the one that found the bug) - some crappy NAT-boxes dropped DNS answers with AD set.

If you just want to get an AD bit in the reply if its secure, set the AD
bit in the query to signal that you are ready and able to receive the AD
bit in the reply.

That means getting your stub resolver to set 'AD' in queries.

This has just been documented in the lastest dnssec-bis-updates draft in
the IETF dnsext working group.

yes, this is way to go.

  jakob

4

Hi,

It was fixed because some legacy boxes (adsl I think) did not like
getting AD bits in their replies and crash or hang on it.

Grr! That's annoying. You're right; I'm using BIND 9.3 on the DNSSEC
resolvers.

That means getting your stub resolver to set 'AD' in queries.
Sorry for the breakage,

lol No problem - it's not your fault :slight_smile: My stub has a RES_USE_DNSSEC macro
to set DO if I recompile (yuk) but not a ready-made knob to set AD. I'll
experiment with DO and see how it goes. I don't particularly want my stub
getting all the RRSIGs, etc. Ah well. It looks like I'll have to keep BIND
9.3 for the short-term :confused:

Thanks for your reply (and for Unbound)!

All the best,
james

5

Can we make that behavior configurable?

Roy

6

Roy Arends wrote:

Can we make that behavior configurable?

Roy

Well. I would rather not.

The default would need to be the safe behaviour. And the number of
users that need the unsafe behaviour is very small. Is an upgrade of
the other software an option? (it was expecting AD bits in replies, so
it can be made to set them in queries, I would think).

Best regards,
~ Wouter

7

Hi,

The default would need to be the safe behaviour. And the number of
users that need the unsafe behaviour is very small. Is an upgrade of
the other software an option? (it was expecting AD bits in replies, so
it can be made to set them in queries, I would think).

FreeBSD uses the BIND9 resolver library and that doesn't yet have a
supported twiddle to set AD on queries. I'll pop a note off to the ISC to
ask if it's in the pipeline.

In the meantime I've recompiled libresolv to set DO on queries and that's
working fine for the moment.

A configurable option in Unbound to have the `old BIND' behaviour while the
world's stubs catch up to the new usage of AD in queries would definitely be
good for me :slight_smile:

Thanks again,
james