24 lines
3 KiB
Markdown
24 lines
3 KiB
Markdown
|
# Software Update Check via DNS
|
||
|
|
|
||
|
|
Steve Gibson (https://www.grc.com) has a very good idea for using DNS records for version checking on client software.
|
||
|
|
|
||
|
|
* TL;DR
|
||
|
|
* Make an A record for a subdomain unique to a project (`validrive.rel.grc.com`)
|
||
|
|
* Use the multicast block `239.0.0.0` so the resulting IP will never route
|
||
|
|
* Have 3 bytes for arbitrary version designation (eg. `0.0.1`, `0.0.2`, `3.5.13`)
|
||
|
|
* When software checks for update, resolve DNS for that subdomain
|
||
|
|
* Long cache life on record means update notifications are rolled out gradually over a period
|
||
|
|
* Could be an anti-feature if an update is critical, probably not the case for single-user tools/programs
|
||
|
|
* DNS query is simple, efficient, and anonymous
|
||
|
|
|
||
|
|
From [Security Now! #981](https://www.grc.com/sn/sn-981.htm):
|
||
|
|
|
||
|
|
> Okay. So Matt's correct about my use of DNS, and I am pleased with the way that capability has turned out. Anyone who has the ability to look up the IP address, for example, for validrive.rel.grc.com will find that it returns 239.0.0.1. This is because ValiDrive is still at its first release. When I've released an update to ValiDrive, it will be release number two, and I'll change the IP address of ValiDrive.rel, as in release, .grc.com to 239.0.0.2.
|
||
|
|
>
|
||
|
|
> Whenever an instance of ValiDrive is launched by any user anywhere in the world, it performs a quick DNS lookup of its own product name "validrive.rel.dns.com" and verifies that the release number returned in the lower byte of the IP address is not higher than its own current release number. If it is, it will notify its user that a newer release exists. What's convenient about this, I mean, there are many things about it, you know, there's no massive flood of queries coming in all over the Internet. It also provides all of its users the anonymity of making a DNS query, as opposed to coming back to GRC, so there's that, too. But this version checking is performed by a simple DNS query packet, and that DNS is distributed and caching.
|
||
|
|
>
|
||
|
|
> So it's possible to set a very long cache expiration to allow the cached knowledge of the most recent version of ValiDrive to be spread out across the Internet, varying widely with when each cache expires. This means that when the release number is incremented, the notifications of this event will also be widely distributed in time as those local caches expire. This prevents everyone on the Internet from coming back all at once to get the latest version. And, you know, typically it's not a matter of any urgency.
|
||
|
|
>
|
||
|
|
> And to Matt's question and point, I've never encountered a language that did not provide some relatively simple means for making a DNS query. I know that C# and .NET make this trivial. So anyway, that's the story on that.
|
||
|
|
>
|
||
|
|
> Oh, and I should mention that 239 is obviously a huge block of IPs which have been set aside. That's the high end of the multicast address space. But the 239 block specifically is non-routable. So those IPs will never and can never go anywhere. So that's why I chose 239 as the first byte of the IP in the DNS for my release management.
|