[dns-operations] sharepoint.com dnssec issues?

[Viktor Dukhovni]

> On Feb 13, 2017, at 9:14 PM, Theodore Baschak <theodore at ciscodude.net> wrote:
> 
> A college of mine asked if there was any issues that I was aware of with sharepoint.com and DNSSEC and I said I wasn't aware of any. Then I looked up his domain in question, and www.sharepoint.com and it seems like something is wrong there.
> 
> http://dnsviz.net/d/www.sharepoint.com/dnssec/

No DNSSEC issues, since both sharepoint.com and microsoft.com
are opted-out of DNSSEC at the ".com" zone.

That said, the domain is rather unusual, we see delegation NS
records from "com." to "sharepoint.com."

  $ dig +noall +ans +auth +nocl +nottl -t ns sharepoint.com @a.gtld-servers.net
  sharepoint.com.         NS      ns1.bdm.microsoftonline.com.
  sharepoint.com.         NS      ns2.bdm.microsoftonline.com.
  sharepoint.com.         NS      ns3.bdm.microsoftonline.com.
  sharepoint.com.         NS      ns4.bdm.microsoftonline.com.

However "sharepoint.com" is not your typical zone with SOA and matching
NS records at the zone apex.  Instead, the zone has a CNAME RR at the
apex:

   $ dig +norecur +noall +ans +auth +nocl +nottl -t a sharepoint.com @ns1.bdm.microsoftonline.com
   sharepoint.com.         CNAME   sharepoint.microsoft.com.

   $ dig +norecur +noall +ans +auth +nocl +nottl -t ns sharepoint.com @ns1.bdm.microsoftonline.com
   sharepoint.com.         CNAME   sharepoint.microsoft.com.

   $ dig +norecur +noall +ans +auth +nocl +nottl -t soa sharepoint.com @ns1.bdm.microsoftonline.com
   sharepoint.com.         CNAME   sharepoint.microsoft.com.

The target of this CNAME has no NS or SOA records:

   $ dig +norecur +noall +ans +auth +nocl +nottl -t ns sharepoint.microsoft.com @ns1.msft.net
   microsoft.com.          SOA     ns1.msft.net. msnhst.microsoft.com. 2017021308 7200 600 2419200 3600

   $ dig +norecur +noall +ans +auth +nocl +nottl -t soa sharepoint.microsoft.com @ns1.msft.net
   microsoft.com.          SOA     ns1.msft.net. msnhst.microsoft.com. 2017021308 7200 600 2419200 3600

Thus we have a delegation with no SOA or NS at the zone apex, and only the
non-authoritative NS records from "com" are available.  If this is valid, it
is certainly unusual enough to stress corner cases in resolver implementations.

One might also expect the same CNAME to be reported for all RRtypes, but instead:

   $ dig -4 +norecur +noall +ans +auth +nocl +nottl -t dnskey sharepoint.com @ns1.bdm.microsoftonline.com
   sharepoint.com.         NS      ns4.bdm.microsoftonline.com.
   sharepoint.com.         NS      ns1.bdm.microsoftonline.com.
   sharepoint.com.         NS      ns2.bdm.microsoftonline.com.
   sharepoint.com.         NS      ns3.bdm.microsoftonline.com.

or sometimes for the same nameserver (load-balancing different
implementations?):

   $ dig -4 +norecur +noall +comment +question +ans +auth +nocl +nottl -t dnskey sharepoint.com @ns1.bdm.microsoftonline.com
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10825
   ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags:; udp: 4000
   ;; QUESTION SECTION:
   ;sharepoint.com.                IN DNSKEY

A single owner domain is definitely not supposed to mix CNAME with other RRtypes.

There are likely additional anomalies...  There are also DNS anomalies at
mail.protection.outlook.com.  It seems that creative DNS implementations
are not unusual in Microsoft's cloud services...

-- 
	Viktor.