Dr. Jörg Schweiger of the German domain name registry DENIC posed an interesting question at this morning’s first DENOG meeting, in Frankfurt.
Would domain name users who are concerned about the accuracy of data served pay extra for the ability to sign their DNS zone ? A handful of people in the room raised their hand in agreement, but the overwhelming majority of operators did not.
His argument was that this compared well with SSL certification authorities who sell certificates that suggest that visitors to a website are interacting with a validated entity, and the technology guarantees privacy between the visitor and the website. It’s this technology which makes buying and selling online safe.
However, I think that DNSSEC has different aims altogether – simply to guarantee that DNS data is not changed en-route between the authoratative server, through the caches, all the way to users. Therefore there are significant attack mitigation reasons to deploy DNSSEC, so I hope that operators will begin trials (we are doing so), and that the pace of trials will quicken as the root zone will be signed this year.
If DNSSEC is deployed as designed, then temporary and brief mistakes will not be imported into DNS caches, users will not fall foul to tampered data in caches, and we all receive an authenticated/secure channel for distributing DNS data inside an organisation.
The argument that Dr. Schweiger used is that DNSSEC adds an operational and technical burden to registries (extra communication with registrars, more complex software, additional CPU and bandwidth requirements).
I hope that my colleagues in other organisations agree that there are significant infrastructure advantages to freely allowing DNSSEC to grow, and that Moore’s Law, automation, and the fact that DNS registries normally find it simple to peer widely with ISP networks will offset the needs to consider the commercial signing model.
I have a MySQL server which was starting to scrunch its data more and more slowly. Some analysis led me to blame an autoextending innodb file which had grown somewhat unkept to several GB. I wish the autoextend behaviour could be configured to grow more files rather than grow one file, but that’s another rant. I decided to clear it up which is a simple process :
I decided to create 500 data files of 100MB. When MySQL started, it ignored the config I had set in my.cnf and loaded the innodb defaults – 5MB log files and an ibdata file of 10MB which could autoextend.
It turns out that if the innodb_data_file_path line is too long then the innodb section is ignored and the defaults will prevail. I changed the plan to create 200 files of 250MB, which made for much smaller config, and the innodb settings loaded just fine.
If you want a perl one liner to generate the innodb_data_file_path, I used:
perl -e ‘$i=1; do { $padded = sprintf(“%03d”, $i); print “ibdata$padded:250M;”; $i++; } until ($i eq 200)’;
I have been trying to get a patch applied to Debian’s openssh-client packages since February which would fix a bug that prevents me from logging into Extreme switches via ssh:
trials:/usr/src/openssh-5.1p1# ssh hextreeme -l netadmin
Keyboard-interactive authentication
Enter password for netadmin:
channel 0: open failed: resource shortage: Channel open failed
The bug is described in Debian bug 495917, and it also prevents connection to some NetScreen firewalls. I have this bug with Debian 4 (openssh-client 4.3p2-9etch3) and Debian 5 (openssh-client 1:5.1p1-5).
If anyone else is experiencing the same bug and needs a quick fix, then you can download my Debian packages which replace openssh-client. You of course need to hold the packages if you don’t want them overwriting by a security fix.
By using this software you agree to hassle both the debian-ssh team and extreme to sort their stuff out!
Greetings from Philadelphia! I am presenting as part of the IPv6 at NANOG46 (click here for info of how to watch) at 9:30PM UK time today, or download the IPv6 for Enterprises presentation here, or see information about the other speakers here..
The messages are clear and simple. Working now to get ready for the IPv6 transition will be less expensive and lower risk than waiting for IPv4 starvation to hurt. I interviewed some key enterprises about their specific grumbles but the great news is that most are transitional and already people are working on fixing them.
There are a few policy suggestions pushing their way through the RIPE policy development process which discuss how the final remaining IPv4 addresses should be given to end users in the European region.
They all show that the effects of scarsity of IP addresses will be felt before the final few addresses become assigned to end users. All consumers of addresses will feel constrained, which means all businesses trading online, whether they are a traditional ISP, a growing e-commerce shop, or a datacentre/hosting firm. The policies under consideration are :
This also means that the effects of black market trading in address space will be seen before the ‘anticipated’ IPv4 dry date in 2011. There are no magic bullets, you (and your customers, suppliers, and partners) need deep pockets, decades worth of existing resources, or an ipv6 transition plan. The only sensible option is to plan your v6 deployment today.
Google recently announced that they’d done a front-to-back implementation of IPv6, using engineers’ spare time, in 18 months. Cue well over 100 comments on slashdot claiming that this goes to show how hard implementing any sort of v6 service is at all, given it takes a company known for hiring smart people as long as 18 months.
I decided to put the timetable to the test. On Wednesday at 2:30PM uk time, I applied for a /32. One hour later, we were allocated 2a02:c30::/32. I straight away assigned a /48 for our network infrastruture, and another for our production hosting lan, another for our development hosting lan. From these /48s, several /64s were reserved, one for router loopbacks, another for point to point links, more for individual hosting applications. An hour later, this was implemented on our network – routers had loopbacks, and a v6 IGP was up and running, and working. I filed a ticket with our upstreams, and the first announcement was turned up minutes later – check BGPlay for exact times. Around 2 hours after making our application to RIPE, we were participants on the IPv6 internet.
Now this is not a front-to-back implementation, but in just two hours we had something to hand over to our systems teams for testing and training. If you rely on the internet for your business, this is the stage you need to get to urgently. In fact, by close of play Wednesday, some of our simpler services were already running dual stack, and additionally we are now running Dual-stack for DNS – Nominet having the simplest method for adding ipv6 glue.
Full disclosure: In reality our v6 rollout started months ago, by monitoring advice on operational mailing lists, attending v6 seminars, and in fact we had been engaged in the rollout of ipv6 on several customer networks to date, so this rollout was not frightening for us.
We are now in the position that we can integrate IPv6 addressing as part of every configuration refresh or maintenance on our services, so that v6 is rolled out in a controlled, monitored, and careful manner. By moving now, we have bought ourselves time – a luxury, and firms waiting longer to start their v6 rollout will have a harder time, with the whole migration feeling like a ‘y2k bug’.
I’ve got a nasty dose of bashfail this morning. I had a bash one-liner which generated a list of strings. I needed to iterate over that list in xargs, but the command in xargs was itself a dirty multi-command one-liner :
crazy | stuff | xargs -i {} this {} | that {} (with this and that expanded by xargs, not the shell)
I solved it by generating the command in xargs using ‘echo’, and then passing that into the shell. Example :
crazy | stuff | xargs -i {} echo ” this {} | that {} ” | sh
Is this the cleanest way of doing it ? This works fine, but loses readability points !
At 3pm I’ll deliver this lightning talk to the LINX IPv6 Specialist Techical Workshop 2009 on IPv6 Tooling.
It covers :