Microsoft Windows Update over IPv6 (or not?)

Hello everyone,

I recently stumbled over a document from Microsoft which lists all services/applications that support IPv6. Most of the content wasn’t new for me, but one item caught my attention. Windows Update. I haven’t heard before that Windows Update can be done over IPv6 (but this could just be me not looking hard enough ;)), so I was eager to test it out seeing if this is really the case. I was also curious why Microsoft referenced this document in the respective column.

I installed a small lab consisting of a Windows 7 Enterprise x64, a Windows 8.1 Enterprise x64 and a Windows Server 2012 R2 machine all having a fully dual-stacked connection.

Actually, the Windows 7 was just the installation on my notebook which I use for my daily work. So I started with this one. I fired up Wireshark and began by clicking on “Check for Updates” on my machine, and was excited about the results.

In the first step my Windows 7 tries to resolve the DNS name download.windowsupdate.com. As my machine is running in a dual-stack environment, Windows 7 tries to resolve the A and the AAAA record for this name:

download.windowsupdate.com: type A, class IN
download.windowsupdate.com: type AAAA, class IN

After a couple of CNAME references we eventually got the IPv4 address of download.windowsupdate.com, which seems to be hosted on Akamai.

download.microsoft.com: type CNAME, class IN, cname download.windowsupdate.nsatc.net
download.windowsupdate.nsatc.net: type CNAME, class IN, cname main.dl.wu.akadns.net
main.dl.wu.akadns.net: type CNAME, class IN, cname intl.dl.wu.akadns.net
intl.dl.wu.akadns.net: type CNAME, class IN, cname dl.wu.ms.geo.akadns.net
dl.wu.ms.geo.akadns.net: type CNAME, class IN, cname a26.ms.akamai.net
a26.ms.akamai.net: type A, class IN, addr 82.96.58.65
a26.ms.akamai.net: type A, class IN, addr 82.96.58.41

Unfortunately, the AAAA query did not result in a successful answer, what a bummer!

download.microsoft.com: type CNAME, class IN, cname download.windowsupdate.nsatc.net
download.windowsupdate.nsatc.net: type CNAME, class IN, cname main.dl.wu.akadns.net
main.dl.wu.akadns.net: type CNAME, class IN, cname intl.dl.wu.akadns.net
intl.dl.wu.akadns.net: type CNAME, class IN, cname dl.wu.ms.geo.akadns.net
dl.wu.ms.geo.akadns.net: type CNAME, class IN, cname a26.ms.akamai.net

Interestingly, after the first resolution, Windows 7 tries to resolve the name ds.download.windowsupdate.com, where “ds” most likely stands for “dual-stack”.

ds.download.windowsupdate.com: type A, class IN
ds.download.windowsupdate.com: type AAAA, class IN

I should be right, as both (an A and an AAAA) records are available. Again, after a couple of CNAME references we eventually got the IPv4 and IPv6 addresses.

A record:

ds.download.windowsupdate.com: type CNAME, class IN, cname fg.ds.dl.windowsupdate.com.nsatc.net
fg.ds.dl.windowsupdate.com.nsatc.net: type CNAME, class IN, cname main-ds.dl.windowsupdate.com.nsatc.net
main-ds.dl.windowsupdate.com.nsatc.net: type CNAME, class IN, cname ds.download.windowsupdate.com.edgesuite.net
ds.download.windowsupdate.com.edgesuite.net: type CNAME, class IN, cname a767.dscd.akamai.net
a767.dscd.akamai.net: type A, class IN, addr 88.221.92.241
a767.dscd.akamai.net: type A, class IN, addr 88.221.93.41

AAAA record:

ds.download.windowsupdate.com: type CNAME, class IN, cname fg.ds.dl.windowsupdate.com.nsatc.net
fg.ds.dl.windowsupdate.com.nsatc.net: type CNAME, class IN, cname main-ds.dl.windowsupdate.com.nsatc.net
main-ds.dl.windowsupdate.com.nsatc.net: type CNAME, class IN, cname ds.download.windowsupdate.com.edgesuite.net
ds.download.windowsupdate.com.edgesuite.net: type CNAME, class IN, cname a767.dscd.akamai.net
a767.dscd.akamai.net: type AAAA, class IN, addr 2a02:8070:0:802::6dc1:c089
a767.dscd.akamai.net: type AAAA, class IN, addr 2a02:8070:0:802::6dc1:c08a

Bingo!

My client connected over HTTP to one of the IPv6 addresses and started the Windows Update magic (which consisted of several HTTP HEAD requests for specific .cab files). After some back and forth between my client and the server, Windows 7 tries to resolve the following DNS name:

update.microsoft.com

As it turns out, the above DNS name does not have an AAAA record as we can see from the answer below:

update.microsoft.com: type CNAME, class IN, cname update.microsoft.com.nsatc.net
update.microsoft.com.nsatc.net: type A, class IN, addr 157.56.77.158
update.microsoft.com.nsatc.net: type A, class IN, addr 157.56.67.216

The AAAA query resulted in the answer below:

update.microsoft.com: type CNAME, class IN, cname update.microsoft.com.nsatc.net
nsatc.net: type SOA, class IN, mname admin.nsatc.net

My client connects to one of the IPv4 addresses (obviously) over SSL, and is doing the update over the IPv4 connection. What a disappointment….

Conclusion:

While it seems that “some parts of Windows Update” are IPv6 enabled (for Windows 7 based machines), the actual download of updates is still taking place over IPv4 due to the lack of an AAAA record for update.microsoft.com. That’s at least what I could observe with my machine. It starts to make sense why Microsoft explicitly referenced the “IPv6 on Windows 8” blogpost in the applications/services document 😉

Well, after the first disappointment of the day, let’s see how Windows Update behaves under Windows 8.1 Enterprise.

The first difference to the update mechanism of Windows 7 is that Windows 8.1 and Windows Server 2012 are querying a different DNS name for the update procedure. Windows 8.1 queries the A and AAAA record for the DNS name fe2.update.microsoft.com.

fe2.update.microsoft.com: type A, class IN
fe2.update.microsoft.com: type AAAA, class IN

Fortunately, both queries were a success as can be seen from the output below:

fe2.update.microsoft.com: type CNAME, class IN, cname fe2.update.microsoft.com.akadns.net
fe2.update.microsoft.com.akadns.net: type A, class IN, addr 157.56.77.154

fe2.update.microsoft.com: type CNAME, class IN, cname fe2.update.microsoft.com.akadns.net
fe2.update.microsoft.com.akadns.net: type AAAA, class IN, addr 2a01:111:2004:4::c01

The Windows 8.1 client connects over SSL to the IPv6 address and from there on everything runs over IPv6. Awesome! At least in the Windows 8 space, Windows Update over IPv6 is working.

I was curious, in the Microsoft world you can choose two update “paths”. You can either choose to only receive updates for Windows (default configuration), or you can optionally configure to receive updates for other Microsoft products (installed on your machine) as well.  The above procedure applies to “only updates for Windows”. So I checked the box “Give me updates for other Microsoft Products when I update Windows” in the Windows Update configuration pane.

After the configuration was done I repeated the test to see whether there are any differences. Windows 8.1 tries to resolve another DNS name; sls.update.microsoft.com, as we see in the output below:

sls.update.microsoft.com: type AAAA, class IN
sls.update.microsoft.com: type A, class IN

Both records have an IP address associated with them, great!

sls.update.microsoft.com: type CNAME, class IN, cname sls.update.microsoft.com.akadns.net
sls.update.microsoft.com.akadns.net: type AAAA, class IN, addr 2a01:111:2010:3::cc01

sls.update.microsoft.com: type CNAME, class IN, cname sls.update.microsoft.com.akadns.net
sls.update.microsoft.com.akadns.net: type A, class IN, addr 157.55.240.220

Windows 8 then proceeds to connect to the IPv6 address (again over SSL) doing some update magic. After a couple of packets transmitted, Windows 8.1 proceeds to connect to ds.download.windowsupdates.com (which has an A and AAAA record as seen in the Windows 7 section) and downloads the updates to my client over IPv6. Great!

Conclusion:

Windows 8 can and will receive updates (for Windows and other Microsoft products) over IPv6 as soon as an IPv6 connection is available. Awesome! One step further down the road 😉

Final Conclusion:

While it is great that Microsoft has implemented IPv6 support for Windows/Microsoft Update in the Windows 8/Server 2012 world, pesonally I find it disappointing that it is not available for Windows 7. There are maybe reasons for this, but I fail to see them. Given that the infrastructure is available over IPv6, it shouldn’t be that hard to implement the same mechanism for Windows 7/Server 2012, but I can of course be wrong.

If you want to chat with us over IPv6 security topics or IPv6 in general, you can meet us this week at the Heise IPv6 Kongress. Hope to see you there!

I wish you all a nice week,

Chris