Re: [Dnsmasq-discuss] [Cerowrt-devel] Had to disable dnssec today

2014-04-26 Thread Aaron Wood
David,

With two of them (akamai and cloudflare), I _think_ it's a dnsmasq issue
with the DS records for proving insecure domains are insecure.  But Simon
Kelley would know that better than I.

With BofA, I'm nearly certain it's them, or an issue with one of their
partners (since the domain that fails isn't BofA, but something else):

(with dnssec turned off):

;; QUESTION SECTION:
;sso-fi.bankofamerica.com. IN A

;; ANSWER SECTION:
sso-fi.bankofamerica.com. 3599 IN CNAME saml-bac.onefiserv.com.
saml-bac.onefiserv.com. 299 IN CNAME saml-bac.gslb.onefiserv.com.
saml-bac.gslb.onefiserv.com. 119 IN A 208.235.248.157

And it's the saml-bac.gslb.onefiserv.com host that's failing (see here for
debug info):

http://dnssec-debugger.verisignlabs.com/sso-fi.bankofamerica.com

-Aaron


On Sat, Apr 26, 2014 at 6:00 PM, dpr...@reed.com wrote:

 Is this just a dnsmasq issue or is the DNSSEC mechanism broken at these
 sites?   If it is the latter, I can get attention from executives at some
 of these companies (Heartbleed has sensitized all kinds of companies to the
 need to strengthen security infrastructure).



 If the former, the change process is going to be more tricky, because
 dnsmasq is easily dismissed as too small a proportion of the market to
 care.  (wish it were not so).



 On Saturday, April 26, 2014 7:38am, Aaron Wood wood...@gmail.com said:

  Just too many sites aren't working correctly with dnsmasq and using
 Google's DNS servers.
 - Bank of America (sso-fi.bankofamerica.com)
 - Weather Underground (cdnjs.cloudflare.com)
 - Akamai (e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net)
 And I'm not getting any traction with reporting the errors to those sites,
 so it's frustrating in getting it properly fixed.
 While Akamai and cloudflare appear to be issues with their entries in
 google dns, or with dnsmasq's validation of them being insecure domains,
 the BofA issue appears to be an outright bad key.  And BofA isn't being
 helpful (just a continual we use ssl sort of quasi-automated response).
 So I'm disabling it for now, or rather, falling back to using my ISP's dns
 servers, which don't support DNSSEC at this time.  I'll be periodically
 turning it back on, but too much is broken (mainly due to the cdns) to be
 able to rely on it at this time.
 -Aaron

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


Re: [Dnsmasq-discuss] [Cerowrt-devel] Had to disable dnssec today

2014-04-26 Thread Simon Kelley
On 26/04/14 20:44, Simon Kelley wrote:
 I plan to see if dnsmasq can be modified to improve this.

In the git repo now, the change allows the akamai domain to resolve
successfully.


Simon.



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


Re: [Dnsmasq-discuss] [Cerowrt-devel] Had to disable dnssec today

2014-04-26 Thread Dave Taht
On Sat, Apr 26, 2014 at 4:38 AM, Aaron Wood wood...@gmail.com wrote:
 Just too many sites aren't working correctly with dnsmasq and using Google's
 DNS servers.

After 4 days of uptime, I too ended up with a wedged cerowrt 3.10.36-6 on wifi.

The symptoms
were dissimilar from what has been described here - I was seeing odhcpd
trying to and failing to answer requests on the wifi interfaces, which I'd never
seen in operation before (and could have been a self-induced failure by
fiddling with hnetd)

I have merged with openwrt head, which has some hostapd and routing fixes,
as well as dnsmasq head which has some dnssec lookup fixes...
and put out cerowrt-3.10.36-7. On first boot, it had problems getting anything
on wifi to do dhcp. A reboot later (with multicast 9000 also disabled),
a kindle that was failing to get online did. This box has also never got
upstream dns servers right from the isp. I'll fiddle with the multicast thing
later, to see if that or the reboot fixed it.

With this dnssec with dnssec-check-unsigned, once time is correct:

 - Bank of America (sso-fi.bankofamerica.com)

still fails. It ain't our fault it's broke.

 - Weather Underground (cdnjs.cloudflare.com)

succeeds.

 - Akamai (e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net)

succeeds.

 http://test-ipv6.com/

don't have ipv6 capability at this location, so this succeeds. I did see
it fail once on the first boot but haven't repeated it.


 And I'm not getting any traction with reporting the errors to those sites,
 so it's frustrating in getting it properly fixed.

There needs to be constant network wide scanning service of some kind
to detect dnssec configuration errors.


 While Akamai and cloudflare appear to be issues with their entries in google
 dns, or with dnsmasq's validation of them being insecure domains, the BofA
 issue appears to be an outright bad key.  And BofA isn't being helpful (just
 a continual we use ssl sort of quasi-automated response).

Cluebats are needed.

 So I'm disabling it for now, or rather, falling back to using my ISP's dns
 servers, which don't support DNSSEC at this time.  I'll be periodically
 turning it back on, but too much is broken (mainly due to the cdns) to be
 able to rely on it at this time.

don't blame you, but if we weren't beating it up, nobody would be.


 -Aaron



 ___
 Cerowrt-devel mailing list
 cerowrt-de...@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/cerowrt-devel




-- 
Dave Täht

NSFW: 
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

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