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

Discussion:

Kevin Darbyshire-Bryant

2016-09-09 14:24:34 UTC

Hi All,

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.
sharepoint.microsoft.com. 3346 IN A 64.4.6.100
sharepoint.microsoft.com. 3346 IN A 65.55.39.10

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 17 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 8.8.8.8
;; WHEN: Fri Sep 9 15:14:12 2016
;; MSG SIZE rcvd: 110

If I disable 'check unsigned' on the router's dnsmasq instance things
work ok.

Why does dnsmasq think bogus, but google think ok?

Kevin

/dev/rob0

2016-09-09 18:35:39 UTC

Permalink

Post by Kevin Darbyshire-Bryant
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
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45014
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; sharepoint.com. IN A
sharepoint.com. 20224 IN CNAME sharepoint.microsoft.com.

This is broken.

Post by Kevin Darbyshire-Bryant
sharepoint.microsoft.com. 3346 IN A 64.4.6.100
sharepoint.microsoft.com. 3346 IN A 65.55.39.10

snip

Post by Kevin Darbyshire-Bryant
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.

--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Simon Kelley

2016-09-09 20:09:14 UTC

Permalink

Post by /dev/rob0

This is broken.

Post by Kevin Darbyshire-Bryant
sharepoint.microsoft.com. 3346 IN A 64.4.6.100
sharepoint.microsoft.com. 3346 IN A 65.55.39.10

snip

Post by Kevin Darbyshire-Bryant
If I disable 'check unsigned' on the router's dnsmasq instance
things work ok.
Why does dnsmasq think bogus, but google think ok?

;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23615
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9
; EDNS: version: 0, flags: do; udp: 4096
;sharepoint.com. IN ANY
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.

Kevin Darbyshire-Bryant

2016-09-17 08:26:59 UTC

Permalink

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

Post by Simon Kelley

Post by /dev/rob0

This is broken.

Post by Kevin Darbyshire-Bryant
sharepoint.microsoft.com. 3346 IN A 64.4.6.100
sharepoint.microsoft.com. 3346 IN A 65.55.39.10

snip

Post by Kevin Darbyshire-Bryant
If I disable 'check unsigned' on the router's dnsmasq instance
things work ok.
Why does dnsmasq think bogus, but google think ok?

Agreed.
What actually trips dnsmasq is this.
; (1 server found)
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26376
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 512
;sharepoint.com. IN DS
sharepoint.com. 7513 IN CNAME sharepoint.microsoft.com.
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
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

--
Thanks,

***@Darbyshire-Bryant.me.uk
M: +44 7947 355344 H: +44 1256 478597