Sysadmins told to update their software or risk killing the internet The world's internet providers and sysadmins need to make sure they are running up-to-date software or they risk cutting their customers off from the internet in October, DNS overseer ICANN has warned. Following a process that started back in May 2016, the cryptographic keys that secure the foundations of the domain name …
I wonder how much fun we can have with this within corporate change systems
Scope
External change - Internet reboot
(I know, but its more accurate than many changes I've seen go through)
Detail
Following the request from many users across multiple companies to "Reboot the Internet" when they can't get to their favourite cat pictures site, ICANN has decided to reboot the name servers that hold the Internet together for the first time in history, this will cause a rolling reboot of the whole Internet aligned to each time zone.
Risk
Everything breaks, the Internet won't work, Facebook will not work, outbreaks of work will occur.
Rollback
None - break out the paper and pencils and revert to the old ways of working
Demonstration of Pre-Prod testing
None - there is no Pre-prod Internet, it was de-scoped as it cost too much.
It's got to be worth a try ..
"At that point, anyone who doesn't use it will find themselves effectively cut off from the internet."
That's some exageration right there. DNS is not required for the internet to work. Sure stuff will break because of its reliance on DNS, but the whole of the internet? seriously? it will just cut you off? lol
You're wrong
"That's some exageration right there. DNS is not required for the internet to work. Sure stuff will break because of its reliance on DNS, but the whole of the internet? seriously? it will just cut you off? lol"
You'd be surprised* how few Internet services use hardcoded IP addresses. How load balancers rely on DNS. And web sites and email. And database connectors, monitoring, backups, host administration, logging, IDP, and cloud...everything. Yes, the Internet relies on DNS resolution.
*not many would be surprised, but clearly you would be.
Unless site is using multiple IP to serve same domain then entry in host file will allow access.
Those that do use multiple IP for same domain (load balancing) mostly still allow you to pick your own if required so hostfile will still work. If anyone can thinks otherwise post up the domain
I am all for encrypting DNS traffic but if the entities you do not wish to see that traffic get default access then truely what is the point
hmv - "It's not just DNSSEC for a domain that would break. It's any host resolution where DNSSEC verification is turned on"
I beg to differ that that is even an issue
https://dnssec-name-and-shame.com
Anonymous Coward - "Unless site is using multiple IP to serve same domain then entry in host file will allow access"
Are we talking about the Internet, ie the whole Internet, or are we talking about the WWW? Because the title says "Sysadmins told to update their software or risk killing the internet" and it only mentions the word web once.
jtaylor - "You'd be surprised* how few Internet services use hardcoded IP addresses. How load balancers rely on DNS. And web sites and email. And database connectors, monitoring, backups, host administration, logging, IDP, and cloud...everything. Yes, the Internet relies on DNS resolution."
Ok fair point, but, and I may be clutching at straws here, but would these "workarounds" that you just described be an issue with IPv6?
:p
Trivially simple. Ditch your old static trusted-key stanza for "." and add:
managed-keys {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
};
Do it now before the rollover window closes. You need 30 days of old ZSK signed new ZSK (read that carefully, the new ZSK is pre-published signed by the old one) for this to work.
I must confess I scrabbled around in my /etc/bind before finding I'd done it in 2013 :-)
I think this is the new key:
# This key (20326) is to be published in the root zone in 2017.
# Servers which were already using the old key (19036) should
# roll seamlessly to this new one via RFC 5011 rollover. Servers
# being set up for the first time can use the contents of this
# file as initializing keys; thereafter, the keys in the
# managed key database will be trusted and maintained
# automatically.
. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
Aye, but you don't want the new key in there yet if managed-keys is going to work its magic. Right now the new key is in the prepublication state, i.e. published but signed with the old KSK and not being used to sign the ZSK(s). You have until 11th September (a significant date I can only assume was chosen to make it extremely easy to remember) to get your managed-keys stanza into your config.
After this date, I suspect you'll have to manually intervene with the new key because the new ZSK won't have been published and signed, as far as your named is concerned, for the required 30 days but using managed-keys will future-proof the setup.
The article isn't quite clear to me - seems as if this is specific to DNSSEC ? if I just grep for the word key in my bind 9.8 config there are 0 matches(and I have never ever worked with DNSSEC - yes have run authoritative DNS since 1996(for personal stuff, company I work for uses dynect for external DNS hosting) as well as caching DNS for internal stuff)
I read an interesting(perhaps amusing?) post by someone earlier this year that talked about how bad DNSSEC(it went into quite a bit of technical detail why DNSSEC was basically worthless) was and to just not bother with it. Can't find the link at the moment, it was good. Not that I needed convincing to (not) use DNSSEC.
edit: I think this is the link:
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
The days when each server in the chain between you and the actual web site could be implicitly trusted to be who they say they are are long over.
In theory all ISP's have had plenty of time to prep for this.
In practice I expect it will show who are the clueful and who the lazy, greedy or merely stupid.
Just to put this in context.
Samples of the new £1 coins and £5 notes were avaible to companies involved in making and mainting coin operated devices for over 6 months (I'm sure I saw a quote from Royal Mint saying it was actually 18 months, but I can't find that).
100% were ready on day one weren't they?
The article is not completely accurate and almost reads as if DNS records are 'encrypted' by a new key that makes any use of the record impossible if the client does not have the new key. This is inaccurate. A reading of DNSSEC would have been a good idea.
DNSSEC sends out the standard DNS records, however there is an additional 'signing' portion, which is signed by the new asymmetric key. The actual record DNS is still in clear-text.
The only problem can occur when a DNS server caches or resolves requests as in a corporation. A problem occurs if the client machines in the corporation are expecting DNSSEC, but the corporate DNS server does not speak DNSSEC. If, on the other hand, the internal corporate client machines don't expect DNSSEC, there would not be a problem with DNS record look-ups. The only risk would be the potential spoofing of DNS records - which is the current case (and why DNSSEC was brought about). NOTE: It would be a good idea to do the update though.
NOTE: There is another scenario that would be of concern for a corporate DNS server. On an outward facing corporate DNS server sends records ie. for authoritive MTA, there would be a problem when the systems of other corporations are expecting DNSSEC on a MTA lookup, while the target corporation is not updated to talk DNSSEC. For the most part though, most corporations do not advertise/map/expose their internal hostname-address mapping outside of their internal subnet, except for machines on their Demilitarized zone.
I'm giving you an UpVote before the "DON'T USE GOOGLE DNS! ARE YOU EFFING *MAD*?!?" crowd arrives.
Those are really useful, and, as was pointed out above, it's (Not Bloody Difficult) easy to change DNS really fast, and for a short period of time.
I run my own DNS (my personal stuff, my company, the better-half's company, our client's companies, &c.), and we use DNSSec...but really:
1. Patch, patch, patch yer' crap. Just keep up on BIND and you're mostly home.
2. It's {severely edited for length and *cough* content} time those keys were changed.
3. If it all goes Pear, we can all take a holiday while ICANN(ot) and/or $ISP get their shit together (and wouldn't That be nice?).
I'd rather eat my own appendages than run BIND anywhere for any reason.
And what problem does DNSSEC solve exactly?
The endemic DNS spoofing problems of old are basically worked around since many years. And I'm assuming admins generally don't want to fiddle around physically at HSMs when making DNS changes, so the keys for most zones are likely to be accessible if you compromise the relevant servers/admin workstations.
I consider DNS to essentially be part of untrusted transport. We have fixed the whole issue of untrusted transport by applying cryptographic protocols on top of it.
Really, I don't want a frigging PKI in my DNS.
PS. I certainly don't need to change any keys in any resolver I admin. Though I will have a second look next week to make sure DNSSEC is actually disabled in the few that do support it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
