September 2014 archive
Sep 10
TDYR #173 – Apple’s iPhone6 and AppleWatch: Some Initial Thoughts
Sep 10
Any Ideas For A Better Color Scheme For Our DNSSEC Deployment Maps?
Do any of you have any suggestions for a better palette of colors for us to use for our DNSSEC deployment maps? We generate them every Monday morning and send them out to a public mailing list (to which any of you are welcome to subscribe). Here is a recent global view (click/tap to see larger image):
My issue (and maybe this is just me) is that I’m not entirely fond of the colors used in the “early” stages of a TLD’s deployment. As we note on the deployment maps page, we track a TLD through five stages of DNSSEC deployment:
- Experimental – Internal experimentation announced or observed
- Announced – Public commitment to deploy
- Partial – Zone is signed but not in operation (no DS in root)
- DS in Root – Zone is signed and its DS has been published
- Operational – Accepting signed delegations and DS in root
The most important states are the final two when DNSSEC for the TLD is “working”. I like the existing green colors for those two states, although the “DS in Root” green is perhaps a bit brighter than I would want. The point is that we want to use green to show the “good” states of DNSSEC deployment – and over time we’d like to see the whole map go to that darker shade of green.
It is the first three states that bother me a bit. There is a progression between those three states as it often goes like this:
- Someone from a TLD says at a conference or on a mailing list that they are experimenting with DNSSEC. We can then flag them as “Experimental”.
- Perhaps next someone from that TLD issues a formal statement, publishes a blog post or these days sends out a tweet or posts another social media update saying that they are going to deploy DNSSEC. We can then flag them as “Announced”.
- Then at some point the TLD’s zone is actually signed with DNSSEC, but the DS key hasn’t been uploaded to the root. Now we can put them as “Partial” in the database.
In my ideal world I’d have some color progression that shows the movement along this path. The orange, yellow and blue we currently use don’t really show a progression. I’ve tried using different shades of yellow or orange but you also want it to be easy to determine what state a given TLD is in – and for that the current set of colors does work.
Anyway… if anyone has ideas I’d be open to hearing them. The software we’re using can set the colors to be any of the typical hex-encoded colors used in web pages. It can’t do shading or lines or anything like that, just colors.
Please feel free to leave suggestions here – or contact me directly at york@isoc.org. Thanks!
P.S. And if you would like to help get more domains signed with DNSSEC, please see our “Start Here” page to find resources targeted at your type of organization!
Sep 09
Watch ION Belfast Live TODAY To Learn About IPv6, DNSSEC, BGP and more
Want to learn the current state of IPv6 deployment? DNSSEC? Securing BGP and more? If so you can watch LIVE today our ION Belfast event at:
http://uknof.bogons.net/uknof29.html
Today’s ION agenda begins at 1:45 pm British Summer Time (UTC+1) and is packed with information about our topics. Sessions include:
- Two Years After World IPv6 Launch: Are We There Yet?
- Why Implement DNSSEC?
- IPv6 Success Stories – Network Operators Tell All!
- IETF Update
- Panel: Routing Around Catastrophe
- Securing BGP
There are an outstanding set of speakers and we’re very excited to hear their sessions and the conversations that will emerge out of them.
All the sessions will be streamed live and will be recorded for later posting on our Deploy360 YouTube channel.
Please join us as it should be a great event!
NOTE: As we mentioned yesterday, there are also what look to be some excellent sessions happening in the morning UK time as part of the UKNOF agenda. In particular, these two sessions should be of interest to those concerned about IPv6:
- 11:30 BST – What went wrong with IPv6?
- 12:00 BST – IPV6-only Data Centres: What happens when you turn off IPv4
They, too, will be webcast on the same live stream link and will be recorded for later viewing.
Again, it should be an outstanding day at the combined UKNOF / ION Belfast event – we do hope you will join us!
P.S. And if you are motivated to deploy these technologies such as IPv6 and DNSSEC, please visit our Start Here page to find resources to help you get started!
Sep 08
Watch ION Belfast / UKNOF Live Tuesday, Sept 9, for IPv6, DNSSEC, BGP Security and More (Featured Blog)
Sep 08
Yea! LinkedIn Joins Facebook And Google In Permanently Enabling IPv6
We were delighted to read today that LinkedIn has now permanently enabled IPv6 for their website. I proved it myself by visiting the LinkedIn site moments ago using a Google Chrome browser with the IPvFoo extension installed:
As my colleague Phil Roberts writes on the Internet Technology Matters blog:
As they say, “The transition to IPv6 is invisible for our members.” So if you’re a member who has looked at your LinkedIn profile today, you did this over IPv6 and probably weren’t aware. I’m also encouraged that in their trial run before the full launch, they saw about 3% of their members using IPv6 to reach them.
Given that I have native IPv6 in my home office, presumably my connections to LinkedIn from my various devices will now start to all be over IPv6… which is excellent for the growth of the Internet!
Personally, given how much I do with social media, I’m pleased because this now means that with one exception the major social networks I use will all work over IPv6:
- Google … both for Google+ and for YouTube
… which just leaves Twitter as the major social media laggard still stuck on legacy IPv4 (of the social networks I use).
When you consider that other major sites like Yahoo, Wikipedia, AOL, Netflix and thousands of other web sites are now available over IPv6, adding LinkedIn to those sites is a great addition.
Particularly when LinkedIn has a major focus right now of aiming to recruit people to publish content on their platform – this move means that all that new content will now be accessible to all the new networks that are coming online via IPv6.
Congratulations to Zaid Ali Kahn and the rest of the LinkedIn team that made this happen! As he notes in his post:
Rolling out IPv6 at scale was not a trivial task. Our IPv6 task force has worked for a year to ensure today’s smooth addition of IPv6 connectivity. We did many code changes and a series of production tests along the way, including a recent 42-hour global test where we saw approximately 3 percent of members visiting LinkedIn services via IPv6. The IPv6 task force was a collective effort of many talented individuals across engineering and operational teams.
Congrats! And we look forward to many other content providers and web sites joining the production version of the Internet running over IPv6!
If you want to get started with making the move to IPv6, please see our Start Here page to find resources most appropriate to your type of organization. If you operate a web site like LinkedIn, you may find our “IPv6 for content providers” page the easiest place to start. And please do let us know if you need more help!
Sep 08
FIR #772 – 9/8/14 – For Immediate Release
Sep 08
Watch UKNOF Today To Learn About IPv6, IXPs, Internet Connectivity
Want to learn about IPv6, Internet Exchange Points (IXPs) and some of the latest connectivity ideas in the United Kingdom? If so, you can watch the live webcast of UKNOF 29 starting today, September 8, 2014, at 13:30 British Summer Time (BST, which is UTC+1). The critical links to know are:
Today’s sessions are mainly focused on network operations and Internet connectivity and include:
- HEAnet’s Optical Backbone & School’s Connectivity
- Watery Wireless
- Options for Metro 100Gig
- Network Function Virtualisation, bringing virtualised network infrastructure into the cloud
- Broadcast editing and delivery over IP (from the BBC)
- LINX’s UK regional peering strategy
- An overview of BT’s network infrastructure in Ireland and Northern Ireland including connectivity to the the rest of the UK
- UKNOF Status Update
Tomorrow, Tuesday, September 9, 2014, the morning sessions include some that may be of interest to our readers and then the afternoon will be our ION Belfast event. Here’s the current UKNOF agenda going from 09:30-12:35 BST:
- Latest Internet Plague: Random Subdomain Attacks (about DNS security)
- Tales of the unexpected – handling unusual DNS client behaviour
- Using 100 Billion DNS Queries to Analyse the Name Collision Problem
- What went wrong with IPv6?
- IPv6-only Data Centres
- Introduction of UK IPv6 Council
In particular I would point your attention to the “What went wrong with IPv6?” talk at 11:30 BST by Dave Wilson from HEAnet. He recently gave a version of this talk at RIPE 68 and both the video and the slides from that talk are available. He asks some great questions and, I think, has some great ideas for we can advance IPv6 deployment – definitely worth listening to!
After a lunch break, our ION Belfast event will then begin with a packed agenda talking about IPv6, DNSSEC and securing BGP. That, too, will be webcast live for all to see!
All in all it will be two days of outstanding sessions talking about the Internet’s infrastructure and how we can make it work better, faster and more secure!
I hope you will join me in tuning in to watch!
Sep 05
New RFC 7344 – Aiming To Solve The DS Upload Issue in DNSSEC
How can we automate the communication between a DNS operator and a registrar when a DNSSEC key has changed?
I saw this issue very starkly myself the other week when I received 4 email messages from one of the DNS hosting operators I use telling me that new Key Signing Keys (KSKs) had been generated for four of my domains. Now, on one level this was good, in that they were automagically rolling the KSKs over without me having to do anything. However… they had no way to tell the registrars for those domains that a new DNSKEY record (and therefore a DS record) had been created. In other words:
The global chain of trust was now broken for those four domains.
Any DNS resolver performing DNSSEC validation would now find a broken chain of trust and would send back a SERVFAIL. People behind a DNSSEC-validating DNS server would not be able to reach my site.
Now, this happens for me because I use a different operator for my DNS servers than my registrar. If you think of the different players involved in the DNSSEC process, very often a registrar is also acting as a DNS hosting operator. In other words, when you register your domain with a registrar, they are also providing the DNS services for you. In that case the DNS hosting side of the company can communicate to the registrar side of the company that there is a new key and all can work well.
However, in my case the company providing DNS services for me is different from my registrar. I am paying a company for DNS hosting – but I could instead be hosting my own authoritative DNS servers. This might be common if I were an enterprise / business that operated my own data centers, for instance.
The key point here is that a registrar needs to pass a Delegation Signer (DS) record (or in some cases a DNSKEY record) up to the registry for the top-level domain (ex., .org, .com, .whatever). This needs to happen in order to have the “global chain of trust” work and to be sure that the DNSSEC signatures are not being falsified.
Within the DNSOP working group in the IETF we’ve been debating a number of proposals about how to fix this for quite some time. One of those proposals has now been issued as an Informational RFC 7344:
http://tools.ietf.org/html/rfc7344
Formally titled “Automating DNSSEC Delegation Trust Maintenance“, the RFC specifies the creation of two new DNS record types that you would use to signal to a parent zone (for example, a top-level domain registry) that you have a new DNSSEC record that the parent zone needs to retrieve. The two records are:
- CDS
- CDNSKEY
Typically you would probably use one or the other depending upon what your TLD registry requires, but both are specified within the RFC 7344.
The RFC goes into much greater detail, but in a nutshell it would work something like this:
- As the DNS operator of EXAMPLE.ORG, I would generate a new DNSKEY record (for the KSK).
- I would also generate a DS record and publish that as a CDS record.
- The parent zone, .ORG in this example, would notice that a new CDS record has been published.
- The .ORG registry would retrieve my CDS record and then publish it as a DS record for my zone.
- Once the DS record has been published I could then stop publishing the CDS record until the next time I made a change.
The global chain of trust would now be intact.
The key challenge of this approach is step #3 – how does the parent zone notice that a new CDS record has been published?
This is a critical point and one that was debated at some length. The primary thinking is that parent zones that want to use this type of approach would create some kind of “parental agent” that would poll zones periodically to see if there are new CDS records out there. RFC 7344 gets into this in section 6.1 and suggests that there could be both polling and pushing mechanisms developed. Such software is not yet out there, but now that the RFC is out it can certainly be developed.
In any event, this RFC 7344 is now out there providing one potential solution to this “DS upload” problem. What do you think? Is this something you can see implementing? Would you like to see your registries, registrars and DNS hosting operators supporting this approach? Do you have another idea?
P.S. Want to get started with DNSSEC? Please visit our “Start Here” page to find appropriate resources…
Sep 05
MarketingPodcasts.com Coming Soon From Jay Baer
Jay Baer is the force behind the site and said last month on Google+ only this:
Soon, I am launching MarketingPodcasts.com the search engine for podcasts about all things marketing and communications.
One of our key features will be podcast reviews (like Pitchfork, for you indie music geeks).
As readers probably know, I am a weekly contributor to the For Immediate Release (FIR) podcast that focuses on the intersection of social media and public relations, business and marketing. I am a huge fan of audio podcasting, and FIR is just one of the podcasts to which I contribute. I also enjoy listening to podcasts... and so I'll be intrigued to see what Jay surfaces through this new site.
Right now you can just provide your email address to be notified when the site goes live. We'll see, hopefully soon, what it is all about!
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- following me on App.net;
- subscribing to my email newsletter; or
- subscribing to the RSS feed.
