[Dnsmasq-discuss] DNSSEC check unsigned vs sharepoint.com
kevin at darbyshire-bryant.me.uk
Sat Sep 17 09:26:59 BST 2016
Thank you one & all for that.
I've tried to explain it to Microsoft....and....given up.
I just won't use 'Onedrive for Business' or 'sharepoint'.
On 09/09/2016 21:09, Simon Kelley wrote:
> On 09/09/16 19:35, /dev/rob0 wrote:
>> On Fri, Sep 09, 2016 at 03:24:34PM +0100, Kevin Darbyshire-Bryant wrote:
>>> Having some issues with my 'onedrive for business' application
>>> which in turn uses 'sharepoint.com'. Short version: dnsmasq 2.76
>>> thinks sharepoint.com is bogus. Directly querying upstream servers
>>> is okay:
>>> # drill -D @220.127.116.11 sharepoint.com
>>> ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45014
>>> ;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
>>> ;; QUESTION SECTION:
>>> ;; sharepoint.com. IN A
>>> ;; ANSWER SECTION:
>>> sharepoint.com. 20224 IN CNAME sharepoint.microsoft.com.
>> This is broken.
>>> sharepoint.microsoft.com. 3346 IN A 18.104.22.168
>>> sharepoint.microsoft.com. 3346 IN A 22.214.171.124
>>> If I disable 'check unsigned' on the router's dnsmasq instance
>>> things work ok.
>>> Why does dnsmasq think bogus, but google think ok?
>> $ dig sharepoint.com. any @f.gtld-servers.net. +norec +dnssec
>> ; <<>> DiG 9.10.3 <<>> sharepoint.com. any @f.gtld-servers.net. +norec +dnssec
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23615
>> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
>> ;; QUESTION SECTION:
>> ;sharepoint.com. IN ANY
>> ;; AUTHORITY SECTION:
>> sharepoint.com. 172800 IN NS ns1.bdm.microsoftonline.com.
>> sharepoint.com. 172800 IN NS ns2.bdm.microsoftonline.com.
>> sharepoint.com. 172800 IN NS ns3.bdm.microsoftonline.com.
>> sharepoint.com. 172800 IN NS ns4.bdm.microsoftonline.com.
>> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
>> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20160915044336 20160908033336 27452 com. xNERKmnAlkb3XiEf76OahP52D10WKZLu7GcWpYhVT4be0SBbmq9Kn+XV AnaMG/Ywu1/4VPyMfDxnw+XJLMXLn3NJN7TbNLA9Z0TqcpbRZcnTq1Na cO9/iuAx32Oaf5pbJIwuSS7HAhfDY4tahpYuSYDz8xOQzyf5W6wnjWAL sAc=
>> 3HGLO8KLU2RJ9G8IIOE1U9FPP77E8J3F.com. 86400 IN NSEC3 1 1 0 - 3HGMM5Q6EQANHO53VDJUCIMH8GVFL0BU NS DS RRSIG
>> 3HGLO8KLU2RJ9G8IIOE1U9FPP77E8J3F.com. 86400 IN RRSIG NSEC3 8 2 86400 20160915042007 20160908031007 27452 com. sVonxyL0/UgM+9KOG56hO1KezbbM8nzXaEDQYkfJISKVXy+P4m3vF1CX pO54bvTDo+msHBjNfNnjZ/4W7NnCutFTs0MNGXYZHOmXJE0B58KXW3Ui xsS8lzMlvGKvRuqwe3sHVi1K7TVz2BS96oxljuQ2LXpB+m0MX3eyMt5l zO8=
>> Microsoft has a broken implementation here. They have put a CNAME
>> where NS already exists. Some resolvers are fooled and will go along
>> with it, but apparently dnsmasq can't do that while checking DNSSEC.
>> If you are paying them, complain.
> What actually trips dnsmasq is this.
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @126.96.36.199 +dnssec ds sharepoint.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26376
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;sharepoint.com. IN DS
> ;; ANSWER SECTION:
> sharepoint.com. 7513 IN CNAME sharepoint.microsoft.com.
> ;; AUTHORITY SECTION:
> microsoft.com. 547 IN SOA ns1.msft.net. msnhst.microsoft.com.
> 2016090906 7200 600 2419200 3600
> ;; Query time: 60 msec
> ;; SERVER: 188.8.131.52#53(184.108.40.206)
> ;; WHEN: Fri Sep 09 20:59:46 BST 2016
> ;; MSG SIZE rcvd: 133
> The CNAME record overwrites the proof of non-existence of the DS record
> of sharepoint.com, so there's no way to prove that lack of signature of
> the A-record is OK. This is a direct result of the CNAME at the root of
> the sharepoint.com domain.
> The google recursive servers can sort this out, because they'll ask the
> authoritative servers for .com for the sharepoint.com DS record and not
> get the garbage from the sharepoint.com authoritative servers. Dnsmasq
> has no choice to do that and has to use what its upstream recursive
> server gives it.
> You could argue that the decision of the google servers to give the
> CNAME answer from the sharepoint.com auth servers, rather than the
> answer from the .com auth servers is wrong, but the root problem is
> misconfigured sharepoint.com domain.
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
Kevin at Darbyshire-Bryant.me.uk
M: +44 7947 355344 H: +44 1256 478597
More information about the Dnsmasq-discuss