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.



_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to