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 @8.8.8.8 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       64.4.6.100
>>> sharepoint.microsoft.com.       3346    IN      A       65.55.39.10
>> snip
>>
>>> 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.
>>
> 
> Agreed.
> 
> What actually trips dnsmasq is this.
> 
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @8.8.8.8 +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: 8.8.8.8#53(8.8.8.8)
> ;; 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.
> 
> 
> Cheers,
> 
> Simon.
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


-- 
Thanks,

ke...@darbyshire-bryant.me.uk
M: +44 7947 355344 H: +44 1256 478597

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

Reply via email to