[Cerowrt-devel] test-ipv6.com vs dnssec

[Dave Taht]

jg tells me the test-ipv6.com site fails with dnssec and enabled on native ipv6.

disabling dnssec works.

anyone can confirm? get a log/packet capture?

[Jim Gettys]

More specifically, after boot, most of the time test-ipv6.com reports lots
of problems.

Then I turned off both dnssec and dnssec-check-unsigned, and restarted
dnsmasq; clean bill of health from test-ipv6.com.

Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a
clean bill of health.

Then I turned on both at the same time, and things are working.

So we seem to have a boot time race of some sort.
- Jim

Post by Dave Taht
jg tells me the test-ipv6.com site fails with dnssec and enabled on native ipv6.
disabling dnssec works.
anyone can confirm? get a log/packet capture?
--
Dave TÀht
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Simon Kelley]

Post by Jim Gettys
More specifically, after boot, most of the time test-ipv6.com reports lots
of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted
dnsmasq; clean bill of health from test-ipv6.com.
Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a
clean bill of health.
Then I turned on both at the same time, and things are working.
So we seem to have a boot time race of some sort.
- Jim

test-ipv6.com is unsigned, so the important thing which is likely
failing is the query for the DS record of test-ipv6.com, which should
return NSEC records providing it doesn't exist, signed by .com


Simon.

Post by Jim Gettys

Post by Dave Taht
jg tells me the test-ipv6.com site fails with dnssec and enabled on native ipv6.
disabling dnssec works.
anyone can confirm? get a log/packet capture?
--
Dave Täht
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[Török Edwin]

Post by Simon Kelley

Post by Jim Gettys
More specifically, after boot, most of the time test-ipv6.com reports lots
of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted
dnsmasq; clean bill of health from test-ipv6.com.
Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a
clean bill of health.
Then I turned on both at the same time, and things are working.
So we seem to have a boot time race of some sort.
- Jim

test-ipv6.com is unsigned, so the important thing which is likely
failing is the query for the DS record of test-ipv6.com, which should
return NSEC records providing it doesn't exist, signed by .com

According to http://dnssec-debugger.verisignlabs.com/test-ipv6.com
test-ipv6.com
No DS records found for test-ipv6.com in the com zone
Query to ns1.test-ipv6.com/216.218.228.118 for test-ipv6.com/DNSKEY timed out or failed
Query to ns2.test-ipv6.com/209.128.193.197 for test-ipv6.com/DNSKEY timed out or failed
Failed to get DNSKEY RR set for zone test-ipv6.com
No response from test-ipv6.com nameservers

Compare this to a domain that works with check-unsigned on:
openwrt.org
No DS records found for openwrt.org in the org zone
No DNSKEY records found
openwrt.org A RR has value 78.24.191.177
No RRSIGs found

Is the timeout/failed DNSKEY reply for test-ipv6.com the problem?

with dnssec-check-unsigned turned on (and no IPv6, just IPv4) I get this:
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[A] test-ipv6.com from 172.30.42.12
dnsmasq: forwarded test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DNSKEY] com to 213.154.124.1
dnsmasq: dnssec-query[DS] com to 213.154.124.1
dnsmasq: dnssec-query[DNSKEY] . to 213.154.124.1
dnsmasq: reply . is DNSKEY keytag 40926
dnsmasq: reply . is DNSKEY keytag 19036
dnsmasq: reply com is DS keytag 30909
dnsmasq: reply com is DNSKEY keytag 30909
dnsmasq: reply com is DNSKEY keytag 56657
dnsmasq: validation result is INSECURE
dnsmasq: reply test-ipv6.com is 216.218.228.119
dnsmasq: query[A] ipv4.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: query[AAAA] ipv4.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 213.154.124.1
dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS
dnsmasq: validation result is BOGUS
dnsmasq: reply ipv4.test-ipv6.com is 216.218.228.119
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 213.154.124.1
dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 213.154.124.1
dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 213.154.124.1
dnsmasq: query[A] ipv4.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: query[AAAA] ipv4.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: query[A] ipv6.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv6.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: query[AAAA] ipv6.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv6.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 193.231.252.1
dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS
dnsmasq: validation result is BOGUS
dnsmasq: reply ipv4.test-ipv6.com is 216.218.228.119
dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS
dnsmasq: validation result is BOGUS
dnsmasq: reply ipv4.test-ipv6.com is NODATA-IPv6

[Török Edwin]

Post by Török Edwin

Post by Simon Kelley

Post by Jim Gettys
More specifically, after boot, most of the time test-ipv6.com reports lots
of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted
dnsmasq; clean bill of health from test-ipv6.com.
Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a
clean bill of health.
Then I turned on both at the same time, and things are working.
So we seem to have a boot time race of some sort.
- Jim

test-ipv6.com is unsigned, so the important thing which is likely
failing is the query for the DS record of test-ipv6.com, which should
return NSEC records providing it doesn't exist, signed by .com

Also retrieving those signatures seems to work (from the LAN):
$ dig +dnssec -t DS test-ipv6.com

; <<>> DiG 9.9.5-3-Debian <<>> +dnssec -t DS test-ipv6.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47250
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;test-ipv6.com. IN DS

;; AUTHORITY SECTION:
com. 874 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1398455240 1800 900 604800 86400
com. 874 IN RRSIG SOA 8 1 900 20140502194720 20140425183720 56657 com. Em3k/33z2feLqtirerPNVE4HwF+ZstYVtR+J7rowCn/++FnDtRv7OBZp rbtNBI90BQj23QjzEkrwaBmVfcFOQSNhdAIHFxPSqOPCWbxdwQxf18yi 3ifhorL9mUX7ir2AqLb57LX+sPaFYOlAPQSIie4+nELiXZfH4mQ2cEXr eLY=
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 874 IN RRSIG NSEC3 8 2 86400 20140501044827 20140424033827 56657 com. JUeicIqLHJIYo10Z0M2LbKefhiW3g2T45jv0l0wxZC/8fdKLCBqIpk2k cjy1CSs1pzpR58BZM3E7QfVMZO61ncCOnK1Zarry6Z0ZYMm54sL625dl MMfYMhMpLVuzbBaK8TJmX3jvQWR8bxkoEXYUy3bP7+x88lHPK6wYkJlB VSA=
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 874 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
ERPPHPFQOHA3Q5F237FVRROKA4N73V2M.com. 874 IN RRSIG NSEC3 8 2 86400 20140501112409 20140424101409 56657 com. Zbz49pAXUE4iYhGmN3ywbWpWECc4fdBkT2HBwApFLr4UGDG67YbjtxhI D4ihlqTCKZES4/zFp4DqdA45/ha6m6nKUfo4/hE2y/ljhGbx08GqY3Ba cBWvBrfnmS1EGU8Yh1VG8tQ5CYK8qO6isUIzyGaV4Wpn4SQmTEAmaqfn FHk=
ERPPHPFQOHA3Q5F237FVRROKA4N73V2M.com. 874 IN NSEC3 1 1 0 - ERPT5A7MVN31GIUL5DMRAU0K8N2IGLTI NS DS RRSIG

;; Query time: 29 msec
;; SERVER: 172.30.42.1#53(172.30.42.1)
;; WHEN: Fri Apr 25 22:48:01 EEST 2014
;; MSG SIZE rcvd: 763

Post by Török Edwin
According to http://dnssec-debugger.verisignlabs.com/test-ipv6.com
test-ipv6.com
No DS records found for test-ipv6.com in the com zone
Query to ns1.test-ipv6.com/216.218.228.118 for test-ipv6.com/DNSKEY timed out or failed
Query to ns2.test-ipv6.com/209.128.193.197 for test-ipv6.com/DNSKEY timed out or failed
Failed to get DNSKEY RR set for zone test-ipv6.com
No response from test-ipv6.com nameservers
openwrt.org
No DS records found for openwrt.org in the org zone
No DNSKEY records found
openwrt.org A RR has value 78.24.191.177
No RRSIGs found
Is the timeout/failed DNSKEY reply for test-ipv6.com the problem?
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[A] test-ipv6.com from 172.30.42.12
dnsmasq: forwarded test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DNSKEY] com to 213.154.124.1
dnsmasq: dnssec-query[DS] com to 213.154.124.1
dnsmasq: dnssec-query[DNSKEY] . to 213.154.124.1
dnsmasq: reply . is DNSKEY keytag 40926
dnsmasq: reply . is DNSKEY keytag 19036
dnsmasq: reply com is DS keytag 30909
dnsmasq: reply com is DNSKEY keytag 30909
dnsmasq: reply com is DNSKEY keytag 56657
dnsmasq: validation result is INSECURE
dnsmasq: reply test-ipv6.com is 216.218.228.119
dnsmasq: query[A] ipv4.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: query[AAAA] ipv4.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 213.154.124.1
dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS
dnsmasq: validation result is BOGUS
dnsmasq: reply ipv4.test-ipv6.com is 216.218.228.119
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 213.154.124.1
dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 213.154.124.1
dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 213.154.124.1
dnsmasq: query[A] ipv4.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: query[AAAA] ipv4.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv4.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: query[A] ipv6.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv6.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv6.test-ipv6.com to 213.154.124.1
dnsmasq: query[AAAA] ipv6.test-ipv6.com.home.lan from 172.30.42.12
dnsmasq: config ipv6.test-ipv6.com.home.lan is NXDOMAIN
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: forwarded ipv4.test-ipv6.com to 213.154.124.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[AAAA] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: dnssec-query[DS] ipv4.test-ipv6.com to 193.231.252.1
dnsmasq: query[A] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: query[AAAA] ipv6.test-ipv6.com from 172.30.42.12
dnsmasq: forwarded ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: dnssec-query[DS] ipv6.test-ipv6.com to 193.231.252.1
dnsmasq: query[A] ipv4.test-ipv6.com from 172.30.42.12
dnsmasq: dnssec retry to 193.231.252.1
dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS
dnsmasq: validation result is BOGUS
dnsmasq: reply ipv4.test-ipv6.com is 216.218.228.119
dnsmasq: reply ipv4.test-ipv6.com is BOGUS DS
dnsmasq: validation result is BOGUS
dnsmasq: reply ipv4.test-ipv6.com is NODATA-IPv6
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Dave Taht]

Post by Simon Kelley

Post by Jim Gettys
More specifically, after boot, most of the time test-ipv6.com reports lots
of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted
dnsmasq; clean bill of health from test-ipv6.com.
Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a
clean bill of health.
Then I turned on both at the same time, and things are working.
So we seem to have a boot time race of some sort.
- Jim

test-ipv6.com is unsigned, so the important thing which is likely
failing is the query for the DS record of test-ipv6.com, which should
return NSEC records providing it doesn't exist, signed by .com

As one example of a registrar not with the program, name.com
(registrar for bufferbloat.net) does not allow for ds records to
come from it, so that domain can't be fully signed.

So it sounds to me as if negative proofs are not possible with
registrars that lack this support?

Post by Simon Kelley
Simon.

Post by Jim Gettys

Post by Dave Taht
jg tells me the test-ipv6.com site fails with dnssec and enabled on native ipv6.
disabling dnssec works.
anyone can confirm? get a log/packet capture?
--
Dave Täht
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[James Cloos]

DT> As one example of a registrar not with the program, name.com
DT> (registrar for bufferbloat.net) does not allow for ds records to
DT> come from it, so that domain can't be fully signed.

DT> So it sounds to me as if negative proofs are not possible with
DT> registrars that lack this support?

No. Signed parent zones (like com, net, org) always provide either a
signed DS record if it exists or proof of non-existance.

Try doing:

dig @i.gtld-servers.net. bufferbloat.net ds +dnssec

The two nsec3 records (each signed by an rrsig record) prove that there
is no DS record in net. with the name bufferbloat.net.

Compare that with what you get asking for ns records:

That replies with the two ns records, as well as the proof that the DS
records do not exist.

Now, try with a zone which is signed:

dig @i.gtld-servers.net. jhcloos.net ns +dnssec
dig @i.gtld-servers.net. jhcloos.net ds +dnssec

The first returns both the ns and ds records, with an rrsig over the ds
records (returned in the authority section); the latter returns the
signed ds records in the answer section and net's own signed ns set in
the authority section.

Given that some zones have nameservers which fail to respond if they do
not like or understand the query, it seems that only root-down verifi-
cation can work. Unless I'm missing something....

-JimC
--
James Cloos <***@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

[Török Edwin]

Post by James Cloos
DT> As one example of a registrar not with the program, name.com
DT> (registrar for bufferbloat.net) does not allow for ds records to
DT> come from it, so that domain can't be fully signed.
DT> So it sounds to me as if negative proofs are not possible with
DT> registrars that lack this support?
No. Signed parent zones (like com, net, org) always provide either a
signed DS record if it exists or proof of non-existance.
The two nsec3 records (each signed by an rrsig record) prove that there
is no DS record in net. with the name bufferbloat.net.
That replies with the two ns records, as well as the proof that the DS
records do not exist.
The first returns both the ns and ds records, with an rrsig over the ds
records (returned in the authority section); the latter returns the
signed ds records in the answer section and net's own signed ns set in
the authority section.
Given that some zones have nameservers which fail to respond if they do
not like or understand the query, it seems that only root-down verifi-
cation can work. Unless I'm missing something....

Given that a NS is more likely to get answered than a DS (by a nameserver
that is broken/doesn't support DNSSEC), can you make a NS query, and decide
based on the reply whether you should switch to a top-down verification?
i.e. if the NS answer included everything you wanted, then you're done,
otherwise, for broken nameserver, you fallback to verifying from the root that
they're indeed unsigned.
Does that make sense, or the NS reply doesn't have all the required info?

Best regards,
--Edwin

[James Cloos]

TE> or the NS reply doesn't have all the required info?

Replies to NS requests include DS records iff the requests are sent to
the parent of the zone, even when the requestor sets the DO bit. That
is to say, when the replies are glue records.

Everything is optimized for root->down verification.

-JimC
--
James Cloos <***@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

[James Cloos]

None of the posted examples which I've looked at have been dnssec signed.

There must be a bug in how dnsmasq tries to prove the non-existance of
the signatures.

Unbound, running on a box inside of a openwrt nat, has no problems with
any of them.

To confirm whether the bug is in dnsmasq or at goog, someone should run
their own verifying resolver (such as unbound) on a public box, open it
just enough for their cerowrt to use it, configure it to log verbosely,
and have their cero use it.

If that also leads to fails, then dnsmasq has the bug. Otherwise, goog
does something "interesting".

How much ram is available in cero for the resolver? Unbound on glibc/
amd64 only needs a bit less than 78M virt, 18M rss (with a well-stocked
cache). The other verifying resolvers probably need similar resources.

Even back when I used a dialup, unbound was perfectly usable inside¹.
The extra traffic from verifying from the roots down shouldn't hurt.

1] in its early days it could DoS, but that issue was fixed.

-JimC
--
James Cloos <***@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

[Török Edwin]

More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>.
So we seem to have a boot time race of some sort.

There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it).
When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show',
and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?).
It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same.
I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition?

Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health.

I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4.

Then I turned on both at the same time, and things are working.

With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below.



Best regards,
--Edwin

[Dave Taht]

We used to arbitrarily restart dnsmasq after boot with a script.
Perhaps doing a /etc/init.d/dnsmasq reload 60 sec after boo will show
something.

But I am puzzled as to not getting an ipv4 route. This hints at an
issue on the ubus.

I am trying to take a bit of vacation for the next week or so, it was
my hope everything was actually working...

... and even if it isn't, I need a break. Good Luck on this y'all,
I'll be back after a tan.


On Fri, Apr 25, 2014 at 12:24 PM, Török Edwin

Post by Török Edwin

More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>.
So we seem to have a boot time race of some sort.

There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it).
When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show',
and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?).
It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same.
I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition?

Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health.

I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4.

Then I turned on both at the same time, and things are working.

With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below.
Best regards,
--Edwin
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Sebastian Moeller]

Hi List, hi Dave,

so I had to restart cerowrt 3.10.36-6 today after coming home from a 5 day trip. I had some issues connecting with a macbook and one of 2 nexus 4s. after a reboot of the router both MacBooks connected fine on the 5GHz radio but none of the nexi connected to either the 2.4GHz nor the 5GHz radio, instead they produced endless repetitions of:
Sat Apr 26 21:27:15 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: disassociated
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: authenticated
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: associated (aid 1)
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 WPA: pairwise key handshake completed (RSN)
Sat Apr 26 21:27:30 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:33 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:35 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:39 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:47 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00

Following Dave's recommendation of issuing a "/etc/init.d/dnsmasq reload" allowed both phones to connect again, so we might still have a race hidden somewhere… (This is on a system without working ipv6 currently). 3.10.36-6 looks like it needs a bit more maturation time ;) It would be interesting to learn whether the same approach might help other people as well...

Best Regards
Sebastian

Post by Dave Taht
We used to arbitrarily restart dnsmasq after boot with a script.
Perhaps doing a /etc/init.d/dnsmasq reload 60 sec after boo will show
something.
But I am puzzled as to not getting an ipv4 route. This hints at an
issue on the ubus.
I am trying to take a bit of vacation for the next week or so, it was
my hope everything was actually working...
... and even if it isn't, I need a break. Good Luck on this y'all,
I'll be back after a tan.
On Fri, Apr 25, 2014 at 12:24 PM, Török Edwin

Post by Török Edwin

More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>.
So we seem to have a boot time race of some sort.

There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it).
When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show',
and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?).
It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same.
I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition?

Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health.

I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4.

Then I turned on both at the same time, and things are working.

With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below.
Best regards,
--Edwin
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Dave Taht]

Post by Sebastian Moeller
Hi List, hi Dave,
Sat Apr 26 21:27:15 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: disassociated
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: authenticated
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: associated (aid 1)
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 WPA: pairwise key handshake completed (RSN)
Sat Apr 26 21:27:30 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:33 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:35 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:39 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:47 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00

Well, somehow dnsmasq ran out of leases, or was unable to derive an
ip address range from the interface's
ifconfig. There are only a very few leases by default (28), and they
time out after a few hours, so a bunch of drive-by
dhcp requests could have run you out, but I'd suspect a bug unless
you have/had a large number of leases in
/tmp/dhcp.leases.

I have been fiddling with things, and (for example) changing wifi
parameters and doing a reload sometimes
loses the ip address on one or more wifi interfaces. (you get a
different error from dnsmasq in that case)

So I figure we have multiple race conditions right now causing
problems, in addition to some long term
bugs in wifi handling. Tighter integration of dnsmasq with the ubus
system would be good. A better grip
on how to exercise and debug ubus events would be good too.

Of possible relevance, this just landed in openwrt head:

https://dev.openwrt.org/changeset/40573

There are also some routing bugs fixed in 3.10.37

I have been running without setting a multicast_rate now for half a
day on 3.10.36-7

Post by Sebastian Moeller
Following Dave's recommendation of issuing a "/etc/init.d/dnsmasq reload" allowed both phones to connect again, so we might still have a race hidden somewhere… (This is on a system without working ipv6 currently). 3.10.36-6 looks like it needs a bit more maturation time ;) It would be interesting to learn whether the same approach might help other people as well...
Best Regards
Sebastian

Post by Dave Taht
We used to arbitrarily restart dnsmasq after boot with a script.
Perhaps doing a /etc/init.d/dnsmasq reload 60 sec after boo will show
something.
But I am puzzled as to not getting an ipv4 route. This hints at an
issue on the ubus.
I am trying to take a bit of vacation for the next week or so, it was
my hope everything was actually working...
... and even if it isn't, I need a break. Good Luck on this y'all,
I'll be back after a tan.
On Fri, Apr 25, 2014 at 12:24 PM, Török Edwin

Post by Török Edwin

More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>.
So we seem to have a boot time race of some sort.

There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it).
When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show',
and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?).
It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same.
I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition?

Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health.

I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4.

Then I turned on both at the same time, and things are working.

With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below.
Best regards,
--Edwin
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Sebastian Moeller]

Hi Dave,

thanks for the information.

Post by Dave Taht

Post by Sebastian Moeller
Hi List, hi Dave,
Sat Apr 26 21:27:15 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: disassociated
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: authenticated
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 IEEE 802.11: associated (aid 1)
Sat Apr 26 21:27:29 2014 daemon.info hostapd: sw00: STA 10:68:3f:4b:0b:48 WPA: pairwise key handshake completed (RSN)
Sat Apr 26 21:27:30 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:33 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:35 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:39 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00
Sat Apr 26 21:27:47 2014 daemon.warn dnsmasq-dhcp[2560]: no address range available for DHCP request via sw00

Well, somehow dnsmasq ran out of leases, or was unable to derive an
ip address range from the interface's
ifconfig. There are only a very few leases by default (28), and they
time out after a few hours, so a bunch of drive-by
dhcp requests could have run you out, but I'd suspect a bug unless
you have/had a large number of leases in
/tmp/dhcp.leases.

Alas, I rebooted before checking that file (I should have saved the borked state somewhere, but was too eager to get internet access working again ;) ) I will monitor tis more closely on 3.10.38-1.

Best Regards
Sebastian

Post by Dave Taht
I have been fiddling with things, and (for example) changing wifi
parameters and doing a reload sometimes
loses the ip address on one or more wifi interfaces. (you get a
different error from dnsmasq in that case)
So I figure we have multiple race conditions right now causing
problems, in addition to some long term
bugs in wifi handling. Tighter integration of dnsmasq with the ubus
system would be good. A better grip
on how to exercise and debug ubus events would be good too.
https://dev.openwrt.org/changeset/40573
There are also some routing bugs fixed in 3.10.37
I have been running without setting a multicast_rate now for half a
day on 3.10.36-7

Post by Sebastian Moeller
Following Dave's recommendation of issuing a "/etc/init.d/dnsmasq reload" allowed both phones to connect again, so we might still have a race hidden somewhere… (This is on a system without working ipv6 currently). 3.10.36-6 looks like it needs a bit more maturation time ;) It would be interesting to learn whether the same approach might help other people as well...
Best Regards
Sebastian

Post by Dave Taht
We used to arbitrarily restart dnsmasq after boot with a script.
Perhaps doing a /etc/init.d/dnsmasq reload 60 sec after boo will show
something.
But I am puzzled as to not getting an ipv4 route. This hints at an
issue on the ubus.
I am trying to take a bit of vacation for the next week or so, it was
my hope everything was actually working...
... and even if it isn't, I need a break. Good Luck on this y'all,
I'll be back after a tan.
On Fri, Apr 25, 2014 at 12:24 PM, Török Edwin

Post by Török Edwin

More specifically, after boot, most of the time test-ipv6.com <http://test-ipv6.com> reports lots of problems.
Then I turned off both dnssec and dnssec-check-unsigned, and restarted dnsmasq; clean bill of health from test-ipv6.com <http://test-ipv6.com>.
So we seem to have a boot time race of some sort.

There is definitely something wrong when ipv6 is enabled (I just noticed that since my latest upgrade I forgot to enable it).
When I enable ipv6 for PPPoE, then IPv6 works in the sense I can ping6 stuff from the router ... except IPv4 is completely broken: there is no default route added according to 'ip route show',
and even if I add a default route machines from LAN still can't reach IPv4 (presumably firewall would need to be reloaded too?).
It doesn't seem to be dnssec related, as even if I turn both dnssec and dnssec-check-unsigned off the behaviour is still the same.
I haven't investigated more deeply whats wrong yet. Do you think it could be related to your race condition?

Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a clean bill of health.

I've been using this for a while, it gets me a 0/10 score, i.e. ipv4 works, ipv6 fails, dual stack works with ipv4.

Then I turned on both at the same time, and things are working.

With both on I get a 'n/a' as a result, saying that dual-stack lookups timed out, presumably because ipv6 is off see below.
Best regards,
--Edwin
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article