[Dnsmasq-discuss] Testers wanted: DNSSEC.

Wed Feb 5 08:46:03 GMT 2014

On 05/02/14 01:36, Matthias Andree wrote:
> Am 04.02.2014 16:29, schrieb Simon Kelley:
>> DNSSEC in dnsmasq is a long story. There have been requests for the
>> feature for at least five years, and work was started in earnest two
>> years ago, when Giovanni Bajo got much of the way on validation, and I
>> made the necessary changes to the cache code. That effort stalled until
>> this winter, when  grant from Comcast
>> (http://techfund.comcast.com/index.php/home/root/comcast-news/summer-2013-project-support-update)
>> allowed me to work full-time to get things moving again.
>
> I am testing -test6 on FreeBSD 9.2 amd64,
> and
>
> 1. I am getting different results on two subsequent identical queries
> WRT RRSIG record and AD flag.
>
> 2. I am not so sure if RRSIG belongs in the Answer section of the first
> run in the first place, but I have not studied the DNSSEC IETF standards.
>
> To test, run this (assuming 10.9.8.7 is hosting your dnsmasq, else adjust):
>
> $ dig @10.9.8.7 sigok.verteiltesysteme.net.
>
> (This is from <http://dnssec.vs.uni-due.de/>, they also have a
> sigfail.verteiltesysteme.net. RR)
>
> Note the result contains rrsig, and an "ad" flag.
>
> Run the *same* dig command again, and you no longer get the cached RRSIG
> in the answer and additional sections of the reply, nor the "ad" flag.
>
> First run:
>
>> ; <<>> DiG 9.8.4-P2 <<>> @127.0.0.1 sigok.verteiltesysteme.net.
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57211
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 9
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
>> ;; QUESTION SECTION:
>> ;sigok.verteiltesysteme.net.	IN	A
>>
>> ;; ANSWER SECTION:
>> sigok.verteiltesysteme.net. 60	IN	A	134.91.78.139
>> sigok.verteiltesysteme.net. 60	IN	RRSIG	A 5 3 60 20140807184544 20130807174544 30665 verteiltesysteme.net. C8TG0IWcDh3IiH5+t3eNvdfQ+z+6B8DWN9gIRRn4dYvmeJ+JqLmovajC 7cY7pfa2RNfkAziydI2eCxYfBc6P8vP3XR4XdV91d5XmhHeqwJNK0P+h mv9+JMG+1qzhSbRugB/mYdfBiLrO+fJrB25CzDSEGhj0nelVHPzRfz9b uoY=
>>
>> ;; AUTHORITY SECTION:
>> verteiltesysteme.net.	3113	IN	NS	ns2.verteiltesysteme.net.
>> verteiltesysteme.net.	3113	IN	NS	ns1.verteiltesysteme.net.
>> verteiltesysteme.net.	3600	IN	RRSIG	NS 5 2 3600 20140807184544 20130807174544 30665 verteiltesysteme.net. Qlfx5F7c2nIHNc9nugx2nr64fyq43Zr08cIC+LeYV5YSrI1OoVxkFHma 46mKlti76ocJbIXnxDzaJDlciHkPTUbbgWN57+dU6gDdd4WYNy1Q5sx8 VnmRujLo17OG4lhsK/+fWSAWEWuNnbUtjx46ePm8iHRtlZM0lmvi+Yiz ov4=
>>
>> ;; ADDITIONAL SECTION:
>> ns1.verteiltesysteme.net. 172313 IN	A	134.91.78.139
>> ns1.verteiltesysteme.net. 172313 IN	AAAA	2001:638:501:8efc::139
>> ns2.verteiltesysteme.net. 172313 IN	A	134.91.78.141
>> ns2.verteiltesysteme.net. 172313 IN	AAAA	2001:638:501:8efc::141
>> ns1.verteiltesysteme.net. 3600	IN	RRSIG	A 5 3 3600 20140807184544 20130807174544 30665 verteiltesysteme.net. ca+sMK15TJ2KI64YwjEoDSjkz5wR9s0VoZSB1dEEAzfUFD/z2RGxCr3y KHChCV6Ia5BjRal7JHR9udLHBxAinRIHZcR38Prd3EVPO9q7ci0VqrWT QO9CZFF1DZ5DtcWL8IWFtqf+9OfZyl1pKFoHGywhK1wi8ykD4+Osnpy3 cMg=
>> ns1.verteiltesysteme.net. 3600	IN	RRSIG	AAAA 5 3 3600 20140807184544 20130807174544 30665 verteiltesysteme.net. HeEOfKbGF1UFc96bsPPVviH9bnWnJB8XirKP8cJpUrwiYZdUmAwiN349 vh14oxkQHU0vSrw5IDnK20D71x0uf8q+EXJzt1qG/2uEi6D/72aPEB2m Ke8mVeFwC/Z8/Cwfh7o99x8gWymeTc8lZNiXzaqdYp+2a7MBWmhe9Ymu t4M=
>> ns2.verteiltesysteme.net. 3600	IN	RRSIG	A 5 3 3600 20140807184544 20130807174544 30665 verteiltesysteme.net. jDhD/SCNbDXYErsB+8ne3asgjxOutT4ylKj7LnPYHPszr5SHmk03bE9k 0cHKrlRlRtvQd1ZQwx/OFjmZCCiRJwnCnTwU00arxJa4XOe14HbVIobp D3/e8BbKDLOgiDtI4mzbLU+qJUy/Yw8EuWH6cEp1600rmIjJ8zW+gKsf FhQ=
>> ns2.verteiltesysteme.net. 3600	IN	RRSIG	AAAA 5 3 3600 20140807184544 20130807174544 30665 verteiltesysteme.net. JHCnSkP2JKeqpcAIL40B05wcQPX2kEgTFAvC2Qdmck8nx+KIzQsGMLa1 aOvoN7rcUivLlhXHFR0ve5NTdxdJi3pBJmITPjZJf7SvYX2DydKpixCm VNWrqadHoz+H/1XImXN+qzlEZy7oMAcx8bYFSa38aHFhdFFQoe7qNwOP Wow=
>>
>> ;; Query time: 44 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Wed Feb  5 02:34:04 2014
>> ;; MSG SIZE  rcvd: 1275
>>
>
> Second run:
>
>> ; <<>> DiG 9.8.4-P2 <<>> @127.0.0.1 sigok.verteiltesysteme.net.
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22950
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>>
>> ;; QUESTION SECTION:
>> ;sigok.verteiltesysteme.net.	IN	A
>>
>> ;; ANSWER SECTION:
>> sigok.verteiltesysteme.net. 44	IN	A	134.91.78.139
>>
>> ;; Query time: 0 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Wed Feb  5 02:34:20 2014
>> ;; MSG SIZE  rcvd: 60
>>
>
> HTH
>

My guess is that the first answer comes from the upstream nameserver, 
and the second from the dnsmasq cache. In order to get the DNSSEC 
information it needs to do validation, dnsmasq sets the D0 bit in the 
query, so that the upstream server does DNSSEC processing. That menas 
the answer has the RRSIG records in the answer section and the answer 
gets relayed back to the original reuestor. I've considered (and am 
still considering) stripping that information from the replies, but it's 
more difficult to do that reliably than it might appear, and it's not 
clear is that route is more or less likely to create problems than 
sending the information through to the client.

The second answer comes from the cache, and the D0 bit is not set in the 
query, so the answer doesn't have the AD  flag or RRSIG, if you add 
"+dnssec" to the dig command you should see both in replies from the cache,

Cheers,

Simon.