(posted at 10:29AM GMT)
It feels like an age has passed since I last posted anything to my ever-so-neglected part of the Internet :-(
I have been quite busy sorting out some upgrades to our ADSL services with the hope that we should be providing some FTTC-based offerings in the very near future; enjoyed diagnosing an MTU issue with BT Wholesale concerning one of our uplinks, why oh why do suppliers state that our end must be able to support an MTU of 1600 and then proceed to configure their end with an MTU of 1500 (stock Ethernet setting) ?
Whenever we set up a link between our network and another, I always insist on providing them with a copy of our switchport/router interface config and requesting that they provide us with the same for their end.
It eases link setup/future troubleshooting plus it gives each admin some comfort that the other admin has set up their end correctly.
Apparently, BT Wholesale don't do this quoting that their config is 'confidential'.
How can making the hard-coded MTU, duplex and speed settings of an interface available to an admin whose network directly connects to said interface be a breach of 'confidentiality' ?
*shakes head in disbelief*
In other news, I spent a pleasant morning in sunny Amsterdam on Monday in the offices of the RIPE NCC
discussing a variety of DNS-related things with the resident DNS Services Manager and the hardened IT Manager (who has been doing the job for sixteen years and looks very well for it too!).
I always welcome the opportunity to talk 'shop' with folk outside of my own circle of colleagues/friends in the industry; especially when one of those has superuser access to k.root-servers.net
While I can't go into too much about what was discussed, I enjoyed my visit immensely and the subject matter which was covered but did manage to take the opportunity to see a few of the tourist attractions around the RIPE NCC offices with Dam Square
offering some lovely examples of Dutch architecture.
One of the topics which we covered was DNSSEC
continuous validation; essentially, the RIPE NCC had an issue
with zones being signed with already-expired signatures that turned out to be a software bug with their signers but would have been caught if they had been checking the signatures on zones prior to publication or were continually verifying the DNSSEC 'trustability' of their zones.
The reason I mention this here is that as DNSSEC is something which is being actively rolled out and the RIPE NCC folks have been doing DNSSEC since 2005, it seems prudent to point out that if this can happen to them, it can happen to anyone else and has spurred me into passing all signed zone data through ldns-verify-zone
prior to publication along with all of the other (in)sanity checks we have on our provisioning platform.
The main question though is, "How far should continuous validation really be taken ?":
- Check signatures are valid after zone has been signed but prior to publication ?
- Perform regular AXFRs of the zones in question and check the signatures/expiry times of each resource record ?
To me, the first option is acceptable but then again, our nameservers see in the regions of tens of queries per second whereas the parts of the in-addr.arpa tree which are delegated to the RIPE NCC will be seeing many many thousands of queries per second in relation to rDNS lookups... if we break DNSSEC on our nameservers, it might result in a single support ticket from our own monitoring boxes telling us to pull our fingers out and fix it plus maybe a couple from some of our more tech-savvy users.
If the same issue hits the RIPE NCC or any other TLD/popular domain, it has far worse consequences due to the dependency which the Internet has on the root and the in-addr.arpa tree.
The second option is more appealing for the RIPE NCC due to the fact that their DNS is more mission-critical than ours (ours is still mission-critical but if ours breaks, we don't have a large part of the Internet shouting at us to fix it) and it is easier to continually validate the small number of zones which the RIPE NCC hosts as opposed to us validating 25,000+ zones on a high-frequency basis.
Nevertheless, I am certain that DNSSEC will continue being a source of fun and games for us and the RIPE NCC alike :-P