[Cerowrt-devel] Had to disable dnssec today

[Aaron Wood]

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
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[dpreed]

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"  said:



Just too many sites aren't working correctly with dnsmasq and using Google's 
DNS servers.
- Bank of America ([http://sso-fi.bankofamerica.com] sso-fi.bankofamerica.com)
- Weather Underground ([http://cdnjs.cloudflare.com] cdnjs.cloudflare.com)
- Akamai ([http://e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net] 
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___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[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,  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"  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
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[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



On Apr 25, 2014, at 21:42 , Dave Taht  wrote:

> 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
>  wrote:
>> On 04/25/2014 09:01 PM, Jim Gettys wrote:
>>> 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 .
>>> 
>>> 
>>> 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
>> Cerowrt-devel@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
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

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

[Simon Kelley]

On 26/04/14 17:20, Aaron Wood wrote:
> 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.
> 


The result of the analysis of the akamai domain was that there's a
problem with the domain (ie it's an akamai problem) See the post in the
Cerowrt list by Evan Hunt for the origin of this conclusion.

There's a dnsmasq issue to the extent that dnsmasq uses a different
strategy for proving that a name should not be signed than other
nameservers (dnsmasq works bottom-up, the others can work top-down,
since they are recursive servers, not forwarders.) This means that
dnsmasq sees the akamai problem, whilst eg unbound happens not to. I
plan to see if dnsmasq can be modified to improve this.

I'm not sure of cloudflare has been looked at in detail, but my
impression was that it's the same as akamai.

> 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,  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).
>> 


Given it's less than a month since the first DNSSEC-capable dnsmasq
release, anything other than small market share would be fairly miraculous!

Cheers,

Simon.

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

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

[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.


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

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

[Dave Taht]

On Sat, Apr 26, 2014 at 12:44 PM, Simon Kelley  wrote:
> On 26/04/14 17:20, Aaron Wood wrote:
>> 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.
>>
>
>
> The result of the analysis of the akamai domain was that there's a
> problem with the domain (ie it's an akamai problem) See the post in the
> Cerowrt list by Evan Hunt for the origin of this conclusion.
>
> There's a dnsmasq issue to the extent that dnsmasq uses a different
> strategy for proving that a name should not be signed than other
> nameservers (dnsmasq works bottom-up, the others can work top-down,
> since they are recursive servers, not forwarders.) This means that
> dnsmasq sees the akamai problem, whilst eg unbound happens not to. I
> plan to see if dnsmasq can be modified to improve this.

If it's not a violation of the specification, the bottom-up method might
be good to add to a dnssec validation tool.

>
> I'm not sure of cloudflare has been looked at in detail, but my
> impression was that it's the same as akamai.
>
>> 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,  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).
>>>
>
>
> Given it's less than a month since the first DNSSEC-capable dnsmasq
> release, anything other than small market share would be fairly miraculous!
>
> Cheers,
>
> Simon.
>
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@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
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] looks like dhcpv4 has sprouted dhcp v4 support

[Dave Taht]

And it's not configured right.

(This may be an artifact of me trying hnetd out.)

Anyone else seen this?

# logread

Sun Apr 27 00:03:22 2014 daemon.warn odhcpd[22321]: DHCPv4 range out
of assigned network
Sun Apr 27 00:03:25 2014 daemon.warn odhcpd[22321]: DHCPv4 range out
of assigned network
Sun Apr 27 00:03:28 2014 daemon.warn odhcpd[22321]: DHCPv4 range out
of assigned network


-- 
Dave Täht

NSFW: 
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[Dave Taht]

On Sat, Apr 26, 2014 at 4:38 AM, Aaron Wood  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-devel@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
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel