Discussion:
[Dnsmasq-discuss] Wildcard Domain resolving does not work with DNSSEC
Uwe Schindler
2016-01-04 14:48:46 UTC
Permalink
Hi,

I found out that resolving of DNSSEC signed wildcard domains does not work correctly with dnsmasq. I think the problem is that it looks for a signature of the requested domain name and not the wildcard.

The following fails:

$ dig issues.pangaea.de

; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> issues.pangaea.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59252
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;issues.pangaea.de. IN A

;; Query time: 18 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 04 15:43:42 CET 2016
;; MSG SIZE rcvd: 46


The reason is: "issues.pangaea.de" is covered by a star domain "*.pangaea.de" that is correctly signed (tested from another server - not using dnsmasq):

$ dig +dnssec *.pangaea.de

; <<>> DiG 9.8.1-P1 <<>> +dnssec '*.pangaea.de'
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8436
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;*.pangaea.de. IN A

;; ANSWER SECTION:
*.pangaea.de. 28790 IN A 134.1.2.171
*.pangaea.de. 28790 IN RRSIG A 7 2 28800 20160109144508 20151226151023 12714 pangaea.de. jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64=

;; AUTHORITY SECTION:
pangaea.de. 28790 IN NS ns2.domaindiscount24.net.
pangaea.de. 28790 IN NS ns3.domaindiscount24.net.
pangaea.de. 28790 IN NS ns1.domaindiscount24.net.
pangaea.de. 28790 IN RRSIG NS 7 2 28800 20160109071640 20151226151023 12714 pangaea.de. l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g=

;; Query time: 0 msec
;; SERVER: 85.25.128.10#53(85.25.128.10)
;; WHEN: Mon Jan 4 14:42:43 2016
;; MSG SIZE rcvd: 471

How should this be solved? This is another one where dnssec fails, so clearly a bug.

There is a test page about exactly that case, which fails for me when resolving through dnsmasq: http://0skar.cz/dns/en/

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: ***@thetaphi.de
Uwe Schindler
2016-01-04 14:57:12 UTC
Permalink
Please note:
I fixed the example domain to have a real A record. Try any other fake name instead:
e.g., "dummy.pangaea.de", also referring to wildcard domain.

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
-----Original Message-----
Sent: Monday, January 04, 2016 3:49 PM
Subject: Wildcard Domain resolving does not work with DNSSEC
Hi,
I found out that resolving of DNSSEC signed wildcard domains does not work
correctly with dnsmasq. I think the problem is that it looks for a signature of
the requested domain name and not the wildcard.
$ dig issues.pangaea.de
; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> issues.pangaea.de
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59252
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 4096
;issues.pangaea.de. IN A
;; Query time: 18 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 04 15:43:42 CET 2016
;; MSG SIZE rcvd: 46
The reason is: "issues.pangaea.de" is covered by a star domain
"*.pangaea.de" that is correctly signed (tested from another server - not
$ dig +dnssec *.pangaea.de
; <<>> DiG 9.8.1-P1 <<>> +dnssec '*.pangaea.de'
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8436
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 4096
;*.pangaea.de. IN A
*.pangaea.de. 28790 IN A 134.1.2.171
*.pangaea.de. 28790 IN RRSIG A 7 2 28800 20160109144508
20151226151023 12714 pangaea.de.
jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q
MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m
HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64=
pangaea.de. 28790 IN NS ns2.domaindiscount24.net.
pangaea.de. 28790 IN NS ns3.domaindiscount24.net.
pangaea.de. 28790 IN NS ns1.domaindiscount24.net.
pangaea.de. 28790 IN RRSIG NS 7 2 28800 20160109071640
20151226151023 12714 pangaea.de.
l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p
O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql
maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g=
;; Query time: 0 msec
;; SERVER: 85.25.128.10#53(85.25.128.10)
;; WHEN: Mon Jan 4 14:42:43 2016
;; MSG SIZE rcvd: 471
How should this be solved? This is another one where dnssec fails, so clearly
a bug.
There is a test page about exactly that case, which fails for me when
resolving through dnsmasq: http://0skar.cz/dns/en/
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
Kevin Darbyshire-Bryant
2016-01-04 15:39:59 UTC
Permalink
Post by Uwe Schindler
Hi,
I found out that resolving of DNSSEC signed wildcard domains does not work correctly with dnsmasq. I think the problem is that it looks for a signature of the requested domain name and not the wildcard.
;; Query time: 0 msec
;; SERVER: 85.25.128.10#53(85.25.128.10)
;; WHEN: Mon Jan 4 14:42:43 2016
;; MSG SIZE rcvd: 471
How should this be solved? This is another one where dnssec fails, so clearly a bug.
There is a test page about exactly that case, which fails for me when resolving through dnsmasq: http://0skar.cz/dns/en/
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
I just tried that page using dnsmasq276test2 and got 'green' for all tests.

Kevin
Uwe Schindler
2016-01-04 16:05:03 UTC
Permalink
Hi,

Was there a change in dnsmasq related to this? Would be good to get some feedback. I'll try this version now. Currently I am running 2.75 (Debian testing pkg 2.75-1)
Do you have dnssec enabled?

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
-----Original Message-----
From: Dnsmasq-discuss [mailto:dnsmasq-discuss-
Sent: Monday, January 04, 2016 4:40 PM
Subject: Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work
with DNSSEC
Post by Uwe Schindler
Hi,
I found out that resolving of DNSSEC signed wildcard domains does not
work correctly with dnsmasq. I think the problem is that it looks for a
signature of the requested domain name and not the wildcard.
Post by Uwe Schindler
;; Query time: 0 msec
;; SERVER: 85.25.128.10#53(85.25.128.10)
;; WHEN: Mon Jan 4 14:42:43 2016
;; MSG SIZE rcvd: 471
How should this be solved? This is another one where dnssec fails, so
clearly a bug.
Post by Uwe Schindler
There is a test page about exactly that case, which fails for me when
resolving through dnsmasq: http://0skar.cz/dns/en/
Post by Uwe Schindler
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
I just tried that page using dnsmasq276test2 and got 'green' for all tests.
Kevin
Kevin Darbyshire-Bryant
2016-01-04 16:19:06 UTC
Permalink
Post by Uwe Schindler
Hi,
Was there a change in dnsmasq related to this? Would be good to get some feedback. I'll try this version now. Currently I am running 2.75 (Debian testing pkg 2.75-1)
Yes. BIG changes. See the git log:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary

In fact I see I am far behind the times - test3 out 12 minutes ago :-)
Post by Uwe Schindler
Do you have dnssec enabled?
Yes.

Kevin
Uwe Schindler
2016-01-04 16:40:49 UTC
Permalink
Hi,

Yeah, works. Just rebuilt debian package with "2.76test3" - all fine now.

It could be that this has fixed it:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=13480e8c2a0e170a5e070f82c46e6ae00c464a89
(although this talks about a wildcard pointing to a CNAME). Maybe Simon can inform us which commit fixed this issue.

Thanks for the quick reply!

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
-----Original Message-----
Sent: Monday, January 04, 2016 5:19 PM
Subject: Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work
with DNSSEC
Post by Uwe Schindler
Hi,
Was there a change in dnsmasq related to this? Would be good to get some
feedback. I'll try this version now. Currently I am running 2.75 (Debian testing
pkg 2.75-1)
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary
In fact I see I am far behind the times - test3 out 12 minutes ago :-)
Post by Uwe Schindler
Do you have dnssec enabled?
Yes.
Kevin
Simon Kelley
2016-01-04 15:54:58 UTC
Permalink
What release are you using, Uwe.

I just tried the git-HEAD code, and pangaea.de is OK, both
issues.pangea.de, which is a genuine record, and simon.pangea.de which
is an expansion of the wildcard

;simon.pangaea.de. IN A

;; ANSWER SECTION:
simon.pangaea.de. 21599 IN A 134.1.2.171
simon.pangaea.de. 21599 IN RRSIG A 7 2 28800 20160109144508
20151226151023 12714 pangaea.de.
jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q
MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m
HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64=

;; AUTHORITY SECTION:
pangaea.de. 21599 IN NS ns2.domaindiscount24.net.
pangaea.de. 21599 IN NS ns3.domaindiscount24.net.
pangaea.de. 21599 IN NS ns1.domaindiscount24.net.
pangaea.de. 21599 IN RRSIG NS 7 2 28800 20160109071640 20151226151023
12714 pangaea.de.
l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p
O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql
maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g=
ram3pr4d5q9klnm2dsopmt3hjmua0mf6.pangaea.de. 3599 IN NSEC3 1 0 5
89D0BF16A5176B72 U1NCQMCLBNAMOFE2B186713NF2I82HUC CNAME RRSIG
ram3pr4d5q9klnm2dsopmt3hjmua0mf6.pangaea.de. 3599 IN RRSIG NSEC3 7 3
3600 20160111155643 20151228181431 12714 pangaea.de.
JuqEskBXSOC+3d+a2VPrlLlvQgMsiIa+duYpe/egYi4M9UdixtzDfYs2
qWJpDqlsO3lf5Eeeh2bbrZudnYmjQ9q4i8viPZO2j+nGdDCASFNUXzHb
B7ynmS1Ba3393TAiCoYbPKbf5HURNRDjR3T6m4dUriYPGJM7mc6Q7Cu+ MRM=


The 0skar.cz test domains have very long dates on the signature
expiration fields, which found a bug in that code. Having fixed that,
I can validate everything that Google DNS validates.

Cheers,

Simon.
Post by Uwe Schindler
Hi,
I found out that resolving of DNSSEC signed wildcard domains does
not work correctly with dnsmasq. I think the problem is that it
looks for a signature of the requested domain name and not the
wildcard.
$ dig issues.pangaea.de
; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> issues.pangaea.de ;; global
SERVFAIL, id: 59252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0,
AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;;
QUESTION SECTION: ;issues.pangaea.de. IN A
Mon Jan 04 15:43:42 CET 2016 ;; MSG SIZE rcvd: 46
The reason is: "issues.pangaea.de" is covered by a star domain
"*.pangaea.de" that is correctly signed (tested from another server
$ dig +dnssec *.pangaea.de
+cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 8436 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4,
ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;;
QUESTION SECTION: ;*.pangaea.de. IN A
;; ANSWER SECTION: *.pangaea.de. 28790 IN A
134.1.2.171 *.pangaea.de. 28790 IN RRSIG A 7 2
28800 20160109144508 20151226151023 12714 pangaea.de.
jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q
MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m
HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64=
;; AUTHORITY SECTION: pangaea.de. 28790 IN NS
ns2.domaindiscount24.net. pangaea.de. 28790 IN
NS ns3.domaindiscount24.net. pangaea.de. 28790
IN NS ns1.domaindiscount24.net. pangaea.de.
28790 IN RRSIG NS 7 2 28800 20160109071640 20151226151023
12714 pangaea.de.
l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p
O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql
maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g=
;; Query time: 0 msec ;; SERVER: 85.25.128.10#53(85.25.128.10) ;;
WHEN: Mon Jan 4 14:42:43 2016 ;; MSG SIZE rcvd: 471
How should this be solved? This is another one where dnssec fails, so clearly a bug.
There is a test page about exactly that case, which fails for me
when resolving through dnsmasq: http://0skar.cz/dns/en/
Uwe
----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Uwe Schindler
2016-01-04 17:32:15 UTC
Permalink
Hi,
Post by Simon Kelley
I just tried the git-HEAD code, and pangaea.de is OK, both
issues.pangea.de, which is a genuine record, and simon.pangea.de which
is an expansion of the wildcard
I changed issues.pangaea.de to a genuine record already (this is how I identified the issue). The test with simon.pangaea.de now also passes (test4), but this one is broken with 2.75.

Sorry for changing the DNS record after I submitted to this mailing list.
Post by Simon Kelley
;simon.pangaea.de. IN A
simon.pangaea.de. 21599 IN A 134.1.2.171
simon.pangaea.de. 21599 IN RRSIG A 7 2 28800 20160109144508
20151226151023 12714 pangaea.de.
jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q
MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m
HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64=
pangaea.de. 21599 IN NS ns2.domaindiscount24.net.
pangaea.de. 21599 IN NS ns3.domaindiscount24.net.
pangaea.de. 21599 IN NS ns1.domaindiscount24.net.
pangaea.de. 21599 IN RRSIG NS 7 2 28800 20160109071640
20151226151023
12714 pangaea.de.
l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p
O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql
maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g=
ram3pr4d5q9klnm2dsopmt3hjmua0mf6.pangaea.de. 3599 IN NSEC3 1 0 5
89D0BF16A5176B72 U1NCQMCLBNAMOFE2B186713NF2I82HUC CNAME
RRSIG
ram3pr4d5q9klnm2dsopmt3hjmua0mf6.pangaea.de. 3599 IN RRSIG NSEC3 7 3
3600 20160111155643 20151228181431 12714 pangaea.de.
JuqEskBXSOC+3d+a2VPrlLlvQgMsiIa+duYpe/egYi4M9UdixtzDfYs2
qWJpDqlsO3lf5Eeeh2bbrZudnYmjQ9q4i8viPZO2j+nGdDCASFNUXzHb
B7ynmS1Ba3393TAiCoYbPKbf5HURNRDjR3T6m4dUriYPGJM7mc6Q7Cu+
MRM=
The 0skar.cz test domains have very long dates on the signature
expiration fields, which found a bug in that code. Having fixed that,
I can validate everything that Google DNS validates.
Cheers,
Simon.
Post by Uwe Schindler
Hi,
I found out that resolving of DNSSEC signed wildcard domains does
not work correctly with dnsmasq. I think the problem is that it
looks for a signature of the requested domain name and not the
wildcard.
$ dig issues.pangaea.de
; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> issues.pangaea.de ;; global
SERVFAIL, id: 59252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0,
AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;;
QUESTION SECTION: ;issues.pangaea.de. IN A
Mon Jan 04 15:43:42 CET 2016 ;; MSG SIZE rcvd: 46
The reason is: "issues.pangaea.de" is covered by a star domain
"*.pangaea.de" that is correctly signed (tested from another server
$ dig +dnssec *.pangaea.de
+cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 8436 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4,
ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;;
QUESTION SECTION: ;*.pangaea.de. IN A
;; ANSWER SECTION: *.pangaea.de. 28790 IN A
134.1.2.171 *.pangaea.de. 28790 IN RRSIG A 7 2
28800 20160109144508 20151226151023 12714 pangaea.de.
jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q
MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m
HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64=
;; AUTHORITY SECTION: pangaea.de. 28790 IN NS
ns2.domaindiscount24.net. pangaea.de. 28790 IN
NS ns3.domaindiscount24.net. pangaea.de. 28790
IN NS ns1.domaindiscount24.net. pangaea.de.
28790 IN RRSIG NS 7 2 28800 20160109071640 20151226151023
12714 pangaea.de.
l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p
O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql
maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK
W+g=
Post by Uwe Schindler
;; Query time: 0 msec ;; SERVER: 85.25.128.10#53(85.25.128.10) ;;
WHEN: Mon Jan 4 14:42:43 2016 ;; MSG SIZE rcvd: 471
How should this be solved? This is another one where dnssec fails, so clearly a bug.
There is a test page about exactly that case, which fails for me
when resolving through dnsmasq: http://0skar.cz/dns/en/
Uwe
----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen
_______________________________________________ Dnsmasq-
discuss
Post by Uwe Schindler
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCAAGBQJWipXSAAoJEBXN2mrhkTWiKtAQAJ3P1xuzpuF6QUGbTQHE
rbJ/
ypClZDMNRWuVy0vCF8rQjZoR1xlJU5RMawUzeXmqHgfOg1v148vyZWwG/7E
CTfH+
zHziB7Fi0D+lo6fwXmFMMz7L0fXRmyK1YIvQ98+rJoSImV0H8eXJxyJzeh5+BQZ
G
FqzL25PntLLn3HetzwQddwdn6D3Ev4TbL5ECjSwoyFmRHz4U/T0hYq/+bAl2M3
Ip
16rGMHa0xD10SSlKI/ZEVRhGXZba/di4rskIp9MEuBmNftchmFtjndSvs4hLTYnq
OB3oMbCfLzNL7zN23rzXZRWkoTPKkEKffS0hvnpEZRXPvD2mZKHsxx0M7iG75
ZNE
cyg2vFiUVdv/vNNWEVenL6GTjLShv0zEwEJ6JhO89lF4PaCz7FEifldSw6YDVHnY
jhZ+IX/bSL3P4iWA1WvykaD7Edctq2gPkwjwljeNBOGHrdHWET3tDXopKzUkEH
cz
rH/UKFr+p4OVaKJsKdIbJFnIgr8bK+kNbXLHHI2sr0hUAOG40j+HQ+ZPYAJW1gk
W
3duZLds9fKIaQqy3Ria/4y2rtnS4BQmIoLXPD/BW4znNf5DBZAY11Cz5NIBheHAL
OEptaJpaIVQgKglbzIlVKDDHHyhC0TJDxr1H409yn4CMK1HC1wASgPLCsbLNR0X
d
u7aRdENLTmSfWXGDy3GS
=H7RO
-----END PGP SIGNATURE-----
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Simon Kelley
2016-01-04 17:40:48 UTC
Permalink
Hi,
That is fixed already (used 2.75 from debian, no bleeding edge)! I
tried test3 (now test4 because of spinning bug) and this one worked
correctly. The test page also passed: http://0skar.cz/dns/en/
Good, good.
Do you have an idea, which commit may have fixed it? I found one
(see other mail), but it talked about CNAME's which were not used
here.
The code in that commit is now gone, the post-2.75 re-write
drastically simplifies this code, and avoids all the special-case code
that was there before.

I'm slightly puzzled that http://0skar.cz/dns/en/ failed, since there
was a campaign to fix all the bugs that showed up before, and at one
time, last year, it would pass everything. Maybe the problem this time
was the very-long expiration times on some of the signatures. That bug
has been there forever, so the records must have changed since I last
tried it.

Cheers,

Simon.
Uwe
Loading...