Re: [Dnsmasq-discuss] DNSSEC and Mozilla domains not working

2016-07-14 Thread mmmfotografie 

On 14-7-2016 23:22, Simon Kelley wrote:

On 12/07/16 00:17, mmmfotografie wrote:

On 11-7-2016 23:08, Simon Kelley wrote:

I just tried all those domains using 2.76 and 8.8.8.8 upstream and all
behaved correctly. 194.109.9.99 won't talk to me, so I can't try that.

The upstream is clearly answering the direct question OK, but the
stalling of some of the DNSSEC queries needed to verify it. That could
be an upstream problem, or a problem with the authoritative servers for
the domain. ftp.mozilla.org is signed, but it's a CNAME to
cloudfront.org, so the DS from .org proving that cloudfront.org is not
signed is also required.

Are you still seeing the problem now, or has this resolved itself?

Cheers,

Simon.

Thanks Simon for your reply and testing. I have now tried with 8.8.8.8
and I have the same problem.

I see that the DNSSEC on firefox.com and mozilla.com are now disabled
and I don't get a "ad" on them when I use dig and the output of DNSmask
states INSECURE. So maybe Mozilla is now working around that problem.

mozilla.org will not resolve on 8.8.8.8 or 194.109.9.9  and the
ftp.mozilla goes indeed through Cloudfront bit is not secure.
.
.
.
I have been testing a few setting...a lot of settings and combinations
in the past hours and have now way to get a good response from DNSmasq.

I first use "/dig +dnssec +multi mozilla.org @127.0.0.1/" which seems to
have more patience in waiting for a response. DNSmasq seems to do only
one try when using dig and not three as with nslookup. DNSmasq is
thinking about four seconds and then give a valid response using dig.

dnsmasq: dnssec-query[DNSKEY] mozilla.org to 8.8.8.8
dnsmasq: reply mozilla.org is DNSKEY keytag 22205, algo 7
dnsmasq: reply mozilla.org is DNSKEY keytag 65337, algo 7
dnsmasq: reply mozilla.org is DNSKEY keytag 44421, algo 7
dnsmasq: reply mozilla.org is DNSKEY keytag 42422, algo 7
dnsmasq: validation result is SECURE
dnsmasq: reply mozilla.org is 63.245.215.20

So on my standard upstream server:
dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
dnsmasq: reply mozilla.org is DNSKEY keytag 65337, algo 7
dnsmasq: reply mozilla.org is DNSKEY keytag 22205, algo 7
dnsmasq: reply mozilla.org is DNSKEY keytag 44421, algo 7
dnsmasq: reply mozilla.org is DNSKEY keytag 42422, algo 7
dnsmasq: validation result is SECURE
dnsmasq: reply mozilla.org is 63.245.215.20

Now the information is in the cache and a next request is instant.

Also ftp.mozilla.org is instant now but insecure:

dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
dnsmasq: validation result is INSECURE
dnsmasq: reply ftp.mozilla.org is 
dnsmasq: reply d34chcsvb7ug62.cloudfront.net is 52.85.250.4
dnsmasq: query[] ftp.mozilla.org from 192.168.21.190
dnsmasq: cached ftp.mozilla.org is 
dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
dnsmasq: validation result is INSECURE
dnsmasq: reply ftp.mozilla.org is 

And if I don't use dig mozilla.org or ftp.mozilla.org before the
nslookup, it times out again:

dnsmasq: reply . is DNSKEY keytag 46551, algo 8
dnsmasq: reply . is DNSKEY keytag 19036, algo 8
dnsmasq: reply org is DS keytag 9795, algo 7, digest 1
dnsmasq: reply org is DS keytag 9795, algo 7, digest 2
dnsmasq: dnssec-query[DS] mozilla.org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq: reply org is DNSKEY keytag 3177, algo 7
dnsmasq: reply org is DNSKEY keytag 2097, algo 7
dnsmasq: reply org is DNSKEY keytag 9795, algo 7
dnsmasq: reply org is DNSKEY keytag 17883, algo 7
dnsmasq: reply mozilla.org is DS keytag 44421, algo 7, digest 1
dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
dnsmasq: query[] ftp.mozilla.org from 192.168.21.190
dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
dnsmasq: query[A] ftp.mozilla.org from 192.168.21.190
dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
dnsmasq: query[] ftp.mozilla.org from 192.168.21.190
dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99



So the problem seems to be that the reply to the query for DNSKEY on
mozilla.org is not being replied to in a reliable way.

One possibility is that the reply is quite large (886 bytes) and
probably larger than most DNS replies. It has been known for firewalls
to do crazy things like rejecting all DNS packets >512 bytes, so it's
worth exploring that a bit more.


What happens when you use dig to make the same query?

dig @8.8.8.8 dnskey mozilla.org
dig @194.109.9.99 dnskey mozilla.org


Cheers,

Simon.


Underneath you will find the outputs of the two dig requests:

; <<>> DiG 9.9.5-9+deb8u6-Raspbian <<>> @8.8.8.8 dnskey mozilla.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36160
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512

Re: [Dnsmasq-discuss] Strange replies for DNSSEC domains

2016-07-14 Thread Simon Kelley 
On 13/07/16 20:15, mmmfotografie wrote:
> Hi, I just had a problem when I wanted to visit a site and when I looked
> it up in the log-file I recognize a strange behavior, that I had before
> when I had wen I had the "DNSSEC/TLSA Validator" as plug-in of Firefox.
> It stopped completely browsing for a minute by becoming unresponsive.
> This was only when I used DNSmasq and direct upstream replies went
> without a hitch.
> 
> The bit of log underneath was without any plug-in so a plain request.
> You see that the domain name is split up in parts and it first returns
> the dot and then the org part.
> 
>>   forwarded www.raspberrypi.org to 194.109.9.99
>>   dnssec-query[DS] org to 194.109.9.99
>>   dnssec-query[DNSKEY] . to 194.109.9.99
>>   reply . is DNSKEY keytag 46551, algo 8
>>   reply . is DNSKEY keytag 19036, algo 8
>>   reply org is DS keytag 9795, algo 7, digest 1
>>   reply org is DS keytag 9795, algo 7, digest 2
>>   dnssec-query[DS] raspberrypi.org to 194.109.9.99
>>   dnssec-query[DNSKEY] org to 194.109.9.99
>>   reply org is DNSKEY keytag 3177, algo 7
>>   reply org is DNSKEY keytag 2097, algo 7
>>   reply org is DNSKEY keytag 17883, algo 7
>>   reply org is DNSKEY keytag 9795, algo 7
> This bit is directly underneath and to me this looks correct:
>>   reply raspberrypi.org is DS keytag 21912, algo 10, digest 2
>>   dnssec-query[DNSKEY] raspberrypi.org to 194.109.9.99
>>   reply raspberrypi.org is DNSKEY keytag 23657, algo 10
>>   reply raspberrypi.org is DNSKEY keytag 21912, algo 10
>>   reply raspberrypi.org is DNSKEY keytag 12500, algo 10
>>   validation result is SECURE
> Going to try the 8.8.8.8 with the plug-in and see if it can be
> replicated on a other nameserver.
> 

That's quite normal. Dnsmasq knows the public key for the root zone, and
it has to make queries for DS and DNSKEY records that extend the
chain-of-trust from the root to the domain that you asked for. Those
queries are generated by dnsmasq and logged as "dnssec-query".

Cheers,

Simon.

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


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

Re: [Dnsmasq-discuss] DNSSEC and Mozilla domains not working

2016-07-14 Thread Simon Kelley 
On 12/07/16 00:17, mmmfotografie wrote:
> On 11-7-2016 23:08, Simon Kelley wrote:
>> I just tried all those domains using 2.76 and 8.8.8.8 upstream and all
>> behaved correctly. 194.109.9.99 won't talk to me, so I can't try that.
>>
>> The upstream is clearly answering the direct question OK, but the
>> stalling of some of the DNSSEC queries needed to verify it. That could
>> be an upstream problem, or a problem with the authoritative servers for
>> the domain. ftp.mozilla.org is signed, but it's a CNAME to
>> cloudfront.org, so the DS from .org proving that cloudfront.org is not
>> signed is also required.
>>
>> Are you still seeing the problem now, or has this resolved itself?
>>
>> Cheers,
>>
>> Simon.
> 
> Thanks Simon for your reply and testing. I have now tried with 8.8.8.8
> and I have the same problem.
> 
> I see that the DNSSEC on firefox.com and mozilla.com are now disabled
> and I don't get a "ad" on them when I use dig and the output of DNSmask
> states INSECURE. So maybe Mozilla is now working around that problem.
> 
> mozilla.org will not resolve on 8.8.8.8 or 194.109.9.9  and the
> ftp.mozilla goes indeed through Cloudfront bit is not secure.
> .
> .
> .
> I have been testing a few setting...a lot of settings and combinations
> in the past hours and have now way to get a good response from DNSmasq.
> 
> I first use "/dig +dnssec +multi mozilla.org @127.0.0.1/" which seems to
> have more patience in waiting for a response. DNSmasq seems to do only
> one try when using dig and not three as with nslookup. DNSmasq is
> thinking about four seconds and then give a valid response using dig.
> 
> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 8.8.8.8
> dnsmasq: reply mozilla.org is DNSKEY keytag 22205, algo 7
> dnsmasq: reply mozilla.org is DNSKEY keytag 65337, algo 7
> dnsmasq: reply mozilla.org is DNSKEY keytag 44421, algo 7
> dnsmasq: reply mozilla.org is DNSKEY keytag 42422, algo 7
> dnsmasq: validation result is SECURE
> dnsmasq: reply mozilla.org is 63.245.215.20
> 
> So on my standard upstream server:
> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
> dnsmasq: reply mozilla.org is DNSKEY keytag 65337, algo 7
> dnsmasq: reply mozilla.org is DNSKEY keytag 22205, algo 7
> dnsmasq: reply mozilla.org is DNSKEY keytag 44421, algo 7
> dnsmasq: reply mozilla.org is DNSKEY keytag 42422, algo 7
> dnsmasq: validation result is SECURE
> dnsmasq: reply mozilla.org is 63.245.215.20
> 
> Now the information is in the cache and a next request is instant.
> 
> Also ftp.mozilla.org is instant now but insecure:
> 
> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
> dnsmasq: validation result is INSECURE
> dnsmasq: reply ftp.mozilla.org is 
> dnsmasq: reply d34chcsvb7ug62.cloudfront.net is 52.85.250.4
> dnsmasq: query[] ftp.mozilla.org from 192.168.21.190
> dnsmasq: cached ftp.mozilla.org is 
> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
> dnsmasq: validation result is INSECURE
> dnsmasq: reply ftp.mozilla.org is 
> 
> And if I don't use dig mozilla.org or ftp.mozilla.org before the
> nslookup, it times out again:
> 
> dnsmasq: reply . is DNSKEY keytag 46551, algo 8
> dnsmasq: reply . is DNSKEY keytag 19036, algo 8
> dnsmasq: reply org is DS keytag 9795, algo 7, digest 1
> dnsmasq: reply org is DS keytag 9795, algo 7, digest 2
> dnsmasq: dnssec-query[DS] mozilla.org to 194.109.9.99
> dnsmasq: dnssec-query[DNSKEY] org to 194.109.9.99
> dnsmasq: reply org is DNSKEY keytag 3177, algo 7
> dnsmasq: reply org is DNSKEY keytag 2097, algo 7
> dnsmasq: reply org is DNSKEY keytag 9795, algo 7
> dnsmasq: reply org is DNSKEY keytag 17883, algo 7
> dnsmasq: reply mozilla.org is DS keytag 44421, algo 7, digest 1
> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
> dnsmasq: query[] ftp.mozilla.org from 192.168.21.190
> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
> dnsmasq: query[A] ftp.mozilla.org from 192.168.21.190
> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
> dnsmasq: query[] ftp.mozilla.org from 192.168.21.190
> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
> 


So the problem seems to be that the reply to the query for DNSKEY on
mozilla.org is not being replied to in a reliable way.

One possibility is that the reply is quite large (886 bytes) and
probably larger than most DNS replies. It has been known for firewalls
to do crazy things like rejecting all DNS packets >512 bytes, so it's
worth exploring that a bit more.


What happens when you use dig to make the same query?

dig @8.8.8.8 dnskey mozilla.org
dig @194.109.9.99 dnskey mozilla.org


Cheers,

Simon.





signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk

Re: [Dnsmasq-discuss] dnsmasq to provide public DNS service

2016-07-14 Thread /dev/rob0 
On Thu, Jul 14, 2016 at 03:35:58PM +0200, Albert ARIBAUD wrote:
> Le Thu, 14 Jul 2016 00:21:20 + (UTC)
> T o n g  a écrit:
> 
> > After struggled for a few days, I finally decided that I should 
> > reply, to bring some closure on this. Thank you for all these 
> > days of your tireless help. However, my conclusion is still the 
> > same as my first post -- dnsmasq is unable to provide public DNS 
> > service -- It can be used as DNS server for local host, or local 
> > network, but just not for the general public. We've ruled out 
> > everything possible, and the only thing left is dnsmasq.
> 
> Your conclusion is wrong; the only thing you can conclude from your 
> trials is that dnsmasq will not operate properly in an environment 
> which does not conform to Internet standards -- and *that* is 
> hardly a surprise.

Agreed.  One simple way to test (and to disprove) Tong's conclusion 
is to try it with other software, BIND or unbound or pdns-recursor,
for example, and to see how those work.

> > I.e., if there is any probelm with my ISP or my hosting provider, I 
> > wouldn't have been able to start a working second SSH session
> > listening to port 53 (instead of 22). 
> 
> You are again not concluding properly. DNS requires *UDP* port 53 as
> well as *TCP* port 53. Your assumption that DNS somehow can do with
> *TCP* port 53 alone is unfounded and plain wrong.
> 
> > In other words, all else the same, swap in SSH to listen to port 53,
> > it works; swap in dnsmasq, and it fails. With all else the same,
> > dnsmasq is the only problem. 
> 
> This experiment only proves that *TCP* port 53 works between your 
> home and box, but that was apready proven by previous tests I 
> suggested. However, dnsmasq requires *UDP* port 53 -- and due to a 
> crippled access, you cannot use that UDP port, contrary to a 
> considerable quantity of other persons who daily prove that dnsmasq 
> can be used way beyond a LAN.

I'll agree that dnsmasq as an authoritative server to the Internet 
might not be insane, but dnsmasq as resolver for an ISP or larger 
network is not a good idea.  It's only forwarding queries, not
actually doing the recursion itself.

> > Thanks anyway for all your helps. 
> 
> You're welcome. :)

And a very good job on your part for trying to help.  Unfortunately 
this matter feels very much like an "XY" problem: "I want to do X, I 
think Y would do it for me, so I am asking how to do Y."  As is 
common in such cases, "Y" makes little sense.

If Tong should decide to bring this up again, I would strongly 
suggest asking about "X", the real goal.  
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

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

Re: [Dnsmasq-discuss] dnsmasq to provide public DNS service

2016-07-14 Thread Albert ARIBAUD 
Hi Tong,

Le Thu, 14 Jul 2016 00:21:20 + (UTC)
T o n g  a écrit:

> After struggled for a few days, I finally decided that I should
> reply, to bring some closure on this. Thank you for all these days of
> your tireless help. However, my conclusion is still the same as my
> first post -- dnsmasq is unable to provide public DNS service -- It
> can be used as DNS server for local host, or local network, but just
> not for the general public. We've ruled out everything possible, and
> the only thing left is dnsmasq. 

Your conclusion is wrong; the only thing you can conclude from your
trials is that dnsmasq will not operate properly in an environment
which does not conform to Internet standards -- and *that* is hardly a
surprise.

> I.e., if there is any probelm with my ISP or my hosting provider, I 
> wouldn't have been able to start a working second SSH session
> listening to port 53 (instead of 22). 

You are again not concluding properly. DNS requires *UDP* port 53 as
well as *TCP* port 53. Your assumption that DNS somehow can do with
*TCP* port 53 alone is unfounded and plain wrong.

> In other words, all else the same, swap in SSH to listen to port 53,
> it works; swap in dnsmasq, and it fails. With all else the same,
> dnsmasq is the only problem. 

This experiment only proves that *TCP* port 53 works between your home
and box, but that was apready proven by previous tests I suggested.
However, dnsmasq requires *UDP* port 53 -- and due to a crippled
access, you cannot use that UDP port, contrary to a considerable
quantity of other persons who daily prove that dnsmasq can be used way
beyond a LAN.

> Thanks anyway for all your helps. 

You're welcome. :)

Amicalement,
-- 
Albert.

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