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
[email protected]
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
