[Dnsmasq-discuss] DNSSEC check unsigned vs sharepoint.com

Simon Kelley simon at thekelleys.org.uk
Fri Sep 9 21:09:14 BST 2016


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.



More information about the Dnsmasq-discuss mailing list