I experience the following problem with unbound-1.1.1.
A bug? or I hope somebody to kindly point out my fault.
What I did is the following.
- Sign a zone data of "example.jp", which contains an HINFO
RR, with dnssec-signzone in BIND-9.4.2, key is generated
by dnssec-keygen in BIND-9.4.2, too.
- Serve the zone by NSD 3.2.0.
The result is the following.
- Look up the HINFO RR via named(recursive only) results
NOERROR
- Look up via unbound 1.1.1 results SERVFAIL. unbound says
"message contains bad rrsets" at the time.
- Look up the A RR of same owner via unbound results
NOERROR.
# example.jp before signing:
$TTL 1m
@ IN SOA ns.example.jp. hostmaster.example.jp. (
0 ; overridden by dnssec-signzone
15m
10m
4w
15m)
$INCLUDE ksk.key
$INCLUDE zsk.key
NS ns.example.jp.
ns A 10.2.0.18
foo A 10.20.30.40
HINFO VMware FreeBSD
This is an interpretation problem in RFC4034 6.2(3).
A workaround is to give your HINFO in lowercase:
HINFO "vmware" "freebsd"
Unbound lowercases all text in the rdata of HINFO records before
verification. Because that is what I believe RFC4034 6.2(3) means.
Other software (ldns, bind) does not lowercase HINFO rdata, it seems.
It would be prudent to find a common interpretation. Something for
dnsext, already posted there.
Of course putting up a lowercase HINFO entry is against RFC1010, which
mandates all uppercase, and only - and /. Also the first word is the
CPU and second OS. Thus,
HINFO "INTEL-CORE-I7-920" "FREEBSD-7-0"
This would be appropriate use according to RFC1034/1035.
however, due to the interpretation problems in RFC4034 you are not
guaranteed DNSSEC verification unless you put this in lowercase,
HINFO "intel-386" "freebsd"
Unbound lowercases all text in the rdata of HINFO records before
verification. Because that is what I believe RFC4034 6.2(3) means.
Isn't this one of those places where you can be liberal in what you accept?
That is, trying multiple cases (wire format and lowercase, to be precise)
while validating the signature?
I mean, there's hardly a security concern in the upper/lowercase distinction.
No. Either it is case insensitive and folded by the signer already, or
the case is important. Starting to tryout which change verifies leads in
a very dangerous path. And who knows if SPF strings are not case
sensitive and when they will be used in the HINFO type
The unbound behaviour for HINFO is to follow the dnssec-updates draft.
