Repository navigation
DNSSEC validation of CNAME records is incorrect #33
Description
It seems that DNSSEC lookups of CNAME records that are digitally signed are turning the value BOGUS.
Consider this example program, which performs a RRTYPE_A and then an RRTYPE_CNAME lookup of www.nist.gov and prints all of the responses:
import getdns
extensions = {"dnssec_return_validation_chain" : getdns.EXTENSION_TRUE}
dnssec_status = {getdns.DNSSEC_SECURE:"SECURE",
getdns.DNSSEC_INDETERMINATE:"INDETERMINATE",
getdns.DNSSEC_INSECURE:"INSECURE",
getdns.DNSSEC_BOGUS:"BOGUS",
None:""}
rtype = {getdns.RRTYPE_A:"A",
getdns.RRTYPE_CNAME:"CNAME",
getdns.RRTYPE_RRSIG:"RRSIG",
getdns.RRTYPE_TLSA:"TLSA"}
print dnssec_status
#extensions = {}
if __name__=="__main__":
ctx = getdns.Context()
hostname="www.nist.gov"
for request_type in [getdns.RRTYPE_A, getdns.RRTYPE_CNAME]:
print "hostname:",hostname," request_type:",rtype[request_type]
results = ctx.general(name=hostname,request_type=request_type,extensions=extensions)
for reply in results.replies_tree:
for a in reply['answer']:
dstat = reply.get('dnssec_status')
print "request type:",a['type'],rtype[a['type']]
print "dnssec:",dstat,dnssec_status[dstat]
print "answer:",a
print "---"
print "====================="
Here is the execution:
$ python2.7 c2.py
{400: 'SECURE', 401: 'BOGUS', 402: 'INDETERMINATE', 403: 'INSECURE', None: ''}
hostname: www.nist.gov request_type: A
request type: 5 CNAME
dnssec: 400 SECURE
answer: {'ttl': 1800, 'rdata': {'rdata_raw': <read-only buffer ptr 0xdbdbc0, size 10 at 0x7f7ec1cc2070>, 'cname': 'www.glb.nist.gov.'}, 'type': 5, 'class': 1, 'name': 'www.nist.gov.'}
---
request type: 46 RRSIG
dnssec: 400 SECURE
answer: {'ttl': 1800, 'rdata': {'signers_name': 'nist.gov.', 'signature_expiration': 1442200767, 'algorithm': 7, 'type_covered': 5, 'labels': 3, 'rdata_raw': <read-only buffer ptr 0xdbe120, size 156 at 0x7f7ec1cc20b0>, 'key_tag': 43607, 'signature': <read-only buffer ptr 0xdbe1d0, size 128 at 0x7f7ec1cc20f0>, 'original_ttl': 1800, 'signature_inception': 1441594728}, 'type': 46, 'class': 1, 'name': 'www.nist.gov.'}
---
request type: 1 A
dnssec: 400 SECURE
answer: {'ttl': 30, 'rdata': {'ipv4_address': <read-only buffer ptr 0xdbe8d0, size 4 at 0x7f7ec1cc2130>, 'rdata_raw': <read-only buffer ptr 0xdbe8f0, size 4 at 0x7f7ec1cc2170>}, 'type': 1, 'class': 1, 'name': 'www.glb.nist.gov.'}
---
request type: 46 RRSIG
dnssec: 400 SECURE
answer: {'ttl': 30, 'rdata': {'signers_name': 'glb.nist.gov.', 'signature_expiration': 1441871741, 'algorithm': 7, 'type_covered': 1, 'labels': 4, 'rdata_raw': <read-only buffer ptr 0xdbee50, size 160 at 0x7f7ec1cc21b0>, 'key_tag': 56900, 'signature': <read-only buffer ptr 0xdbef00, size 128 at 0x7f7ec1cc21f0>, 'original_ttl': 30, 'signature_inception': 1441266941}, 'type': 46, 'class': 1, 'name': 'www.glb.nist.gov.'}
---
request type: 46 RRSIG
dnssec: 400 SECURE
answer: {'ttl': 30, 'rdata': {'signers_name': 'glb.nist.gov.', 'signature_expiration': 1442078767, 'algorithm': 7, 'type_covered': 1, 'labels': 4, 'rdata_raw': <read-only buffer ptr 0xdbf800, size 160 at 0x7f7ec1cc2230>, 'key_tag': 31787, 'signature': <read-only buffer ptr 0xdbf8b0, size 128 at 0x7f7ec1cc2270>, 'original_ttl': 30, 'signature_inception': 1441473967}, 'type': 46, 'class': 1, 'name': 'www.glb.nist.gov.'}
---
=====================
hostname: www.nist.gov request_type: CNAME
request type: 5 CNAME
dnssec: 401 BOGUS
answer: {'ttl': 1800, 'rdata': {'rdata_raw': <read-only buffer ptr 0xdf2240, size 10 at 0x7f7ec1ccab30>, 'cname': 'www.glb.nist.gov.'}, 'type': 5, 'class': 1, 'name': 'www.nist.gov.'}
---
request type: 46 RRSIG
dnssec: 401 BOGUS
answer: {'ttl': 1800, 'rdata': {'signers_name': 'nist.gov.', 'signature_expiration': 1442200767, 'algorithm': 7, 'type_covered': 5, 'labels': 3, 'rdata_raw': <read-only buffer ptr 0xdf27a0, size 156 at 0x7f7ec1ccab70>, 'key_tag': 43607, 'signature': <read-only buffer ptr 0xdf2850, size 128 at 0x7f7ec1ccabb0>, 'original_ttl': 1800, 'signature_inception': 1441594728}, 'type': 46, 'class': 1, 'name': 'www.nist.gov.'}
---
=====================
$
As you can see, it says that the results of the A lookups are secure, but the result of the CNAME lookup is bogus.
However, when I use dig, I am told that the CNAME lookup is properly signed:
$ dig @8.8.8.8 -t cname www.nist.gov +dnssec
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.38.amzn1 <<>> @8.8.8.8 -t cname www.nist.gov +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30092
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.nist.gov. IN CNAME
;; ANSWER SECTION:
www.nist.gov. 1286 IN CNAME www.glb.nist.gov.
www.nist.gov. 1286 IN RRSIG CNAME 7 3 1800 20150914031927 20150907025848 43607 nist.gov. Bqqs7Jgv8yGh0jN5Cmwkyj1PRGAyEdCh3uns3TcPcT1ix6mbN5u1TNHO 8LM/gUTGPYNOPEKdY02zPHIVF3DVoj7HjkoSWZ3njO091A75ZuQM+HEq S7zLR8HPn1KOZCaL3YcqNA0CXlDITFdEzeTa0UuiT31dHq8oihme47as SW4=
;; Query time: 10 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Sep 7 21:18:12 2015
;; MSG SIZE rcvd: 231
$
Activity
wtoorop commentedon Sep 8, 2015
Thank you Simson!
This is indeed a bug in getdns' native DNSSEC validation code. Note
that the status will report secure when you will use only the
dnssec_return_status extension (and not the
dnssec_return_validation_chain extension) in full recursive resolution
mode. Also, the CNAME is assessed SECURE when not queried directly (for
example via the A query in your script).
I haven't looked deeply into it yet, but I strongly suspect that the
native DNSSEC validation code is blindly following the CNAME and in
response to the direct CNAME query combined with the detection of the
CNAME redirection, wants to validate an answer for www.glb.nist.gov
request type CNAME.
This bug is triggered only when querying directly for CNAME in stub
mode, or when using the dnssec_return_validation_chain extension. Also
the getdns_dnssec_validate() function will be affected. Indirect
queries for CNAMEs will never be affected.
I will write a patch ASAP and consult with my fellow developers how to
proceed (i.e. decide whether we need an emergency release or not).
Thank you very much for finding and reporting this! Much appreciated!
-- Willem Toorop
Op 07-09-15 om 23:18 schreef Simson L. Garfinkel:
wtoorop commentedon Sep 8, 2015
Hi Simson,
Attached patch resolved the issue and can be applied to version 0.3.0,
0.3.1 and 0.3.2 of getdns. Alternatively you can checkout the v0.3.3
branch from github and have some other "minor" bugfixes as well. If you
decide to do the latter, don't forget to equip the repo with the correct
libtool and configure scripts by doing
libtoolize -ci
autoreconf -fi
first.
Thanks again for finding and reporting this bug!
-- Willem
Op 07-09-15 om 23:18 schreef Simson L. Garfinkel:
wtoorop commentedon Sep 8, 2015
Hmmm... I didn't see the attachment in github, so here printed verbatim:
wtoorop commentedon Sep 8, 2015
Sorry, white spaces are lost that way. You can download the patch here:
https://getdnsapi.net/patches/dnssec-cname-query-validation.patch
simsong commentedon Sep 8, 2015
Thanks for the patches.
As an aside, I keep getting this error when I compile getdns with the
openssl-0.1.2d:
Traceback (most recent call last):
ImportError: /usr/local/lib/libgetdns.so.1: undefined symbol: SRP_Calc_A
My only way around this has been to remove openssl-0.1.2d from the path
when compiling getdns.
Any idea what might be causing that?
On Tue, Sep 8, 2015 at 5:42 AM, wtoorop notifications@github.com wrote:
wtoorop commentedon Sep 18, 2015
Sorry for the late response.
I haven't been able to reproduce yet. Do you see this with the
getdns-0.3.3 source tarball? Or with the develop branch?
Not that it should matter, but are your libldns and/or libunbound linked
against the same openssl?
-- Willem
Op 08-09-15 om 14:52 schreef Simson L. Garfinkel:
simsong commentedon Sep 18, 2015
You are correct. The getdns and libunbound were linked against different openssls.